freopen_s («conout $») и fclose

Question

freopen_s («conout $») и fclose

0

Visual C++ сообщает, что недопустимый параметр был передан fclose, причем этот параметр является FILE* возвращаемым freopen_s:

#include <WinSock2.h>
#include <iostream>

int APIENTRY wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow) {
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(nCmdShow);

#ifdef _DEBUG
    AllocConsole();
#else
    AttachConsole(ATTACH_PARENT_PROCESS);
#endif

    FILE* pCout;
    freopen_s(&pCout, "conout$", "w", stdout); //returns 0

    fclose(pCout);

#ifdef _DEBUG
    system("pause");
#endif

    FreeConsole();

    return 0;
}

Должен ли я не пытаться закрыть conout $ в конце программы? Исключено ли исключение, поскольку указатель файла разделяется между процессами для всех консольных выходов?

NmdMystery 23 нояб. 2013, в 06:06

Источник

0

Нет репродукции с Visual C ++ 2013. Пожалуйста, предоставьте полную репродукцию, которая демонстрирует проблему. Что возвращает вызов freopen_s ? (Если вы собираетесь вызвать _s вариант, вам нужно проверить возвращенный статус.)
James McNellis 23 нояб. 2013, в 04:24
0

Возвращаемое значение errno_t равно 0, что означает отсутствие ошибки, верно?
NmdMystery 23 нояб. 2013, в 04:30
0

Кстати, это происходит только в режиме релиза, хотя функция возвращает 0 в обоих случаях.
NmdMystery 23 нояб. 2013, в 04:35
0

Учитывая результаты отчетов @JamesMcNellis, вам нужно опубликовать рабочий код для демонстрации проблемы.
Carey Gregory 23 нояб. 2013, в 04:47
0

@JamesMcNellis Я закомментировал весь код между freopen_s и fclose, и нет никакой разницы, так что только те функции вызывают проблему.
NmdMystery 23 нояб. 2013, в 04:48
0

Никаких репродукций с VS 2010 тоже. Ваша проблема лежит в другом месте. Вероятно, это файлы, которые вы включаете, параметры компилятора или что-то еще, что вы нам не показываете. Код как есть работает отлично.
Carey Gregory 23 нояб. 2013, в 04:55
0

@CareyGregory Обновленный код.
NmdMystery 23 нояб. 2013, в 04:59
0

Ничего себе, небольшое количество строк кода добавлено, но огромные изменения. Я принял на себя консольное приложение.
Carey Gregory 23 нояб. 2013, в 05:17
0

С вашим новым кодом freopen_s терпит неудачу, поэтому неудивительно, что fclose терпит неудачу. Вы создаете приложение как приложение Windows, но используете функции, которые предполагают консольное приложение. Я думаю, в этом твоя проблема.
Carey Gregory 23 нояб. 2013, в 05:28
0

@CareyGregory Тогда что мне использовать, чтобы открыть стандартный вывод? иначе std :: wcout не работает.
NmdMystery 23 нояб. 2013, в 05:45
0

«Кстати, это происходит только в режиме релиза». Вы вызываете AllocConsole() для отладочных сборок, но не для AllocConsole() сборок. В этом и заключается разница. Если консоли нет, то когда CRT вызывает CreateFile() для открытия conout$ , вызов завершится неудачно.
James McNellis 23 нояб. 2013, в 06:11
0

@JamesMcNellis А как насчет AttachConsole?
NmdMystery 23 нояб. 2013, в 06:14
0

Если у родительского процесса нет консоли, вызов AttachConsole() завершается неудачно, как объясняется в документации.
James McNellis 23 нояб. 2013, в 06:18
0

Также обратите внимание, что при сбое вызова freopen_s он не возвращает ноль, как вы сказали: он возвращает EBADF .
James McNellis 23 нояб. 2013, в 06:22

Показать ещё 12 комментариев

Теги:

c++

c

windows

freopen

1 ответ

Ещё вопросы

Нет репродукции с Visual C ++ 2013. Пожалуйста, предоставьте полную репродукцию, которая демонстрирует проблему. Что возвращает вызов freopen_s ? (Если вы собираетесь вызвать _s вариант, вам нужно проверить возвращенный статус.)
Возвращаемое значение errno_t равно 0, что означает отсутствие ошибки, верно?
Кстати, это происходит только в режиме релиза, хотя функция возвращает 0 в обоих случаях.
Учитывая результаты отчетов @JamesMcNellis, вам нужно опубликовать рабочий код для демонстрации проблемы.
@JamesMcNellis Я закомментировал весь код между freopen_s и fclose, и нет никакой разницы, так что только те функции вызывают проблему.
Никаких репродукций с VS 2010 тоже. Ваша проблема лежит в другом месте. Вероятно, это файлы, которые вы включаете, параметры компилятора или что-то еще, что вы нам не показываете. Код как есть работает отлично.
Ничего себе, небольшое количество строк кода добавлено, но огромные изменения. Я принял на себя консольное приложение.
С вашим новым кодом freopen_s терпит неудачу, поэтому неудивительно, что fclose терпит неудачу. Вы создаете приложение как приложение Windows, но используете функции, которые предполагают консольное приложение. Я думаю, в этом твоя проблема.
@CareyGregory Тогда что мне использовать, чтобы открыть стандартный вывод? иначе std :: wcout не работает.
«Кстати, это происходит только в режиме релиза». Вы вызываете AllocConsole() для отладочных сборок, но не для AllocConsole() сборок. В этом и заключается разница. Если консоли нет, то когда CRT вызывает CreateFile() для открытия conout$ , вызов завершится неудачно.
Если у родительского процесса нет консоли, вызов AttachConsole() завершается неудачно, как объясняется в документации.
Также обратите внимание, что при сбое вызова freopen_s он не возвращает ноль, как вы сказали: он возвращает EBADF .

James McNellis · Accepted Answer · 2013-11-23T04-00-00.000Z

Вызов fclose не работает, потому что вы передаете пустой FILE*. FILE* имеет значение null, поскольку вызов freopen_s завершается с ошибкой. Этот вызов завершается с ошибкой, потому что в процессе нет консоли, которую нужно открыть.

Ваша программа работает в отладочных сборках, потому что вы вызываете AllocConsole для выделения консоли для вашего процесса. Ваша программа не работает в сборках релизов, потому что вы не вызываете AllocConsole; вы вызываете AttachConsole, который не будет работать (и не имеет эффекта), если родительский процесс не имеет консоли.

+1 за хорошее суммирование всех комментариев и моего ответа в один сплоченный ответ. Я сделал ошибку, продолжив комментарии в ответ.
Ладно, упс. Это должно было быть очевидно с самого начала, но я проверял вывод из командной строки, где AllocConsole и freopen_s не работали, и отлаживал от VS без консоли, где AllocConsole и freopen_s терпели неудачу. Отладчик по-прежнему сообщал, что возвращаемое значение freopen_s равно 0, поэтому, возможно, оно было просто неточным.