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

Цитировать не буду. И так слишком длинно.

Итак, с чем я согласен. Ну, почти со всем. Вот только COM пока не мертв. В новй Windows.Net так и не появилось серьезного сервера приложений для .NET, а вот как раз COM+ улучшился. Похоже у MS просто не хватает сил и мужества сделать все так как гворил Бокс. Бокс романтик, а продукт-менеджеры в MS реалисты. Правда сервером может выступать и IIS, но это позволяет решать только проблпмы автоматизации web-а. Это конечно не плохо, но для полной победы явно мало.

Я бы на сегодня сказал так. COM и С++ остаются, но потихоничку переходят в разряд низкоуровневых средств.

.NET можно смело считать новой версией COM-а. (У меня есть фактическое этому подтверждение) По крайней мере он развивает все то хорошее что было в COM-е:
Динамическую загрузку и исполнение кода.
Описание типов (теперь она стало полным).
Абстрагирование интерфейса от реализации.
Динамическое приведение типов.


Ну, и по основной проблеме. Хотя я и согласен со всеми твоими доводами я бы все же сказал, что начинать программировать лучше на менее объемных и концептульных вещах. Вот только С++ тут ну никак не подходит. Слишком сложен и запутан этот язык. Я бы выбрал старый добрый С. Причем плюнл бы на библиотеки и остановился бы на принципах структурного программирования. Это все же база без которой никуда.

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

Кстити, # больше унаследовал от С, чем от С++. Я иногда даже подумываю, что те кто создали этот язык хотели сделать свой компонентно-ориентированный С.

В общем, я бы дал такой совет. Начинать нужно с основ программирвания и лучше чем на С этого не сделать. А второй зык однозначно Шарп. Начиная изучать сегодня С++ молодой программист рискует безнадежно отстать от прогресса. На С же много времени не нужно...

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

ГВ>>Также не согласен с доводом, что C++ — это язык для низкоуровневых систем. C++ — язык для сложных и больших программ, а не только низкоровневых.
AVK>Вот как раз для сложных и болшьших программ С++ подходит хуже нежели шарп и джава.

Ну, это ты зря! На С++ любая программа становится большой и сложной.

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

ГВ>Сразу вопрос. Что такое нормальные property и event?

Ой дайте я.

property:

MyObj.SomeProp = 12345;

Вот такой. Если у кого есть ольтернатива, то выкладывайте ее. Возникает вопрос, а зачем они нужны? Дык есть таки программки называются визульными дизайнерами. Там на базе концепции свойств задают начальное состояние компонента. Зачем нжны комоненты поянять нужно?

ГВ> Какая реализация, например, событий, была бы "логичной"?

Любая которая дала бы возможность быстро и удобно организовывать колбэк-вызовы. Помнишь в С была такая простая и эффективная идеея — указатели на фуниции? Вглядело это так:

MyFunc1(int iArg){...}
MyFunc2(int iArg){...}
MyFunc3(int iArg){...}
...
(pFunc*)(int iArg);
pFunc = MyFunc1;
pFunc(1);
pFunc = MyFunc2;
pFunc(2);
pFunc = MyFunc3;
pFunc(3);

С синтаксисом без компилятора могу наврать, но общая идея такая. И что зделали с этой идеей в С++? Её убили на корню. Зделали указатели на фуниции-члены классов. Кому они нужны? Ведь вызвть фуницию с совподающим описанием неудастся.

Проблема решается двумя способами введением в язык указателя на метод экземпляра и интерфейсами. Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.

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

Интересно, что в тихую замял вопрос про рефлекшен. Возможно просто незнаешь термина. В COM это назывлось TypeInfo. Так вот, С++ напрочь лишен подобного михонизма. И чтобы создать теже события для компонентов реализованных на С++ к программе нужно прилепить еще гору года в виде разных tlb. Так рождается COM. А потом рождаются разные ATL и #import, единственная цель которых скрыть все сложности реализации компонентов и упростить работу. В итоге мы порождаем проблему и ее же решаем.

Так вот в .NET и Яве компонентный подход был интегрирован в рантайм-подсистему. Теперь вместо QueryInterface можно просто привести тип и рантайм все поймет и сделает как ужно, а не будет недоуменно смотреть и говорить что он знает только типы доступные во время компиляции.

Тто же рефлекшон дает возможность динамически грузить объекты и выполнять их методы. Создатели С++ даже боятся заикаться о рантайме.

ГВ> Каким, например, должен быть механизм передачи событий? Должен ли он предусматривать межпроцессную передачу данных? Должна ли принимающая сторона уметь идентифицировать отправителя события? Должна ли создаваться очередь событий? Варианты ответов на эти вопросы прекрасно можно оформить библиотеками классов на C++! Зачем навязывать самим себе "единственно правильную" модель реализации?

Вот сразу видно, что сам ты подсудимого не знал и книг его не читал. Знаешь что такое делигат? В .NET он как раз решает все те вопросы о котоых ты говоришь так иронично. Причем решает локонично, красиво и универсально. Пишиш так:

public delegate void FileCallback(string sFileName);
...
internal void IterateNode(FileCallback Callback, string sPath)
{
    ...
    foreach(string File in m_Files) // перебираем их..
        Callback(sPath + File); // и вызываем для каждого callback-метод.
}

... // в другом классе, а то и вообще в другом модуле (а то и в проекте)

m_SearchEngine.IterateNodes(new FileCallback(ProcessFile));

public void ProcessFile(string sFileName){...}

Все это работат очень похоже на указатели на фуниции в С. Но делегат это тип (почти класс). О нем можно узнать информацию черз рефлекшон (динамически). Колбэки можно осуществлять сквозь границы процессов и машин. Можно подключать сразу нескльно обработчиков к одному делегату. В общем современный вариант решения проблемы, а не перекладывание ее на плечи программиста.

ГВ>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM), а Java... кстати, в Java event-ов и property на уровне языка нет! Есть библиотеки!

Нда, про COM ты похже знаешь совсем мало, а про .NET вообще ничего не знаешь, но выводы делешь. "Сам я подсудимого не занаю и произведений его не читал, но как и весь совесткий народ..." (с).

COM стэкуется с .NET через довольно сложную систему именуемую Interop. Собственно через нее нэт стыкуется и с обычным Win32. Причем базовая часть нэта, так называемая CLI (в народе Ротор) порирована под Фришку. Так что амбиции то амбициями, а факты фактоми.

ГВ>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций) с моделью объектов в языках реализации не совсем корректно.

Это где же ты такое определение COM-а нашел? Вообще-то COM — это бинарная компонентная модель позволяющая создавать модули совместимые между разными языками. То о чем ты подумал называется ORPC. Или в простонародье DCOM-ом.

ГВ>Реализация COM для C++ в Miscrosoft-овском варианте

А что были другие?

ГВ> обладает теми же чертами, что и плоский API на C с небольшими вкраплениями объектного подхода. То есть — можно было бы и лучше.

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

ГВ> Потом, не надо забывать о том, что, действительно, по сравнению с C++ (что, впрочем, ИМХО, справедливо для любого языка общего назначения) языки специального назначения обладают преимуществами в специальных областях. Ну, например, VBS или Perl лучше подходят для скриптования идиотской модели объектов ClearQuest, нежели C++, хотя и там время от времени приходится использовать его.

