Они может и нет, но опять, можно использовать другие решения.
Хотя можно было через ADO/ODBC. Но это очень тормознутые технологии.

Кроме тормозов там есть еще какие-то проблемы с фокспрошными дбфками, сейчас навскидку не вспомню какие именно.

Для работы с dbf без BDE мне компонент попадался, причем даже для 2009+ версия. Возможн есть и получше решения, вопрос только в том, нафига вообще использовать dbf.



Ну поскольку у тебя GC, то тобой она и не решается. Х) Впрочем я уже вообще перестал понимать, что ты хочешь. Ну вызову я руками FreeAndnil, хотя в ряде случаев это даже не обязательно, т. к. многие контейнеры вроде TList'а могут получать право владения компонентом и при удалении объекта из списка, он будет удален автоматом. Заметь, подавляющее большинство удаляемых и создаваемых объектов размещаются как раз в контейнерах.

Кстати, жду лекцию по слабым ссылкам, и иным извратам для решения не решаемых GC проблем.



Если твой код оформить нормально до юзебельного класса, и сделать двунаправленные связи с весами, то он тоже распухнет до 50 строк из которых половина будет пустыми. Причем заметь у меня не было ни одного метода длиннее 3 строк кода. Вообще Delphi, как известно, не позволяет писать код сразу после объявления метода, поэтому код может выглядеть более громоздким. Ну так на то она и серьезный инструмент, чтобы не давать идиотам реализовать 100500 методов там, где все нормальные люди пишут удобную для ознакомления их спецификацию. А что касается тестирования, то я тебя ничего писать не просил. Скажи спасибо, что я вообще что-то там набросал, сейчас правда считаю, что перемудрил с классом как и ты с итератором. Кстати, ты сам в начале забыл, что у тебя ссылка в самой v5 остается. Ладно переписал, кстати, ЕМНИП на экране у меня твой текст не помещался, так что про 20 строк не надо.



Не находишь, что при упаковке с помощью GC имеет места та же проблема? По сути я тебе описываю тот же GC, но работающий на меньшем пуле и с доступом к пулу только через преобразователи адреса. Непонятно только зачем я это делаю, изначально-то речь шла о массиве на структурах, который фрагментации не боится, но тебе понадобилось зачем-то хранить 100 разных классов, что само по себе пожар в борделе.



Автоматом выводящее сразу всю отрисовку. Ты опять ничего не понял. Инструменты для тестирования делаются всегда, юнит-тесты лишь один из вариантов со своей областью применения.



Алле, гараж, для этого структуры есть. В 158-ой раз повторяю. Впрочем классов в моем понимании я в плюсах и не вижу, аналог древних паскалевских обджектов, не более. 



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



Вряд ли кодера интересует тьюринговская трясина.



Да ну, а вот сишники всех мастей уверены, что без фигурной скобки и выражений наполовину состоящих из знаков препинания жизни нет.



1) Ты лично убедился в этом?
2) А в жабе никто не зарабатывает компонентостроением? Бесплатного для Delphi тонны.
3) И о чем это свидетельствует?



Можно сделать, чтобы вызвал, а можно, чтобы не вызвал. Так сложно механизм владения что ли добавить?
Хотя можно усложнить задачу, пусть на вершины насаживаются объекты из какого-нибудь списка, объект может быть, как связан с вершиной, так и свободен. Мы удаляем вершину, и ее объект, если таковой есть, должен вернуться в список доступных для связывания. Охотно посмотрю, как GC поможет все здесь сделать силой мысли. Кстати, попутно демонстрируется слабая сторона ООП, деструктор вершины само собой ни о каком объекте, и куда его возвращать, не знает. Надо или писать внешний код, или делать хелпер для вершины, или создавать одноименного наследника (в Delphi можно, в др. языках не знаю).

Legacy софт.


О чем речь? Слабые ссылки есть везде.


Т.е. если я захочу создавать объект по ситуации на стеке или в куче, то мне придется описать его дважды -- как запись и как класс? И про то, что у записей нет деструкторов тебе намекали и не раз. Попробуй повторить RAII-пример.


Свое личное понимание можешь оставить при себе, оно никому не интересно.


Вот поэтому это и субъективный фактор. Ты же понимаешь значение слова "субъективный"?


Т.е. ты не понял, почему этот пункт бессмысленен, чуть более, чем полностью?


Да.


Кто-то пытается, кто-то наверное и зарабатывает. Но бесплатного море.


О том, что это не делфи-специфичное утверждение. К.О.



Т.е. мне еще и в каждой коллекции механизм владения реализовывать?


А при чем тут управление памятью вообще и GC в частности?


ОМГ. Попутно демонстрируется ###дизайн. Скажи, как деструктор вершины может не знать про объект, если ссылка на него есть в вершине?

Это сообщение отредактировал(а) k0rvin - 30.4.2013, 13:35

