Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Спасибо, что напомнили. Посоветую эту школу одному своему знакомому, который застенчиво прикрывается паспортом и стесняется честно сказать, кто он на самом деле.
>Школа анонимных Тарасов
Ммм… Тарас спрашивает Тараса:
- Тарас, как тебя зовут? Ты Конардо?
- Нет, - отвечает Тарас. - Моё имя Тарас!
- А тебя наверное зовут Иван, а Тарас?
- Нет! Меня зовут Тарас!
повар.жпег
[color=shite]Это в связи с недавними событиями, когда некие разноцветные анонимы представлялись Тарасами.[/color]
Я что-то не понял?
Где олдфаги?
Где люди, с которыми можно поговорить про пользу умных указателей?
Здесь вообще хоть кто-то понимает, о чём я веду речь?
по-честному, delete вообще более говнокодно, чем new (потому что бывает shared_ptr<T> a = new T), но во-первых, в новом стандарте, если я не ошибаюсь, new уже не нужно даже для создания указателя на объект, конструируемый с несколькими параметрами, во-вторых, тогда бы я не уложился в три символа.
>shared_ptr<T> a = new T
make_shared >в новом стандарте, если я не ошибаюсь, new уже не нужно даже для создания указателя на объект, конструируемый с несколькими параметрами
Совершенно верно + добавили make_unique
К сожалению чистые указатели (и чистое new) может потребоваться при передаче указателя на объект библиотеке, которая сама занимается управлением переданной памятью. (Никогда такого не видел, но в теории в легаси говнокоде возможно)
Ах, да, и ещё низкоуровневая реализация разных компонентов (тех же make_*). Также адекватной замены placement new не существует.
> К сожалению чистые указатели (и чистое new) может потребоваться при передаче указателя на объект библиотеке, которая сама занимается управлением переданной памятью. (Никогда такого не видел, но в теории в легаси говнокоде возможно)
Для этого можно использовать std::allocate_unique + std::unique_ptr::release когда понадобится передать в легаси библиотеку управление памятью. std::unique_ptr можно использовать и с массивами.
Это ведь своего рода акт создания некой культурной ценности ;)). Вспомнил про типа, который 10-го прибил яйца к мосту для протеста. Он называет себя художником.
Вот бы кто-нибудь приколотил свои яйца к мосту, а перед этим наколол на груди c++ - говно. Какая была б подстава бы была c++ хейтерам.
Голый художник с татуировкой "c++ - говно" на груди, с грустью глядящий на свои яйца, прибитые к мосту, кстати, очень символичен. Нагота художника показывает нам ограниченность стандартной либы. Мост олицетворяет переход от с++98 до с++14. Прибитые яйца - требования заказчика и обратную совместимость.
Не, просто чувствуешь себя так, как-будто яйца прибитые. Хочешь встать и пойти дальше по мосту (поюзать новую удобную фичу с++11 типа for), а тебя гвоздь совместимости держит за яйца. И ты с грустным видом продолжаешь писать for с итераторами.
Блин, товарищи, каким образом можно избежать попадания копий объекта с одинаковыми свойствами в список tobjectlist? Я уже всю плешь проел с этими объектами. Тарасбер, ты что скажешь? Выручай. Там что-то неясное с IndexOF, но не осилил.
Разделаюсь с этим - выложу готовую прогу. Вы не пожалеете.
А не тормозно ли будет? Я ассигную tobjectlist с tstringlist, у которого дубликаты выставлено в duperror - генерить исключение, если попались 2 похожие строки, которое сам же и обрабатываю. Возник exception - убиваю предыдущий объект. Тормозит жутко. Я уверен, что примерно 20% мощности убивается на этом тупом переписывании.
А как можно оптимизировать такой момент:
Имеется tobjectlist заполненный элементами.Мы в цикле получаем элементы списка, и в зависимости от свойств этого объекта (через дженерики) заполняем listview (т.е. в зависимости от свойств объекта меняется иконка и caption) и внедряем в один из subitems ссылку на этот объект. Все вроде ничего, но если лист содержит более 1000 элементов, начинает тормозить ( Я пробовал просто заполнять listview, не тормозит.
Если делфи так медленно работает с памятью, я сильно ошибся языком.
Так вроде уже было нечто похожее: #11251
PS> Там еще кое-кто контекст уточнял. #comment143118 Хотя, признаюсь, я б и сам с интересом почитал крестотред про умные указатели, все дела.
Это не проверка работы и не школовайп.
Я абсолютно серьёзно.
- Здравствуйте. Меня зовут Тарас и я Тарас.
Ммм… Тарас спрашивает Тараса:
- Тарас, как тебя зовут? Ты Конардо?
- Нет, - отвечает Тарас. - Моё имя Тарас!
- А тебя наверное зовут Иван, а Тарас?
- Нет! Меня зовут Тарас!
повар.жпег
[color=shite]Это в связи с недавними событиями, когда некие разноцветные анонимы представлялись Тарасами.[/color]
Где олдфаги?
Где люди, с которыми можно поговорить про пользу умных указателей?
Здесь вообще хоть кто-то понимает, о чём я веду речь?
>new
Наверно нужно было оставить комментарий после кода.
make_shared
>в новом стандарте, если я не ошибаюсь, new уже не нужно даже для создания указателя на объект, конструируемый с несколькими параметрами
Совершенно верно + добавили make_unique
К сожалению чистые указатели (и чистое new) может потребоваться при передаче указателя на объект библиотеке, которая сама занимается управлением переданной памятью. (Никогда такого не видел, но в теории в легаси говнокоде возможно)
Ах, да, и ещё низкоуровневая реализация разных компонентов (тех же make_*). Также адекватной замены placement new не существует.
Библиотеки, управляющие памятью не по принципу Тараса Бульбы? Так говнокод же.
Для этого можно использовать std::allocate_unique + std::unique_ptr::release когда понадобится передать в легаси библиотеку управление памятью. std::unique_ptr можно использовать и с массивами.
Всем было бы достаточно комбинации, чтобы всё понять и простить
C++ / Говнокод #.....
Запостил: TarasB
Вот бы кто-нибудь приколотил свои яйца к мосту, а перед этим наколол на груди c++ - говно. Какая была б подстава бы была c++ хейтерам.
Это как? Раньше все себе яйца прибивали?
Разделаюсь с этим - выложу готовую прогу. Вы не пожалеете.
Имеется tobjectlist заполненный элементами.Мы в цикле получаем элементы списка, и в зависимости от свойств этого объекта (через дженерики) заполняем listview (т.е. в зависимости от свойств объекта меняется иконка и caption) и внедряем в один из subitems ссылку на этот объект. Все вроде ничего, но если лист содержит более 1000 элементов, начинает тормозить ( Я пробовал просто заполнять listview, не тормозит.
Если делфи так медленно работает с памятью, я сильно ошибся языком.
PS> Там еще кое-кто контекст уточнял. #comment143118
Хотя, признаюсь, я б и сам с интересом почитал крестотред про умные указатели, все дела.