- 1
- 2
- 3
- 4
- 5
- 6
CharT getline(std::istream& i, string& s, const CharT* delim) {
...
if (!i.operator void*())
break;
...
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+2
CharT getline(std::istream& i, string& s, const CharT* delim) {
...
if (!i.operator void*())
break;
...
}
Библиотека Apache UIMA-CPP.
Что могло заставить написать так, вместо обычного if (i)? Какой-то древний компилятор, который не использует каст к указателю в условии?
Ну и, разумеется, в C++11 ios::operator void*() заменили на explicit ios::operator bool(), так что работать перестало.
А как тебе вызов деструктора по названию?
Кстати, а что будет, если потом сделать delete ptr?
new ничего нового не выделял, просто прокастовал указатель на buf и вызвал конструктор. По сути, new(buf) SomeClass - просто вызов конструктора на указанном куске памяти.
Даже так: освобождение через delete чего-то, что не вернуло new - UB.
очень может быть что на стеке
просто другого потока например
а как?
сколько в интеле всего, чем никто не пользуется
на интеле. на всех остальных процах, прога с валится с радостным сообщением о кривом выравнивании адреса. потому что по умолчанию strict alignment проверка включена на большинстве процов (даже арм уже дошёл до уровня имения этого флага).
Если бы валилось... На арме молча возвращалось "повёрнутое" слово.
В общем, копирование данных с адреса, не кратного машинному слову, может быть не реализовано в процессоре физически: просто схема не соберётся. Эмулировать ли это копирование, используя «микрооперации», или отвечать исключением — это дело процессора.
Ситуация осложняется также тем, что размер какого-нибудь типа данных может быть не равен или не кратен машинному слову и мы можем не знать заранее, сколькими инструкциями копирования реализована операция присвоения в конкретном компиляторе или в конкретной библиотеке.
А с чем это связано?
Например в классическом 8086 проц читал два байта (16 бит, оно же машынное слово). Когда он просил у контроллера памяти считать байты 0x1 и 0x2 то первый попадал в одну часть регистра (например AL) а второй в другую (AH). Соответственно считать машинное слово 0x1 легко.
А вот попробуй считать слово начиная с адреса 0x2 (0x2 и 0x3). Придется сначала считать 0x1 и 0x2, потом 0x2 переложить из AH в AL, затем считать 0x3 0x4, затем откинуть 0x4.
Долго и нудно.
С тех пор много говна утекло, контроллеры памяти теперь читают данные из DIMM сразу по 64 бита, контроллер кеша (который между ядром и контроллером памяти) старается заполнить всю кеш-линейку (которая может быть еще больше), но проблема в целом осталась: если ты читаешь N байт, и перехлестываешь некоторую границу, то читать нужно 2 раза, а не 1. И это усложняет
Placement delete вроде нет.
Placement delete вручную вызвать нельзя.
Он вызывается, если в конструкторе выбрасывается исключение - вызывается delete, соответствующий по сигнатуре использованному оператору new.
использование в контейнерах это частный случай аллокатора так то
a.operator + <Type>(b)
Хотя, может еще быть operator + (a,b);
Охлол, это отдельным говнокодом надо как while(x --> 0).
Бедный парсер.
К "a.operator +(b)" вроде уже привык, а такое я ещё не видел и удивился.