Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
VD>>Может не стоит обсуждать вопросы в которых не имешь полного понимания? S> Читать внимательно надо. Я подтвердил. Но как быть с унсейвом. Ведь C++ практически весь на указателях. Или там повсеместно GC.Alloc и интероп????
Боюсь, тебя никто не понял.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, sergei74ap, Вы писали:
S>Часто приходится слышать мнение, что разработчики, использующие delphi - S>ваще не программисты, а так... детишки неразумные. S>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы, S>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и S>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить? S>По-вашему, чем вызвано такое негативное отношение?
Здравствуйте, 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
Здравствуйте, VladD2, Вы писали:
kuj>>...Атрибуты есть в IDL, в COM, в ATL и в компиляторе VC++. ms-help://MS.MSDNQTR.2003APR.1033/vcattrib/html/vcrefattributesbygroup.htm
VD>В общем, продолжим эту плодотворную беседу когда ты скомпилируешь этот "С++-код" на каком-нить gcc или С++Builder.
Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.
Здравствуйте, VladD2, Вы писали:
VD>Это романтика. На практике качественный софт — это продуманные и тщательно спроектированные решения. А это не совестимо со странностями. Другое дело, что идеи могут быть дерзкими и неординартыми. Но не странными!
Конечно. Но иногда мы имеем дело с исследовательской работой. Какой, например? Да хотя бы искусственный интеллект. Конкретно, взаимодействие нейронных сетей в рамках каких-либо условий. Здесь сложно что-либо заранее спроектировать. Вы согласны? При этом появляются и дерзкие, и неординарные, и странные идеи. Их не обязательно переносить на практику. Зачастую им там просто нет применения... Но тем не менее.
VD>Думаю, что C# 2.0 в сочетании с нашим R#-ом будет как раз шагом к некому идеалу.
Гм. Идеал — это то, к чему нужно стремиться... Он недостижим...
Здравствуйте, Lloyd, Вы писали:
L>Просто я пытаюсь отслеживать информацию по Аксапте, и ничего о том, что ее будут портировать (именно портировать Аксапту, а не писать новую систему) на Нет, не слышал. Возможно я что-то упустил.
Представитель МС (Дмитрий Старостин) после PDC говорил что уже сейчас ведется работа по переводу Аксапты на MBF.
Здравствуйте, Serginio1, Вы писали:
S> если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.
Попрошу не путать. Количество объектов на это не влияет, даже количество всех классов на это не влияет. На размер ITable влияет количество классов, реализующих интерфейсы и количество самих интерфейсов. Размер ITable конкретного класса равен максимальному порядковому номеру от старта программы реализуемых интерфейсов * 4. Поскольку часто используемые интерфейсы как правило загружаются раньше то большие ITable будут только у классов, реализующих редко используемые и поздно загруженные интерфейсы. В итоге расход памяти на itable в реальной программе очень небольшой.
Здравствуйте, 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 и еще раз подумайте о простоте:
Здравствуйте, NoFate, Вы писали:
NF>Конечно. Но иногда мы имеем дело с исследовательской работой. Какой, например? Да хотя бы искусственный интеллект. Конкретно, взаимодействие нейронных сетей в рамках каких-либо условий. Здесь сложно что-либо заранее спроектировать. Вы согласны?
Нет. Ты описываешь разработку методом тыка. Я сам иногда на нее сваливась, но это не есть гуд. Идеи идеями. Продумывание же их реализации и реализация — это отдельные процессы. И в них скатываться на тык не стоит.
NF> При этом появляются и дерзкие, и неординарные, и странные идеи.
Дерзкие, не ординарные... согласен. Но странными идеи становятся тольео если плохо продуманы и изложены (плохо поняты в конце концов) или если они бессмысленны.
NF> Их не обязательно переносить на практику. Зачастую им там просто нет применения... Но тем не менее.
Ну, если идеи затрагивают фундаментальные знания, то наверно. А так все же лучше видеть все разумные идеи на практике.
NF>Гм. Идеал — это то, к чему нужно стремиться... Он недостижим...
А знашь почему он не достижим? Потму, что когда мы достигаем того, что когда-то считали идиалом, то начинаем видить новые горизонты к которым хочется стремиться. Так что важен не идеал, а стремление к нему.
ЗЫ
Здесь принято общаться на ты. На вы обычно переходят одновременно с переходом на личности.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kuj, Вы писали:
kuj>Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.
С++ и описывается стандартом. Если приписывать к нему частные доработки, то можно договориться, до того, что в С++ давно есть сепер-мощные фичи, так как есть OpenC++.
Ни КОМ, ни расширения компиляторв, ни что иное не записанное в стандарте С++-ом не является.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
kuj>>Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее. VD>С++ и описывается стандартом. Если приписывать к нему частные доработки, то можно договориться, до того, что в С++ давно есть сепер-мощные фичи, так как есть OpenC++. VD>Ни КОМ, ни расширения компиляторв, ни что иное не записанное в стандарте С++-ом не является.
Да, Вы несомненно правы, но речь-то шла немного о другом.
Напоминаю:
Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.
Не знаю как у Вас, но среди моих знакомых и коллег нет ни одного "сишника", которому не приходилось бы работать с COM и ATL.
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Представитель МС (Дмитрий Старостин) после PDC говорил что уже сейчас ведется работа по переводу Аксапты на MBF.
А чего ради, если через год-два обещают новую систему?
Здравствуйте, VladD2, Вы писали:
NF>> При этом появляются и дерзкие, и неординарные, и странные идеи.
VD>Дерзкие, не ординарные... согласен. Но странными идеи становятся тольео если плохо продуманы и изложены (плохо поняты в конце концов) или если они бессмысленны.
Пожалуй, я имел в виду плохо понятые идеи.
VD>Здесь принято общаться на ты. На вы обычно переходят одновременно с переходом на личности.
Не знал.
Здравствуйте, 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>Пример можно?
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>
AVK>Попрошу не путать. Количество объектов на это не влияет, даже количество всех классов на это не влияет. На размер ITable влияет количество классов, реализующих интерфейсы и количество самих интерфейсов. Размер ITable конкретного класса равен максимальному порядковому номеру от старта программы реализуемых интерфейсов * 4. Поскольку часто используемые интерфейсы как правило загружаются раньше то большие ITable будут только у классов, реализующих редко используемые и поздно загруженные интерфейсы. В итоге расход памяти на itable в реальной программе очень небольшой.
Насчет объектов оговорился. Разумеется речь шла о классах. Но есть круг задач где количество классов может исчислятся десятками тысяч, и так же количество интерфыейсов. Хотя во основном согласен.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня