конкретная строка кода, выходящая с кодом 255 после изменения генерации кода - PullRequest
3 голосов
/ 20 ноября 2010

Что ж, я попытался скомпилировать небольшое тестовое приложение, над которым я работаю.

Итак, чтобы быть кратким и простым:

Когда я устанавливаю генерацию кода из "Многопоточной DLL" в«Многопоточный», чтобы избавиться от некоторых зависимостей, следующая строка кода приводит к сбою моего приложения (где оно обычно выполняется без каких-либо недостатков)

Сбой происходит, когда я хочу преобразовать короткий путь в длинный путь.как таковой:

LPCSTR tmp = reinterpret_cast<LPCSTR>(getenv("Temp"));
GetLongPathNameA(tmp,tempFolder,MAX_PATH);

Авария, в частности, происходит в первой строке:

LPCSTR tmp = reinterpret_cast<LPCSTR>(getenv("Temp"));

Итак, есть какие-нибудь идеи, почему это вдруг перестает работать, когда вы переключаете режим генерации кода?Спасибо!

РЕДАКТИРОВАТЬ:

После некоторого переписывания кода мне удалось обнаружить, что он конкретно зависает при выполнении

getenv("Temp");

очень и очень странно видеть, как это работает вдругой режим

Ответы [ 5 ]

1 голос
/ 12 января 2011

Вы должны проверить возвращаемое значение getenv (), прежде чем получить к нему доступ:

LPCSTR tmp = getenv("Temp");
if(tmp != NULL)
    // do something with tmp

Я предполагаю, что ваша программа не может прочитать переменную окружения, и обращение к полученному NULL-указателю приведет к сбоям программы.

Microsoft рекомендует вместо этого использовать getenv_s (), вот их пример MSDN, слегка измененный для вашей работы:

char *tmp;
size_t requiredSize;

getenv_s(&requiredSize, NULL, 0, "Temp");
tmp = (char *) malloc(requiredSize * sizeof(char));
if (tmp != NULL)
{
    getenv_s(&requiredSize, tmp, requiredSize, "Temp");
    if(tmp != NULL)
        // do something with tmp

    free(tmp);
}

Я бы лично порекомендовал переключиться на функцию WinAPI GetEnvironmentVariable (), вместо этого это даст вам более подробное сообщение об ошибке (используйте GetLastError () в случае сбоя функции), которое может помочь вам добраться до сути вашей проблемы (или исправить ее это с помощью одной из этих альтернатив).

1 голос
/ 20 ноября 2010

Убедитесь, что все проекты (и все файлы этих проектов) постоянно настроены на компиляцию и связывание с одной и той же версией библиотек времени выполнения, т. Е. Многопоточной статической, в вашем случае. Если вы смешаете эти параметры, компиляция и связанная программа будут иметь неопределенное поведение. Также убедитесь, что вы компилируете и ссылаетесь на правильные версии внешних библиотек (MFC и т. Д.). В некоторых случаях вам запрещено использовать определенные версии среды выполнения, например, если вы взаимодействуете с .Net, вы должны использовать многопоточную версию dll.

0 голосов
/ 25 ноября 2010

Вы не должны использовать reinterpret_cast, потому что это для объектов, которые наследуются или наследуются от других классов. Просто используйте static_cast для базовых типов или указатели на базовые типы.

0 голосов
/ 20 ноября 2010

Вы указали libcmt.lib и libcpmt.lib как зависимости в настройках компоновщика после переключения с динамического времени выполнения на статическое?Если нет, пожалуйста, попробуйте это.А затем сделать перестройку.

0 голосов
/ 20 ноября 2010

Попробуйте перестроить проект.Очистите его, убедитесь, что в выходной папке ничего не осталось, для правильной меры удалите также .ncb, затем соберите.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...