мнение о Delphi - Священные войны

Здравствуйте, Serginio1, Вы писали:

S>>>>> Еще раз в Net нет статических виртуальных методов,
kuj>>>>А зачем нужны статические виртуальные методы?

S>>> На них вся Delphi построена
kuj>>А в LISP все построено на списочных структурах — разве это значит, что и в C# следует использовать такую методику? Вы так и не ответили на вопрос: зачем нужны статические виртуальные методы...
S> Изучи исходники Delphi и сразу все станет ясно, зачем нужны виртуальные конструкторы, класс виртуальные методы итд.
Нет, спасибо. Изучать исходники Делфи не входит в сферу моих интересов и обязаностей. Разве что, как пример неудачной архитектуры.
S> В Net альтернатива им рефлексия и атрибуты отнюдь не быстрые.

S>>>и компонентная модель (информация о типе, виртуальные конструкторы при создании объектов из метаклассов, пользовательская информация о типе ее расширение, в том числе и десериализация итд).
kuj>>В .NET и без статических виртуальных методов компонентная модель живет и здравствует. И уж точно развита получше, чем в Delphi.
S> Живет и здравствуеи но с метаклассами здравствовала бы еще лучше.
Возможно, хотя я бы не был так категоричен.
S>В Delphi.Net есть поддержка метаклассов.
И что? Delphi.Net не соответствует CLS? Что в этом хорошего?
S>>>>>частично они перекрываются атрибутами но очень дорогой ценой,
kuj>>>>Каким же образом?
S>>> Attribute.GetCustomAttribute.
kuj>>Пример можно?
S> http://www.rsdn.ru/forum/Message.aspx?mid=554256&only=1
А пример с Attribute.GetCustomAttribute, заменяющий статические виртуальные методы где?

S>>>То есть программирование с интерфейсами по технике такое же как и в Net.
kuj>>Вы можете написать интерфейс, который не наследует IUnknown?
S> Нет.
Значит не такое же.
S>>> если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.
kuj>>Я бы сказал, копейки. Подумайте сами...
S> Смотря сколько классов. В нормальных приложениях исчисляются десятками тысяч.
Да хоть сотнями — все-равно копейки. Подумайте.
S>>>>> Гибкость в создании сложной иерархии классов прежде всего,
kuj>>>>Так с созданием иерархии классов в C++ нет особых проблем. Да и с гибкостью, кстати, тоже, потому что: а) множественное наследование,
kuj>>>>б) шаблоны, в) пространства имен, г) перегрузка операторов.
S>>> Гибкость нужна прежде всего компилятору
kuj>>Компилятору? Так ведь шаблоны. Если Вы это понимаете под "гибкостью".
S>>>и ООП. Все что ты привел имеет слабое отношение к ООП
kuj>>Если исключить из рассмотрения шаблоны, то самое непосредственное.
S> И еще в) пространства имен,
Это тоже ООП — с помощью пространств имен выполняется разрешение конфликтов имен.
S>г) перегрузка операторов ну никаким боком к ООП.
А если подумать? Оператор сам по себе ничего не значит. Его значение сугубо прикладное. А т.к. оператор имеет непосредственное отношение к понятию "класс", то и к ООП он имеет отношение. Как минимум косвенное.
S>>>и RTTI
kuj>>Так ведь шаблоны во многих случаях избавляют нас от надобности использовать RTTI.
S> Да????
Естественно. Простейший пример: list<int> VS TList — в первом случае RTTI не нужен, во-втором нужен.
S>>>>> А ручная гибкость уже никому не нужна в сложных системах.
kuj>>>>Весьма спорно.
S>>> Хорошо у меня есть много классов работающих в 4 раза быстрее нетовских (написанных на Net), есть объектная надстройка над файлами 1С типизированный аналог "объектов" 1С скорость в 30 раз и выше в зависимости от сложности. Думаешь кому нибудь это нужно?????
kuj>>В Вашем классе задач, возможно, нет.
S> В моих задачах они используются.
Сами себе противоречите.

S>Скорее в Ваших.
А что Вы можете знать про мой класс задач?
S>>> К сожалению простота и стандартность для большинства залог здоровья. А скорость нужна для очень узкого круга задач.
kuj>>Так где же простота? Напишите, например, аналог этого на Delphi и еще раз подумайте о простоте:

kuj>>

kuj>>#include "stdafx.h"
kuj>>#include <list>
kuj>>#include <hash_map>

