Здравствуйте, dilmah, Вы писали:

D>ни close ни flush не гарантируют запись.
D>fflush флашит буфера libc.
D>Для гарантии записи fsync

Задача: найти fsync для Visual Studio. Флаг FILE_FLAG_WRITE_THROUGH для CreateFile не предлагать.

ГВ>То есть? Ты хочешь сказать, что fclose не сбрасывает буферы перед закрытием потока?

fclose сбрасывает буферы libc.
Буферы ОС и буферы самого диска -- нет.

Здравствуйте, dilmah, Вы писали:

D>да не сбрасывает close ничего на диск (ну разве что в виндоуз какое-то спецповедение).

Есть ещё несколько промежуточных слоёв, на каждом из которых возможна буферизация.

Здравствуйте, ДимДимыч, Вы писали:

ДД>Если это обычный (релизный) malloc, то значения могут быть абсолютно любыми.
ДД>При использовании отладочных версий malloc может заполнять распределяемую память каким-нибудь фиксированным значением, например 0xDEADBEEF.

В консольных прогах нет мышей. Из-за этого от запуска к запуску мусор может не отличаться...

Здравствуйте, Erop, Вы писали:

E>В консольных прогах нет мышей. Из-за этого от запуска к запуску мусор может не отличаться...

Эммм. Не понял, какие мыши имеются ввиду

Здравствуйте, ДимДимыч, Вы писали:

ДД>Эммм. Не понял, какие мыши имеются ввиду

Компьютерные...

Здравствуйте, MasterZiv, Вы писали:

>> — Зачем необходимо закрывать файл?

MZ>Чтобы данные этого файла физически сохранились на диске. Если ты не закроешь
MZ>файл или не вызовиш для этого файла функцию flush(), запись файлов физически
MZ>на диск не гарантируется.
MZ>И по той же причине, что освобождать память -- файлы -- такой же ресурс, как
MZ>и память, кол-во файлов открытых в системе не бесконечно.

Добавлю. Не знаю как для Windows, но если в Linux этот файл — блокирующийся fifo, который служит для общения между двумя процессами, то не закрыв его вы можете подвесить процесс с другой стороны. А закрывая файл вы как бы говорите другому процессу "всем спасибо, все свободны".

Здравствуйте, Erop, Вы писали:

ДД>>Эммм. Не понял, какие мыши имеются ввиду

E>Компьютерные...

Тогда не ясно, какое отношение они имеют к распределению памяти.

Здравствуйте, ДимДимыч, Вы писали:

ДД>Тогда не ясно, какое отношение они имеют к распределению памяти.

А про какие ясно?..

Обычно в GUI-based приложении ловится куча каких-то асинхронных сообщений, в первую очередь мышинных, они все обрабатываются, при этом могут происходить аллокации, и состояние кучи обычно возмущается. А в консольном приложении обычно всё стабильно от пуска к пуску...

Здравствуйте, dilmah, Вы писали:


ГВ>>То есть? Ты хочешь сказать, что fclose не сбрасывает буферы перед закрытием потока?

D>fclose сбрасывает буферы libc.
D>Буферы ОС и буферы самого диска -- нет.

Сбрасывает не сбрасывает, суть того о чём идёт речь в том, что после fclose по идее должен срабатывать некий механизм завершения работы с файлом. В любой ОС

fopen
fwrite
fclose
fopen
fread

позволит прочитать из файла то, что в него было записано, а

fopen
fwrite
fread

не обязательно, потому что работа с файлом не была завершена.

Здравствуйте, Erop, Вы писали:

ДД>>Тогда не ясно, какое отношение они имеют к распределению памяти.
E>А про какие ясно?..

Мало ли, может какие ментальные мыши, которые память грызут

E>Обычно в GUI-based приложении ловится куча каких-то асинхронных сообщений, в первую очередь мышинных, они все обрабатываются, при этом могут происходить аллокации, и состояние кучи обычно возмущается. А в консольном приложении обычно всё стабильно от пуска к пуску...