Скриптования это круто. Я вот только не пойму, C# тоже специализированный язык для этого самого скриптования или ты о чет-то другом?

ГВ>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun, а C# + CLR — как противовес Java в той же области, то, естественно, они в этом смысле обладают преимуществами перед C++. Тогда как C++ создан для упрощения решения проблем программирования. Что называется — почувствуйте разницу

Ты сам то понял что сказал? Язык "создан для упрощения решения проблем программирования". Может он того... для самого этого программирования и создан? И какая разница тогда между Явой и С++?

ГВ>И здесь я действительно согласен с тем, что на C# проще реализовать что-то на базе модели COM. Но, ёлки-палки, COM — это не способ построения абстракций уровня реализации, он слишком ограничен для этого!
ГВ>

Надо мужикам расказать, а то они и незнали. (с)

1. C# не прднозначен для создания COM-объектов хотя на нем их действительно делать не сложно.
2. COM единственная доведенная до серийного исползования бинарная компонентная модель.
3. COM замечательно подходит для "построения абстракций уровня реализации".

ГВ>Итак, цели: выделение абстракций и их комбинирование.
ГВ>Чего нет в Java: а) множественное наследование;

Это действительно прискорбно.

ГВ> б) шаблоны;

Это тоже. Но в следующей версии Явы они уже будут.

ГВ> в) инлайнирование (как инструмент совмещения структурированных абстракций и эффективности исполнения).

Да словечко еще то. Так вот лучшие на сегодня компиляторы от MS и Intel уже сегдня плюют на эти директивы. Более того они умеют делать автоподстановку, причем значительно эффективнее чем прогаммист. Это и не мудренно, так как только комилятор может понять эффективна она или нет. В Яве и .Net это метод тоже используется.

ГВ>Предлагать назвать что-то, имеющееся в Java, что нельзя сделать в C++ — было бы подставой тебя с моей стороны, поскольку ничего такого нет, за исключением возможности переноса байт-кода.

А ты не стесняйся. Вот попробуй на С++ сделать указатель на член экземпляра объекта. Ну или реализуй алгоритм сборки мусора, да так чтобы тебя не полсли куда подальще когда увидят насколько это сложна и неээфективно. Покажи еще как на С++ динамически загрузить объект и вызват его методы. Причем на КОМ не фига пинять. Там от С++ ничерта не остаются. Ты попробцй срдствами языка. Попробуй вызвать виртуальный метод из коструктора или деструктора. Попробуй найти кострукцию finally.

ГВ>Абсолютно не согласен. Вопрос в том — что именно называть большой и сложной программой.

Да любой проект можно сделать большим сложным и глючным.

ГВ>...SQL+VB, где основная сложность — поддержание адекватности структуры отчётов структуре БД, что суть прямое нарушение принципа абстракции пользовательского интерфейса (отчётов) от деталей реализации (структуры БД). Так основное время команды уходило на вот это самое бестолкове сопровождение.

А ты случаем не видел аналога на C++ + SQL? О... забавное зрелище. Тут есть люди которые с такими системами борются. Я согласен, что большие и сложные вещи можно писать на чем угодно, но С++ больше подходит для низкоуровневых разработок, чем для RAD-разработки. Именно поэтому CGI так быстро уступили разным ASP, PHP и JSP.

ГВ>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

Ну, ты ради хохмы открой хоть один из них. Может и вопросы придут. Явно же видно что ты их максимум посмотрел и отбросил. Иначе бы не стал их со скриптами сравнивать.

ГВ>К примеру, именно отсутствие в Java (и в C#) шаблонов и приведёт либо к разбуханию большой и сложной программы, либо к снижению эффективности её работы, за счёт необходимости run-time-приведения типов (виртуальные функции). Не считая уже того, что в Java невозможно будет перенести на транслятор такую же часть контроля корректности программирования, как и в C++.

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

ГВ> Т.е., Java-программы будет сложнее сопровождать, если конечно, не требовать от пользователя поставить 4-х процессорный сервер P4-2200 под 10-пользовательскую CRM.

Практика показывает, что сопровождать как раз проще Яву и Шарп. Дело в том, что у этих языков выше уровень абстракции, ниже склонность толкать программиста на совершение ошибок. Это позволяет делать программы быстрее, с меньшим количеством ошибок и более формлизованных. К тому же это компонентные языки. Разбиение программы на компонены позволяет создавать ее как бы из кирпичиков. При этом каждый кирпичик можно оттестировать и документировать. Понятно, что это можно делать и на ассемблере, но Ява и Шарп подталкивают к этому и предоставлют мощьную поддержку.

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

VD>Ой дайте я.

Так-так... \

VD>property:

VD>MyObj.SomeProp = 12345;

VD>Вот такой. Если у кого есть ольтернатива, то выкладывайте ее. Возникает вопрос, а зачем они нужны? Дык есть таки программки называются визульными дизайнерами. Там на базе концепции свойств задают начальное состояние компонента. Зачем нжны комоненты поянять нужно?

То есть, проблема пропертей инспирирована единственно дизайнерами окошек... Так тогда она и яйца выеденного не стоит.

ГВ>> Какая реализация, например, событий, была бы "логичной"?

VD>Любая которая дала бы возможность быстро и удобно организовывать колбэк-вызовы. Помнишь в С была такая простая и эффективная идеея — указатели на фуниции? Вглядело это так:
VD>

VD>MyFunc1(int iArg){...}
VD>MyFunc2(int iArg){...}
VD>MyFunc3(int iArg){...}
VD>...
VD>(pFunc*)(int iArg);
VD>pFunc = MyFunc1;
VD>pFunc(1);
VD>pFunc = MyFunc2;
VD>pFunc(2);
VD>pFunc = MyFunc3;
VD>pFunc(3);
VD>

VD>С синтаксисом без компилятора могу наврать, но общая идея такая. И что зделали с этой идеей в С++? Её убили на корню.

Да, дружище. Забыл ты C++. Указатели на функции и на статические члены типов там живут и благоденствуют.

VC>Зделали указатели на фуниции-члены классов. Кому они нужны? Ведь вызвть фуницию с совподающим описанием неудастся.

Это ещё что за новости? Да, вызвать функцию, совпадающую по формальным параметрам, но не являющуюся членом класса по указателю на функцию-член действительно нельзя, поскольку нужен ещё и экземпляр класса. А статическую функцию-член — очень даже можно. Впрочем, об этом — ниже.

VD>Проблема решается двумя способами введением в язык указателя на метод экземпляра и интерфейсами.

Ещё она решается шаблонами, но об этом — попозже.

VD>Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.

Ну да, так примерно и есть.

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

Это что-то новое. Указатель на функцию можно хранить в inline-static или в специализации этого метода. А зачем реализовывать ещё и все методы интерфейса? И ещё — что означает твоё выражение "реализовать только один метод интерфейса"? Реализовать где? По идее — если методы могут реализовываться абсолютно независимо, то это уже — отдельные классы.

Стоп, кажется, понял. Ты имеешь ввиду — реализовать отдельный метод класса, оставив часть их абстрактными, т.е., нереализованными?

VD>Есть еще решения в силе С и Виндовс, но они и вовсе уродливы. И чтобы скрыть их уродство весь код программы покрывается макросами.

VD>Интересно, что в тихую замял вопрос про рефлекшен.

Замнёшь его, как же В другой ветке где-то, а сейчас — ещё и в "Философии программирования" на эту тему есть рассуждения AndrewVK, IT и мои.

VD>Возможно просто незнаешь термина.

Не знал.

VD> В COM это назывлось TypeInfo. Так вот, С++ напрочь лишен подобного михонизма. И чтобы создать теже события для компонентов реализованных на С++ к программе нужно прилепить еще гору года в виде разных tlb. Так рождается COM. А потом рождаются разные ATL и #import, единственная цель которых скрыть все сложности реализации компонентов и упростить работу. В итоге мы порождаем проблему и ее же решаем.

Что верно — то верно.

VD>Так вот в .NET и Яве компонентный подход был интегрирован в рантайм-подсистему. Теперь вместо QueryInterface можно просто привести тип и рантайм все поймет и сделает как ужно,

Ну, если на то пошло, то если тип COM-интерфейса вообще не был известен на этапе трансляции COM-клиента (ни по IID ни по-иначе), то вызов методов можно было и через IDispatch оформить с соответствующим заворачиванием в шаблоны/функторы, а имя типа объекта — из окошка ввести. Вариант не лучший, бесспорно, с любой стороны, поскольку нет никакой гарантии, что подвернувшийся объект будет адекватно на эти вызовы реагировать.

VD>а не будет недоуменно смотреть и говорить что он знает только типы доступные во время компиляции.

ИМХО, элемент залога устойчивости системы.

VD>Тто же рефлекшон дает возможность динамически грузить объекты и выполнять их методы. Создатели С++ даже боятся заикаться о рантайме.

Слушай, давай определись — какой аспект рантайма ты имеешь ввиду.

ГВ>> Каким, например, должен быть механизм передачи событий? Должен ли он предусматривать межпроцессную передачу данных? Должна ли принимающая сторона уметь идентифицировать отправителя события? Должна ли создаваться очередь событий? Варианты ответов на эти вопросы прекрасно можно оформить библиотеками классов на C++! Зачем навязывать самим себе "единственно правильную" модель реализации?

VD>Вот сразу видно, что сам ты подсудимого не знал и книг его не читал. Знаешь что такое делигат? В .NET он как раз решает все те вопросы о котоых ты говоришь так иронично. Причем решает локонично, красиво и универсально. Пишиш так:

VD>

VD>public delegate void FileCallback(string sFileName);
VD>...
VD>internal void IterateNode(FileCallback Callback, string sPath)
VD>{
VD>    ...
VD>    foreach(string File in m_Files) // перебираем их..
VD>        Callback(sPath + File); // и вызываем для каждого callback-метод.
VD>}

VD>... // в другом классе, а то и вообще в другом модуле (а то и в проекте)

VD>m_SearchEngine.IterateNodes(new FileCallback(ProcessFile));

VD>public void ProcessFile(string sFileName){...}
VD>

VD>Все это работат очень похоже на указатели на фуниции в С.

Согласен, здесь даже укрыты различия между "обычными" функциями и методами. На C++ решается не так лаконично, но делегат...

VD>Но делегат это тип (почти класс).

...sealed, т.е., наследовать от него нельзя.

VD> О нем можно узнать информацию черз рефлекшон (динамически). Колбэки можно осуществлять сквозь границы процессов и машин. Можно подключать сразу нескльно обработчиков к одному делегату. В общем современный вариант решения проблемы, а не перекладывание ее на плечи программиста.

Ну, это уж кому как.

ГВ>>Для C# и Java эти вопросы решались исходя из целей этих языков. C# — поддержание амбиций Microsoft (т.е., внедрение поддержки модели COM), а Java... кстати, в Java event-ов и property на уровне языка нет! Есть библиотеки!

VD>Нда, про COM ты похже знаешь совсем мало, а про .NET вообще ничего не знаешь, но выводы делешь. "Сам я подсудимого не занаю и произведений его не читал, но как и весь совесткий народ..." (с).

VD>COM стэкуется с .NET через довольно сложную систему именуемую Interop. Собственно через нее нэт стыкуется и с обычным Win32. Причем базовая часть нэта, так называемая CLI (в народе Ротор) порирована под Фришку. Так что амбиции то амбициями, а факты фактоми.

Хорошо. Признаю, что здесь с определениме целей я ошибся.

ГВ>>Ну, во-первых. Сравнивать COM (в сущности — способ структурирования коммуникаций) с моделью объектов в языках реализации не совсем корректно.

VD>Это где же ты такое определение COM-а нашел? Вообще-то COM — это бинарная компонентная модель позволяющая создавать модули совместимые между разными языками. То о чем ты подумал называется ORPC. Или в простонародье DCOM-ом.

Основу для такого вывода я нашёл в глоссарии к MS SDK help.

ГВ>>Реализация COM для C++ в Miscrosoft-овском варианте

VD>А что были другие?

Ну, скажем так, могли бы быть.

ГВ>> обладает теми же чертами, что и плоский API на C с небольшими вкраплениями объектного подхода. То есть — можно было бы и лучше.

VD>Ну, если язык подправить, то конечно. А так... попробуй, может что у тебя выйдет. У других не вышло...

ГВ>> Потом, не надо забывать о том, что, действительно, по сравнению с C++ (что, впрочем, ИМХО, справедливо для любого языка общего назначения) языки специального назначения обладают преимуществами в специальных областях. Ну, например, VBS или Perl лучше подходят для скриптования идиотской модели объектов ClearQuest, нежели C++, хотя и там время от времени приходится использовать его.

VD>Скриптования это круто. Я вот только не пойму, C# тоже специализированный язык для этого самого скриптования или ты о чет-то другом?

C# специален для CLR. В отсутствие CLR с его специфическими особенностями, C# попросту нет.

ГВ>>Здесь я имею в виду то, что если Java создана для решения проблемы переносимости (решается виртуально) и популяризации Sun, а C# + CLR — как противовес Java в той же области, то, естественно, они в этом смысле обладают преимуществами перед C++. Тогда как C++ создан для упрощения решения проблем программирования. Что называется — почувствуйте разницу

VD>Ты сам то понял что сказал? Язык "создан для упрощения решения проблем программирования". Может он того... для самого этого программирования и создан? И какая разница тогда между Явой и С++?

В самом "верхнем" смысле — никакой, кроме той, что C++ гибче.

ГВ>>И здесь я действительно согласен с тем, что на C# проще реализовать что-то на базе модели COM. Но, ёлки-палки, COM — это не способ построения абстракций уровня реализации, он слишком ограничен для этого!
ГВ>>

VD>Надо мужикам расказать, а то они и незнали. (с)

Странные у тебя мужики А что, отсутствие множественного наследования и шаблонов (надеюсь, временное) увеличивает гибкость? Относительно того, что C# непосредственно унаследован от COM — признаю свою ошибку, хотя, всё равно, ИМХО, CLR много у него взял. Ну что ж, это вполне логично и оправданно.

VD>1. C# не прднозначен для создания COM-объектов хотя на нем их действительно делать не сложно.

Признаю.

VD>2. COM единственная доведенная до серийного исползования бинарная компонентная модель.

Это не говорит о нём ни "за" ни "против".

VD>3. COM замечательно подходит для "построения абстракций уровня реализации".

Нет. Поскольку за COM-интерфейсами есть ещё много чего.

ГВ>>Итак, цели: выделение абстракций и их комбинирование.
ГВ>>Чего нет в Java: а) множественное наследование;