kuj>>int _tmain(int argc, _TCHAR* argv[])
kuj>>{
kuj>>    std::list< int > strList;
kuj>>    strList.push_back(1);
kuj>>    strList.push_back(2);
kuj>>    strList.push_back(3);
    
kuj>>    stdext::hash_map<TCHAR*, int> hashTable;
kuj>>    hashTable["value 1"] = 1;
kuj>>    hashTable["value 2"] = 2;
kuj>>    hashTable["value 3"] = 3;

kuj>>    std::list< int >::const_iterator strListIter = strList.begin();
kuj>>    for(; strListIter != strList.end(); strListIter++)
kuj>>    {
kuj>>        std::cout << (*strListIter) << std::endl;
kuj>>    }

kuj>>    stdext::hash_map<TCHAR*, int>::const_iterator hashTableIter = hashTable.begin();
kuj>>    for(; hashTableIter != hashTable.end(); hashTableIter++)
kuj>>    {
kuj>>        std::cout << "[" << hashTableIter->first << "] = " << hashTableIter->second << std::endl;
kuj>>    }

kuj>>    std::cout << hashTable["value 1"] << std::endl;
kuj>>    std::cout << hashTable["value 2"] << std::endl;
kuj>>    std::cout << hashTable["value 3"] << std::endl;

kuj>>    return 0;
kuj>>}
kuj>>

S> Написать типизированный hashTable 2 минуты,
Докажите. А потом посмотрим на ваш код, на его читабельность, на его эффективность. Кстати, интересно так же узнать, как без перегрузки операторов Вы повторите алгоритм работы operator[]...
S>очереди пол минуты.
А с каких это пор двусвязный список стал очередью? Он как минимум дек. Хотя и деком эту структуру никак нельзя назвать. Это именно двусвязный список.
S>Какие проблемы?????
1) читабельность кода, 2) эффективность реализации, 3) целесообразность (изобретаем велосипед), 4) потенциальный источник дополнительных ошибок (в основном алгоритмического типа).

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Serginio1, Вы писали:

S>>> А что говорить с автозапчастями,

AVK>>О, это делал. Никаких десятков тысяч интерфейсов, смею тебя уверить.
S> Смотря как делал.

Хорошо.

S> Если брать каталоги запчастей к разного рода иномарок, то классификаторов там огромная куча. Это не относится к учету а к поиску нужных деталей.

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

S>Конечно 10 тысяч это черезчур.

А чего тогда споришь?

AVK>>А там что? Там с точки зрения автоматизации вобще все довольно примитивно.
S> Это с точки зрения автоматизации учета, но никак не классификации товара. Так как групп препаратов очень много со всоим набором свойств.

И при чем тут количество интерфейсов?

AVK>>Отлично. Не вижу зачем для этого десятки тысяч интерфейсов.
S> Все зависит от количества групп классификаторов.

Не зависит.

S>Но есть еще и программные библиотеки
S> Смотрим на Ёксель ХП то там насчитывается порядка 400-500 интерфейсов.

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

S> А если ссумировать весь Net????

Суммируй.

AVK>>Да, разумеется. ВОт только почему то ни в одной реальной КИС я такого количества интерфейсов не встречал. Не подскажешь почему?
S> Да сложно все это. Упрощение залог здоровья.

О как. Так нафига ты рассказываешь байки про ужасное пожирание памяти в itable? Опять сферический конь в вакууме?

S> Тем более, что такого рода системы универсальны, и далеки от реальных потребностей предприятий.

Я видел и неуниверсальные, нет там такого количества интерфейсов.

S> Как то читал, что Банк заказал IBM систему учета стоимостью под миллиард.
S> В любом случае 10 тысяч это не рядовое приложение, но вполне вероятно.

Вобщем я уже понял. Ты не видел, просто трепишься.

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, kuj, Вы писали:

kuj>Изучать исходники Делфи <...> как пример неудачной архитектуры.
+

By the grace of God Almighty
And the pressures of a marketplace
The human race has civilized itself
It's a miracle

Здравствуйте, AndrewVK, Вы писали:

AVK>Мужик, ты не понял. Я делал реальную систему для сети магазинов и складов, торгующих запчастями. Не надо мне рассказывать что там и как, это я сам могу тебе подробно рассказать.
А у меня уже сделано

S>>Конечно 10 тысяч это черезчур.

AVK>А чего тогда споришь?

