- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
SkinDog* crateDog()
{
return reinterpret_cast<SkinDog*>( new Dog() );
};
void deleteDog( SkinDog* pDog)
{
delete reinterpret_cast<Dog*>( pDog );
}
EvilDog::bite()
{
Dog* pDog = mutationDog();
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+38
SkinDog* crateDog()
{
return reinterpret_cast<SkinDog*>( new Dog() );
};
void deleteDog( SkinDog* pDog)
{
delete reinterpret_cast<Dog*>( pDog );
}
EvilDog::bite()
{
Dog* pDog = mutationDog();
Не удержался, чтоб не запостить. Сами знаете откуда.
Что-за дикое ООП с reinterpret кастами?
И это называется "хорошим ооп" в "умных книжках" ;)
К тому же, связный список - очень мощный и гибкий инструмент. Потому так много интерфейсов и реализует. Остальные коллекции в Java реализуют гораздо меньше интерфейсов.
implements List<E>, Deque<E>, Cloneable, Serializable
4 != 100500
List, который в свою очередь от Collection
И Collection, который в свою очередь от Iterable.
Java is simple!
надо было весь постить, кстати
P.S. Мда, а автор всего лишь хотел PImpl... а ему тут такое сокрытие сбацали.
но если честно, не уловил сути начальной проблемы "нихачю чтобы пользователь моего кода знал, что для работы ему понадобится windows.h"
ЕМНИП, всякие WORD да POINT, и почти все APIшные функции замакрены.
P.S. Само собой, что в крестоблядском коде мало кто захочет описать свой WORD или POINT, и проблема по большей части надумана.
P.P.S. А вот макрос с именем CreateFile (если мне не изменила память, и они есть) может доставить неприятности.
просто windows.h у меня на работе в любом виндовом проекте инклюдится прямо в pch, и не сказать, чтобы я испытывал какой-то дискомфорт
видать, отсутствие конфликтов имен самостоятельно разруливается использованием stl/boost стиля - я в здравом уме свою функцию CreateFile не назову
Поэтому против включения windows.h в проект я ничего не имею, а в либу, которую впоследствии будут юзать другие - не стоит.
сишкопроблемы ты хотел сказать
все претензии только к дефайнам и любви микрософта к TCHAR (#ifdef UNICODE...), имеющей очевидное историческое обоснование
Комитет не принял. Proposal на это был для С++11.
Можно задефайнить nsp как namespace, и писать везде nsp вместо namespace.
А можно препроцессировать файлы LaTeX.
Почему не срабатывает перемещающий конструктор?
Как видно перемещающий конструктор на месте:
http://en.cppreference.com/w/cpp/io/basic_fstream/basic_fstream
см
Есть идеи, как переписать, чтобы работало в if уже сейчас или даже в старом стандарте?
потому что там всё жутко ограничено
c++03 6.4 Selection statement в с++11 в condition добавилась еще возможность инициализации через {}, что по сути тоже copy/move construction, а не direct
Или даже так работает:
Так что не понятно, почему код выше не компилируется (не считая того, что move конструктор не определен) или ещё лучше следующий код (который тоже не компилируется):
я же всё описал
конструктор без имени переменной - приводится к expression
выражение с = тоже описано в стандарте
а выражение, содержащее имя переменной и direct constructor (через скобки) - не описано
поэтому все компиляторы его и не поддерживают
поэтому внутри if с = будет работать, только когда заработает move ctor для ifstream
а так - только вынос переменной до if
Это путь по помойке. Сколько лишних конструкций приходится городить... Одни наружние {} вокруг всей конструкции стрима чего стоят...
В том же сишарпике все намного короче:
Кстати, для любителей сишарпика, после чего file будет закрыт? Или уже никогда не будет, пока сборка мусора не произойдет?
А с чего это ему вдруг закрываться? Пока Dispose не вызовет кто-то. Ну этот кто-то и будет GC:
CLR ведь не знает - когда ты захочешь еще с этого файла что-то прочитать.
Другое дело, что GC может оказаться умным и если var file будет в методе, без публикации наружу, то он его соберет при выходе из этого метода.
А может и не оказаться. Поэтому я не стал бы полагаться на судьбу, и закрыл бы файл самостоятельно. Неприятно будет, если программе понадобится через несколько секунд открыть файл, а гц его еще не закрыл.
это само по себе странно, когда есть
std::ifstream file("kakaka");
а вместо скобок всегда можно сделать file.close(); в нужном месте, раз оно так жжотся, что не дотерпит до выхода из внешнего scope
крестотравма дает рецидив, приносит тяжкие душевные страдания
Я правильно понял псевдокод этой конструкции?
Получается в принципе нельзя вызвать конструктор с нужным кол-вом параметров, а только default constructor и assigment operator?
в с++ в общем случае выполняется в последовательности
т.е. выражение должно удовлетворять стандарту (для fstream не удовлетворяет, потому что copy ctor сокрыт, а move написать за год энтузиасты не сдюжили)
а затем уже работает оптимизатор, который может элиминировать ненужные временные объекты
в принципе, copy initialization vs direct initialization на ГК уже обсуждалось
А где можно почитать и набраться уму разуму?
http://govnokod.ru/11600#comment151119
Компилится. Шо скажите посоны?
все таки ГК - полезный сайт
с++03 и с++11: п. 12.2/5
вкратце - в данном примере временный объект, на который ссылается ссылка, будет уничтожен только когда будет уничтожаться ссылка
гуест (он же гумно, он же ламер007) таки заставил с++ делать using :)
Ничего я посоны не нашел. Так как пользоваться константным ссылками на файл бесполезно даже для чтения :(
А не константная понятно не скомпилится:
Зато я нашел такой вариант:
Этот вариант лучше auto file, тк последний предпологает вызов перемещающего конструктора, что не оптимально (Имею ввиду не конкретно файлы, а using паттерн в целом, тк он применим не только для файлов).
Очень сильный аргумент.
Я не боюсь того, кто изучает 10,000 различных ударов. Я боюсь того, кто изучает один удар 10,000 раз
(с) Брюс Ли
но решение так очевидно!
http://liveworkspace.org/code/1ee1eb80806e9665c48be78d273b44cd
Мне ещё одна наркоманская мысль пришла: Написать перемещающий оператор приведения к типу? Но это пожалуй отложим до дождичка в четверг.
Это не работает в старом стандарте. Хотябы из-за auto. Есть у кого идеи, как реализовать using в старом стандарте?
using, С++, старый стандарт:
http://liveworkspace.org/code/bf5b986361f4b638a71cb8629ff5f584
2. Твой макрос ломает вложенные конструкции if. Я понимаю, что это для лулзов, но неокрепшие умы с геймдева ведь и вправду заюзают...
http://liveworkspace.org/code/4600ad70040f6ad89187836fa2fc32f9
> Так лучше?
Хм. Это никак не поможет... Плохой макрос...
Превратил кресты в паскаль, посему доволен. Таким образом избавлюсь от проблем рассинхронизации if else \ ; .
Дальше осталось сделать так бля большой паскализации:
RAII снова восторжествовало!
Ты меня заинтересовал. Пожалуй я перейду с дельфей на кресты.
Он спрятался за многоточием...
Посчитать кол-во строк в файле хедера, чтобы begin в крестах заработал также как в delphi.
Учительница в школе задала тебе эту задачку? Ну уж нет, решай ее сам ;)
Угу. Фактически в одно действие.