Нет, это ты пытаешься так позиционировать Делфи.

Добавлено через 41 секунду

Очень интересно, что же его заменит?

@Beltar


Ты привёл статью, поливающую ООП фекалиями в ключе "всё изобретено до ООП, и при помощи нескольких финтов ушами имитируется в процедурном языке" (что не является открытием ни для кого). С этим оправданием ты сплющил иерархию юнитов РТС в одну запись и вручную реализовал таблицу виртуальных методов. Необходимость разнесения данных по разным типам ты вообще отсёк. И это мы ещё рассмотрели только иерархию с одним корнем. Это -- надругательство над ООП, и никак иначе. Это и есть позиция "ООП -- для неудачников".


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


Чувствую, зря я тебе рассказал про фичу F# для импортирования членов статических классов в глобальное пространство имён. На тебя это вредно подействовало -- одно сходство (форму записи) ты принял за полную идентичность.  


Сайтики для меня -- это мелкий побочный продукт для быстрого заработка и развлекалова. Крупный сайт на моей совести один, он писался в команде, и никуда не разваливался. Собственно, и самый первый мой сайт не разваливается, несмотря на эпический экскрементокод внутри (mysql_query, чистая процедурщина, глобальные переменные, прочее), просто он достиг порога, когда развивать его невыгодно. Но от него этого и не требуется, в общем-то.


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


Глобальная переменная и синглтон вводят в приложение глобальное состояние. Только одно в процедурном языке, а другое -- в объектно-ориентированном. Ты предложил создать глобальную переменную "файл", я привёл статьи с объяснением, что это -- экскрементокод и путь в бездну. Что непонятно?


"Новенькие контрольчики" не дают возможности красиво нарисовать данные в том же листбоксе. Вон, когда я предложил тебе нормально прорисовать элементы листбокса, ты сказал, что это всё нафиг никому не нужно, что это выпендривание на пустом месте, и что ты не умеешь пользоваться OnDrawItem/OnMeasureItem. Мало того, что кастомная прорисовка в VCL/WinForms -- это то ещё удовольствие с тоннами кода, так ты ещё и пользоваться этим не умеешь. Ну как здесь поможет контрол? Да никак.


Сейчас не два часа ночи, и ты не смотришь фильм, однако решения проблем с твои "пулом" в извращённой антиООПной "архитектуре" я так и не вижу. Ну, где? (И обвинения в хамстве забавны -- кто меня послал в пешее эротическое путешествие раза три-четыре? Или ты за хамство считаешь перечисление недостатков "архитектуры"?)


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

@LSD


Должно быть ясно из контекста, что я имею в виду. Ладно, вот тебе официальная документация, там написано по-человечески:
http://msdn.microsoft.com/en-us/library/ee...bage_collection
(И, похоже, я таки наврал про потоки -- опций больше. Прошу прощения, никогда серверным GC не пользовался.)

Добавлено через 3 минуты и 31 секунду
@Beltar


Для разных задач разные оптимальные языки и инструменты. Где-то лучше одно, где-то другое. Где-то выбор неоднозначен, и в дело идут личные предпочтения.

Ясно одно: оптимальный инструмент -- всегда НЕ дельфи.

Трупом он станет только в эротических фантазиях дельфинов(может тогда эти некрофилы захотят на него перейти?). А пока это один из самых популярных языков, и никаких предпосылок для его смерти нет.
таких нет.
Поддержка дельфи на "других платформах" намного более сомнительна.
ага, а некоторым даже в асме тесно, и они пишут на машкодах. Что за чушь?   

Выучи же хоть один приличный язык. До нормального понимания. Может и увидишь со стороны всю убогость своей детской песочницы.   

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

На графах же, когда оказалось, что основная проблема это разорвать связи, а не Node.Free написать, ты начал утверждать, что я ничего не решил.



Ясно одно, что делфихейтерство это болезнь, которая от плюсников, комплексовавших, что все у них там через задницу просто перешла к шарперам, которые просто боятся признать, что плюсы их достали, а теперь надо как-то оправдаться, что сами используют то, что в Delphi было изначально.

Это сообщение отредактировал(а) Beltar - 29.4.2013, 19:58

@Beltar


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


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

И хватит уже увиливать. Где исправление "пула"? Будет?


Ты ни одного сообщения не можешь написать без пассажа про хейтерство, всемирный заговор, слабоумие оппонентов, разъедание мозгов ООПом и далее по списку?

И давай, расскажи, что такое потрясающее было в дельфи 7, чего не было C++03. Давай, я даже начну за тебя: свойства, вложенные функции... всё? (Только давай серьёзное сравнение, без всяких там begin/end и регистронезависимости. И без того, что тривиально реализуется средствами языка, типа дельфийских множеств.)

не было там свойств.