AVK>>>А там что? Там с точки зрения автоматизации вобще все довольно примитивно.
S>> Это с точки зрения автоматизации учета, но никак не классификации товара. Так как групп препаратов очень много со всоим набором свойств.

AVK>И при чем тут количество интерфейсов?
А это уже как проектировать. Применение интерфейсов с точки зрения программирования предпочительней, применять к набору свойств именно интерфейсы.
AVK>>>Отлично. Не вижу зачем для этого десятки тысяч интерфейсов.
S>> Все зависит от количества групп классификаторов.

AVK>Не зависит.
Опять же все зависит от проектирования. В 1С вообще нет интерфейсов, но возможность их применения повысила бы производительность труда.
S>>Но есть еще и программные библиотеки
S>> Смотрим на Ёксель ХП то там насчитывается порядка 400-500 интерфейсов.

AVK>Причем если выкинуть порождения сна разума с номерками в конце то их будет еще меньше. Ну и где десятки тысяч?
Там их 1400 уже сократил до минимума. Так это один Ёксель. Возможно применение и других монстроидальных программ.
S>> А если ссумировать весь Net????

AVK>Суммируй.
А смысл.
AVK>>>Да, разумеется. ВОт только почему то ни в одной реальной КИС я такого количества интерфейсов не встречал. Не подскажешь почему?
S>> Да сложно все это. Упрощение залог здоровья.

AVK>О как. Так нафига ты рассказываешь байки про ужасное пожирание памяти в itable? Опять сферический конь в вакууме?
Хочу стать Сказочником. Просто не очень красивое решение, но быстрое и ничего против не имею.
S>> Тем более, что такого рода системы универсальны, и далеки от реальных потребностей предприятий.

AVK>Я видел и неуниверсальные, нет там такого количества интерфейсов.

S>> Как то читал, что Банк заказал IBM систему учета стоимостью под миллиард.
S>> В любом случае 10 тысяч это не рядовое приложение, но вполне вероятно.

AVK>Вобщем я уже понял. Ты не видел, просто трепишься.
Ну ради этого и существуют форумы. Тем более тема во флейме.
А вообщето спор был о возможности.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, kuj, Вы писали:

S>> Изучи исходники Delphi и сразу все станет ясно, зачем нужны виртуальные конструкторы, класс виртуальные методы итд.
kuj>Нет, спасибо. Изучать исходники Делфи не входит в сферу моих интересов и обязаностей. Разве что, как пример неудачной архитектуры.
Да уж такое высказывание говорит о многм. И зачем это позвольте Вас спросить M$ переманила к себе Андреаса Хейлсберга, после которой потянулись суды и в итоге M$ скупила 10% акций Борланда, заключило патентное соглашение в итоге выплатив порядка 100 миллионов $. Не плохая цена за неудачную архитектуру.

... << RSDN@Home 1.1.0 stable >>

G_>>Это не в тему, вообще-то.

Но зачем кричать про революционные идеи в .NET

AVK>Вот ведь забавная штука — этот аргУмент я слышу регулярно. Где в этом топике кричали про революционные идеи .NET?

Я не про этот топик, а про MS говорю.

G_>>, если a) _НИЧЕГО_НОВОГО_ в .NET нету. _Н И Ч Е Г О_.
G_>>b) в .NET нет ни одной идеи, которая была _придумана в MS_.

AVK>Ну и? Что дальше?

kuj>>>PreProcessMessage позволяет обработать сообщение непосредственно перед dispatch.

G_>>Я не понимаю о чем Вы.

AVK>Можно обработать сообщение до того как оно попало в WndProc конкретного окна.

И? Приведенный мною код именно это и делает.

kuj>>>Модульная схема компиляции и линковки? А как это?

G_>>C++ компилирует файлы, Delphi компилирует модули.

AVK>

AVK> 5 баллов за компиляцию модулей, и еще 5 за компиляцию модулей, которые не файлы. В юмор, однозначно.

Речь о том, что в C++ изначально заложена концепция файловой компиляции, все файлы равнозначны для линкера. Хедер по сути несет
только объявления, но не говорит линкеру о том, где искать тело функции.

В дельфи и других модульных системах есть понятие модуля. при этом когда один из модулей использует другой (через uses) линкер
знает где искать и тело и объявления функции. Соотвественно есть взаимозависимость модулей и отсюда возможность частичной компиляции и пр.

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

S>>> Предпочитаю свои классы, т.к. стандартные как правило ограничены.