Ну я бы не стал рассчитывать на такие эффекты. Очень уж специфичные должны быть условия, чтобы наличие обработчиков асинхронных событий детерминированно влияло на состояние динамически выделяемой памяти.

Здравствуйте, ДимДимыч, Вы писали:

ДД>Ну я бы не стал рассчитывать на такие эффекты. Очень уж специфичные должны быть условия, чтобы наличие обработчиков асинхронных событий детерминированно влияло на состояние динамически выделяемой памяти.

Тем не менее факт, при отладке проги с развитым GUI часто от запуска к запуску работа аллокаторов немного меняется. Из-за этого труднее воспроизводить ошибки, кстати...

Спасибо за ответы.

Надеюсь, что я вам ещё не надоел, потому что я хотел бы задать вам ещё неск. вопросов.

— Что означает array<System::String ^> ^args? С int argc, char* argv[] и int argc, char **argv вроде как разобрался (насколько я понял, первое значение отвечает за кол-во параметров, которое было передано приложению, второе — это массив символов, из которых состоят данные параметры). Правильно?

— Правильно ли я понял, что даже в том случае, если тип возвращаемого значения у функции main () присутствует, то писать return 0 вовсе необязательно? Компилятор выдаёт сообщение, однако программа запускается и завершается точно так же, как и с return 0. Это грубая ошибка или такое делать можно?

— Почему убрали возможность писать примерно такое:

int value (a, b) int a, b;
{
c = a + b;
return c;
}

Разве это не было бы удобным в функции, где много раз пришлось бы писать int value (double a, double b, double c, double d) вместо int value (a, b, c, d) double a, b, c, d или как?

— Как можно сделать проверку на то, что пользователь вводит в переменную, например, типа int — число или символ?

— Можно ли изменять адрес ячейки памяти для переменных, которые уже были объявлены в программе? Где вообще можно более подробно почитать про адреса ячеек памяти и какие интересные свойства у них есть?

Заранее благодарю за возможные ответы.

Здравствуйте, YourLastSong, Вы писали:

YLS>- Что означает array<System::String ^> ^args?

Это C++/CLI, ^ — ссылка на managed-объект. Очень сильно Microsoft-specific. Читай про .Net.

YLS>С int argc, char* argv[] и int argc, char **argv вроде как разобрался (насколько я понял, первое значение отвечает за кол-во параметров, которое было передано приложению, второе — это массив символов, из которых состоят данные параметры). Правильно?

Да. Эти параметры означают ровно то же самое, что и в программе на C.

YLS>- Правильно ли я понял, что даже в том случае, если тип возвращаемого значения у функции main () присутствует, то писать return 0 вовсе необязательно? Компилятор выдаёт сообщение, однако программа запускается и завершается точно так же, как и с return 0. Это грубая ошибка или такое делать можно?

В принципе, так делать можно, но не нужно. Код, возвращаемый из main может анализироваться запускающим процессом. Посмотри, например, здесь.

YLS>- Почему убрали возможность писать примерно такое:

YLS>int value (a, b) int a, b;
YLS>{
YLS>c = a + b;
YLS>return c;
YLS>}

YLS>Разве это не было бы удобным в функции, где много раз пришлось бы писать int value (double a, double b, double c, double d) вместо int value (a, b, c, d) double a, b, c, d или как?

"Архаичный стиль" объявления параметров не поддерживается в C++. Особых страданий по этому поводу никто, вроде, не испытывает (это я об удобстве).

YLS>- Как можно сделать проверку на то, что пользователь вводит в переменную, например, типа int — число или символ?

А как ты бы сделал это на C? Остальные вопросы будут такими: как организован ввод данных и какова, вообще говоря, задача, которую ты решаешь?

YLS>- Можно ли изменять адрес ячейки памяти для переменных, которые уже были объявлены в программе?

Адрес объекта поменять нельзя. Но можно сделать копию объекта, которая будет размещена по адресу, отличному от адреса исходного объекта.

YLS>Где вообще можно более подробно почитать про адреса ячеек памяти и какие интересные свойства у них есть?

"Ячейки памяти" в C++ — это то же самое, что и "ячейки памяти" C. Соответственно, никаких новых свойств у них не появилось, указатели в C++ имеют тот же самый смысл, что и в C.

ГВ>А как ты бы сделал это на C? Остальные вопросы будут такими: как организован ввод данных и какова, вообще говоря, задача, которую ты решаешь?

Например, вот так:

int a;
cin >> a;
cout << a;
_getch ();

В данном случае пользователь может ввести абсолютно любое значение a, в том числе и символ. Как можно реализовать проверку и можно ли вообще?

Кстати, почему я так редко видел использование register перед указанием типа переменной, и почему вообще он не стоит изначально? Было бы ведь гораздо удобнее, я считаю, если бы он стоял у переменных изначально.

Здравствуйте, YourLastSong, Вы писали:

ГВ>>А как ты бы сделал это на C? Остальные вопросы будут такими: как организован ввод данных и какова, вообще говоря, задача, которую ты решаешь?

YLS>Например, вот так:

YLS>int a;
YLS>cin >> a;
if(cin)
  YLS>cout << a;
else
  cerr<<"Error";
YLS>_getch ();

YLS>В данном случае пользователь может ввести абсолютно любое значение a, в том числе и символ. Как можно реализовать проверку и можно ли вообще?

YLS>Кстати, почему я так редко видел использование register перед указанием типа переменной, и почему вообще он не стоит изначально? Было бы ведь гораздо удобнее, я считаю, если бы он стоял у переменных изначально.

Компиляторы гораздо умнее чем ты дуваешь... Он и так, имеет право поместить в регистры почти любую переменую.
Практика показывает, что бездумное использование register только мешает оптимизатору.

int a;
cin >> a;
if(cin)
cout << a;
else
cerr<<"Error";
_getch ();

В данном случае выдаётся ошибка "error C2678: binary '>>' : no operator found which takes a left-hand operand of type 'std::istream' (or there is no acceptable conversion)".

Здравствуйте, YourLastSong, Вы писали:

YLS>int a;
YLS>cin >> a;
YLS>if(cin)
YLS>cout << a;
YLS>else
YLS>cerr<<"Error";
YLS>_getch ();

YLS>В данном случае выдаётся ошибка "error C2678: binary '>>' : no operator found which takes a left-hand operand of type 'std::istream' (or there is no acceptable conversion)".

Берем шприц (cin), набираем в него крЭм (читаем значение из консоли например), и заполняем крЭмом пирожное (int a)...

А что проверяем то? if(шприц)? Дык это ж инструмент, и непростой, как там что проверять, да и зачем тебе это? if(a) было бы понятнее проверять, т.е. не равно ли случайно значение а нулю? А если надо проверить его "умещаемость" в заранее заданные пределы — то так и пишем if((крЭм > минимум) &&(крэм < максимум)) {пирожное заполнено нормально} else {варианты неправильного заполнения пирожного крЭмом}. Как-то так, чтоли

Здравствуйте, YourLastSong, Вы писали:

YLS>cin >> a;

YLS>В данном случае выдаётся ошибка "error C2678: binary '>>' : no operator found which takes a left-hand operand of type 'std::istream' (or there is no acceptable conversion)".

Ошибка как бы намекает, что кто-то забыл какой-то #include. Вероятнее всего — <istream>. И нет, <iostream> включить недостаточно.

Здравствуйте, Centaur, Вы писали:

C>Здравствуйте, YourLastSong, Вы писали:

YLS>>cin >> a;

YLS>>В данном случае выдаётся ошибка "error C2678: binary '>>' : no operator found which takes a left-hand operand of type 'std::istream' (or there is no acceptable conversion)".

C>Ошибка как бы намекает, что кто-то забыл какой-то #include. Вероятнее всего — <istream>. И нет, <iostream> включить недостаточно.

А не попытка приведения (cin) к boolean типу не срабатывает ли?