- 1
- 2
- 3
- 4
- 5
- 6
void f_ai(intrusive_ptr<serial> i);
//...
static serial ai;
serial* ii=&ai;
//...
f_ai(ii);-
C++ / Говнокод #7978
+151
Компилируется, а потом грохается. С++ такой Си...
Запостил:
CKrestKrestGovno,
25 Сентября 2011
Follow us!
что-то это мне кажется знакомым...
Компилируемость программы не говорит о её работоспособности.
А что ты имеешь против ислама?
И C тоже:
Люрко-знатцы, порадуйте диагнозом.
Сидят на 17 съезде КПСС старпёры, и значит, главный старпёр читает по бумажке:
"Товаращи, я, от имени и по поручению, по заданию Партии, приехал на хуй... кхм".
Шёпот в зале - "а я же говорил, что не надо было число 17 писать римскими цифрами!"
Нет
а не скрипты с мусоросборником
в московской патриархии
Короче, ошибка здесь не в бусте, а в ДНК автора.
Вы так говорите, как-будто чтобы научится писать на С++ - необходимо в течении 10 лет набить 100500 шишек, а только потом ты станешь писать нормально. Работодатели такого не любят.
Насчёт 10 лет - сроки, конечно, индивидуальны. Однако если есть голова и желание учиться, ничего лучшего, чем толковый лид, ещё не придумали. Т.к. можно 10 лет набивать шишки самостоятельно, потом 2 года набивать их же на продакшене, а потом за 1 научиться большему, чем за прошлые 12. Проверено.
На собственном опыте? 13 лет? ох, лол?
надо же, а мой меня научил zx basic'у
А такое "всеобъемлющее" понятие, как целая философия - при многовековых попытках философов трудно создать что-то действительно непохожее.
Вот, например, давайте я попробую:
Я считаю, что всё сущее (всё, что вполне может существовать, но не встречалось) существует реально. И, к примеру, привидения и русалки тоже.
Также я уверен, что каждый индивид прав во всём, при этом создавая(или, точнее, "прикасаясь") со своим вариантом сущего.
Например, возьмём тот же древний спор о религиях, или проще: есть ли Бог или же Его нет. Так вот, кто в Него верит, для того на самом деле Он есть, а кто не верит -- никогда не увидит (варианты, зависят от "точек зрения": не узнает, нет вообще, не нужно знать).
То есть, у меня этакая "теория относительности", распространённая не только на материю. Скажите, я ведь повторяю одного или даже нескольких философов?
дохтур, а вот ко мне давеча стая нейтринов залетела...
солипсизм же!
Вам надо написать книгу: "Как выучить С++, лишь захотев, за 1 день."
Правильно. Чуть выше говорим про 1 ночь :)
Т.е. я имею, язык сам по себе, в отрыве от долбоёбов, которые пишут в лаба-style, не так уж плох. Успешно использую в своих проектах. Креши и утечки памяти случаются раз в месяц. Дебажу ошибки за пять минут. И т.д.
Надо смотреть в сторону тулкитов и систем подобных Qt. Стандартная библиотека и boost, имхо, действительно аляповатое overdesigned говно.
Автор просто не знал, что функция f_ai принимает умный указатель. Эту функцию другой человек написал. Я же говорю, что на самом деле говно в бустеBOOST::intrusive_ptr, тк автор забыл указать одно ключевое слово при его реализации. В том же shared_ptr и прочих этой ошибки нет. Код банально не скомпилируется. Не будет никаких неявных преобразований.
>Нехрен просто использовать указатели с подсчётом ссылок для объектов, которые могут существовать не в куче.
Где автор кода использует умные указатели? Автор просто не подозревал, что их использует.
> тк автор забыл указать одно ключевое слово при его реализации.
Если чуточку загуглить, можно легко убедиться в том, что "constructor is implicit by design". (c)
> Эту функцию другой человек написал.
> Где автор кода использует умные указатели?
> Автор просто не подозревал, что их использует.
Ок, ошибка разработчика интерфейса (т.е. автора другой части кода). Если для объекта используется подсчёт ссылок, объект не должен удаляться никаким другим способом. Если объект не должен удаляться другим способом - нужно позаботиться о том, чтобы этого не случилось. Самый простой и безопасный способ - закрыть объекту конструктор, закрыть копирование и сделать статический метод create, создающий его на куче (и, возможно, сразу оборачивающий в указатель нужного вида). Если всего этого нет - я делаю вывод, что человек, который ввёл в своей интерфейс intrusive_ptr, не умеет им пользоваться.
А зачем? Что-бы случайно натыкаться на такие ошибки?
>Самый простой и безопасный способ - закрыть объекту конструктор, закрыть копирование и сделать статический метод create
Как видно, объект используется в проекте и при подсчете ссылок и без. Неоправданное ограничение вы предлагаете ввести.
http://lists.boost.org/Archives/boost/2005/07/90408.php
Лично мне достаточно этой аргументации + того факта, что при аккуратном использовании это попросту удобнее, чем каждый раз явно прописывать создание объекта intrusive_ptr.
> Как видно, объект используется в проекте и при подсчете ссылок и без.
А зачем? Что-бы случайно натыкаться на такие ошибки?(c)
Без дополнительной информации лично мне это кажется серьёзным просчётом архитектуры. Подобное смешение изначально небезопасно и непрозрачно (что и приводит к таким вот случайным удалениям статического объекта). И то, что оно чуть менее опасно, чем при использовании shared_ptr, этого факта не меняет. Я бы перед принятием подобного решения десять раз подумал. Наверняка можно найти более удачный выход.
Ну сшаред_птром так ошибиться просто не возможно. Так что не чуть менее опасно, а безопасно. Возможно ошибится, только по полному не знанию принципов работы shared_ptr. А тут реально серьёзный парень допустил такую ошибку просто по не внимательности, а не из-за незнания. Хотя может архитектуру и стоило пересмотреть. Не спорю. Но архитектуру то он не сам разрабатывал, а просто поддерживал старый код. Хорошо, что хоть ошибка обнаружилась сразу.
С шаред_птром при малейшем усложнении ситуации может вылезти куча другого геморроя, тянущего за собой всяческие shared_from_this и прочие извращения, которые интрузиву просто не нужны. Не говоря уже о том, что у shared_ptr гораздо больше оверхеда...
Правда, в отличие от интрузива, для него реализованы слабые указатели. Вот здесь я уже не согласен с бустовцами, считающими, что они не нужны и "не имеют смысла". Однако написать их вручную, несмотря на все их умные протесты, на практике оказалось вполне подъёмной задачей.
Можно несколько примеров?
Будут ли эти извращения при использовании intrusive_ptr?
>корень зла здесь всё-таки далеко не в том, что у intrusive_ptr конструктор сделан неявным
А в чем корень зла?
>Однако написать их вручную
Простите, не понял. Написать что и кем?
Ничего очень конкретного сейчас уже не дам, т.к. довольно давно почти не пользуюсь shared_ptr. Но гипотетический пример достаточно прост: допустим, у вас есть некий общий ресурс, с которым совершенно независимо друг от друга работают два (или больше) пользователя. Ресурс должен быть удалён, когда все они закончат с ним работать (т.е. счётчик ссылок обнулится). Предположим, один пользователь, хранящий в себе shared_ptr на ресурс, у вас уже где-то есть (или может быть), но где и какой именно - прямо сейчас неизвестно (или просто нет к нему доступа из нужной точки к коде). Как вы собираетесь корректно передать ещё один такой shared_ptr следующему пользователю? Правильно, наследуем ресурс от enable_shared_from_this, вызываем shared_from_this()... ну не извращение ли?
> Будут ли эти извращения при использовании intrusive_ptr?
Не будут. Т.к. в описанном выше примере счётчик ссылок один и хранится в самом ресурсе. Поэтому можно независимо создавать intrusive_ptr из одного и того же простого указателя хоть тыщу раз в разных местах, не заботясь о том, кто и где на него уже ссылается: пока объект существует - это безопасно. И, кстати, в отличие от shared_ptr, никогда не выделяет динамически дополнительную память под счётчик.
> А в чем корень зла?
В архитектуре, позволяющей и поощряющей использование объекта, содержащего внутри себя счётчик ссылок, так, как будто этого счётчика в нём нет и им никто не пользуется.
> Простите, не понял. Написать что и кем?
Что - слабые указатели, успешно работающие в паре с intrusive_ptr.
Кем - собой. :)
А чем пользуетесь? Видимо, intrusive_ptr ?
[не аргумент]"Умным может быть кто-то один - либо указатель, либо программист".
[/не аргумент]
А что-за протесты?
Явный вызов деструктора без delete (до обнуления счётчика слабых ссылок), видимо, религия не позволяет.
Тк за работой меньше просидишь и займешься спортом, ибо все уже сделал, или сделаешь очень много проектов, успев заработать на дорогие лекарства. (:
оптимистично
Правило простое: пока не понимаешь - не трогай. Умнее от этого не покажешься.
В остальном С++ чрезвычайно прозрачен, интуитивен и прост для меня (если не обращать внимание на синтетические примеры), и я не искренне не понимаю всего ажиотажа насчёт его необычайной сложности и запутанности.
Я, кстати, с бейсика начинал. Так что, не в языке дело, а в голове.