Миф № 1. Указатели страдают опасностью утечки, якобы забывается delete и поэтому нужен сборщик мусора, который всё адалит автоматически. Я программирую с 1995-го, а конкретно на плюсах с 2001-го. Потратил больше месяца, чтоб добиться утечки. Думаете, я delete забыл? Чёрта с два, он набирается инстинктивно с того самого 2001-го с первого дня использования плюсов и до сих пор. А пропустил я присвоить указатель при увеличении массива. Внимание вопрос: чем мне поможет сборщик? Он ведь не знает, что нужно удалить и нужно ли что то вообще удалять, а чтоб понять это из текста, надо его анализировать, имея знания и подлинный разум, не уступающие автору. В примере с пропущенным присваиванием  что сделает сборщик? А пропустить delete я так и не смог даже специально. Ни разу с 2001-го.

Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 11:25

сборщик мусора не только для этого (кстати при его использовании утечки памяти возможны), есть еще висячие ссылки, и это проблема посерьезнее. и придумано оно не для устранения косяков программистских, а для удобства работы. 

по мне - основной недостаток GB не столько в производительности, сколько в концепции, устраняющей определенность с вызовом деструкторов. имхо в императивных языках сборщик мусора не нужен. в функциональных - другое дело, там операции работы с памятью выглядят неестественно.

Прилетит исключение, что будешь делать?

Миф и заключается именно в том, что он нужен только для этого, проблему гарантированно решает, а без него она не решаема.

Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 13:17

Миф №2: Люди, которые "программируют на плюсах" более 10 лет, досконально хорошо знают язык программирования С++.

  Язык С++ ориентирован на статические конструкции (шаблоны, объекты поля, структуры). Статическое связывание и т.д. Пока это так операций new/delete не так много и можно избежать утечек. Другое дело ситуации, когда на этапе компиляции есть мало информации о структурах данных, когда все это саморазварачивается, связывается, подгружается и т.д. Появляются ситуации когда время жизни объекта неизвестно и зависит от состояния других объектов. А если еще  это все запущено в многопоточной среде, то следить становиться совсем сложно. В примитивных случаях конечно нет проблем отследить выделение/освобождение. Зачастую даже этого делать даже не нужно. В STLе полно контейнеров которые сами за всем следят.

Ну ка обоснуй, чем язык c++ мешает использовать и разрабатывать dll, связывание которых как раз может быть только динамическим. Бейсик мешает, по крайней мере старые его диалекты. А с++? [quote=Alexeis, 7.10.2013,  13:47, post2585578] Пока это так операций new/delete не так много и можно избежать утечек.[quote]. Как раз на c++ c количество new/delete, в отличие от количества malloc/free на чистом c значения не имеет, а динамическое связывание вообще не отличается от статического.

Добавлено через 4 минуты и 28 секунд
Ну ка приведи пример хоть одной задачи, когда время жизни хоть одного объекта может быть известно, но не в случае, когда количество объектов в каждой области видимости вообще постоянно. Этот случай не принимается, так как ему вообще не нужны new/delete, они ему даже мешают, а нужны обычные именованные статические и автоматические объекты.

Добавлено через 5 минут и 29 секунд
Ну ка обоснуй, как динамическая память вообще связана с потоками.

Добавлено через 7 минут и 18 секунд
В примитивных случаях вообще нет самой задачи что то отслеживать и вообще нет нужды связываться с указателями, так как время жизни всех объектов и всех скалярных переменных известно до начало разработки.

Здравый смысл подсказывает, что речь идет о случаях, когда созданный объект "отправляется в самостоятельное плавание" и, таким образом, время его жизни не контролируется кодом, который его создал. А вовсе не о том, что ты заранее не знаешь, сколько точно времени проживет некий объект.


Примерно так же, как и все остальное. Она не связана с потоками, но многопоточность требует особого подхода, в том числе и к выделению/освобождению памяти.


А об использовании указателей Вы же сами разговор и начали. А намек на контейнеры STL почему-то проигнорировали.

