Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
ㅌㄹ ㄱㅌ ; Помещаем в BX текущее значение регистра ES <───────┐
ㅈㅿ ; Загружаем младший байт регистра флагов в AH │
; │
ㅊㅋ ; В пару ES:DI кладем то, что сейчас находится в AX │
; |
ㄹㅅ ; Дважды увеличиваем значение регистра DI |
ㄹㅅ ; на одну единицу |
; │
ㅎㅋ ㅿㅈ ; Образуем бесконечный цикл >───────┘
Господа, ОНО вернулось. Следующая итерация всеми нами любимого и восхваляемого [имя, которое нель̸̗̠̘̘̪̳̩зя произносить]. Я б̞̫͔̜ы на вашем ме̤̣̺͇̫с̨͈те покинул стр̵а̻̘̪̙͎̳̕н̬̙̤̙̪̝̺͠ицу. С̫е̜й̱͎ч̦̦̝͔а̙͓͓с̛̩̞̘ ̫̹͙̲̤̖͉ж̶͉̻е҉̼̦.
> UB который работает и не дает варнингов! За это ли мы любим С++?
У тебя неправильный посыл.
Вся суть сишки и плюсцов в том, что компилятор имеет полное право считать, что НИКАКОГО UB В ПРОГРАММЕ НЕТ. Программист — царь, он сделал всё правильно, и исходя из этого компилятор может делать кучу оптимизаций. Поэтому когда компилятор видит твою строчку, он думает не "опа, УБ!", а "опа, господин позаботился о том, что в этом выражении нет УБ, как мне это оптимизнуть?".
> А вдруг c_str() иногда возвращает nullptr или статическую пустую строку
Ладно, статическая строка (даже непустая) - это понятно.
А вот nullptr - это реальность c_str или обобщение случая до произвольной функции?
Вроде бы указатель на питушню, в которой лежит один нулевой символ, т.к. по умолчанию пустая строка "".
Или у std::string в области значений есть не только "", но и NULL?
Я на днях почитал свежие посты и охренел от того, что "Инканус" слил пароль. Только потом сравнил ID.
Кстати, не сразу заметил, что там "_", поначалу думал, что "e" в "gray".
А как я докажу, что да или что нет?
В это можно только уверовать. А те, кто верит, что я не чья-то файка, об этом не спрашивают, им и доказательств не нужно.
> Он не знает что вернул c_str(). Может быть там копия strdup'нутая и всё ок...
А почему так?
c_str специально реализован так, чтобы у std::string с небольшой вероятностью вызывался strdup и текла память?
Или оптимизатор после всех преобразований уже код c_str очень слабо видит и не помнит, что там за функция была?
Ну откуда он знает, какая там семантика? Это весь класс надо изучать, чтобы разобраться что и когда он там аллоцирует и удаляет... Да и реализация может быть в другом модуле.
Я думал, компилятор стандартную библиотеку лучше знает. По крайней мере, на хабре в статьях про анализатор с единорогом что-то про стандартную библиотеку сишки писали.
Ну а строка - это же шаблонная питушня -- более открытая, чем другое.
Забавно, что при этом компиляторы умеют кидать ворнинг, если printf вызывается с константой в качестве формата, но при этом закорючки в формате не соответствуют типам остальных параметров. Т. е. printf компилятор знает, а чему-то более сложному его не научили.
The format attribute specifies that a function takes printf, scanf, strftime or strfmon style arguments that should be type-checked against a format string.
Я почему-то думал, что форматирование валют обычно велосипедят или используют монстроподобные библиотеки вроде ICU. В стандартной библиотеке даже апкейсу нельзя доверять (он может не сработать для некоторых языков).
> форматирование валют обычно
> даже апкейсу нельзя доверять
После слова ДАЖЕ идёт более сложная задача. В случае с валютами ведь нет проблем с кодировками, хуё-моё. Расставил пробелы и точку или запятую и всё. Апкейст-то похардовее будет.
Довольно сложно:)
В большинстве языков (java, ruby, python, за редким исключением и в C#) все объекты живут в куче, а программист работает с ними через указатель, и объекты удаляются под воздействием GC.
В С++ же это не так, и это порождает массу лулзов, непонятных программистам на других языках.
В частности в упомянутых ваше ЯПах в результате выражения "foo" + "bar" на куче появится String и будет жить пока он кому-нить нужен.
В С++ же он сразу же удалится.
Понятнее не стало. Одни согласные и даже одна устаревшая буква (ㅿ).
const char* buz = (std::string("foo") + std::string("bar")).c_str();
std::cout << buz;
Почему компилятор не ругается?
да.
> Почему компилятор не ругается?
Потому что проблема останова не разрешима. А вдруг c_str() иногда возвращает nullptr или статическую пустую строку, тогда никакого UB не будет.
Впрочем, может быть статические анализаторы типа PVS и знают.
Самое ужасное что это работает в VC++!
UB который работает и не дает варнингов! За это ли мы любим С++?
В дебаге или в релизе?
vs 2015
судя по ideone и gcc тоже съел
надо шланг проверить
зы: Лол!
в релизе не работает!
Теперь ты спокоен?
Теперь я думаю чому operator new возвращает указатель на void* а не на класс.
У тебя неправильный посыл.
Вся суть сишки и плюсцов в том, что компилятор имеет полное право считать, что НИКАКОГО UB В ПРОГРАММЕ НЕТ. Программист — царь, он сделал всё правильно, и исходя из этого компилятор может делать кучу оптимизаций. Поэтому когда компилятор видит твою строчку, он думает не "опа, УБ!", а "опа, господин позаботился о том, что в этом выражении нет УБ, как мне это оптимизнуть?".
Ладно, статическая строка (даже непустая) - это понятно.
А вот nullptr - это реальность c_str или обобщение случая до произвольной функции?
a.c_str() что вернет?
Или у std::string в области значений есть не только "", но и NULL?
а что тогда вернет string("")?тож самое?
Должен вернуть то же самое. По крайней мере, явно инициализируется пустой строкой, а не нулевым указателем.
Да. Не заметил, что они долгое время не появлялись, а тут в один вечер проснулись?
Кстати, не сразу заметил, что там "_", поначалу думал, что "e" в "gray".
В это можно только уверовать. А те, кто верит, что я не чья-то файка, об этом не спрашивают, им и доказательств не нужно.
На курятник?
> Почему компилятор не ругается
Он не знает что вернул c_str(). Может быть там копия strdup'нутая и всё ок...
>>Он не знает что вернул c_str()
🙁
А почему так?
c_str специально реализован так, чтобы у std::string с небольшой вероятностью вызывался strdup и текла память?
Или оптимизатор после всех преобразований уже код c_str очень слабо видит и не помнит, что там за функция была?
Ну а строка - это же шаблонная питушня -- более открытая, чем другое.
В общем, печально, что не знает.
Видимо, не только printf успел всех заебать...
> даже апкейсу нельзя доверять
После слова ДАЖЕ идёт более сложная задача. В случае с валютами ведь нет проблем с кодировками, хуё-моё. Расставил пробелы и точку или запятую и всё. Апкейст-то похардовее будет.
В большинстве языков (java, ruby, python, за редким исключением и в C#) все объекты живут в куче, а программист работает с ними через указатель, и объекты удаляются под воздействием GC.
В С++ же это не так, и это порождает массу лулзов, непонятных программистам на других языках.
В частности в упомянутых ваше ЯПах в результате выражения "foo" + "bar" на куче появится String и будет жить пока он кому-нить нужен.
В С++ же он сразу же удалится.