Здравствуйте, Аноним, Вы писали:

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

Почему жалко именно это?
Скорее надо жалеть или не жалеть о том, что обобщённое и метапрограммирование широким слоям нафиг не сдалось

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

КЛ>>2) Реализация шаблона Singleton (В какой-то степени, а ты? Применимость — почти каждый юзает в том или ином виде)
E>Не использую. Мало того, считаю, что самая хорошая реализация синглетона -- это что-то типа:
E>

E>class CMySingletonObject {
E>    //  тут что-то такое
E>};
E>extern CMySingletonObject MySingletonObject;
E>

Смотря для чего

КЛ>>3) Интеллектуальные указатели (юзаю, а ты? то же, что и предыдущий)
E>Использую, но не такие сложные, как у А. Но шаблонные
E>НО конкретно в умных указателях, ИМХО, А. нисего нового и при этом полезного не сказал.

Он это сказал аж в 2002 году. Для кого-то это не ново, для кого-то ново.

КЛ>>6) Шаблон Visitor (к своему сожалению юзаю в 1ом месте, а ты? Пременимость — пр. пункт)
E>Почему к сожалению и о чём именно ты сожалеешь? О том, что используешь или о том, что используешь один раз?

О том, что 1 раз .

E>Мне известно о четырёх серъёзных попытках использовать этот шаблон. Все четыре провалились. То есть потом код был всё-таки переписан, без визитора и стал проще, лучше, понятнее и всё такое.

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

Erop wrote:
> C>Списки типов генерируется с помощью Comet из TLB-файлов (
> C>http://www.lambdasoft.dk/comet/index.htm ).
> ИМХО из TBL-файлов можно бы генирировать и что-то более понятное и удобное
Понятнее — можно

А вот удобнее — вряд ли. Через пару недель использования Comet'овских
стабов при необходимости использовать ATL тянет перейти нафиг на C#

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

E>Почему жалко именно это?
E>Скорее надо жалеть или не жалеть о том, что обобщённое и метапрограммирование широким слоям нафиг не сдалось

Если бы обобщённое программирование заключалось не в том, что надо писать template<class T>, а в том, что не надо писать тип параметра функции, к нему относились бы подругоиму.

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

[skipped]

E>>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.

КЛ>>Я бы не был столь категоричным. Большинство того, что он там пишет можно и нужну использовать. Просто надо знать "что?где?когда?". Никто не говорит о использовании typelists в приложении на 20 .h/.cpp., которое кажет 1 диалог с 2-мя кнопками... Если я не ошибась, А. сам пишет о том, что нужно искать компромиссы, здравые решения для каждой конкретной ситуации.

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

E>Но я так и не понял согласен ли ты с выделенным?

Хорошая программа — это:
1) программа, котрая делает то, что нужно
2) имеет мало багов
3) которую легко сопровождать и добавлять функционал

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

C>А вот удобнее — вряд ли. Через пару недель использования Comet'овских
C>стабов при необходимости использовать ATL тянет перейти нафиг на C#

А недостатки у этой вундерваффе (Comet) есть?

Left2 wrote:
> C>А вот удобнее — вряд ли. Через пару недель использования Comet'овских
> C>стабов при необходимости использовать ATL тянет перейти нафиг на C#
> А недостатки у этой вундерваффе (Comet) есть?
Есть. Оно понимает только Automation-compatible интерфейсы, в результате
обертки для IStream/IStorage пришлось писать самому по образу и подобию
Comet.

Здравствуйте, Константин Л., Вы писали:

КЛ>Нууу, я всей темы не знаю. Мало-ли как вы там его писали и нужен ли он был вообще . Я юзал 1 раз и остался очень доволен
Ну писали хорошо довольно. Но не шмогли всё равно прислонить с толком
А вообще интересно бы узнать задачу.

Здравствуйте, Аноним, Вы писали:

А>Если бы обобщённое программирование заключалось не в том, что надо писать template<class T>, а в том, что не надо писать тип параметра функции, к нему относились бы подругоиму.
Да и называлось оно иначе как-нибдь. Perl-coding, скажем

Здравствуйте, Константин Л., Вы писали:

E>>>>Ведь хорошая программа -- это не программа с boost, loki, паттернами, и ещё каким-то меганаворочеными архитектурными решениями. А ровно другая. Когда всё-всё-всё написанно максимально просто. Понятно, по возможности вообще без сложных каких-то методов средств и приёмов.

КЛ>Хорошая программа — это:
КЛ>1) программа, котрая делает то, что нужно
КЛ>2) имеет мало багов
КЛ>3) которую легко сопровождать и добавлять функционал

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

Собственно я в выделенном абзаце и утверждаю, что обычно boost, loki, etc портят 3, 2, и как следствие и 1
Да ещё и удорожают разработку, так как не каждый программист затянет применить все эти прелести не слишком разрушительно

Собственно содержание моего утверждения такое. Но я так ине понял согласен ты с ним или нет.

КЛ>Всем нравится простой код, а "крутой" еще больше
А какой код "крутой"? Ты что имеешь в виду? У меня есть подозрение, что "крутой код" мне не нравится.

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

E>А ты считаешь, что если можно усложнить что-то, то надо. Ну и что, что для этого "Опять же надо обладать некими знаниями." и что это "Согласен, это опять же сложнее.". Но ведь если ещё и такой assert прикрутить и сякой и тесты модульные наладить, то типа бкдт нам счастье. А я не понмаю зачем. Единственный заметный мне эффект -- разработка требует больше времени, более продвинутых, то есть дорогих, программеров и становиться труднее в отладке и поддержке. А плюсы-то какие?

сам же и ответил (см. выделенное)
Разве этого мало?

You will always get what you always got
  If you always do  what you always did

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

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

Этот подход тоже вполне имеет право на существование.
Чем менее квалифицированные программисты нужны, тем меньше риски проекта, потому что в любой момент ты можешь взять с улицы первого попавшегося и он вольется в команду за пару дней.
А если сидит квалифицированный перец, который мыслит исключительно рекурсивными шаблонами — то даже если ты построишь процесс разработки так, что все будет хорошо, пока этот программист в штате, что случится, когда он уйдет? Кто подхватит знамя? Аналогичного по скиллам ты быстро не найдешь, а проект все это время должен развиваться (банально должны оперативно фикситься баги), а не ждать, когда же придет очередная звезда с "шаблонным" мышлением.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Erop!

Erop, дело в том, что Александреску подходит к проектированию как разработчик библиотеки общего назначения, которая будет потом использоваться в реальном прикладном коде, а ты мыслишь сразу категориями прикладного кода.
А у этих двух подходов принципиально разные задачи. У библиотечного — дать нечто максимально гибкое, всеобемлющее и удобное, чтобы его можно было заюзать при создании своего прикладного кода, а у прикладного — решить конкретную узкую и обычно простую задачу максимально простым и ясным способом.

Грубо говоря, если тебе нужно нечто вроде for_each(v, v+size, mem_fun_ptr), то если у тебя нет под рукой STL — ты напишешь цикл и не будешь париться, а если под рукой есть STL — ты заюзаешь for_each. Но несмотря на все преимущества for_each, если у тебя нет STL, то ради одного for_each городить всю многофайловую инфраструктуру из iterator, algorithm, functional и т.д. несколько неумно. Но если оно уже есть — почему бы этим не воспользоваться?

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

А то, что ты пишешь про прикладной код — это все правильно и я с этим полностью согласен.

You will always get what you always got
  If you always do  what you always did

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

КЛ>>Хорошая программа — это:
КЛ>>1) программа, котрая делает то, что нужно
КЛ>>2) имеет мало багов
КЛ>>3) которую легко сопровождать и добавлять функционал

E>Я согласен со всем, кроме быть может "добавлять функционал", и то не так чтобы я спорю, но формулировка мне не нравится. Я бы предпочёл написать "развивать в соответсвии с потребностями потребителей"
E>Ну и два бы я расширил в сторону "легко отлаживать".

E>Собственно я в выделенном абзаце и утверждаю, что обычно boost, loki, etc портят 3, 2, и как следствие и 1

как раз для 2, 3 и необходим boost.
вы в проектах ипользуете std::vector, std::string, или свои поделки?
boost::shared_ptr, boost::lexical_cast, boost::function, ... -- все из той же серии.
Надеюсь со временем он займет место аналогичное CPAN, CTAN

E>Да ещё и удорожают разработку, так как не каждый программист затянет применить все эти прелести не слишком разрушительно

E>Собственно содержание моего утверждения такое. Но я так ине понял согласен ты с ним или нет.

C>Есть. Оно понимает только Automation-compatible интерфейсы, в результате
C>обертки для IStream/IStorage пришлось писать самому по образу и подобию
C>Comet.

То есть, она не понимает не-IDispatch унаследованных интерфейсов или ей не нравится когда в методы передаются не Variant-совместимые типы? А то ведь в ActiveX море интерфейсов которые не унаследованы от IDispatch...

Вообще интересен совет от профессионала который этой библиотекой пользовался — стоит ли вообще тратить время на то чтобы с ней разбираться или преимущества её перед ATL не стоят свеч?

Left2 wrote:
> То есть, она не понимает не-IDispatch унаследованных интерфейсов или ей
> не нравится когда в методы передаются не Variant-совместимые типы? А то
> ведь в ActiveX море интерфейсов которые не унаследованы от IDispatch...
Ей не нравятся некоторые advanced-конструкции IDL, связаные с
custom-марашаллингом.

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

> Вообще интересен совет от профессионала который этой библиотекой
> пользовался — стоит ли вообще тратить время на то чтобы с ней
> разбираться или преимущества её перед ATL не стоят свеч?
У меня достаточно сложная модель объектов в приложении, так что мне
очень удобно использовать Comet.

Сравните:

doc->GetPage(page_num)->GetItem(item_num)->SetSelected(false);

и

CComPtr<IPage> page;
HRESULT hr=doc->GetPage(page_num,&page);
check_res(hr);
CComPtr<IItem> item;
hr=page->GetItem(item_num,&item);
check_res(hr);
item->SetSelected(VARIANT_FALSE);

Ну и по мелочам — оно само генерирует нормальные стабы для
event-интерфейсов. Оказалось, что они замечательно сцепляются с
Boost.Signals:

boost::signal<void(Frame*)> frameClosedSig;
...
IFrameEventsCP* cp=&(
    connection_point_for<IFrameEvents>::connection_point);

frameClosedSig.connect(bind(&IODAS2FrameEventsCP::Fire_FrameClosed,cp,_1));

И еще по мелочам: есть очень удобный класс для работы с реестром,
STL-compatible bstr_t, "правильная" обертка для VARIANT'а и т.п.

Comet можно использовать совместно с ATL. Например, с помощью ATL
реализуем ActiveXовые интерфейсы, а Comet используем для прикладных
интерфейсов. Причем в одном coclass'е.

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

E>Здравствуйте, Аноним, Вы писали:

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

E>Почему жалко именно это?
E>Скорее надо жалеть или не жалеть о том, что обобщённое и метапрограммирование широким слоям нафиг не сдалось


Цитата из статьи Страустропа "A rationale for semantically enhanced library languages":

The focus will be on templates because they provide the key mechanism for statically type-safe expression of advanced ideas in C++

Здравствуйте, Erop, Вы писали:
[skipped]

E>Собственно я в выделенном абзаце и утверждаю, что обычно boost, loki, etc портят 3, 2, и как следствие и 1
E>Да ещё и удорожают разработку, так как не каждый программист затянет применить все эти прелести не слишком разрушительно

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

E>Собственно содержание моего утверждения такое. Но я так ине понял согласен ты с ним или нет.

Не совсем.

КЛ>>Всем нравится простой код, а "крутой" еще больше
E>А какой код "крутой"? Ты что имеешь в виду? У меня есть подозрение, что "крутой код" мне не нравится.

Высокотехнологичный, сложный....

Но это когда ты его писал , а вот когда не ты

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

E>>Единственный заметный мне эффект -- разработка требует больше времени, более продвинутых, то есть дорогих, программеров и становиться труднее в отладке и поддержке. А плюсы-то какие?
J>сам же и ответил (см. выделенное)
J>Разве этого мало?

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

Здравствуйте, Константин Л., Вы писали:


КЛ>Ну от некоторых частей буста я тоже в шоке — трудно для понимания, с наскоку не разберешся.
+1

E>>Собственно содержание моего утверждения такое. Но я так ине понял согласен ты с ним или нет.

КЛ>Не совсем.

КЛ>>>Всем нравится простой код, а "крутой" еще больше
E>>А какой код "крутой"? Ты что имеешь в виду? У меня есть подозрение, что "крутой код" мне не нравится.

КЛ> Высокотехнологичный, сложный....

КЛ>Но это когда ты его писал , а вот когда не ты
Ну я уже достиг такой победы склероза, что если и я, но не прямо сейчас, то тоже