- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
struct Obect: public AbsractPrimitiv
{
float X,Y;
Obect(float x, float y)
{
X=x;
Y=x;
};
Obect(void)
{
new(this) Obect(0,0);
};
//...
//...
//...
private://Требование конвенции. Блок private обязан быть в каждом классе.
};
Follow us!
Обосранная приметивная обезьяна.
А это что означает? Что конструктор принимает один пустой безымянный параметр?
Малявка?
Ты уверен, что это минус?
Это обфускация от школоты, типа тебя.
почему рудимент? если можно возвращать void, почему бы его нельзя и принимать?
Всё таки void - это не тип, а отсутствие оного.
Нормальные люди знают что boo() это синоним boo(void);
Но это нормальные, которые знают Cи. А которые прямо из детсада пошли на php-дельфи писать -- те в курсе конечно.
"пустой безымянный".. марштышка бля
А программист от макаки тем и отличается, что знает си (хотя писать может хоть на джаве хоть на питоне)
Но это не страшно: что бы сдать зачот по информатике за 8й класс -- и дельфи прокатит.
А после школы пойдешь в макдональдс.
Ты уже хеллоу ворлд написал?
Между прочим в нормальном обществе люди не стесняясь друг друга спрашивают о чём хотят и получают на это нормальные ответы... а вам главное утвердить своё Эго. А в итоге, из-за этого инфантильного поведение, мнение о вас только падает.
Повторю свою мысль. Если вы видите адекатный вопрос, то лучше всего просто дать на него адекватный ответ, а не начинать "понтами раскидываться". Просто будте взрослее.
А больше всего меня бесит, когда люди скрываясь за "anonymous"-ом начинают обсирать других.
Но это нормальные, которые знают Cи
не путай мерзкий с++ с православным святотроицким си, сука. в си b() это "b с любым количеством аргументов", что не есть b(void). а вот в с++ это одно и то же, однако в с++ писать b(void) вместо b() считается моветоном, видно что автор хуила, школота и копипаст, нихуя не знает синтаксис.
struct Obect: public AbsractPrimitiv наследование структур?
Obect(float x, float y) функции в структурах?
new(this) Obect(0,0); а это что за высер?
> new(this) Obect(0,0); а это что за высер?
Изучаем матчасть: http://www.cplusplus.com/reference/std/new/operator%20new/
А где lvalue ?
new(this) Obect(0,0);
==
this = new Obect(0,0);
new(this) Obect(0,0); создаст объект на месте this без выделения памяти,
а this = new Obect(0,0); создаст в памяти новый объект и вызовет оператор присваивания
а если новый объект не влазит в память? или можно только текущего типа?
интересный сахар, только его употребление, имхо, пригодно разве что в говнокод-сценариях.
можно и другого типа, главное чтобы размер был одинаковый
> а если новый объект не влазит в память? или можно только текущего типа?
можно disregard, I suck cocks.
НАХРЕН "создавать" this в пределах самого класса, если можно ТУПО изменить поля?
Т.е. нахрен писать new(this) Object(0, 0) если можно тупо часть конструктора выделить в initFields, и вместо этого говна тупо писать initFields(0, 0)?
Пиздец страуструп ебалай какой-то.
Вообще-то this модифицировать нельзя.
// Нечто с const_cast<> и this
cout << this << endl;
Покажите мне код, где будут выводиться разные значения ?
Действительно высер и так делать нельзя, хотя компилируется. Так делают любители скрытых проблем на свою задницу.
код 100% рабочий, я гарантирую это...
вот [url="http://www.prooflink.ru"]пруф[url]
P.S. В новом стандатре разрешили вызывать конструкторы из конструкторов...
Я знаю.
>код 100% рабочий
Код 100% глючный. Сейчас объясню.
Не инженерный подход...
См комменты несколько ниже с объяснениями.
Или я не прав, и оно тут чето другое означает?
> тоже
> тоже
> тоже
палишься
Как это работает и что делает? И вообще работает ли правильно?
Это не будет работать так, как задумано. Грязный нерабочий хак.
new(this) Obect(0,0);
Что произойдёт?
Хуйню получим. Работать правильно не будет.
оператор new(void* ptr) не выделяет память, он на участке ptr, создает объект... но если от этого объекта наследоваться, то получим хуйню, так как этот конструктор затрет vptr если она есть и нужна...
в мат библиотеках (где не бывает vptr) такой хак используют для создания куч разнообразных конструкторов...
Поподробнее объясните этот момент? Что произойдёт?
Если этот объект имеет предка, то получим хуйню. В данном случае он имеет предка:
>struct Obect: public AbsractPrimitiv
1)Конструктор AbsractPrimitiv вызовиться 2 раза подряд. Если там выделялись/резервировались ресурсы, то они остануться заблокированными на всегда, например семафор или выделенная паямть.
2)Произойдёт лишняя работа, например 2 раза инициализируется таблица виртуальных методов.
3)В стандарте не сказано, что при создании объекта компилятор не может проводить всякие внутренние работы, например регистрироваться в списках RTTI. Что при повторной регистрации может привести к неопределённому поведению. В стандарте не сказано, как именно нужно реализовывать RTTI, так что это можно сделать по разному. Кроме RTTI компилятор может проводить прочую скрытую от программера работу.
4)Если в некой функции объявить объект так:
То получаем ещё одну говняшку. Во время скрытой работы объект зарегистрирует свой деструктор на вызов во время завершения приложения 2 раза.
Вообщем не код, а одно сплошное несчастье. И это я не перечислил всех бед, вызванных таким говнокодом.
Программист должен видеть сокрытое и не делать таких ляпов.
[code=cpp]
void f()
{
static Obect obj(/*...*/);
};
[code]
кроме статической переменной, ее адрес регистрирует не конструктор, поэтому с удалением все будет ок
и RTTI никаких действий не производит с объектами в конструкторе... таблицы RTTI создаются статически, в объектах хранится указатель на описание класса, он в конструкторе перезапишется на тоже самое значение, vtbl тоже создается в статике, в объект записывается указатель на нее (RTTI и vtbl выдны в таблице экспорта obj файлов)...
то есть верным остается только первый пункт, и я об этом говорил... поэтому я дописал, что такой хак популярен в некоторых быблиотеках работающих с PODтипами, типа матбиблиотек...
я еще раз повторю, код - отменное говно, но есть условия в которых он рабочий...
>vtbl тоже создается в статике, в объект записывается указатель на нее
Повторяю. Это в вашей реализации компилятора. В стандарте это не указано и всё может происходить именно так, а может и не так.
>vtbl тоже создается в статике, в объект записывается указатель на нее
Это далеко не так очевидно при множественном наследовании.
>статической переменной, ее адрес регистрирует не конструктор
Опять же есть компиляторы с ошибкой, в моём случае - оптимизатора, в котором это именно не так. Мой регистрирует себя при static во время вызова конструктора самого первого предка. Оптимизатор так делает, если его включить.
>но есть условия в которых он рабочий...
А есть условия, когда код не рабочий и одни условия превращаються в другие очень легко по случайности или недосмотру, так что этим хаком лучше не пользоваться. Достаточно добавить предка и наступает ужас. Поменять "хороший" компилятор на "плохой" и получаем тоже самое.
>вы правы на 100%...
Судя по тому, что вы сейчас сказали - лишь на 25% :D
http://lj.rossia.org/users/kouzdra/664091.html?nc=66
Как только начинаешь использовать кучу - наступает jopa жопа (не java).
В момент использования кучи в С++ - его рвут все языки, даже java и OCaml.
можешь посмотреть исходники языков в которых это есть...
людская молва не врёт, ты олень.
подразумевается компактирующий сборщик, который бы работал для с++, т.е. я делаю в с++ MyCoolObject* o = new MyCoolObject(); и через N секунд указатель o будет указывать в другую память.
слабо такое на с++ поиметь?
да, нужно писать и возиться... да, нужно хорошо подумать а нет ли пути проще... да, нужно сначала решить, а нужно ли оно вообще...
все ваши коллекторы написаны не от хорошей жизни... никто не хочет думать, поэтому те кто умеют думать, пишут для тех, кто не умеет...
в большей половине случаев программа на С++ не требует какой либо магии с хипом... в большинстве случаев работа с хипом вообще не требуется, кроме как выделил в начале/удалил в конце, и все приведенные выше тесты из области абсурда... никто (даже последний говнокодер) не пишет так на С++...
P.S. жду тестов где после каждой комманды в С++ будет цикл до миллиона...
Компилиер это соптимизит.
чувствую скоро начнут появляться посты типа если после каждой строки в С++ вставить цикл до миллиона, он начнет тормозить...
ты такой дебил что прямо вообще. основная идея статьи - проверить работу с++ с кучей. как ты собираешься тестировать кучу, не обращаясь к куче, олень?
этот пример можно написать без использования кучи, и никакая ява и окамл даже близко не подлезет по производительности к С++...
С++сом нужно уметь пользоваться... к каждой строке нужно подходить с головой, всетаки не C#/java и тем более не PHP...
Плюс использования new в GC языках в том, что думать ненужно лишний раз. Нет необходимости напрягаться в тех местах, где за тебя может напрячся компилятор. Зато можно напрячся над хорошим алгоритмом.
Если используешь new, а хороший компилер с GC подумает, да выделит память из пула, а то и из стека. И только в критических ситуациях воспользуеться оптимизированной(уже написанной, не велосипедной) кучи.
Попробуй ка в своём С++ переопределить new delete так, что-бы они выделяли память из стека безопасным не хакоподобным образом. Не в жизнь неполучится.
В языках со сборкой мусора между прочим тоже, как и в С++ можно не выделять память лишний раз. Лишний раз выделяют только обезьяны.
Если начали делать линивую систему, делающую всё автоматически, то довелибы её до конца и сделали бы деструктор. Память пускай потом освбождает в свободное время, а деструктор вызовет сейчас в этом потоке.
Как последствие вышесказанного: Занятые ресурсы, типа открытых файлов или занятых семафоров меня бесят.
Ну ты странный. Это то же самое, чтос казать "ООП меня бесит. Использовать процедурное программирование нельзя." или "RAII меня бесит. Использовать в java нельзя" или что-то типа того. Это друголй подход, а ты лезешь в чужой монастырь со своим уставом.
> В случае ловли исключений приходиться чутьли не вручную вызывать "деструктор" (метод dispose()); Бред.
А как иначе? Отсекается 99% ёбли с памятью, из-за чего мы имеем 1% неоднозначных случаев типа этого. А ты предлагаешь из-за 1% непрофита поплевать на 99% профита. На лицо признаки олигофрении.
> . Память пускай потом освбождает в свободное время, а деструктор вызовет сейчас в этом потоке
Как ты представляешь себе вызов деструктора в gc-системе без трекинга ссылок? (который происходит при сборке)? Как система может узнать, что нужно деструктить, не определив, что объект не используется?
Нужно дестурктить прям щас - вызывай dispose. В чём проблема? если забудешь это сделать - то ресурс всё равно высвободится при сборке мусора позднее. в с++ у нас будет 100% утечка.
Кто просил убирать финализатор? Пускай будет финализатор и деструктор. Финализатор вызывается сборщиком в другом потоке, а деструктор сразу, если его конечно переопределили.
Никакого непрофита не будет.
Признаки гидроцифалии?
Ты путаешь. Не у нас, а у тебя. Про деструкторы почитай что-ли.
Это не один процент, а часто. Любая синхронизация, любой доступ к ресурсу.
Между тем, не нужно говорить, что это мега сложно и не оптимально. С++/CLI это умеет. У него финализатор и деструктор есть. деструктор, если его нет - просто не вызываеться, зато решение перекрывает твой так называемый 1%.
И работает ни чуть не медленее.
Если уж не пользоваться goto, то не пользоваться им до конца.
Если пользоваться хорошим нью, то пользоваться и хорошим delete.
ps: Я леньтяй и не хочу, как мудак сидеть и настраивать пулы, да как мудак сидеть и искать где же я забыл вызвать "деструктор".
Зачем полурешение? Если компилятор может сделать ручную работу за меня, достаточно оптимально и надёжно.
Я или всё делаю вручную и сам слежу, или всё отдаю на откуп компилятору. Пусть сам делает, раз начал.
Всякого рода обезьяны не знают, про проблемы деструктора в С#. Вот что им делать? А они тоже люди. А ведь C# позиционируеться, как язык "доступный" обезьянам. Почему он им полностью не потыкает?
то есть вы и сами знаете что проблема с памятью не решена... в С++ только слово по другому называется (delete)... все тоже самое...
чот прямо хочется спросить, ты что за софт такой пишешь, где не нужна динамическая память? тетрис?
раньше казуалки и PS3.
всегда найдется программист который любой код на jave перепишет на С++ и получит профит в виде экономии памяти и выигрыше в производительности... попробуйте поспорить с этим фактом...
спорю: загруженный нонстоп сервер. с++ уже через день будет так дефрагментирован, что будет сначала жутко тормозить, потом вылетать с out of memory exception.
Заметь. Все языки справились с лишними нью, а С++ не справился.
там даже цифры есть из правильной версии, че-то никто не подошел к ним поближе...
Новый стандарт? Новее С++0х?