А я вот подумал. GC удаляет объекты, если счетчик ссылок на область памяти, в которой расположен данный объект, равен нулю, так?
Теперь представим сложную структуру, в которой объекты могут ссылаться друг на друга. В данной ситуации, мы не получаем выиграша от использования GC, т.к. все равно необходимо обнулять все ссылки на данную область памяти. Та ли это?

Не так. Далеко не все GC используют счетчики ссылок. Те, которые используют (например в Python), имеют доп.механизм для разруливания циклических ссылок. У остальных проблемы циклических ссылок не возникает.

Или ты не об этом?

Это сообщение отредактировал(а) k0rvin - 30.4.2013, 13:36

Ну не только про циклические ссылки. Допустим на один объект ссылается несколько других. Для того чтобы удалить данный объект, мне необходимо обнулить ссылки во всех остальных? 
А то я что-то запутался в вашем споре: (ручное освобождение памяти) vs GC =)

GC не панацея, но без него тоже никуда - увы пока лучше ничего не придумали. Все новые языки выходят с GC. Думаю, его и в делфи засунут (лет через дцать).

@Beltar


В данном конкретном случае FreeAndNil не прокатит. При удалении связи тебе нужно будет ручками пробежаться по всему графу и посчитать число упоминаний вершин, на которые указывает удаляемая связь. Получается очень дорогая операция для такой тривиальной задачи.


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


Начерта мне веса и двунаправленность? У меня связный ориентированный граф без весов, для демонстрации возможностей GC этого более, чем достаточно. Если наворотить фич, то кода будет много, и будет менее наглядно. Но суть-то не изменится.

Не, мне не проблема решить пару задачек на графе. Но только если я напишу, то ты должен реалиовать то же самое, а не вопить про то, что тебе лень запускать код или ещё что-нибудь. Ты будешь реализовывать абсолютно все заказанные тобой фичи в полном объёме, без багов и утечек памяти. Тебе подходят условия?


Нормальные люди вообще-то не беспокоятся о наиболее скором удалении из памяти 16 байт посреди метода, который выполняется за 0.001 мс. Это ты настоял.


Я ж тебе сказал: на GC не ссылайся, в твоём мире его не существует, это тёмная магия, к тому же тормозная и всё такое. Как я буду решать проблему изменения указателя в шарпе -- я знаю. А вот ты -- нет.


Мы решаем реальные задачи. Если тебе сказали, что "нужно выделить список в памяти одним куском", это не значит, что такой список должен быть один на всё приложение. Разумеется, речь идёт про реальные приложения с сотнями и тысячами классов. И пул, разумеется, нужен не для одного класса, а больше. И вот в этой ситуации именно ты предложил слить всё в одну кучу, надругавшись над ООП.


"Автоматом" -- это когда результат проверяется компьютером.


Белтар, ну слушай, ты хоть иногда делай вид, что используешь мозг. Ну хотя бы притворяйся. "Классы в твоём понимании" -- это что? Твоя структура из пула?


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

@Guinness


Сборка мусора реализуется не только через счётчики ссылок, поэтому проблемы с циклическими ссылками не возникает.

Можно здесь почитать: http://en.wikipedia.org/wiki/Garbage_colle...mputer_science) (в русской статье тоже что-то есть, но английская более подробная).


Если на объект что-то ссылается, то его не нужно удалять, не так ли?

Почему? Абсолютно не факт. 
Допустим есть у Вас объект User. Объект уникален, и вроде как является сущностью. Т.е. копировать его весьма нежелательно, ибо отслеживать изменения в каждой части программы данного объекта, тем самым поддерживая его целостность, не самая приятная задача.
Таким образом мы передаем указатель(ссылку на него) различным нуждающимся в нем объектам. В одном из них есть возможность вызвать метод удаления User. Вот мы его вызвали, как GC мне поможет обнулять ссылки?

И как должны отреагировать остальные части программы на отсутствие пользователя?

А обязательно, чтобы была реакция?
Допустим какие-то удалятся, т.к. не имеют смысла существования без данного объекта. Какие-то уберут некоторую строчку в гуи(или что-нибудь перерисуют) . Другие хранят список пользователей, соответственно, нужно удалить его оттуда. Кто-то должен по сети уведомить об удалении. Ну мало ли как должна реагировать программа.
С пользователем, наверно, не очень удачный пример, просто это была первая сущность, которая пришла в голову.

циклические ссылки

Тут более интересен другой вопрос. А что можно считать циклической ссылкой? Допустим у меня есть 10 объектов ссылающихся друг на друга.
В 1-ом случае, это какая-то часть структуры, которую я бы хотел удалить.
Во 2-ом - десять объектов работающих в системе независимо от остальных.

Я так подозреваю, ответ на мой вопрос может быть в ссылке представленной Athari, но, мне кажется, я долго буду там искать.

Это сообщение отредактировал(а) Guinness - 30.4.2013, 14:46

Про это уже писали выше. У полноценных GC этой проблемы нет. У GC с подсчетом ссылок есть спец костыли для этого.