G_>>Это спор разработчика-одиночки и разработчика-члена-команды. Понятно, что свои компоненты ближе к сердцу и можно делать с ними все что
G_>>угодно, только иногда как ни странно важна стандартизация и абсолютная безглючность, проверенная временем.

G_>>Я тоже написал в свое время Б-дерево, идея возникла за 15 минут, реализация — за день. Только вот
G_>>_нормальное_работающее_Б-дерево_, охваченное итераторами, оптимизированное где нужно, с самопроверкой и пр. взошло не один месяц спустя.

S> Когда опираешься на собственные реализации алгоритмов и проверенные временем то они становятся для меня уже стандартными.

Для Вас — да! Но не для остальных разработчиков. Стандартизация имеет свои прелести, хотя и немного ограничивает.

S> Кстати многие сишникиеи простейших алгоритмов не знают. Зато знают вектор map итд. А переходя на C# руки опускаются.

Отчего?

G_>>Мое самое оптимизированное Б-дерево все равно было медленнее map примерно в 1.5 раза.
S> Значит таков алгоритм или его реализация. А под мап можно подогнать и Хэш таблицы и BitArray и B+ деревья и просто массив и у всех есть плюсы и минусы и своя область применения.

Я о том и говорю. Что в STL, как правило, зашиты самые удачные алгоритмы, к тому же многократно проверенные.

G_>>>>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.
S>>> Пользоваться можно чем угодно в том числе и генераторами кода.
S>>> А против стандарта и корпоративного кодирования ничего против не имею, только скучно.

G_>>Да уж, зато вставить в свою программу глючный компонент, обрушить пару сотен терминалов в самый разгар торгов,
G_>>получить сотню одновременных звонков на предмет невозможности торговать от клиентов, кучу претензий, удары по всем
G_>>частям тела от хедпдеска и от начальства и от начальства начальства — быстро начинать править код, каждый
G_>>5 сек. дергаемый словами "ну что готово" и "там опять все упало", быстро раздать это все какой-то паре сотен клиентов — вот ерунда-то! — это конечно не скучно, это очень весело!!!!!

S> Значит не надо делать глючные компоненты. А своих багов добавить и простейший код всегда пожалуйста, а во многом юзерский код оказывается намного алгоритмически сложнее чем стандартные библиотеки где кода 10 строчек.
S> Не ошибается тот кто ничего не делает, а кривизны в стандартных библиотеках хватает выше крыши как в Delphi, Net, Java.
S> Нет кривизны только в STL !!!!!!

G_>>Я тоже заметил, что в теории программирования все всегда просто. Взять алгоритм да и внедрить его.
G_>>Откуда берутся глючные программы совершенно непонятно...)

VD>А это из-за велосипидистов.

Не хотят они взять чужой алгорим, а хотят сами по граблям полазить.

Я имел в виду другое. Что корректная реализация сложного алгоритма непростая задача сама по себе.

G_>>Вот это и плохо. Borland обязана была что предпринять на эту тему.

VD>Ну, а без Борланда, что трава не расти? Что только в Борланде грамотные программисты есть?

Я немного о другом.

VD>>>Ага. А так же ее доказывает. Наличие МФЦ, АТЛ-а, буста, и других библиотек содержащих свои коллекции.

G_>>Что конкретно плохо в STL и чем она вас не устраивает?

VD>Да многим. Есть не продуманные интерфейсы, как у мап-а.

В чем непродуманность?

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

Ну все-таки Б+-деревья не каждый день нужны. А вот map это must have.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Gregory_krovosos, Вы писали:

VD>>>Вообще-то в дельфи есть тип object и record.

G_>>У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.

AVK>У object есть.

Я имел в виду, что они не вызываются при размещении объекта на стеке и следовательно object бесполезен.

VD>>>Так это наличие автоматического вызова деструктора/финалайзера. В Шарпе этого тоже нет. Но есть IDisposeble и инструкция using.

G_>>Да, действительно.

G_>>Немного отступая от темы — непонятно зачем вC# делать так неудобно?????

AVK>Потому что GC

G_>>Это совместимость с какой-то предыдущей OLE-байдой?

AVK>Нет

G_>>Почему нельзя было для любого класса просто дернуть деструктор

AVK>Потому что деструктора нет.

Ну есть же finalize, зачем нужно воротить?

G_>> вместо наследования IDisposable,

AVK>Реализации, не наследования.

Разумеется.

G_>> переопределения двух методов

AVK>Каких двух методов?

Сори, одного. Ну чтобы понять что я имел в виду надо просто посмотреть пример в MSDN для IDisposable.
Вместо упрощения — усложнение кода.