VD>Это действительно прискорбно.

ГВ>> б) шаблоны;

VD>Это тоже. Но в следующей версии Явы они уже будут.

ГВ>> в) инлайнирование (как инструмент совмещения структурированных абстракций и эффективности исполнения).

VD>Да словечко еще то. Так вот лучшие на сегодня компиляторы от MS и Intel уже сегдня плюют на эти директивы. Более того они умеют делать автоподстановку, причем значительно эффективнее чем прогаммист. Это и не мудренно, так как только комилятор может понять эффективна она или нет. В Яве и .Net это метод тоже используется.

O'K, согласен.

ГВ>>Предлагать назвать что-то, имеющееся в Java, что нельзя сделать в C++ — было бы подставой тебя с моей стороны, поскольку ничего такого нет, за исключением возможности переноса байт-кода.

VD>А ты не стесняйся. Вот попробуй на С++ сделать указатель на член экземпляра объекта.

Запросто. Я же говорю, что ты подзабыл C++. Кстати, укзатель на член экземпляра — это указатель на тип этого самого члена.

class A { public: int _a; }

typedef int A::*a_member;

...

A my_a, my_b;

a_member ap = &A::a;

cout << my_a.*ap << endl;
cout << my_b.*ap << endl;

Впрочем, я понимаю, что ты имеешь ввиду — реализовать ту же модель, что реализована делегатами. В принципе, я уже придумал реализацию, запощу чуть позже. Сюда или в "C++". Хотя, повторюсь, что на C++ реализация не столь лаконична, как в C#.

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

Ну, не так уж он и нужен.

VD> Покажи еще как на С++ динамически загрузить объект и вызват его методы. Причем на КОМ не фига пинять.

Есть такой паттерн, называется прокси, если не ошибаюсь... или lazy-object.

VD> Там от С++ ничерта не остаются. Ты попробцй срдствами языка. Попробуй вызвать виртуальный метод из коструктора или деструктора.

Если метод абстрактный, то и не попробую из конструктора/деструктора того же класса. Прямое следствие семантики создания/разрушения. ИМХО — очень разумное.

VD> Попробуй найти кострукцию finally.

Можно и без неё обойтись.

ГВ>>Абсолютно не согласен. Вопрос в том — что именно называть большой и сложной программой.

VD>Да любой проект можно сделать большим сложным и глючным.

Особенно, если компонентизировать его без меры.

ГВ>>...SQL+VB, где основная сложность — поддержание адекватности структуры отчётов структуре БД, что суть прямое нарушение принципа абстракции пользовательского интерфейса (отчётов) от деталей реализации (структуры БД). Так основное время команды уходило на вот это самое бестолкове сопровождение.

VD>А ты случаем не видел аналога на C++ + SQL? О... забавное зрелище.

Видел. То, как их реализуют мне тоже не понравилось.

VD> Тут есть люди которые с такими системами борются. Я согласен, что большие и сложные вещи можно писать на чем угодно, но С++ больше подходит для низкоуровневых разработок, чем для RAD-разработки.

В каком-то смысле — да, ИМХО, он больше апеллирует к разработке собственного языка (например, как набора идиом/классов/шаблонов) для прикладной задачи.

VD> Именно поэтому CGI так быстро уступили разным ASP, PHP и JSP.

ГВ>>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

VD>Ну, ты ради хохмы открой хоть один из них. Может и вопросы придут. Явно же видно что ты их максимум посмотрел и отбросил. Иначе бы не стал их со скриптами сравнивать.

Да, это я сгоряча, в общем-то.

ГВ>>К примеру, именно отсутствие в Java (и в C#) шаблонов и приведёт либо к разбуханию большой и сложной программы, либо к снижению эффективности её работы, за счёт необходимости run-time-приведения типов (виртуальные функции). Не считая уже того, что в Java невозможно будет перенести на транслятор такую же часть контроля корректности программирования, как и в C++.

VD>К разбуханию конечно не приведт, но производительность действительно храмает. Не так сильно, но... Надеюсь в следующих версиях это исправят (т.е. добавят шаблоны).

Шаблоны добавляют производительности не столько готовой программе, сколько процессу её разработки.

ГВ>> Т.е., Java-программы будет сложнее сопровождать, если конечно, не требовать от пользователя поставить 4-х процессорный сервер P4-2200 под 10-пользовательскую CRM.

VD>Практика показывает, что сопровождать как раз проще Яву и Шарп. Дело в том, что у этих языков выше уровень абстракции, ниже склонность толкать программиста на совершение ошибок. Это позволяет делать программы быстрее, с меньшим количеством ошибок и более формлизованных. К тому же это компонентные языки. Разбиение программы на компонены позволяет создавать ее как бы из кирпичиков. При этом каждый кирпичик можно оттестировать и документировать. Понятно, что это можно делать и на ассемблере, но Ява и Шарп подталкивают к этому и предоставлют мощьную поддержку.

Да, конечно. Ява и Шарп в каких-то случаях лаконичнее, но в каких-то — принципиально не смогут обеспечить той же лаконичности, что и C++. Хотя бы за счёт отсутствия множественного наследования и (всё ещё) — шаблонов.

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

VD>Итак, с чем я согласен. Ну, почти со всем. Вот только COM пока не мертв. В новй Windows.Net так и не появилось серьезного сервера приложений для .NET, а вот как раз COM+ улучшился.
Похоже у них просто сил не хватает, или не хочется вкладывать в это деньги пока дотнет не завоевал определенного сегмента рынка. Пока что только SQL-сервер мигрирует в сторону .Net.
А вобще хотя бы IIS можно было бы под дотнет переписать, не такой уж IIS большой проект.

VD>Правда сервером может выступать и IIS, но это позволяет решать только проблпмы автоматизации web-а.
Не, ну какой из IIS апп сервер? Если без всяких MSMQ еще можно прожить, то без транзакций и кеша/пула объектов уже сложно.

VD> Это конечно не плохо, но для полной победы явно мало.
Мало

VD>Я бы на сегодня сказал так. COM и С++ остаются, но потихоничку переходят в разряд низкоуровневых средств.
С++ и COM останется до тех пор пока большая часть NT не будет переписана под .NET, а это если и будет то очень нескоро.

VD>.NET можно смело считать новой версией COM-а. (У меня есть фактическое этому подтверждение) По крайней мере он развивает все то хорошее что было в COM-е:
VD>Динамическую загрузку и исполнение кода.
VD>Описание типов (теперь она стало полным).
VD>Абстрагирование интерфейса от реализации.
VD>Динамическое приведение типов.
Ну это характеристики не СОМ а компонентной модели вобще.

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

VD>Ой дайте я. :)

VD>property:

VD>MyObj.SomeProp = 12345;

VD>Вот такой. ;) Если у кого есть ольтернатива, то выкладывайте ее. Возникает вопрос, а зачем они нужны? Дык есть таки программки называются визульными дизайнерами. Там на базе концепции свойств задают начальное состояние компонента. Зачем нжны комоненты поянять нужно?

Так вот товарищ как раз утверждает что компоненты на самом деле не очень то и нужны.

VD>Проблема решается двумя способами введением в язык указателя на метод экземпляра и интерфейсами. Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.
Ну делегаты по сути дела тоже самое только понавороченнее — это не указатель а коллекция указателей.

VD>Интересно, что в тихую замял вопрос про рефлекшен. Возможно просто незнаешь термина. В COM это назывлось TypeInfo.

Ну если не нужна компонентная модель то и рефлекшен в общем то не особенно нужен. Потому как статическая проверка типов лучше динамической в рантайме.

VD>Так вот в .NET и Яве компонентный подход был интегрирован в рантайм-подсистему. Теперь вместо QueryInterface можно просто привести тип и рантайм все поймет и сделает как ужно, а не будет недоуменно смотреть и говорить что он знает только типы доступные во время компиляции.
Самое интересное что и компилятор при компиляции тоже пользуется рефлекшеном и компонентной моделью.

VD>Все это работат очень похоже на указатели на фуниции в С. Но делегат это тип (почти класс).
Почему почти? Класс и есть.

VD>COM стэкуется с .NET через довольно сложную систему именуемую Interop. Собственно через нее нэт стыкуется и с обычным Win32. Причем базовая часть нэта,
Стандартизованная в ECMA
VD> так называемая CLI (в народе Ротор)
CLI это common language implementation, название стандарта. Ротор — название конкретной реализации.

VD> порирована под Фришку.
Причем при активном участии MS, т.е. в отличие от Mono это не самодеятельность.

ГВ>> б) шаблоны;

VD>Это тоже. Но в следующей версии Явы они уже будут.

Prototype for JSR014: Adding Generics to the JavaTM Programming Language v. 1.2
Доступно для скачивания. Так что почти что уже есть.

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

VD>>Вот такой. Если у кого есть ольтернатива, то выкладывайте ее. Возникает вопрос, а зачем они нужны? Дык есть таки программки называются визульными дизайнерами. Там на базе концепции свойств задают начальное состояние компонента. Зачем нжны комоненты поянять нужно?

ГВ>То есть, проблема пропертей инспирирована единственно дизайнерами окошек... Так тогда она и яйца выеденного не стоит.
Инспирирована компонентной архитектурой.

VD>>а не будет недоуменно смотреть и говорить что он знает только типы доступные во время компиляции.
ГВ>ИМХО, элемент залога устойчивости системы.

Тем не менее даже монстры вроде WebLogic написанные на джаве вполне устойчивы.

VD>>Тто же рефлекшон дает возможность динамически грузить объекты и выполнять их методы. Создатели С++ даже боятся заикаться о рантайме.

ГВ>Слушай, давай определись — какой аспект рантайма ты имеешь ввиду.

Динамическую загрузку классов.

VD>>Но делегат это тип (почти класс).

ГВ>...sealed, т.е., наследовать от него нельзя.

А зачем?

VD>> О нем можно узнать информацию черз рефлекшон (динамически). Колбэки можно осуществлять сквозь границы процессов и машин. Можно подключать сразу нескльно обработчиков к одному делегату. В общем современный вариант решения проблемы, а не перекладывание ее на плечи программиста.
ГВ>Ну, это уж кому как.
Ну если ты мазохист и любишь изобретать велосипеды в каждом проекте то конечно.

VD>>Это где же ты такое определение COM-а нашел? Вообще-то COM — это бинарная компонентная модель позволяющая создавать модули совместимые между разными языками. То о чем ты подумал называется ORPC. Или в простонародье DCOM-ом.

ГВ>Основу для такого вывода я нашёл в глоссарии к MS SDK help.

Он настолько монстроидален что при желании там можно найти что угодно
Вон в дотнетовском форуме человек где то вычитал что можно Remoting сервер использовать COM-клиентами. Хотя далее становится понятно что имелось ввиду просто возможность использования одних и тех же объектов для ремоутинга и COM+.

VD>>А что были другие?
ГВ>Ну, скажем так, могли бы быть.
А почему не были?

VD>>Ты сам то понял что сказал? Язык "создан для упрощения решения проблем программирования". Может он того... для самого этого программирования и создан? И какая разница тогда между Явой и С++?

ГВ>В самом "верхнем" смысле — никакой, кроме той, что C++ гибче.
А ассемблер еще гибче.

VD>>Надо мужикам расказать, а то они и незнали. (с)

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

ГВ> Относительно того, что C# непосредственно унаследован от COM — признаю свою ошибку, хотя, всё равно, ИМХО, CLR много у него взял. Ну что ж, это вполне логично и оправданно.
CLR у C++? Что именно?

VD>>Ну или реализуй алгоритм сборки мусора, да так чтобы тебя не полсли куда подальще когда увидят насколько это сложна и неээфективно.
ГВ>Ну, не так уж он и нужен.
Ну да, рефлекшен не реализуем, следовательно не нужен. Компонентная модель по человечески не реализуема следовательно не нужна. GC нормально не реализуем следовательно не нужен. Интересная логика.
Да, при том геморое который сопровождается его реализацией на плюсах действительно не нужен. А вот в джаве и дотнете очень даже ничего.

ГВ>Есть такой паттерн, называется прокси, если не ошибаюсь... или lazy-object.
При чем здесь паттерн? Ты расскажи — как конкретно на лету загрузить класс.

VD>> Попробуй найти кострукцию finally.
ГВ>Можно и без неё обойтись.
Во опять. Нет, значит можно обойтись. Вон в дотнете нет множественного наследования и шаблонов, ну так без них вполне можно обойтись. Тем более что множественное наследование интерфейсов есть, а подключение реализаций можно реализовать.

VD>>Да любой проект можно сделать большим сложным и глючным.
ГВ>Особенно, если компонентизировать его без меры.
Вот как раз наоборот.

ГВ>Да, конечно. Ява и Шарп в каких-то случаях лаконичнее,
Они в большинстве случаев лаконичнее.

ГВ> но в каких-то — принципиально не смогут обеспечить той же лаконичности, что и C++. Хотя бы за счёт отсутствия множественного наследования и (всё ещё) — шаблонов.
Про множественное наследование я уже сказал. Про шаблоны — все таки это средство увеличения производительности программы. Вся их функциональность вполне реализуема виртуальными контейнерами и рефлекшеном.

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

ГВ>То есть, проблема пропертей инспирирована единственно дизайнерами окошек...

Ну, еще дизайнерами миделвэа-приложений и другими дизайнерами.

ГВ>Так тогда она и яйца выеденного не стоит.

Стоит, не стоит. Это удобно и нет ни одного противопоказания. Но в стандрат не вводят. Мелочь конечно, но пративно.

ГВ>Да, дружище. Забыл ты C++. Указатели на функции и на статические члены типов там живут и благоденствуют.

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

Делегаты и клосюры это нечто большее. Вот это в отличии от свойств уже сильно облегчает жизнь. Но не для С++-ников. :(

VC>>Зделали указатели на фуниции-члены классов. Кому они нужны? Ведь вызвть фуницию с совподающим описанием неудастся.

ГВ>Это ещё что за новости? Да, вызвать функцию, совпадающую по формальным параметрам, но не являющуюся членом класса по указателю на функцию-член действительно нельзя, поскольку нужен ещё и экземпляр класса. А статическую функцию-член — очень даже можно. Впрочем, об этом — ниже.


А нафига мне статическая? Этак я и на С-ях писать могу. Мне нужно событийно ориентированное программирование на базе ОО. На С я это и 10 лет назад делал.

VD>>Проблема решается двумя способами введением в язык указателя на метод экземпляра и интерфейсами.

ГВ>Ещё она решается шаблонами, но об этом — попозже.

Да. Мы вот в последнее время так и делаем. Но это работает только внутри проекта. Компоненты так не зделаешь. И приходится мучится с интерфейсами. И к тому же все равно приходится наследоваться. А с указателями на методы экземпляров и делегатами это делается в одну строку без наследования.

VD>>Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.

ГВ>Ну да, так примерно и есть.

Где? В Билдере — да. В стандарте — нет.

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

ГВ> :???: Это что-то новое.

Что новое? Интерфейсы? Да им сто лет.

ГВ> Указатель на функцию можно хранить в inline-static или в специализации этого метода.

Чё-чё. Ты не мудри, ты пальцем покажи. :)

