Re[19]: мнение о Delphi
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.04.04 16:08
Оценка:
Здравствуйте, kuj, Вы писали:

VD>>Видимо я не очень доходчиво выразился. ATL никакого отношения к С++ не имеет. Да и нет в нем никаких атрибутов. Атрибуты есть в КОМ и сепециальной надстройке VS.

kuj>В догонку почитайте еще это: ms-help://MS.MSDNQTR.2003APR.1033/dnmag01/html/attributes.htm

Спасибо. Я лет 5 от барабанил на ATL-е и кое что знаю он нем. Почитай лучше сам. Кстати, достаточно внимательно прочесть заголовок: C++ Attributes: Make COM Programming a Breeze with New Feature in Visual Studio .NET

Еще раз повторяю, все это не имеет никакого отношения к С++. Это расширения среды разработки от МС. К примеру, на GCC ты не сможешь скомпилировать все это.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: мнение о Delphi
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.04.04 16:08
Оценка:
Здравствуйте, Serginio1, Вы писали:

VD>>Может не стоит обсуждать вопросы в которых не имешь полного понимания?

S> Читать внимательно надо. Я подтвердил. Но как быть с унсейвом. Ведь C++ практически весь на указателях. Или там повсеместно GC.Alloc и интероп????

Боюсь, тебя никто не понял.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: мнение о Delphi
От: AndrewJD США  
Дата: 30.04.04 17:22
Оценка:
Здравствуйте, sergei74ap, Вы писали:

S>Часто приходится слышать мнение, что разработчики, использующие delphi -

S>ваще не программисты, а так... детишки неразумные.
S>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и
S>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить?
S>По-вашему, чем вызвано такое негативное отношение?


здесь все видно
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[18]: мнение о Delphi
От: kuj  
Дата: 30.04.04 19:24
Оценка: :)
Здравствуйте, VladD2, Вы писали:

kuj>>При том, что ATL в мире C++ куда как популярнее CBuilder`а. Речь о легкости осуществления перехода.

VD>Видимо я не очень доходчиво выразился. ATL никакого отношения к С++ не имеет.
Вас неверно информировали. Имеет. Он написан на C++.
VD>Да и нет в нем никаких атрибутов.
Есть. Называются они ATL Server Attributes. ms-help://MS.MSDNQTR.2003APR.1033/vcattrib/html/vclrfATLServerAttributes.htm
VD>Атрибуты есть в КОМ и сепециальной надстройке VS.

Атрибуты есть в IDL, в COM, в ATL и в компиляторе VC++. ms-help://MS.MSDNQTR.2003APR.1033/vcattrib/html/vcrefattributesbygroup.htm
... << RSDN@Home 1.1.3 stable >>
Re[19]: мнение о Delphi
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.04.04 23:18
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>...Атрибуты есть в IDL, в COM, в ATL и в компиляторе VC++. ms-help://MS.MSDNQTR.2003APR.1033/vcattrib/html/vcrefattributesbygroup.htm


В общем, продолжим эту плодотворную беседу когда ты скомпилируешь этот "С++-код" на каком-нить gcc или С++Builder.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: мнение о Delphi
От: kuj  
Дата: 01.05.04 05:59
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

kuj>>...Атрибуты есть в IDL, в COM, в ATL и в компиляторе VC++. ms-help://MS.MSDNQTR.2003APR.1033/vcattrib/html/vcrefattributesbygroup.htm


VD>В общем, продолжим эту плодотворную беседу когда ты скомпилируешь этот "С++-код" на каком-нить gcc или С++Builder.

Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.
... << RSDN@Home 1.1.3 stable >>
Re[18]: мнение о Delphi
От: NoFate Россия  
Дата: 01.05.04 14:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это романтика. На практике качественный софт — это продуманные и тщательно спроектированные решения. А это не совестимо со странностями. Другое дело, что идеи могут быть дерзкими и неординартыми. Но не странными!

Конечно. Но иногда мы имеем дело с исследовательской работой. Какой, например? Да хотя бы искусственный интеллект. Конкретно, взаимодействие нейронных сетей в рамках каких-либо условий. Здесь сложно что-либо заранее спроектировать. Вы согласны? При этом появляются и дерзкие, и неординарные, и странные идеи. Их не обязательно переносить на практику. Зачастую им там просто нет применения... Но тем не менее.

VD>Думаю, что C# 2.0 в сочетании с нашим R#-ом будет как раз шагом к некому идеалу.

Гм. Идеал — это то, к чему нужно стремиться... Он недостижим...
... << RSDN@Home 1.1.3 stable >>
Re[29]: мнение о Delphi
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.05.04 15:49
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


Представитель МС (Дмитрий Старостин) после PDC говорил что уже сейчас ведется работа по переводу Аксапты на MBF.
... << RSDN@Home 1.1.3 beta 2 (mobile station) >>
AVK Blog
Re[30]: мнение о Delphi
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.05.04 15:49
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.


Попрошу не путать. Количество объектов на это не влияет, даже количество всех классов на это не влияет. На размер ITable влияет количество классов, реализующих интерфейсы и количество самих интерфейсов. Размер ITable конкретного класса равен максимальному порядковому номеру от старта программы реализуемых интерфейсов * 4. Поскольку часто используемые интерфейсы как правило загружаются раньше то большие ITable будут только у классов, реализующих редко используемые и поздно загруженные интерфейсы. В итоге расход памяти на itable в реальной программе очень небольшой.
... << RSDN@Home 1.1.3 beta 2 (mobile station) >>
AVK Blog
Re[30]: мнение о Delphi
От: kuj  
Дата: 02.05.04 19:02
Оценка:
Здравствуйте, Serginio1, Вы писали:

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

kuj>>А зачем нужны статические виртуальные методы?
S> На них вся Delphi построена
А в LISP все построено на списочных структурах — разве это значит, что и в C# следует использовать такую методику? Вы так и не ответили на вопрос: зачем нужны статические виртуальные методы...
S>и компонентная модель (информация о типе, виртуальные конструкторы при создании объектов из метаклассов, пользовательская информация о типе ее расширение, в том числе и десериализация итд).
В .NET и без статических виртуальных методов компонентная модель живет и здравствует. И уж точно развита получше, чем в Delphi.
S>>>частично они перекрываются атрибутами но очень дорогой ценой,
kuj>>Каким же образом?
S> Attribute.GetCustomAttribute.
Пример можно?
S>То есть программирование с интерфейсами по технике такое же как и в Net.
Вы можете написать интерфейс, который не наследует IUnknown?
S> если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.
Я бы сказал, копейки. Подумайте сами...
S>>> Как скажешь. Только за счет костылей полностью совместимый код с Net. И в чем костыли??? Это фича компилятора очень удобно когда нужно расширить код не прибегая к наследованию в том числе и saled классов.
kuj>>А что, код можно расширять только наследованием? Агрегацию уже отменили?.. Или для ER-логики придумали нечто более эффективное?
S> И перекрывать все методы ?????
Зачем перекрывать? Я про классическую агрегацию (см. UML).
S>Ради добавления 2-3. Кроме того твой любимый оверхэд ни к чему хорошему не ведет.
Не перекрывайте — не будет overhead`а.
S>>> Гибкость в создании сложной иерархии классов прежде всего,
kuj>>Так с созданием иерархии классов в C++ нет особых проблем. Да и с гибкостью, кстати, тоже, потому что: а) множественное наследование,
kuj>>б) шаблоны, в) пространства имен, г) перегрузка операторов.
S> Гибкость нужна прежде всего компилятору
Компилятору? Так ведь шаблоны. Если Вы это понимаете под "гибкостью".
S>и ООП. Все что ты привел имеет слабое отношение к ООП
Если исключить из рассмотрения шаблоны, то самое непосредственное.
S>и RTTI
Так ведь шаблоны во многих случаях избавляют нас от надобности использовать RTTI.
S>>> Кроме того а кто мешает использовать статические методы????
kuj>>Религия.
S> Не религия а фундамент на котром стоит Delphi. И не только
Ну вот, Вы сами ответили на свой вопрос.
S>>> А ручная гибкость уже никому не нужна в сложных системах.
kuj>>Весьма спорно.
S> Хорошо у меня есть много классов работающих в 4 раза быстрее нетовских (написанных на Net), есть объектная надстройка над файлами 1С типизированный аналог "объектов" 1С скорость в 30 раз и выше в зависимости от сложности. Думаешь кому нибудь это нужно?????
В Вашем классе задач, возможно, нет.
S> К сожалению простота и стандартность для большинства залог здоровья. А скорость нужна для очень узкого круга задач.
Так где же простота? Напишите, например, аналог этого на Delphi и еще раз подумайте о простоте:

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

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

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

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

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

    return 0;
}
... << RSDN@Home 1.1.3 stable >>
Re[19]: мнение о Delphi
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.05.04 14:28
Оценка:
Здравствуйте, NoFate, Вы писали:

NF>Конечно. Но иногда мы имеем дело с исследовательской работой. Какой, например? Да хотя бы искусственный интеллект. Конкретно, взаимодействие нейронных сетей в рамках каких-либо условий. Здесь сложно что-либо заранее спроектировать. Вы согласны?


Нет. Ты описываешь разработку методом тыка. Я сам иногда на нее сваливась, но это не есть гуд. Идеи идеями. Продумывание же их реализации и реализация — это отдельные процессы. И в них скатываться на тык не стоит.

NF> При этом появляются и дерзкие, и неординарные, и странные идеи.


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

NF> Их не обязательно переносить на практику. Зачастую им там просто нет применения... Но тем не менее.


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

NF>Гм. Идеал — это то, к чему нужно стремиться... Он недостижим...


А знашь почему он не достижим? Потму, что когда мы достигаем того, что когда-то считали идиалом, то начинаем видить новые горизонты к которым хочется стремиться. Так что важен не идеал, а стремление к нему.

ЗЫ

Здесь принято общаться на ты. На вы обычно переходят одновременно с переходом на личности.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: мнение о Delphi
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.05.04 14:28
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.


С++ и описывается стандартом. Если приписывать к нему частные доработки, то можно договориться, до того, что в С++ давно есть сепер-мощные фичи, так как есть OpenC++.

Ни КОМ, ни расширения компиляторв, ни что иное не записанное в стандарте С++-ом не является.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: мнение о Delphi
От: kuj  
Дата: 04.05.04 18:09
Оценка:
Здравствуйте, VladD2, Вы писали:

kuj>>Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.

VD>С++ и описывается стандартом. Если приписывать к нему частные доработки, то можно договориться, до того, что в С++ давно есть сепер-мощные фичи, так как есть OpenC++.
VD>Ни КОМ, ни расширения компиляторв, ни что иное не записанное в стандарте С++-ом не является.
Да, Вы несомненно правы, но речь-то шла немного о другом.
Напоминаю:

Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.


Не знаю как у Вас, но среди моих знакомых и коллег нет ни одного "сишника", которому не приходилось бы работать с COM и ATL.
... << RSDN@Home 1.1.3 stable >>
Re[23]: мнение о Delphi
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.05.04 19:18
Оценка:
Здравствуйте, kuj, Вы писали:

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


kuj>>>Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.

VD>>С++ и описывается стандартом. Если приписывать к нему частные доработки, то можно договориться, до того, что в С++ давно есть сепер-мощные фичи, так как есть OpenC++.
VD>>Ни КОМ, ни расширения компиляторв, ни что иное не записанное в стандарте С++-ом не является.
kuj>Да, Вы несомненно правы, но речь-то шла немного о другом.
kuj>Напоминаю:
kuj>

kuj>Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.


kuj>Не знаю как у Вас, но среди моих знакомых и коллег нет ни одного "сишника", которому не приходилось бы работать с COM и ATL.