Человек, который может разговаривать в таком тоне, должен быть способен решать свои проблемы с ЯП самостоятельно, без создания тысяч тем об очевидных и банальных, в общем-то, вещах.

И загоняют в рамки. А я вот не хочу stlовый вектор, я хочу строго квадратный массив деревьев списков графорв общего вида? Или дерево на 9-ти взаимоортогональных парах левый-правый потомок? Или ещё что нибудь такое, что разработчки stl могли не предусмотреть. Документ должен сам содержать каталоги, но не быть архивом абстрактных файлов? И в этом внутреннем графе каталогов нет понятия ярлыка, но есть понятие "альтернатива" и альтернатива есть второй путь к каталогу/элменту, то есть был некоторый элемент документа, потом в другом каталоге создана его альтернатива, доступ через эту альтернативу есть доступ к самому элементу, как по ярлыку, то есть любое изменение о отразится на самом элементе и его будет видно, если в следующий раз открыть этот же элемент не через альтернативу, но в отличие от ярлыка, удаление самого элемента не означает удаления данных, пока у этого элемента есть хоть одна альтернатива? Да мало ли что я могу придумать. Так вот, даже если разработчики stl угадают и все мои идеи, и всё, что в бреду изобретёт горе-студент, проще будет историку самостоятельно и без утечек реализовать свой контейнер, чем самому страуструпу изучить на столько универсальную супербиблиотеку контейнерных классов, а при её использовании избежать краха по каким нибудь другим, не связанным с утечками, причинам. Одно дело строки, они достаточно стандартны и ничего нового в плане интерфейса для них не придумаешь, поэтому std::string и ни каких гвоздёв. В крайнем случае версия на другой кодировке, например, на равномерном юникоде. Или на utf-8. На utf-16. На dos-кодировке вместо ANSI. На чём угодно, но сам контейнер остаётся тем же. И совсем другое дело все остальные контейнеры, даже динамические массивы. Один хочет хранить всё, а при добавлении нового индекса добавлять элемент, другому подавай разреженный массив, хеш-функцию из целочисленного деления и прямое отождествление соседних элементов друг с другом, третьему нужно исключение при попытке обратиться по несуществующему действительному индексу, у четвёртого индекс есть октодерево, пятый заводит списки коллизий в разреженном массиве, шестому подавай аппроксимацию не существующих элементов полиномом сотого порядка и всё называется одинаково и даже имеет общую декларацию интерфейса.

Добавлено через 1 минуту и 6 секунд
Здравый смысл подсказывает, что одно означает другое и наоборот.

Добавлено через 8 минут и 36 секунд
Да. Но нужны они не в . У меня количество независимых классов с указательными полями не всегда укладывается в первые два десятка, но почему то первая утечка за 13 лет вылезла не из delete, а из присваивания, а обнаружена по отсутствию элементов одного из нескольких десятков вложенных контейнеров на пятом уровне вложения, а вовсе не наблюдением расхода памяти. Наблюдение расхода эти 19*sizof байт за весь сеанс не найдёт, так как расход как раз правильный байт в байт, память утекла совсем не туда, куда следует из мифа.

В таком случае я не понимаю, чем вызван вопрос о времени жизни. Вы за свои 18 лет работы с кодом не встречали подобных ситуаций?

Добавлено через 1 минуту и 19 секунд

Будем честны - там и с++ не нужен-то.

Многопоточность сама по себе, ни одна особенность того самого подхода вообще ни как не затрагивает указатели. Точно также, как особый подход к покрытию палубным лаком деревянного оленя на капоте "волги" вместо обычного металлического с блестящей поверхностью ни как не влияет на приёмы настойки свч-радиостанции вместо обычной магнитолы. Сложно то и другое, но друг друга эти аспекты не касаются, даже встретившись на одной "волге".

Добавлено через 1 минуту и 59 секунд
Я не встречал как раз иных ситуаций. Время жизни всех объектов во всех моих проектах всегда было известно только пользователям, да и то смутно.

Я ценю Ваши образные и красивые аналогии, но почему Вы отвечаете не на то, что цитируете?
Я написал про выделение/освобождение памяти - Вы мне про указатели. И не поспоришь, да, на указатели как на таковые многопоточность действительно не влияет. А когда Вам понадобится выделять память в одном потоке, освобождать в другом - вот тогда все будет намного интереснее.

И простите мне этот шаг в сторону, но Вы свои мифы сами придумываете, а потом проецируете их на всех. Я помню, что где-то уже сталкивался с чем-то подобным. И точно - вот же. И что-то с того времени прогресс сомнителен.

А какая разница? Крах будет в точности тем же при попытке обратиться к автоматическому объекту в завершённой функции. Мало того, крах будет даже при использовании в одном потоке не действительного значения обычной скалярной глобальной статической переменной, изменённой в другом потоке. И динамическая память ни чего к этой проблеме синхронизации не добавляет.

Добавлено @ 18:16
А ничего, что эту тему именно я поднял не там, а здесь? Там же я отвечал. Рассказывается же миф сторонниками c#, которых я обзываю зарешёченными. Ищи на геймдеве мой пост про тюрьму разума мелкософт.

Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 18:18

Это называется ссылка. Бывают жесткие ссылки (в большинстве ФС каталоги . и .. - это жесткие ссылки соответственно на текущий каталог и на родительский) и символические - специальный файл, который содержит относительный или абсолютный путь к фактическому файлу.
В твоем случае это жесткая ссылка. Удаление файла происходит при удалении всех ссылок на него.
Не надо придумывать новую терминологию.

Эта задача решается с помощью нескольких примитивных структур (нода, файл и каталог), std::list и std::shared_ptr. Изобретать свои контейнеры нет смысла.

Если количество выделенной памяти не равно количеству освобожденной на момент завершения программы, то это простейшая утечка. Она легко находится утилитами типа valgrind.
Какое отношение имеет автоматический объект к динамической памяти?  
Да?!?   Рекомендую посмотреть реализацию фьютекса (это то, что мы называем мьютексом).

Речь идет о другом. Когда один поток удаляет объект, а второй с этим объектом работает. Например, производя увеличение его внутреннего хранилища.

Цитата(ТарасАтавин @  7.10.2013,  19:13 )

А ничего, что эту тему именно я поднял не там, а здесь? Там же я отвечал. Рассказывается же миф сторонниками c#, которых я обзываю зарешёченными. Ищи на геймдеве мой пост про тюрьму разума мелкософт.

Эх, почему люди, которые ничего не знают и знать не хотят, так настойчиво пытаются навязывать свое мнение другим.

GC нужен для...ээмм.. хз для чего, правда. в С++ есть отличная идиома - RAII.

зы
немного оффтоп, но думаю многим пригодится.
есть проект, довольно таки большой проект, ~150000 loc.
начали подготавливать проект к релизу, и обнаружились "стандартные" Си`шные чудеса в виде произвольных падений программы. при том валилась программа в совершенно разных участках, порою даже не связанных(разве что адресным пространством). я в течении нескольких дней понял, что мы имеем дело либо с порчей кучи/стека, либо с висячими указателями, либо и то, и другое.
и вот, три человека, в течении месяца, полный рабочий день занимаются только поисками этих багов. по истечении месяца стало понятно, что ничего найти не получается. стандартные средства типа отладчика и стек-трейсера никак не помогают, а только путают. так же опробован valgrind, который, к слову, тоже только "голову морочил". не для плюсового кода он, однако.

и вот, как последняя надежда, решили попробовать AddressSanitizer, который был включен в gcc-4.8.х(так же был добавлен и ThreadSanitizer, но его пока не приходилось опробовать), и, с его помощью, за один день пофиксили баги.
баги, как оказалось, были однотипные, и всего три - висячие указатели 

хз, сколько еще месяцев потребовалось бы на поиски этих багов, без asan %)

вот такая вот история. но даже в этой ситуации я не думаю, что в С++ нужен GC. тут виноваты исключительно кривые руки ;)


Это сообщение отредактировал(а) boostcoder - 22.10.2013, 13:01