ГВ> А зачем реализовывать ещё и все методы интерфейса?

Потому, что интерфейс это абстрактный класс. Если от него унаследуешься, то обязан реализовывать все методы.

Помойму ты не понимаешь что я имею ввиду под словом интерфейс. COM знаешь? А CORBA-у? Это от туда термин.

ГВ> И ещё — что означает твоё выражение "реализовать только один метод интерфейса"? Реализовать где?

В классе который должен обратбатывать события.

ГВ> По идее — если методы могут реализовываться абсолютно независимо, то это уже — отдельные классы.

Вот здесь бы и подошли абстракции типа клосюра (у Борлонда) или делегатов у MS. Без них событийное программирование — мрак.

ГВ>Стоп, кажется, понял. Ты имеешь ввиду — реализовать отдельный метод класса, оставив часть их абстрактными, т.е., нереализованными?

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

VD>>Интересно, что в тихую замял вопрос про рефлекшен.

ГВ>Замнёшь его, как же :) В другой ветке где-то, а сейчас — ещё и в "Философии программирования" на эту тему есть рассуждения AndrewVK, IT и мои.

Ну, ды ссылку давай. :)

И все же отсуствие полноценной информации о типах во время выполнения программы резко уменьшает возможности автомтизации в программах. Ну, и делают невозможным разработку компонетов на таких языках. MS работая над комом был вынужден добавить tlb и MIDL, т.е. расширил не только язык но и средства разработки. В .NET и Яве рефлекшен снимает все эти проблемы.

ГВ>Ну, если на то пошло, то если тип COM-интерфейса вообще не был известен на этапе трансляции COM-клиента (ни по IID ни по-иначе), то вызов методов можно было и через IDispatch оформить с соответствующим заворачиванием в шаблоны/функторы, а имя типа объекта — из окошка ввести. Вариант не лучший, бесспорно, с любой стороны, поскольку нет никакой гарантии, что подвернувшийся объект будет адекватно на эти вызовы реагировать.

Главное что нет никакой поддержки компилятора. Нужны всякие кодогененраторв. Ну, и самое противное, что вся хваленая типобезопастность С++ идет под снос. :(

VD>>а не будет недоуменно смотреть и говорить что он знает только типы доступные во время компиляции.

ГВ>ИМХО, элемент залога устойчивости системы.

Когда речь идет о компонентах, то выбор состоит из вдух вариантов. Как в С++... отключить к чертям проверку типов (например приведением указателей к void*) и пологаться на свои силы и нервы. Вариант Явы и Шарпа... иметь информацию о типах в рантайме и продолжать контроль типов.

Например, в С++ безпроблем можно привести указатель на один объект к указатлю на другой. Все грохнет в рантайме. И грохнет серьезно (обычно AV). В .NET же в рантайме делаются проверки и неправильное приведение вызовет исключение. Но исключение неправильного приведения типов. Такое исключение легко обработать.

Страуструпу не раз говорили, что подобный механизм нужен. И кое-что было даже включено в язык (динамик_каст), но работает это только внутри одного проекта (т.е. опять же нельзя применять в рантайме).

VD>>Тто же рефлекшон дает возможность динамически грузить объекты и выполнять их методы. Создатели С++ даже боятся заикаться о рантайме.

ГВ>Слушай, давай определись — какой аспект рантайма ты имеешь ввиду.

В смысле? Я имею в виду, то что С++ идеологически настроен на генерацию кода. И рантай его подсистема заканчивается на CRT.

Чтобы понять о чем я говорю, представь сколько кода нужно для вызова метода информация о котором не была доступна во время компиляции? Т.е. на входе есть имя модуля (длл-ки) и нужно дать мозможность вызвать один из методов класса который находится в этом модуле. На C# это пишится за пол часа. На С++ эта задача в общем не решаема. Решить ее можно применяя разные расширения типа COM.

ГВ>Согласен, здесь даже укрыты различия между "обычными" функциями и методами. На C++ решается не так лаконично, но делегат...

Я в свое время пытался сделать удобоваримый вариант. В конце концов все закончилось тем, что пришлось заложиться на реализацию внутренних структур классов конкретным компилятором (VC6) и снова отказаться от контроля типов во время компиляции. Т.е. в принципе проблема решается, но криво. С поддержкой компилятора можно было бы сделать намного проще и лучше. Причем я даже согласился бы на минимальные изменения. Достаточно было бы дать возможность вызывать по указателю методы (у экземпляра) с одинаковым описанием. Остальное решаемо. Но Страуструп опять уперся рогом. :(

VD>>Но делегат это тип (почти класс).

ГВ>...sealed, т.е., наследовать от него нельзя.

К сожалению. Но на практике и этого хватает. А "почти класс" это я ктому, что о нем можно получить информацию в том же рантайме.

VD>>В общем современный вариант решения проблемы, а не перекладывание ее на плечи программиста.

ГВ>Ну, это уж кому как.

Согласись, что С++ стал бы только лучше если бы в него добавили бы эти самые делегаты и рефлекшон? Кому от этог хуже.

ГВ>Основу для такого вывода я нашёл в глоссарии к MS SDK help.

Да. С глосариями у MS всегда были проблемы. Они больше запутывают.

ГВ>>>Реализация COM для C++ в Miscrosoft-овском варианте
VD>>А что были другие? :)))
ГВ>Ну, скажем так, могли бы быть.
:)

VD>>Скриптования это круто. Я вот только не пойму, C# тоже специализированный язык для этого самого скриптования или ты о чет-то другом?

ГВ>C# специален для CLR. В отсутствие CLR с его специфическими особенностями, C# попросту нет.

Ну, а скрипты то тут причем? Скрипт от не скрипта отличает наличие процесса компиляции. Тот же VB3 был интерпретатором, но не скриптом. А уж CLR 100%-но компилирует весь код перед исполнением.

VD>>Ты сам то понял что сказал? Язык "создан для упрощения решения проблем программирования". Может он того... для самого этого программирования и создан? И какая разница тогда между Явой и С++?

ГВ>В самом "верхнем" смысле — никакой, кроме той, что C++ гибче.

Ну, что есть того не отнять. Но обратная сторона этой гибкости — неимоверная сложность программирования на нем. На С++ недельный поиск ошибки — это нормально. Для Явы два часа уже аврал. .NET же вообще дает тебе все варианты. Нужна низкоуровневая оптимизация... берем MC++ (который, кстати не урезан, а даже расширен, и поддерживает все возможности С++ известнве MS :) ). А то и вообще на мсиле в рантайме... Нужна безопастность и скорость разработки... берем C# или VB.NET. Нужны экзотические приколы... берем Перл, Эфил и т.п. Т.е. противопоставление есть только в одну сторону. Ну, а гибкость?... Дык она в основном нужна там где проблема не решается штатными методами. Например, на Шарпе можно создать здоровенное приложение ни разу не обратившись к указатлям. Но как только нужно взаимодействовать с теми же контролами виндовс, как без них не обойтись. Да и вообще становится удобнее писать на С++.