библиотека турбовижин, ее потомок супервижин

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

Это сообщение отредактировал(а) Zloxa - 29.4.2013, 21:58

http://stackoverflow.com/questions/1111537...-you-use-delphi

Но Атари не понять.

Проблема в архитектуре там другая, которую впрочем никто и не прорабатывал, а был сделан просто набросок класса, который никто и не тестил, так что мне непонятно в чем твоя претензия. Оценивают ТОЛЬКО конечный продукт, а не накаляканое карандашом.

Далее, что сделал ты, ладно создал граф, написал итератор, т. к. хотелось попонтаваться, в твоей программе просто руками убраны пара вершин, после чего ты победно заявляешь, что все зашибись, т. к. GC вершину уберет. При этом ты увиливаешь от проблемы, что для удаления вершины из произвольного графа все равно придется писать алгоритм разрыва связей, и лишь там, где дельфин или наСИльник напишет Node.Free\delete Node ты можешь ничего не писать и ждать GC. Ты этого алгоритма не привел. Разумеется если алгоритм удаления написан неверно, и не все связи будут удалены, то GC тебе не поможет. Получается, что в случае действительно нетривиальной очистки объекта, польза от GC сводится лишь к тому, чтобы 1 оператор не писать.

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

Кроме того очень мутно понятие "создать на стеке".

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

@Beltar


Что показательно, больше всего плюсов набрал не какой-то ответ, а комментарий "Is "Boss makes me" a valid reason"  


Ты пыжился продемонстировать замечательную архитектуру, которая будет лучше предложенной мной. Что в твоём коде -- дело десятое. Важно то, что твоя архитектура провалилась на довольно простой задаче (безотносительно того, написал ты конкретное решение или нет). А что в твоём коде была тонна багов -- это как раз показатель проблем с дельфи. И не надо оправдываться, что "не запускал". Я хоть и запускал, но делал это один раз -- чтобы убедиться, что сработало.


Итераторы -- это очевидный инструмент для обхода перечисления. То, что он тебе видится магией -- это твои проблемы. Для тебя и юнит-тесты -- магия и шаманство.


Это проблема? Разве? Я же написал тебе эти аж две фантастически сложные строчки: foreach и list.Remove.


Но ты-то и этого не осилил. Хочешь скопирую сюда твой исходник, чтобы народ поржал?  

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

Магией мне видится не выпендреж, а его полная бесполезность там, где элементарно перебирается массив. Кстати, Диего тоже проникся.



А что было в твоем исходнике? Там был метод удаления вершины? Я, например, такового не вижу, точнее там есть:



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

Я в своей реализации с двусторонними связями делал то же самое.
for i:=0 to V.Links.Count-1 do V.Links[i].BreakLink(V);
Вопрос там в другом, как организовать хранение будет правильнее, можно обернуть, как я сделал, а можно и тупо наследника от TList или TCollection. Впрочем для тебя написание кода для удаления руками, это ничего, а я могу сделать готовую программу, которая будет означенный граф выводить и ты все равно скажешь, что я не реализовал.
Касательно не запускал, то извиняй парниша, но сидеть и что-то дебажить только из-за твоей прихоти мне нафиг не упало. Ты сам выдумал сферическую задачу в вакууме, не имеющую практического смысла нарисовал пару методов, это твои проблемы, я же для тебя ничего тестить не обязан. В то же время делать такую же хрень, как у тебя, мне как-то западло. Граф? Ну так давай нормально делать класс для графа с методами обработки, а не пяток вершин. Так что можешь сколько угодно наезжать на мою архитектуру, но у тебя архитектуры не было вообще, был просто набор точек без какой-либо структуры для их хранения.

Выкладывать что-либо я тебе запрещаю. Я могу любому, кому надо, что угодно переслать, но лично тебе запрещаю. Просто потому что тебе уже невозможно ничего показать без получения тонн г***а в ответ, неважно по делу или нет, а раз так, то зачем мотать себе нервы.



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



Наберет больше всего плюсов в любом языке.

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

Впрочем:



Извлечь объект из обертки как раз-таки можно. Хотя может в шарпе невозможно... Проблема не в этом, проблема именно в том, как указатели не поломать, ну так иди и изучай, как оно в GC делается, задача-то та же, но делается не на всем приложении, которое забито классами, которые будут жить, пока приложение работает, а именно на пуле.

@Beltar


Это и есть элементарный перебор массива. В шарпе для операций с объектами повсеместно используется функциональный подход.


"graph.To[0].To[0]" стоит заменить на нормальную переменную, а так да, всё верно (это я твою прихоть по моментальной сборке мусора удовлетворял).


У тебя не решена задача удаления вершины из памяти после того, как удалена последняя связь с её участием. (Аргументы "это не нужно", "ты тоже не решил, у тебя магический тормозной GC" и прочие жалкие оправдания не принимаются.)


