Сообщение Re[2]: std::fopen падает в релизе с ошибкой 0xc0000417 от 04.02.2022 13:52
Изменено 04.02.2022 14:02 Alexander G
Re[2]: std::fopen падает в релизе с ошибкой 0xc0000417
Здравствуйте, Pzz, Вы писали:
Pzz>Ох. Вот по-этому я говорю, что программы на C++ имеют тенденцию без нужды аллоцировать память на куче мелкими кусочками. Но мне никто не верит. Можно ведь так, например, сделать:
Pzz>
А можно и не делать.
small string optimization хотя бы на три буквы, а то и на семь или больше — де факто стандарт.
И лишние аллокации выоптимизировать компиляторы учатся во всё большем числе случаев.
Завезли constexpr строки в C++20, возможно, скоро будут строки.
Сейчас они должны умереть на этапе компиляции, но это ограничение могут в будущем отменить, и тогда компиляторам придётся уметь делать глубокие оптимизации, т.к. всё равно пропагейтить аллокации нужно будет уметь.
Pzz>На вид все ОК. Наверное где-то протупил, но не таким очевидным образом. Например, fclose() два раза позвал, или как-то по-другому кучу разнес. fopen() не должен кидать исключений, аварийно завершать поток и т.п. ни при каких обстоятельствах.
Всё хуже https://rsdn.org/forum/cpp.applied/8187612.1
Pzz>Ох. Вот по-этому я говорю, что программы на C++ имеют тенденцию без нужды аллоцировать память на куче мелкими кусочками. Но мне никто не верит. Можно ведь так, например, сделать:
Pzz>
Pzz>{
Pzz> char mode[8] = "w";
Pzz> if (!appConfig.getOptOverwrite())
Pzz> strcat(mode, "x");
Pzz>}
Pzz>
А можно и не делать.
small string optimization хотя бы на три буквы, а то и на семь или больше — де факто стандарт.
И лишние аллокации выоптимизировать компиляторы учатся во всё большем числе случаев.
Завезли constexpr строки в C++20, возможно, скоро будут строки.
Сейчас они должны умереть на этапе компиляции, но это ограничение могут в будущем отменить, и тогда компиляторам придётся уметь делать глубокие оптимизации, т.к. всё равно пропагейтить аллокации нужно будет уметь.
Pzz>На вид все ОК. Наверное где-то протупил, но не таким очевидным образом. Например, fclose() два раза позвал, или как-то по-другому кучу разнес. fopen() не должен кидать исключений, аварийно завершать поток и т.п. ни при каких обстоятельствах.
Всё хуже https://rsdn.org/forum/cpp.applied/8187612.1
Автор: удусекшл
Дата: 04.02.22
Дата: 04.02.22
Re[2]: std::fopen падает в релизе с ошибкой 0xc0000417
Здравствуйте, Pzz, Вы писали:
Pzz>Ох. Вот по-этому я говорю, что программы на C++ имеют тенденцию без нужды аллоцировать память на куче мелкими кусочками. Но мне никто не верит. Можно ведь так, например, сделать:
Pzz>
А можно и не делать.
small string optimization хотя бы на три буквы, а то и на семь или больше — де факто стандарт.
И лишние аллокации выоптимизировать компиляторы учатся во всё большем числе случаев.
Завезли constexpr строки в C++20.
Сейчас они должны умереть на этапе компиляции, но это ограничение могут в будущем отменить, и тогда компиляторам придётся уметь делать глубокие оптимизации, т.к. всё равно пропагейтить аллокации нужно будет уметь.
Pzz>На вид все ОК. Наверное где-то протупил, но не таким очевидным образом. Например, fclose() два раза позвал, или как-то по-другому кучу разнес. fopen() не должен кидать исключений, аварийно завершать поток и т.п. ни при каких обстоятельствах.
Всё хуже https://rsdn.org/forum/cpp.applied/8187612.1
Pzz>Ох. Вот по-этому я говорю, что программы на C++ имеют тенденцию без нужды аллоцировать память на куче мелкими кусочками. Но мне никто не верит. Можно ведь так, например, сделать:
Pzz>
Pzz>{
Pzz> char mode[8] = "w";
Pzz> if (!appConfig.getOptOverwrite())
Pzz> strcat(mode, "x");
Pzz>}
Pzz>
А можно и не делать.
small string optimization хотя бы на три буквы, а то и на семь или больше — де факто стандарт.
И лишние аллокации выоптимизировать компиляторы учатся во всё большем числе случаев.
Завезли constexpr строки в C++20.
Сейчас они должны умереть на этапе компиляции, но это ограничение могут в будущем отменить, и тогда компиляторам придётся уметь делать глубокие оптимизации, т.к. всё равно пропагейтить аллокации нужно будет уметь.
Pzz>На вид все ОК. Наверное где-то протупил, но не таким очевидным образом. Например, fclose() два раза позвал, или как-то по-другому кучу разнес. fopen() не должен кидать исключений, аварийно завершать поток и т.п. ни при каких обстоятельствах.
Всё хуже https://rsdn.org/forum/cpp.applied/8187612.1
Автор: удусекшл
Дата: 04.02.22
Дата: 04.02.22