VD>>Надо мужикам расказать, а то они и незнали. (с)

ГВ>Странные у тебя мужики ;)

Ты что рекламу не смотришь? :)

ГВ> А что, отсутствие множественного наследования и шаблонов (надеюсь, временное) увеличивает гибкость?

Нет. Это явные недостатки. Причем явно слизанные с Явы и Дельфи. Мы это уже обсуждали. Вопрос в том, что приемуществ явно больше. Да и скорее всего недостатки эти скоро устранят. Уж если Ява дожила до шаблонов... :)

ГВ> Относительно того, что C# непосредственно унаследован от COM — признаю свою ошибку, хотя, всё равно, ИМХО, CLR много у него взял. Ну что ж, это вполне логично и оправданно.

Кто бы спорил. Забавно, что зародился CLR именно как проект COM-2. Но MS был бы не MS елси бы у него все выходило так как задумано. :)

VD>>2. COM единственная доведенная до серийного исползования бинарная компонентная модель.

ГВ>Это не говорит о нём ни "за" ни "против".

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

VD>>3. COM замечательно подходит для "построения абстракций уровня реализации".

ГВ>Нет. Поскольку за COM-интерфейсами есть ещё много чего.

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

VD>>А ты не стесняйся. Вот попробуй на С++ сделать указатель на член экземпляра объекта.

ГВ>Запросто. Я же говорю, что ты подзабыл C++. Кстати, укзатель на член экземпляра — это указатель на тип этого самого члена.

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

struct A { void MyFanc1(); };
struct B { void MyFanc2(); };

НекийУсловныйУказательНаМетод pMethod = bCondition ? MyFanc1 : MyFanc2;

...

pMethod();

Делегаты с таким справляются на ура.

ГВ> ;) Впрочем, я понимаю, что ты имеешь ввиду — реализовать ту же модель, что реализована делегатами. В принципе, я уже придумал реализацию, запощу чуть позже. Сюда или в "C++". Хотя, повторюсь, что на C++ реализация не столь лаконична, как в C#.

Я уже этим занимался. Как уже говорил получилось не красиво.

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

ГВ>Ну, не так уж он и нужен.

Нужен не нужен... Это из той же оперы. Слова Страуструпа, что сборку мусора можно реализовать как внешнюю библиотеку. Вот тут давича Мишка.Нэт сделал попытку... интересно конечно поичитать, но пользоваться этим нельзя, так как все слишком сложно.

VD>> Покажи еще как на С++ динамически загрузить объект и вызват его методы. Причем на КОМ не фига пинять.

ГВ>Есть такой паттерн, называется прокси, если не ошибаюсь... или lazy-object.

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

VD>> Там от С++ ничерта не остаются. Ты попробцй срдствами языка. Попробуй вызвать виртуальный метод из коструктора или деструктора.

ГВ>Если метод абстрактный, то и не попробую из конструктора/деструктора того же класса. Прямое следствие семантики создания/разрушения. ИМХО — очень разумное.

Тогда сделай поиск по форуму С++. Погляди сколько вопросов по этому поводу. Это же ведь подсознательно разумное решение! Язык должен держаться не за спецификацию, а за людей на нем работающих. Кстити, я гдето там прдлагал ввести нечто вроде пост-конструктора и пре-деструктора. Так чтобы из них можно было вызывать виртуальные методы. Ну, меня Страуструп точно не слышит. :)

VD>> Попробуй найти кострукцию finally.

ГВ>Можно и без неё обойтись.

Вот только нужно ли? Мы вот вообще ATL-объекты без исключений пишим. Но радости от этого никакой. :(

VD>>Да любой проект можно сделать большим сложным и глючным. :)

ГВ>Особенно, если компонентизировать его без меры. ;)

Это без разницы. Были бы "талантливые" руки. Компонентный же подход как раз и становится выходом когда размеры проета становятся невыносимыми.

VD>>А ты случаем не видел аналога на C++ + SQL? О... забавное зрелище.

ГВ>Видел. То, как их реализуют мне тоже не понравилось.

Так может дело в людях?

ГВ>>>Прикол как раз в том, что когда работаешь со скриптовыми языками, часто даже не задаёшь себе тех вопросов, которые не боишься ставить, используя C++. А C# и Java я как раз и считаю разновидностью скриптовых языков, посольку ИМХО они апеллируют к реализации каких-то элементов системы на других языках.

Ну, ошибаешьс ты. Что же тут поделаешь. 99% (см. Анакрино и Ротор) библиотек для C# написанно на нем самом. Вот рантайм-подсистема, та да на 70% плюсовый код.

Та же Ява просто таки навязывает использование контейнеров и алгоритмов. Причем и в ее случае большая часть библиотек создана на самой Яве (тоже есть исходники).

VD>>Ну, ты ради хохмы открой хоть один из них. Может и вопросы придут. Явно же видно что ты их максимум посмотрел и отбросил. Иначе бы не стал их со скриптами сравнивать.

ГВ>Да, это я сгоряча, в общем-то.

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

ГВ>Шаблоны добавляют производительности не столько готовой программе, сколько процессу её разработки.

Не скажи. Методы применяемые в Яве и .NET-е такие же производительные, даже по шустрее в общем итоге. Но с шаблонами там было бы все намного лучше. Одна беда там нужны уже не шаблоны, а "общие типы". Дело в том, что они должны жить в рантайме. В том же MC++ шаблоны есть и на них можно без проблем писать .NET приложения. Все это скомпилируется в мсил и (если ты не зацепил специфичных для платформы вещей) запустится на другой платформе. Но вот унаследовать CLR-класс от такого класса не удасться. :(

ГВ>Да, конечно. Ява и Шарп в каких-то случаях лаконичнее, но в каких-то — принципиально не смогут обеспечить той же лаконичности, что и C++. Хотя бы за счёт отсутствия множественного наследования и (всё ещё) — шаблонов.

Так никто и не спорит. Просто в прикладных задачай Шарпы и Явы подходят как нельзя лучше. А в системных... Вот потому мы выбераем не Яву, а .NET. Там же есть то самый С++. Если что создаем обертку на нем и используем ее из Шарпа. Мы и раньше так делали. VC + VB. На последнем клепаем интерфейсы, на первом логику и низкоуровневый код. Интеграция берез COM. Теперь просто все становится еще проще. Между прочим С++-ные модули прекрасно отлаживаются будучи встроеными в C#-проект. В COM-е нужно было изгаляться по черному, а тут... просто лафа.

VD>Согласен, что на практике можно вообще обходится без указателей, но черт возьми! Прогарммист не их понимающий и не умеющий с ними работь — это даже не ламер. Это просто маральный урод. Уж извените за грубось. Это как тест на выживание. Освоил указатели — программист. Нет — лучше заняться маркетингом и менеджментом.

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

Читал "Насморк" Лема? Вот в программировании начинается то же самое.

Все программисты в компании могут быть хорошими и умными, но когда 1000 программистов пишут продукт в пару миллионов строк кода — начинают вылазить опасные глюки, вероятность которых была бы значительно меньше для маленькой программки, которую пишет один человек и можно было бы апеллировать к таким вещам как "освоил/не освоил".

M.NET>2. Microsoft переходит на .NET, и даже само не может сказать где там будет место для С++. Если человек пишет не под win, то оно конечно всё по другому. Но таких остаётся всё меньше и меньше.

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

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

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

AVK>CLI это common language implementation, название стандарта. Ротор — название конкретной реализации.

CLI = Common Language Infrastructure

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

AVK>>CLI это common language implementation, название стандарта. Ротор — название конкретной реализации.

L>CLI = Common Language Infrastructure

Точно. Наврал немножко впопыхых.

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

IT>Все программисты в компании могут быть хорошими и умными, но когда 1000 программистов пишут продукт в пару миллионов строк кода — начинают вылазить опасные глюки, вероятность которых была бы значительно меньше для маленькой программки, которую пишет один человек и можно было бы апеллировать к таким вещам как "освоил/не освоил".

Вот народ потрахался и стал изобретать разные Явы и .NET-ы...

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

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

IT>>Все программисты в компании могут быть хорошими и умными, но когда 1000 программистов пишут продукт в пару миллионов строк кода — начинают вылазить опасные глюки, вероятность которых была бы значительно меньше для маленькой программки, которую пишет один человек и можно было бы апеллировать к таким вещам как "освоил/не освоил".

VD>Вот народ потрахался и стал изобретать разные Явы и .NET-ы...

имхо. слишком много "левого" народу пришло в программирание.
это я не об участниках этого форума, а вообще. изобретение удобных средств RAD,
языков с упрошенными типами которые не надо описывать и которые сами освобождают
память и т.д.... это все хорошо но уже после того как ты прошел "трудный путь"
ассемблера и C. . получается так что программистами себя считают те кто
прошел курс "освой программирование за 21 день" и что-то вроде этого.

перефразируя опус Эда Поста можно сказать так:
"пока живы настоящие программисты будут существовать С++ и Ассемблер"

зы. касательно сабжа. С++ лучше изучать после С. в институте я изучал
Фортран, С и Ассемблер. С++ изучил сам на 4-м курсе по книжке "от С к С++"
не помню какого автора. Страуструп тогда не пошел. он пишет "не для чайников"
в процессе изучения языка написал курсовую по моделированию управления
процессами в ОС, что на С++ получилось гораздо элегантнее чем на С

Java, C# ориентированы на бизнес-задачи. грубо говоря это тусование данных из базы в
формы или веб и обратно. ВСЕ. не все задачи программирования сводятся к этому.
есть еще множество других интересных областей и С++ там незаменим

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

VD>>Вот народ потрахался и стал изобретать разные Явы и .NET-ы...

A>имхо. слишком много "левого" народу пришло в программирание.
A>это я не об участниках этого форума,

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

A>языков с упрошенными типами которые не надо описывать

И джава и шарп являются языками со строгой типизацией

A> и которые сами освобождают
A>память

А вот это правильно. Это отнюдь не признак ориентированности на ламера. Это способ убрать работу которая не имеет никакого отношения к решаемым задачам.

A>ассемблера
А ассемблер я считаю сейчас вобще не является тем что нужно знать. Так, основы архитектуры железок, приципы функционирования, не более того.

A>Java, C# ориентированы на бизнес-задачи. грубо говоря это тусование данных из базы в
A>формы или веб и обратно. ВСЕ. не все задачи программирования сводятся к этому.
A>есть еще множество других интересных областей и С++ там незаменим
Давай ты не будешь так уверенно рассуждать о том о чем не знаешь. Ты небольшой проектик сделай на этих языках а потом уже будешь сравнивать. Тем более что эти самые бизнес-задачи (и близкие к ним, вроде сапров, АСУ разных видов и т.п.) составляют больше 90% задач программирования, и именно за это деньги платят.

AVK>С одной стороны это вроде плохо. Интереснее было бы чтобы были одни крутые зубры, зарплаты бы у них были >многотысячедолларовые. Вот только тогда практически любой проект стал бы малореальным. Есть куча задач которые кто то >должен решать. И появление языков вроде шарпа или джавы как раз и заставляет этот "левый" народ учится писать >нормальные программы.

согласен.

AVK>И джава и шарп являются языками со строгой типизацией

я имел в виду VB

AVK>А вот это правильно. Это отнюдь не признак ориентированности на ламера. Это способ убрать работу которая не имеет >никакого отношения к решаемым задачам.

это большой плюс. но и минусы есть

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


AVK>Давай ты не будешь так уверенно рассуждать о том о чем не знаешь. Ты небольшой проектик сделай на этих языках а >потом уже будешь сравнивать. Тем более что эти самые бизнес-задачи (и близкие к ним, вроде сапров, АСУ разных видов и >т.п.) составляют больше 90% задач программирования, и именно за это деньги платят.

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

VD>>Вот народ потрахался и стал изобретать разные Явы и .NET-ы...

A>имхо. слишком много "левого" народу пришло в программирание.
A>это я не об участниках этого форума, а вообще. изобретение удобных средств RAD,
A>языков с упрошенными типами которые не надо описывать и которые сами освобождают
A>память и т.д.... это все хорошо но уже после того как ты прошел "трудный путь"
A>ассемблера и C. . получается так что программистами себя считают те кто
A>прошел курс "освой программирование за 21 день" и что-то вроде этого.

Я не считаю, что это лишние люди. Просто характер отрасли меняется.
Когда-то "радиолюбители" — это были такие редкие люди, которые слушали радио с помощью допотопных самодельных приемников. Сегодня их ПРОСТО НЕТ. Потому что радио может слушать каждый, купив FM-приемник. Часть радиолюбителей теперь условно "делает эти приемники".

То же самое — с автомобилистами. Да с любой наверное достаточно новой отраслю — начиная от использования узким кругом людей, которые понимают все в отрасли и заканчивая самым широким применением людьми, которые совершенно не знают "а что внутри".

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

Кто что думает по этому поводу?

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

AVK>>И джава и шарп являются языками со строгой типизацией
A>я имел в виду VB

Странно. VB вобще то в этом топике никто не упоминал.

A>это большой плюс. но и минусы есть
Есть, как же без них. Но плюс жирнее

AVK>>А ассемблер я считаю сейчас вобще не является тем что нужно знать. Так, основы архитектуры железок, приципы >функционирования, не более того.
A>для отладки программ бывает полезно.
Отлаживать программы на уровне ассемблера? Ну заете ли, это когда совсем не чем заняться.

A>я уверенно рассуждаю именно потому что сам занимаюсь этими самыми бизнес-задачами.
A>с одной стороны за это платят деньги а с другой — скучно и везде одно и то же — базы, формы и т.д.
Ну если взяться за дело с умом то не так уж и скучно. Некоторые из задач очень сложны.

A>везет же кому-то на проекты типа мониторинга базовых станций сети GSM в реальном времени
A>и вряд ли они делают это на Java .
Я тебе по опыту скажу — в real time программировании ничего интересного нет, тупое вылавливание задержек и тупые алгоритмы, поскольку особо не наворотишь, ресурсов как правило в притык.

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

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

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

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

IT>>Это не плохо и не хорошо, а похоже на закон. Потенциально программирование вообще может умереть с созданием очень развитого искусственного интеллекта.
AVK>Пока даже на горизонте ничего подобного не проявляется.

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