Ошибки компиляции C ++ в Unicode Release MinDependency, но не в Debug

Question

Позвольте мне начать с того, что я отвечаю за создание сборок и установок и управление ими, а не являюсь разработчиком на C ++, поэтому большинство приведенных ниже ошибок мне непонятно.

При этом разработчик (не сейчас) зарегистрировал некоторый код, который прекрасно компилируется в Debug | Win32 (с использованием VS08), но мне нужно, чтобы он компилировался в Unicode Release MinDependency | Win32.

Есть 88 ошибок, но все, кажется, сводятся к «конвертированию» проблем, и все это всего лишь несколько случаев из перечисленных ниже.

• Являются ли ошибки компиляции фундаментальными для того, как они были закодированы (C ++, ATL)?

• Есть ли какой-либо параметр опции компиляции или параметр VS, который я могу изменить, чтобы заставить его компилироваться как MinDep?

• Есть краткое объяснение того, что вызывает это, так что я понимаю проблемы под рукой?

Ошибка:

cannot convert from 'unsigned short *' to 'ATL::CComBSTR'
cannot convert from 'wchar_t *' to 'unsigned short *'
cannot convert parameter 1 from 'unsigned short *' to 'wchar_t *'
cannot convert parameter 1 from 'LPWSTR' to 'const unsigned short *'
cannot convert parameter 2 from 'BSTR' to 'const unsigned short *'
cannot convert parameter 2 from 'LPWSTR' to 'const unsigned short *'
none of the 2 overloads could convert all the argument types
cannot convert parameter 1 from 'unsigned short *' to 'const OLECHAR *'
cannot convert parameter 1 from 'unsigned short [4096]' to 'wchar_t *'

Answer 1

Проблема в том, что код был плохо написан. Разработчик сделал предположения о символах и целочисленных типах, которые не сохраняются при компиляции в Unicode. Проблема не в Visual C ++, ATL или Visual Studio.

Очевидно, что есть переключатель компилятора, который вы можете использовать для его компиляции, так как это, по-видимому, основное отличие между версиями Debug и Unicode Release Mindependency. Однако вы не хотите переключать его, поскольку это будет означать, что вы больше не выполняете фактическую сборку Mindependency выпуска Unicode.

Вы заметите, что каждое из ваших конверсионных сообщений находится между unsigned short * (указатель на определенный тип целого числа) и некоторым представлением строки. В правильно написанном C ++ вы не конвертируете между целочисленными и символьными типами повсюду. Это может быть необходимо, например, при работе с унаследованным кодом, но это является источником потенциальных проблем и требует внимательного наблюдения.

Вам нужно переписать этот код. Вы сказали, что разработчик не был рядом (возможно, уволен за то, чтобы делать подобные вещи), поэтому вам нужно будет найти другого разработчика, чтобы это исправить.

Answer 2

В Visual Studio IDE есть пара мест (предполагается, что в 2008 г.), где вы можете проверить наличие одинаковых настроек в сборках отладки и выпуска:

Свойства проекта -> Общие -> Набор символов (установлен на использование набора символов Юникод)

Свойства проекта -> C / C ++ -> Язык -> Обрабатывать wchar_t как встроенный тип (обычно установлен на Да)

Свойства проекта -> C / C ++ -> Командная строка - вы должны увидеть как UNICODE, так и _UNICODE

Если эти настройки одинаковы в обеих сборках - это может стать немного хуже, поскольку это может произойти из-за условной компиляции, и там все зависит от того, с какими конкретными библиотеками он работает или его кодом.

Вы можете прочитать здесь http://msdn.microsoft.com/en-us/library/xt153e2k(VS.71).aspx о том, что означает MinDependency. Это на самом деле определение для ATL о том, как связать с CRT.

Обратите внимание, что wchar_t определяется как unsigned short - так что в нем просто отсутствует определение - а не реальная ошибка преобразования, как сказано выше. У меня нет VC 6 для тестирования, но под VC9 это примерно так:

#ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#define _WCHAR_T_DEFINED
#endif

Answer 3

Все ошибки выглядят как строки. Кто-то, вероятно, включил / отключил юникод и / или широкие строки в режиме отладки в режиме выпуска. Попробуйте изменить эти настройки в настройках режима выпуска Visual Studio и посмотрите, скомпилируется ли он. Также можно проверить соответствие всех параметров между режимами выпуска и отладки.