G_>>Спасибо за инфу, но это все таки хеш. А нужно AVL-дерево или аналог.

VD>Ты говорил про мап. Мап самым эффективным образом реализуется на хэш-таблице.

Ну если элементов не много, то да.

VD>С деревьями у борланда фигово.

G_>>Порядок строк важен!

VD>А два листа чем не устраивают?

Ну понятно, что можно написать все что угодно

Речь идет о простом решении.

G_>>У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.

VD>А что толку в деструкторах в Дельфи? Один фиг вручную вызывать.

Я о том же.

G_>>Немного отступая от темы — непонятно зачем вC# делать так неудобно????? Это совместимость с какой-то предыдущей OLE-байдой?
G_>>Почему нельзя было для любого класса просто дернуть деструктор вместо наследования IDisposable, переопределения двух методов и пр.
G_>>Я не понимаю...

VD>Да в общем то сложности никакой нет. Метод переопределят нужно только один.

VD>А почему нет деструктора... Сдается мне это в погоне за чистотой языка. В общем, догмы. Хотя имея трехлетний опыт программирования на Шарпе могу со всей отвественностью заявить, что проблем в этом нет никакий. Финализация нужна крайне редко. И гед она нужна обычно достаточно using-а.

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

G_>>Как бы не вышло опять гладко в теории, а на практике...

VD>Да вот как бы от Дельфи в свое время мы отказались в виду ужасного количества глюков в ВЦЛ-е (еще во времена 4-ой версии), а дотнет вроде как удовлетворяет.

Я с 4-кой не работал, начал с 1-ой версии дельфи

и потом перепрыгнул сразу на 5-ю

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

G_>>Я честно говоря не понял — какой кайф? Хочешь .NET — берешь VS .NET + C# и пишешь. Хочешь нейтив код — берешь Delphi 7 и пишешь.

VD>Ну, если ты в основном писал на Дельфи, то кайф в том что не нужно переучиваться.

G_>>Смысл появление Delphi .NET от меня ускользнул...Ведь и так можно в C# запускать нейтив код...
G_>>Создать очередную всеобъемлющую супер-пупер-унаследованную библиотеку классов?
G_>>Не понял я...

VD>Думаю, что решение о переводе Дельфи на дотнет было принято не от болды. Скорее всего ребята поняли, что МС серьезно переориентируется на него и решили не упускать шанса.

Что ж посмотрим, что выйдет из этого.

PS Не в тему — как шарп относится к ресурсам? В смысле работащее приложение много жрет?

Здравствуйте, Gregory_krovosos, Вы писали:

G_>>>Почему нельзя было для любого класса просто дернуть деструктор

AVK>>Потому что деструктора нет.

G_>Ну есть же finalize, зачем нужно воротить?

Финалайзер это совсем другое.

... << RSDN@Home 1.1.4 beta 1 >>

Здравствуйте, Serginio1, Вы писали:

S>>> Изучи исходники Delphi и сразу все станет ясно, зачем нужны виртуальные конструкторы, класс виртуальные методы итд.
kuj>>Нет, спасибо. Изучать исходники Делфи не входит в сферу моих интересов и обязаностей. Разве что, как пример неудачной архитектуры.
S> Да уж такое высказывание говорит о многм.
Борланд это тоже осознала.
S>И зачем это позвольте Вас спросить M$ переманила к себе Андреаса Хейлсберга,
На ошибках учатся. Не привлекать же им архитекторов MFC.

S>после которой потянулись суды и в итоге M$ скупила 10% акций Борланда, заключило патентное соглашение в итоге выплатив порядка 100 миллионов $. Не плохая цена за неудачную архитектуру.
А при чем тут архитектура? Архитектура VCL, к счастью, осталась в прошлом.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Gregory_krovosos, Вы писали:

G_>Ну если элементов не много, то да.

Много понятие относительное. Скажем так пока памяти хватает и можно построить хороший хэш-то хэш-таблица лучший выбор.

G_>Ну понятно, что можно написать все что угодно

Речь идет о простом решении.

Написать простой класс — это сложное решение?

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

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

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

G_>Я с 4-кой не работал, начал с 1-ой версии дельфи

и потом перепрыгнул сразу на 5-ю

VCL конечно не идеал, но в целом более менее.

А вот мы начали со 2-ой и мучились до 4-той.

G_>Глюков (явных) заметил всего несколько штук, при этом они исправляются.