Я двумя строчками проверил, что программа на 20 строчек запускается. Ты написал 50 (неработающих), а как добавить две строчки для проверки -- так сразу "о ужас, глубокий дебаг, ручное тестирование, ты зажрался" и прочие вопли. Под дельфи так сложно вывести две строчки в консоль, что работа несопоставима с написанием полусотни строк?


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


Понимаю, стыдно...  


Ты на людях не позорься хоть. Юнит-тест -- это код для автоматического тестирования одного отдельно взятого метода класса. Твоё приложение -- это левое приложение для ручного тестирования целого куска функционала. Что, совсем разницы не ощущается?


Юнит-тестирование возможно только при адекватной архитектуре приложения, при низкой взаимосвязанности компонентов. Если ты так и будешь писать Button1OnClick и огромные портянки кода на все случаи жизни, то тестируемого кода у тебя никогда и не появится.


В случае с графом единственное, к чему ты смог придраться в моём коде -- это что в нём нет стройной архитектуры, а есть только POCO и двустрочные алгоритмы с логированием в консоль. Если тебе для проверки реализации алгоритмов нужно выделить всё в красивые методы -- как я уже сказал, ни разу не проблема, а два клика мышью.


Насмешил, GC работает совсем не через двойное разыменование указателей.  

Ты совсем не понял проблему что ли? Ну ладно, объясняю на пальцах:

1. Положим, у нас есть объект Foo foo, обёртка-указатель Wrapper<Foo> wrapper, список указателей List<Wrapper<Foo>> list, пул Pool<Foo> pool.
2. Функция Bar принимает как аргумент объект Foo. Ты не можешь изменить сигнатуру, потому что функция из библиотеки стороннего производителя. Поэтому ты передаёшь ей значение list[i].Wrapped.
3. Функция Bar запоминает значение foo (либо кэширует; либо это инициализирующая функция и значение будет использоваться другими функциями библиотеки впоследствии; либо обработка выполняется в другом потоке).
4. Пул pool решает упаковаться. Объекты в пуле изменяют адреса, параллельно изменяются адреса Wrapped в указателях list.
5. Функция Bar продолжает работать с адресом, по которому объекта уже не существует (либо на его месте "свободная ячейка", либо память вообще была освобождена, если пул решил расшириться).
6. AV

Можешь исправить? (Вариант "учи матчасть" за ответ не принимается, так как такая реализация пула существует только в твоей больной фантазии.)

В делфи 7 небыло свойств? У тебя была какая-то альтернативная делфи 7.

Что же там понимать?

Субъективный фактор.


Это можно сказать о любом Тьюринг-полном языке.


1) Контрпримеры: Go, Common Lisp, SmallTalk.
2) Весьма бесполезное качество.


1) Вранье.
2) Это можно сказать про любой мейнстримный (и не только) язык.


1) Вранье.
2) Многие компоненты платные, в отличие от Java.
3) Можно сказать не только про Делфи.


Вранье: BDE нужен.


Субъективный фактор.


Интересно чем он так powerful? Реквестирую реализацию паттерн-матчинга на паскале и для паскаля, пример кода с десятками тысяч корутин или хотя бы нормальный аналог RAII:

Давай, покажи нам вереницу вложенных try/except и try/finally.

А слабо написать функцию скалярного произведения векторов, такую, что она на этапе компиляции гарантирует, что оба параметра-вектора будут одинаковой длины?


Бенчмарки показывают, что не так уж и быстр.


Вранье: как разместить экземпляры классы на стеке?


Нафейхоа? А что там с Compile-time вычислениями? Что там с вычислениями на типах?


См. выше.


Никакого удовольствия от работы с VCL не вижу, Swing и то поприятней.

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

Скажи, если вершина имеет ссылку на другой объект (не другую вершину), должен ли Node.Free вызвать деструктор того объекта? А если этот объект не имеет других ссылок на себя? А если часть объектов графа имеют на сторонние ссылки на себя, а часть — нет?

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

Видимо уже засыпал. Подумал что речь идет о борландпаскакале 7 

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

БДЕ похоронен борландом еще при пятой, емнип делфе.


При ГЦ вереницы не нужны?
Да бросьте, память это всего лишь один из ресурсов, захватываемых объектом. Есть еще всякие там дескрипторы, блокировки и прочая байда, которую таки надо освобождать.

Но альтернативы для работы со старыми фокспрошными дбфками они не предоставили.


Не обязательно, в C# есть using, в Java7 есть try-with-resources, в Go есть defer, в Python есть with, в Ruby вообще просто блоки передают.
В общем все современные и живые языки уже давно внедрили альтернативу RAII.


Вообще-то я как раз о разных ресурсах и говорю.

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