А причем тут КОМ и АТЛ? Я работали и сними, и С++ и с Дельфи и даже с Явой (правда совсем чуть-чуть).
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: мнение о Delphi
От: Lloyd Россия  
Дата: 04.05.04 22:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Представитель МС (Дмитрий Старостин) после PDC говорил что уже сейчас ведется работа по переводу Аксапты на MBF.


А чего ради, если через год-два обещают новую систему?
... << RSDN@Home 1.1.3 stable >>
Re[32]: мнение о Delphi
От: Lloyd Россия  
Дата: 04.05.04 22:07
Оценка:
Здравствуйте, Курилка, Вы писали:

L>>Значит отсебятина.


К>Вот это тоже отсебятина:

К>http://www.microsoft-watch.com/article2/0,4248,1274625,00.asp ?
К>(хотя там ключ. роль отдана Great Plains)

Ни слова об Аксапте.
... << RSDN@Home 1.1.3 stable >>
Re[31]: мнение о Delphi
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.05.04 06:18
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>А чего ради, если через год-два обещают новую систему?


Рынок ERP штука весьма особая.
... << RSDN@Home 1.1.3 beta 2 (mobile station) >>
AVK Blog
Re[20]: мнение о Delphi
От: NoFate Россия  
Дата: 05.05.04 10:39
Оценка:
Здравствуйте, VladD2, Вы писали:

NF>> При этом появляются и дерзкие, и неординарные, и странные идеи.


VD>Дерзкие, не ординарные... согласен. Но странными идеи становятся тольео если плохо продуманы и изложены (плохо поняты в конце концов) или если они бессмысленны.

Пожалуй, я имел в виду плохо понятые идеи.

VD>Здесь принято общаться на ты. На вы обычно переходят одновременно с переходом на личности.

Не знал.
... << RSDN@Home 1.1.3 stable >>
Re[31]: мнение о Delphi
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.05.04 15:16
Оценка: -1
Здравствуйте, kuj, Вы писали:

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


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

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

Изучи исходники Delphi и сразу все станет ясно, зачем нужны виртуальные конструкторы, класс виртуальные методы итд.
В Net альтернатива им рефлексия и атрибуты отнюдь не быстрые.
S>>и компонентная модель (информация о типе, виртуальные конструкторы при создании объектов из метаклассов, пользовательская информация о типе ее расширение, в том числе и десериализация итд).
kuj>В .NET и без статических виртуальных методов компонентная модель живет и здравствует. И уж точно развита получше, чем в Delphi.
Живет и здравствуеи но с метаклассами здравствовала бы еще лучше. В Delphi.Net есть поддержка метаклассов.
S>>>>частично они перекрываются атрибутами но очень дорогой ценой,
kuj>>>Каким же образом?
S>> Attribute.GetCustomAttribute.
kuj>Пример можно?

http://www.rsdn.ru/forum/Message.aspx?mid=554256&amp;only=1
Автор: Igor Trofimov
Дата: 28.02.04

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


Написать типизированный hashTable 2 минуты, очереди пол минуты. Какие проблемы?????
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[31]: мнение о Delphi
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.05.04 15:16
Оценка:
Здравствуйте, AndrewVK, Вы писали:


AVK>Попрошу не путать. Количество объектов на это не влияет, даже количество всех классов на это не влияет. На размер ITable влияет количество классов, реализующих интерфейсы и количество самих интерфейсов. Размер ITable конкретного класса равен максимальному порядковому номеру от старта программы реализуемых интерфейсов * 4. Поскольку часто используемые интерфейсы как правило загружаются раньше то большие ITable будут только у классов, реализующих редко используемые и поздно загруженные интерфейсы. В итоге расход памяти на itable в реальной программе очень небольшой.

Насчет объектов оговорился. Разумеется речь шла о классах. Но есть круг задач где количество классов может исчислятся десятками тысяч, и так же количество интерфыейсов. Хотя во основном согласен.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.