Здравствуйте, hattab, Вы писали:
H>Здравствуйте, dim-s, Вы писали:
d>>Делфи как язык с платным и закрытым компилятором не может существовать в современном мире.
H>Реальность с тобою не согласна Все же качество FPC и Lazarus не дотягивает до дельфей, что впрочем не удивительно.
Бесплатность, открытость, кроссплатформенность, 64 битные версии с лихвой окупают эти недостатки. Конечно не так удобно для тех, кто кидает компоненты и пишет код только в событиях =). Отладка в последних версиях лазаруса стала вполне хорошей.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, dim-s, Вы писали:
d>> И так, Делфи это не только Борланд или кодегеар, это не только 500$ за минимальную лицензию, это не только Windows зависимость, но это также opensource компилятор FreePascal под win, mac, linux, iphone и другие платформы, это также opensoucre IDE Lazarus со своей системой библиотек GUI, которая обеспечивает кроссплатформенность без свистоплясок.
H>У дельфей выходит (на след. неделе, кажется) стартер едишн за $200. Следующая версия (после XE) обещает кроссплатформу и 64 бита. FPC действительно неплох, но лично мне для работы с ним не хватает поддержки advanced records и nested types, которые уже появились в ветке 2.5.1, но пока официально не релизнуты.
На мой взгляд, даже когда делфи сделают кроссплатформенной она все равно не сможет сразу догнать в этом плане лазаруса и freepascal, потому что под lazarus написано огромное количество кросс гуи компонентов. А цена 200$, интересно, можно ли на этой лицензии делать комерческие продукты? И кстати я думаю цена кроссплатформенной делфи и делфи только под windows будут ох как отличатся, достаточно глянуть на QT creator.
А у fpc есть advanced records не только в 2.5.1, но и в 2.4.2 по-моему. Может быть они там ограниченные, но например переопределять операторы можно. Что же говорить о вложенных типах? Мне кажется пора бы вспомнить Вирта, и все эти возможности уже есть, просто подход с другого места, а суть все равно одна. Для чего собственно объекты, я боюсь recordы превратятся в объекты аля стиля object pascal.
Здравствуйте, dim-s, Вы писали:
d> Бесплатность, открытость, кроссплатформенность, 64 битные версии с лихвой окупают эти недостатки.
Да я согласен, кто же спорит, но код генерится тормозной (не в доску конечно, но все же). У дельфи компилятор далек от идеала, а у FPC выходит еще дальше.
d> Конечно не так удобно для тех, кто кидает компоненты и пишет код только в событиях =). Отладка в последних версиях лазаруса стала вполне хорошей.
Да я вообще не о дизайнере говорю (как по мне так в LCL совсем даже не плохо сделаны привязки контролов, можно вообще без layout'ов обходиться, в VCL такого нет), я говорю о качестве
Я и сам порадуюсь, когда выйдет 2.5.1 и я смогу свой проект скомпилить под Линукс, даже если к тому времени уже выйдет кроссплатформенная дельфя
Здравствуйте, dim-s, Вы писали:
d> H>У дельфей выходит (на след. неделе, кажется) стартер едишн за $200. Следующая версия (после XE) обещает кроссплатформу и 64 бита. FPC действительно неплох, но лично мне для работы с ним не хватает поддержки advanced records и nested types, которые уже появились в ветке 2.5.1, но пока официально не релизнуты.
d> На мой взгляд, даже когда делфи сделают кроссплатформенной она все равно не сможет сразу догнать в этом плане лазаруса и freepascal, потому что под lazarus написано огромное количество кросс гуи компонентов.
Ну так и Москва не сразу строилась. Главное, что будет официальная поддержка кроссплатформы. Под тот же CLX (кроссплатформенный аналог VCL в Kylix на основе Qt) компоненты появлялись достаточно быстро, некоторые до сих пор декларируют совместимость с CLX.
d> А цена 200$, интересно, можно ли на этой лицензии делать комерческие продукты? И кстати я думаю цена кроссплатформенной делфи и делфи только под windows будут ох как отличатся, достаточно глянуть на QT creator.
Да, разрабатывать коммерческий софт на стартере можно, но там ограничение на доходность компании (впрочем это не проблема, ведь как только софт начнет приносить прибыль можно и до проф. апгрейдиться)
d> А у fpc есть advanced records не только в 2.5.1, но и в 2.4.2 по-моему. Может быть они там ограниченные, но например переопределять операторы можно.
Нету adv.records в 2.4.2 (они даже в 2.5.1 еще ограничены, не имеют конструкторов) Перегрузка операторов это еще не все
d> Что же говорить о вложенных типах? Мне кажется пора бы вспомнить Вирта, и все эти возможности уже есть, просто подход с другого места, а суть все равно одна.
Вложенные типы нужны для улучшения инкапсуляции, это очевидно, как по мне Самый банальный пример это TList и TList.TEnumerator вместо TList и TListEnumerator.
d> Для чего собственно объекты, я боюсь recordы превратятся в объекты аля стиля object pascal.
Object уже давно объявлены obsolete и поддерживаются только для обратной совместимости. А adv.records удобно использовать вместо обычных классов/объектов в тех случаях где делать инстанционирование объектов неудобно (скажем, мелкие объекты типа TStopwatch).
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, dim-s, Вы писали:
d>> Бесплатность, открытость, кроссплатформенность, 64 битные версии с лихвой окупают эти недостатки.
H>Да я согласен, кто же спорит, но код генерится тормозной (не в доску конечно, но все же). У дельфи компилятор далек от идеала, а у FPC выходит еще дальше.
d>> Конечно не так удобно для тех, кто кидает компоненты и пишет код только в событиях =). Отладка в последних версиях лазаруса стала вполне хорошей.
H>Да я вообще не о дизайнере говорю (как по мне так в LCL совсем даже не плохо сделаны привязки контролов, можно вообще без layout'ов обходиться, в VCL такого нет), я говорю о качестве
H>Я и сам порадуюсь, когда выйдет 2.5.1 и я смогу свой проект скомпилить под Линукс, даже если к тому времени уже выйдет кроссплатформенная дельфя
Ну на счет тормознутости генерируемого asm кода fpc я бы не сказал, максимум он отстает на 20%. Знаю что там тормознутый SetLength например, но можно же использовать функции для выделения памяти, что и сделано в реализации TList и т.п. Например TList в лазарусе быстрее чем в делфи, а юникод в Гуи был с самого начала, но там как-то так сделали, что нет проблем с ansistring и юникодным gui. У меня были некоторые тесты, где fpc выигрывал у делфи в 4-5 раз, а было и наоборот.
Здравствуйте, hattab, Вы писали:
d>> А у fpc есть advanced records не только в 2.5.1, но и в 2.4.2 по-моему. Может быть они там ограниченные, но например переопределять операторы можно.
H>Нету adv.records в 2.4.2 (они даже в 2.5.1 еще ограничены, не имеют конструкторов) Перегрузка операторов это еще не все
Ну а что мешает написать функцию record'a которая будет возвращать созданный объект в куче. И тот же Free =).
Здравствуйте, dim-s, Вы писали:
d> H>Нету adv.records в 2.4.2 (они даже в 2.5.1 еще ограничены, не имеют конструкторов) Перегрузка операторов это еще не все
d> Ну а что мешает написать функцию record'a которая будет возвращать созданный объект в куче. И тот же Free =).
Конструкторы записей размещают их на стеке, а не в куче. Впрочем, есть надежда, что конструкторы в 2.5.x таки появятся.
Здравствуйте, dim-s, Вы писали:
d> Ну на счет тормознутости генерируемого asm кода fpc я бы не сказал, максимум он отстает на 20%.
Я как то тестировал на своих задачах — ~30%. С вариантами вообще 40%. Можешь сам проверить:
v : Variant;
i : Integer;
v := 1;
for i := 1 to 100000000 do
v := v + v / v;
Delphi 2010 — 9 сек. FPC 2.5.1 — 15 сек.
d> Знаю что там тормознутый SetLength например, но можно же использовать функции для выделения памяти, что и сделано в реализации TList и т.п. Например TList в лазарусе быстрее чем в делфи
С чего бы TList'у в FPC быть быстрее дельфийского, когда они реализованы одинаково?
d>, а юникод в Гуи был с самого начала, но там как-то так сделали, что нет проблем с ansistring и юникодным gui.
Ну в гуе у них Linux way Сделали UTF-8 в ансистроках.
d> У меня были некоторые тесты, где fpc выигрывал у делфи в 4-5 раз, а было и наоборот.
Как говорится, тесты в студию! Самому интересно посмотреть.
По своей сути паттерн посетитель позволяет, не изменяя классы, добавлять в них новые операции. Достигает он этого с помощью приема, называемого двойной диспетчеризацией. Данная техника хорошо известна.
Дизайн шаблона, который решает проблемы такого рода, называется "визитер" (это последний дизайн шаблона в книге "Design Patterns"), и он строится на схеме двойной диспетчеризации, показанной в предыдущем разделе.
Широко распространён пример с обходом древовидной структуры, где для каждого типа узла вызываются определённые операции. Чтобы избежать в коде уродливых switch/case в языках с передачей сообщений (C++/Java/SmallTalk/C#/e.t.c.) используют паттерн "Visitor", в реализации которого используется двойная диспетчеризация.
Ну и сама книжка GOF, разумеется. В ней об отношении этого паттерна и способа двойной диспетчеризации рассказано подробно. Другое дело, что авторы считают тему мультиметодов сложноватой, а книга изначально расчитана на новичков, поэтому и качество подачи материала соответствующее, и термины подобраны "приземленные".
НС>Ссылка в гугль эквивалентна посыланию на три или пять букв.
Ну, требование ссылок на легкодоступную информацию в приличном обществе, в свою очередь, эквивалентна автоматическому самопосыланию.
V>>Например, именно ввиду упомянутого возможна обобщенная библиотечная реализация паттерна визитор в C++, в то время как в дотнете библиотечная реализация этого паттерна принципиально невозможна.
НС>Обобщенная — наверное нет, хотя без внимательного рассмотрения вопроса я бы не стал это с абсолютной уверенностью утверждать.
Рассматривали, поверь. Выходит только на рефлексии (через рефлексию вообще можно что угодно, понятное дело, со всеми её тормозами), или через кодогенерацию, что уже не тянет на библиотечность.
НС>А вот частный случай вполне возможен. И при рукопашной реализации частного случая визитор визитором быть не перестает, не так ли?
Частный случай не может попасть в библиотеку, ибо кол-во и сигнатура методов accept() у визитора зависит от конкретного семейства обслуживаемых типов. Т.е. обслужить заведомо неизвестное семейство типов такая реализация не в состоянии.
НС>Но ты то изначально утверждал несколько другое: НС>
НС>>Это не паттерн Visitor, а какая то фигня. Паттерн используется, когда нужна диспетчеризация по типам с общим корнем.
НС>На статическом полиморфизме визитор тоже прекрасно работает, например в С++.
НС>Прошу обратить внимание, чему именно ты противопоставляешь статику.
Коллега... А ты точно нам коллега? А то меня уже не в первый раз терзают смутные сомнения... Особенно когда ты оперируешь MSDN-ом и википедией вместо своего мнения.
Понимаешь, статика может быть противопоставлена в том контексте только "общему корню". Уверен, любому коллеге даже не хватит воображения противопоставить статику в том контексте чему-либо другому.
V>>Вообще-то, это принципиально для случая "внешнего" обхода
НС>Ять! Визитор предназначен для внешнего "подключения" алгоритма. По определению! Слово "обход" у тебя, кстати, очень показательно.
Нет такого определения и такого предназначения. В первоисточнике сказано:
Ответственность за обход можно возложить либо на саму структуру объектов, либо на посетителя либо на отдельный объект-итератор (см. паттерн итератор).
Чаще всего структура объектов отвечает за обход. Коллекция просто обходит все свои элементы, вызывая для каждого операцию Accept. Составной объект обычно обходит самого себя, «заставляя» операцию Accept посетить потомков текущего элемента и рекурсивно вызвать Accept для каждого из них.
Вот на это я обратил внимание, говоря, что требование посещаемым объектам быть виртуальными — непринципиально, и зависит от сценария обхода. Поэтому ты серьезно ошибся в утверждении насчет обязательности посещаемому быть виртуальным. Ну а насчет необязательности самого визитора быть виртуальными ты уже дважды согласился, и тут ты прав, хотя это тоже "немного противоречит" описанию паттерна. Но там же лажа полная местами: "Для полной независимости посетители имеют отдельную от обслуживаемых структур иерархию". Это что-то вроде телепатического ООП-анализа на расстоянии или как этот грубый косяк назвать?
Конкретно в паттерне они сразу ввели абстрактного посетителя, чтобы можно было подавать разные объекты посетителей для обхода структуры. Но ведь это вообще ортогонально поставленной ими же проблематике и является overdesign для этого паттерна. Если такое требование возникает в конкретных случаях, то для эти случаев они уже давали соотв. паттерны выше в той же самой книге. В общем, на лицо немного сумбур и недостаточный анализ собственных же приводимых примеров. Простить их можно только в том случае, если вспомнить, на какую аудиторию расчитана данная книга: т.е. это что-то из области "полезных советов для начинающих ООП-адептов".
Так что вопрос остается в силе:
Совершенно не понимаю твоей логики, почему одну часть паттерна можно модифицировать, а другую нельзя.
В общем, в решении подразумевается отсутствие навыков инкапсуляции, и отсюда ошибочное требование абстрактного посетителя. Сермяжная правда в том, что эта абстракция в реальной жизни нужна в менее половины случаев, потому как визитор по большей части используется не в AST, а в тех случаях, когда некие близкие по характеру операции в множества однородных объектов было решено вынести в некий другой объект, отвечающий за такие близкие по характеру операции. Т.е. чаще всего ровно один тип посетителя, связанный с данным семейством типов, потому и не требуется для него абстрактный интерфейс. Осталось сделать еще один маленький шажок и понять, что это семейство не обязано быть "из одного корня". Вот конкретно на что было изначальное возражение.
НС>Визитор это не обход, это диспетчеризация.
Мы что, уже успели поменять местами, или ты решил начать маневры?
Единичный вызов визитора действительно и есть банальная диспетчеризация мультиметода, о чем я и говорю. Заменив этот единственный вызов на понятие "обход", адепты свидетелей GOF с пеной у рта доказывают, что визитор не есть двойная диспетчеризация, а лишь испопльзует её как инструмент (да и авторы явно об этом пишут в GOF). Более разумные авторы пишут, что в языках с множественной диспетчеризацией паттерн визитор не нужен по определению. Я лишь добавлю, что если эта же возможность достигается библиотечной двойной диспетчеризацией, то паттерн тоже не нужен. Вернее, ср-ва, ради которых паттерн строился, по прежнему нужны, но в выделенном виде этот паттерн не нужен, ибо полностью дублируется механизмом множественной диспетчеризации. Всю цепочку рассуждений на этот раз отследил? Просто как бэ 3-й раз одно и то же разынми словами талдычить... мы же в общественном месте... это ты паранджу натянул, а я человек публичный...
НС>Обход, конечно, иногда может быть встроен (далеко не всегда!), но это конкретная реализация, комбинирующая несколько вещей. В паттерне никакого обхода нет.
Похоже, ты наконец прошелся по ссылкам из поисковика, похвально. Еще чуть-чуть и ты ухватишь изначальную проблематику паттерна, и спор утихнет сам собой.
Правда, выглядит так, что разыне части этого поста ты писал, обладая разной информацией, иначе к чему твое "ять", если обход не принципиален? Так он есть или нет? Мы обходим элементы коллекции или инкапсулированные поля известного типа? Так нужен общий корень или не нужен?
НС>Без софистики, подтасовок и упорном нежелании ссылаться на реальные определения.
Беда в том, что не все определения формальны. Например, "множественная диспетчеризация" имеет формальное определение, а "визитор" — нет, там воды на несколько страниц. Отсюда бодание на ровном месте. Именно поэтому я попросил поделиться, что есть на твой взгляд "жонглирование терминами" в данном контексте. Жаль, что ты не понял намека, и что-то там оффтопное буркнул в ответ.
V>> По твоей логике здесь тоже должны быть принципиально виртуальные ф-ии
НС>Это по твоей логике.
Это кое-кто уже банально упускает нить беседы. Это ведь ты требуешь следовать букве паттерна, а я пытаюсь возражать, говоря, что для сохранения работоспособности паттерна это необязательно.
НС>В GoF есть еще и определение паттерна. Перечитай.
Вот именно. Перечитай. Там достаточно страниц описания на каждый паттерн, насколько я помню, так что давай копируй сюда то, что ты считаешь формальным определением. ИМХО, описание решения никак не может претендовать ни на какое формальное определение. И уж тем более то описание не в состоянии обособить этот паттерн от формального определения множественной диспетчеризации. Так что наши ваших бьют.
НС>Модифицировать можно что угодно. Но если после этого определение (не пример, а именно определение) перестает подходить, то оно перестает быть визитором. Все очень просто.
Повторю, не вижу формального определения паттерна. Вижу лишь постановку задачи, и способ ее решения на двойной диспетчеризации.
НС>Это не корень взаимонепонимания, а кое кто не потрудился понять, на что же он все таки отвечал.
Я уже прояснил, на что именно я отвечал. И там вариантов и нет особо.
НС>Возможно. Но это не может быть реализовано статически. На статику можно заменить реализацию визитора, но нельзя сделать статическим сам механизм диспетчеризации. Как нельзя сделать полностью статическими мультиметоды или PM по АлгТД.
Мммм... как нудно и как далеко от темы.
Что есть "статически" применительно к С++:
— инлайновость
— оптимизации на основе видимости конкретных типов и значений
— выкидывание лишнего кода на основе анализа.
Т.к. ты фактически воспринимаешь менее из 50% того, что я тебе пишу, поэтому рассмотрю подробный пример.
Берем некоего посетителя БЕЗ виртуальных методов...
Ну реально, абстракция посетителя на интерфейсах в условиях шаблонов С++ не нужна. Более того, в классической двойной диспетчеризации достаточно сделать абстрактным лишь один объект, а вторая часть диспетчеризации выполняется прямо в теле виртуального метода, вызывая нужную перегрузку первого участника мультиметода. Т.е. зачем в двойной диспетчеризации еще третий шаг этой диспетчеризации — непонятно.
Шаг второй, расмотрим, когда объект сам обходит свою структуру, т.е. вызывет visit() для объектов разных типов. Фишка в том, что эти объекты так же не объязаны быть из одного корня. Один корень в классическом ООП используется там для повторного использования кода, т.е. для реализация метода accept() лишь однажды в базе.
Но, однократную реализацию можно сделать и на шаблонах C++:
template<typename ConcreteVisitable>
class Visitable {
public:
template<typename Visitor>
void visit(Visitor * visitor) {
visitor->accept(static_cast<ConcreteVisitable*>(this));
}
};
class SomeElement1 : public Visitable<SomeElement1>
{
};
class SomeElement2 : public Visitable<SomeElement1>
{
};
template<typename Type1, typename Type2>
class BinaryElement {
Type1 elem1;
Type2 elem2;
public:
template<typename Visitor>
void visit(Visitor * visitor) {
elem1.visit(visitor);
elem2.visit(visitor);
}
}
...
BinaryElement<SomeElement1, SomeElement2> binElem;
ConcreteVisitor visitor;
binElem.visit(&visitor);
Фишка в том, что SomeElement1 и SomeElement2 не имеют общий корень. Вот такая особенность наследования от шаблонов. Они наследуют 2 разных типа: Visitable<SomeElement1> и Visitable<SomeElement2>.
Особенно всё прикольно выходит, когда приличную часть функциональности целевого accept тоже делают шаблонным. Для чего же здесь тогда двойной вызов? А читаем еще раз ПРОБЛЕМАТИКУ в описании паттерна. Т.е. когда нам потребуются реализации accept, не описываемые в общем виде на шаблонах, то мы сможем эту реализацию менять/добавлять, не трогая клиентские классы.
В примере был показан случай полностью статической диспетчеризации на шаблонах. В этом случае, когда компилятор видит все типы и может их вывести — происходит статический вызов прямо нужного метода, а учитывая инлайновость, и обычно легковесность операций... в общем, там затраты в сравнении с затратами в варианте на виртуальных ф-иях отличаются более чем на порядок в реальной жизни. Так же в реальной жизни это решение обычно комбинированное, например, если есть некая коллекция верхнего уровня, то её участники могут поддерживать некий общий интерфейс. Но после этой "точки входа" весь обход может идти уже статически. Что мы имеем — фактической использование одной и той же реализации для обоих случаев, полная идентичность дизайна, легкость в переходе на реализацию на виртуальных ф-иях или обратно в статику (базу поменяли и всех делов).
Т.е. тот факт, что зачастую всё проиходит в статике — это можно принять за внутреннее дело компилятора. Можно считать, что мы о ней не знаем, и честно пишем себе классического визитора. А так оно и есть, техника двойной диспетчеризации по-прежнему нужна (пусть даже она порой работает лишь на этапе компиляции), чтобы выйти на конкретный мультиметод, который опять же компилятор вправе "раскрутить" и сделать из него обычную ф-ию, если у него хватает информации.
И напоследок: насчет алгТД и паттерн-матчинга ты категорически не прав. Если оптимизирующий компилятор видит весь пусть возникновения значения, то вместо диспетчеризации в runtime он может сделать это же в compile-time. Фактически, это суперкомпиляция, которая стирает границы м/у runtime и compile-time. И опять же фактически, С++ стал суперкомпилятором с тех пор, как в него вошли inline функции и методы. И вот это всё "статикой" в С++ и называется, т.е. еще раз для закрепления: 1. возможность писать обобщенный код, который в ходе компилирования инстанциируется до конкретных типов, не требуя в 99% случаев применения техники абстрактных классов (в сравнении с Pascal/Java/C#/...), 2. суперкомпиляция, умеющая часть вычислений производить в compile-time, подменяя динамику на статику.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, dim-s, Вы писали:
d>> Ну на счет тормознутости генерируемого asm кода fpc я бы не сказал, максимум он отстает на 20%.
H>Я как то тестировал на своих задачах — ~30%. С вариантами вообще 40%. Можешь сам проверить: H>
H> v : Variant;
H> i : Integer;
H> v := 1;
H> for i := 1 to 100000000 do
H> v := v + v / v;
H>
H>Delphi 2010 — 9 сек. FPC 2.5.1 — 15 сек.
d>> Знаю что там тормознутый SetLength например, но можно же использовать функции для выделения памяти, что и сделано в реализации TList и т.п. Например TList в лазарусе быстрее чем в делфи
H>С чего бы TList'у в FPC быть быстрее дельфийского, когда они реализованы одинаково?
d>>, а юникод в Гуи был с самого начала, но там как-то так сделали, что нет проблем с ansistring и юникодным gui.
H>Ну в гуе у них Linux way Сделали UTF-8 в ансистроках.
d>> У меня были некоторые тесты, где fpc выигрывал у делфи в 4-5 раз, а было и наоборот.
H>Как говорится, тесты в студию! Самому интересно посмотреть.
Ты учти, в режиме отладки в среде lazarus код может замедлятся в 2-50 раз, я сам был в шоке, вот ты проверь скорость без среды, просто запусти ехе и проверь. У меня был прикол TFPList отец TList работал в 10 раз медленнее почему-то, после чего оказалось из-за отладки.
Здравствуйте, dim-s, Вы писали:
d> Ты учти, в режиме отладки в среде lazarus код может замедлятся в 2-50 раз, я сам был в шоке, вот ты проверь скорость без среды, просто запусти ехе и проверь. У меня был прикол TFPList отец TList работал в 10 раз медленнее почему-то, после чего оказалось из-за отладки.
Ну, что я маленький, время мерять из среды да еще и не на релиз настройках Все по честному для обоих проектов: Настройки компилятора — максимум оптимизации, отключение всех проверок, выкидывание дебаг-инфо. Включение режима High Performance (чтоб Cool'n'Quiet на результат не повлиял) и несколько запусков каждого теста (оба проекта консольные, замерялось только время цикла).
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, dim-s, Вы писали:
d>> Ты учти, в режиме отладки в среде lazarus код может замедлятся в 2-50 раз, я сам был в шоке, вот ты проверь скорость без среды, просто запусти ехе и проверь. У меня был прикол TFPList отец TList работал в 10 раз медленнее почему-то, после чего оказалось из-за отладки.
H>Ну, что я маленький, время мерять из среды да еще и не на релиз настройках Все по честному для обоих проектов: Настройки компилятора — максимум оптимизации, отключение всех проверок, выкидывание дебаг-инфо. Включение режима High Performance (чтоб Cool'n'Quiet на результат не повлиял) и несколько запусков каждого теста (оба проекта консольные, замерялось только время цикла).
Оптимизация -Or включена? — Хранить некоторые переменные в регистрах.
К тому же я просто никогда не пользуюсь Variant'ом. Могу скинуть один класс, в котором делфи проигрывает в 4 раза, класс называется TStringArray, это почти TStringList, но там выделение памяти идет кусками, за счет чего добавление нового элемента в список становится намного быстрее.
Здравствуйте, dim-s, Вы писали:
d> Оптимизация -Or включена? — Хранить некоторые переменные в регистрах.
Включена.
d> К тому же я просто никогда не пользуюсь Variant'ом.
Зато он используется в db-access компонентах, да и вообще, варианты это частный случай. У меня и на чисто вычислительных алгоритмах FPC проседал
d> Могу скинуть один класс, в котором делфи проигрывает в 4 раза, класс называется TStringArray, это почти TStringList, но там выделение памяти идет кусками, за счет чего добавление нового элемента в список становится намного быстрее.
Т.е. код будучи скомпилирован в дельфях сольет в 4 раза скомпилированному в FPC? Давай код, будем посмотреть
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Вообще говоря визитор это не только когда диспетчеризация по типам с общим корнем.
НС>Вообще говоря только. По определению. НС>
НС>... the visitor allows one to add new virtual functions to a family of classes without modifying the classes themselves; instead, one creates a visitor class that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.
НС>Википедия
Мухлёшь. Определение шло выше, и оно практически идентично описанной проблематике из GOF:
In object-oriented programming and software engineering, the visitor design pattern is a way of separating an algorithm from an object structure it operates on. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. It is one way to easily follow the open/closed principle.
А конкретно это предложение начиналось так: In essence, the visitor allows...
Самиздат, короче, очередного "толкователя Торы", нихрена не понявшего проблематику паттерна, а заметившего эффект, аналогичный переопределению виртуальных ф-ий для случая иерархии посещаемых. И ведь не сообразил, что если посещаемые не будут из одного корня, то описанный эффект всё-равно сохраняется.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, dim-s, Вы писали:
d>> Оптимизация -Or включена? — Хранить некоторые переменные в регистрах.
H>Включена.
d>> К тому же я просто никогда не пользуюсь Variant'ом.
H>Зато он используется в db-access компонентах, да и вообще, варианты это частный случай. У меня и на чисто вычислительных алгоритмах FPC проседал
d>> Могу скинуть один класс, в котором делфи проигрывает в 4 раза, класс называется TStringArray, это почти TStringList, но там выделение памяти идет кусками, за счет чего добавление нового элемента в список становится намного быстрее.
H>Т.е. код будучи скомпилирован в дельфях сольет в 4 раза скомпилированному в FPC? Давай код, будем посмотреть
Не знаю я писал компилятор байт-кода и виртуальную машину на делфи, там использовались массивы, выделение памяти, классы, объекты. FPC проигрывает иногда 10-20%, иногда не проигрывает.
Здравствуйте, dim-s, Вы писали:
d> H>Т.е. код будучи скомпилирован в дельфях сольет в 4 раза скомпилированному в FPC? Давай код, будем посмотреть
d> Не знаю я писал компилятор байт-кода и виртуальную машину на делфи, там использовались массивы, выделение памяти, классы, объекты. FPC проигрывает иногда 10-20%, иногда не проигрывает.
d> А вот класс можно посмотреть тут: http://code.google.com/p/orionphp/source/browse/trunk/libs/ori_FastArrays.pas
Uses
sysutils, ori_FastArrays;
Var
i : Integer;
sa : TStringArray;
begin
sa := TStringArray.Create;
WriteLn(DatetimeToStr(Now));
for i := 1 to 100000000 do
sa.Add('');
WriteLn(DatetimeToStr(Now));
end.
Delphi 2010 — 2 сек. FPC 2.5.1 — не дождался завершения, время пошло на минуты (явно у него чего-то с менеджером памяти).
Все же качество FPC и Lazarus не дотягивает до дельфей, что впрочем не удивительно.
(впрочем это не проблема, ведь как только софт начнет приносить прибыль можно и до проф. апгрейдиться)
Сделали UTF-8 в ансистроках.