Ну, ждать от моря погоды было некогда.

G_>PS Не в тему — как шарп относится к ресурсам? В смысле работащее приложение много жрет?

Памяти? Памяти оносительно много. По крайней мере больше чем С++ и Дельфи. Но на современных объемах более чем приемлемо. К тому же ЖЦ (отвественное за пожирание памяти) — это такой алгоритм, что он будет работать быстрее на большем общеме за счет пожирания памяти, и не будет жрать памтяи если ее мало, но естественно будет работать медленнее.

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

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, Gregory_krovosos, Вы писали:

G_>Я имел в виду другое. Что корректная реализация сложного алгоритма непростая задача сама по себе.

Дык если делать все с умом, с проектированием, с подбором средств и алгоритмвом, то и программы надежно работают.

VD>>Ну, а без Борланда, что трава не расти? Что только в Борланде грамотные программисты есть?

G_>Я немного о другом.

А я о том. Почему то Дельфи приучает не писать самому. Компонентик там или формочку это можно. А коллекцию — ни, ни... что вы?
Это системная область...

G_>В чем непродуманность?

Устал объяснять. Стройная ОО-модель подразумевает, что понятия четко определены, полноценны, не избыточны и просты в применении. Так вот всем этим параметрам СТЛ как следует не удовлетворяет. Она мешат понятия. Например, вектор полностью смешан со стэком. Не верно определяет их. Например, мап содержит в интерфейсе методы упорядоченного доступа к элементам, а это противоречит концепции мапа. Мап должен сопоставлять один объект с другим. Самый эффектинвный алгоритм тут был бы хэш-таблица. Но в СТЛ испльзуется дерево. Далее сама библиотека построена не в ОО-стиле, а в функциональном. Это может быть дает большую универсальность и гибкость. Но это точно резко усложняет восприятие и изучение библиотеки. Ее практически нельзя использовать без предварительного изучения в учебниках.

G_>Ну все-таки Б+-деревья не каждый день нужны. А вот map это must have.

Если бы они были, то их мап-ы и деревья были бы на фиг не нужны. И данные можно было бы легко хранит на диске.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, kuj, Вы писали:

S>>после которой потянулись суды и в итоге M$ скупила 10% акций Борланда, заключило патентное соглашение в итоге выплатив порядка 100 миллионов $. Не плохая цена за неудачную архитектуру.
kuj>А при чем тут архитектура? Архитектура VCL, к счастью, осталась в прошлом.
Вообщето разговор отнюдь не о VCL, эта малая толика того что есть в Delphi и является побочным продуктом архитектуры Delphi как таковой. Если ты судишь по Delphi только по VCL то разговор у нас очень содержательный.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Gregory_krovosos, Вы писали:

G_>>>>Почему нельзя было для любого класса просто дернуть деструктор

AVK>>>Потому что деструктора нет.

G_>>Ну есть же finalize, зачем нужно воротить?

AVK>Финалайзер это совсем другое.

Чем он принципиально отличается от деструктора?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gregory_krovosos, Вы писали:

G_>>Ну если элементов не много, то да.

VD>Много понятие относительное. Скажем так пока памяти хватает и можно построить хороший хэш-то хэш-таблица лучший выбор.

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

Можно конечно таблицам в хешах динамически менять размер, но думаю так не делается, иначе это уже все будет
сильно напоминать B+-дерево.

G_>>PS Не в тему — как шарп относится к ресурсам? В смысле работащее приложение много жрет?

VD>Памяти? Памяти оносительно много. По крайней мере больше чем С++ и Дельфи. Но на современных объемах более чем приемлемо. К тому же ЖЦ (отвественное за пожирание памяти) — это такой алгоритм, что он будет работать быстрее на большем общеме за счет пожирания памяти, и не будет жрать памтяи если ее мало, но естественно будет работать медленнее.

VD>Остальные же ресурсы как любой другой компилятор. Ну, еще грузятся приложения несколько медленнее.

А почему не взяли Яву?

	От:	akasoft
	Дата:	07.05.04 16:51
	Оценка:

	От:	kuj
	Дата:	08.05.04 14:07
	Оценка:	+1 -1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	08.05.04 20:25
Оценка:

От:	SilverCloud	http://rodonist.wordpress.com
Дата:	09.05.04 15:25
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	11.05.04 11:10
Оценка:

	От:	Gregory_krovosos
	Дата:	12.05.04 12:35
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	12.05.04 23:28
Оценка: