Современный дизайн С++

[Антон (LogRus)]

sss, не верю но я не обязан платить за услугу которая мне не нужна
так же как за RTTI

[sss]

Согласен. Просто я наверное уже закостенелый реликт, der neue gott...

[Dimka]

Начинаю разбираться - оказывается это расходы на полиморфизм!

В критических по времени исполнения приложениях это может быть именно так Хотя в большинстве случаев это совсем не так.

[Not]

Начинаю разбираться - оказывается это расходы на полиморфизм! Веришь?

Точное замечание. Прогулки по виртуальным таблицам увы небесплатны. Если важна скорость работы приложения, то статический полиморфизм - великолепная вещь. Если нужна гибкость объектной модели - динамический лучше. Все зависит от задачи.

[sss]

Интересно, что значит "прогулки по виртуальным таблицам"? Таблица существует в памяти, и по ней никто не гуляет. Просто адрес вызова берется из нее по смещению.

[Dimka]

sss, это значит, что до вызова функции нужно ещё во время исполнения прочитать её адрес из таблицы - дополнительная операция.

[npak]

У меня провокационный вопрос. А где нужно (действительно нужно и очень оправдано) использовать С++?

В наше время почти бесконечно дешевого железа языки Java и .Net дают вполне приличное быстродействие на офисных/финансовых задачах. Есть даже примеры разработки ядер операционных систем на таких языках (если память не изменяет, сборка мусора в ядре поддерживается в Plan9).

Бешеное быстродействие нужно во встроенных системах с жестким реальным временем, но даже для таких систем есть ОО язык Eiffel с поддержкой сборки мусора.

я в последнее время пишу преимущественно на связке Java+C, причем стараюсь как можно больше запихнуть в Джаву, и свести использование С к минимуму.

Так зачем вы используете С++? Для того, чтобы не искушать начальство, ибо сильно умных не любят?

[Антон (LogRus)]

npak, зачем холивары провоцируем? хотя конечно стоит задуматься может и переписать кое-что.

что касается сборки мусора, то в современном C++ это скорее вопрос дисциплины, чем реальная проблема умные указатели вполне справляются с возложенной задачей, а сочетании с пул аллокаторами дают очень приличную производительность в операциях с постоянным выделением/удалением памяти.

[Алексей++]

Так зачем вы используете С++? Для того, чтобы не искушать начальство, ибо сильно умных не любят?

а если мне просто тупо красиво ? вкусно ? И тошнит от шарпов.
Кстати, вот Инге тока шо казал - моему начальству глубоко наплевать, на чём у него программисты пишут, лишь бы работало хорошо

----
кстати, пробовал щас поставить студию 2008 - не вышло, плохая пиратская копия, не сломали . Поставилась 2005. Если новый проект буду начинать - там буду делать. В MFC

[RXL]

Леш, а меня от C++ тошнит с его наворотами. Хотя и пишу на нем...

LogRus, тебе хорошо - ты на бустах руку набил, а для меня он как бред выглядит

Куда легче на Perl программить.

[McZim]

RXL, кому что Меня от Perl и Bash воротит

[Алексей++]

вот. Всем разное нравится. О чём спор, господа ?

[Dimka]

О чём спор, господа ?

npak поднял любопытный вопрос о критериях выбора языка.

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

Фактически, пробуют новое только новички, которые ещё не "застряли" на чём-то.

[Алексей++]

а почему бы и не застрять, если оносейчас устраивает ?

[Dimka]

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

Лично я в последнее время с новыми средствами знакомлюсь менее охотно по другой причине. Я сознаю, что пишу и проектирую хуже, чем мог бы. И понимаю, что новые языки и технологии это не исправляют. Поэтому я предпочитаю тратить время на совершенствование своих знаний и способностей, а не на освоение на практике чужих разработок. Хотя с идеями знакомлюсь охотно. Хочется создавать хорошо, а не потреблять "красивые фенечки". Как кто-то приводил высказывание безвестного подполковника: "В начале научитесь в сортире ссать, не промахиваясь, а потом уже будем высокие технологии осваивать."

[RXL]

dimka, что верно то верно.

И все же Java видится мне перегруженной. А пробовал года три назад браться за ее изучение и меня отпугнула сложность не самого языка (в нем то как раз не так много нового и правила его логичные), а "стандартных библиотек". К примеру, меня тогда интересовали аплеты: чтобы сделать обработчик GUI-события нужно наварачивать какие-то адептеры и прочую хрень. Т.е. для простых действий нужно долго возится со справочниками - крайне непродуктивно.

[Dimka]

чтобы сделать обработчик GUI-события нужно наварачивать какие-то адептеры и прочую хрень.

Зато это более логичный подход с точки зрения ООП в условиях строгой типизиации, нежели добавление в язык нетипизированных делегатов и т.п. вещей, которые нивелируют все преимущества строгой типизиации

Хотя согласен, что изучение этого подхода, да и вообще концепций любой стандартной библиотеки любого языка требует наличия адекватной книжки-справочника.

И, соответственно, возникает необходимости читать эту нередко очень объёмную кокнижку, что сразу угнетает.

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

[RXL]

dimka, золотые слова (последнее)

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

[Dimka]

RXL, полностью согласен (с последним)

[sss]

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

[Алексей++]

Димка, так я ж согласное Знакомиться - всегда пожалуйста. Совершенствовать старое - тоже

[Dimka]

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

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

P.S. Давеча прочитал про нетипизированное ООП в Perl и пришёл в ужас от синтаксического подхода к этому делу. Тогда уж лучше Lua или ECMAScript.

[Dimka]

Отделил последние сообщения о деталях Perl и ECMSScript в отдельную тему

[АлексейК]

Динамический полиморфизм позволяет сделать следующее:

class B
{
};

class D : public B
{
};

class C : public B
{
};

B* obj[2];
D* d = new D;
C* c = new C;
obj[0] = d;
obj[1] = c;

А как подобное сделать с помощью статического полиморфизма?

[Алексей++]

АлексейК, а где тут полиморфизм вообще ? Тут тупо наследование

[Dimka]

АлексейК, в указанном примере происходит уменьшение информации о типе объектов, помещаемых в массив. Доводя уменьшение информации о типе до предела, получим решение вида:

Код: (C)

int x = 5;
char *message = "Hello world!\n";
void *items[2];
items[0] = (void *)&x;
items[1] = (void *)message;

В случае непосредственного применения шаблонов (templates), уменьшения информации о типе не происходит, т.к. специализированный шаблон образует в программе новый тип.

Если и можно, то так или иначе в решении должна теряться информация о типах. Мне такие решения, которые не сводятся к "void *" или к наследованию, не известны.

Алексей1153++, учи матчасть

[АлексейК]

Прошу прощения, пример не полный. Если добавить виртуальные функции, то можно использовать один массив obj для вызова разных методов f():

Код:

class B
{
virtual void f(){};
};

class D : public B
{
virtual void f();
};

class C : public B
{
virtual void f();
};

void D::f()
{
}

void C::f()
{
}

main()
{
B* obj[2];
D* d = new D;
C* c = new C;
obj[0] = d;
obj[1] = c;
for(int i=0; i<2; i++)
  odj[i]->f();
}

Вопрос остается в силе.

[Вад]

А как подобное сделать с помощью статического полиморфизма?

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

Ты пытаешься работать с двумя объектами разных типов единообразно - как с объектами одного базового типа. Это возможно за счёт виртуализации.

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

Поэтому, в частности, можно использовать std::auto_ptr<Type1> и std::auto_ptr<Type2> единообразно (статически, а не в динамике). Или создавать std::vector<Type1> и std::vector<Type2> и делать для них, скажем std::sort или std::includes - порождать разные типы и оперировать с ними одинаково, пользуясь шаблонным интерфейсом.

То, чего ты хочешь, наверное, можно сделать через шаблоны и диспетчеризацию, но решение будет малость извращённым Например, вместо массива можно попробовать использовать специальный контейнер с диспетчеризацией по типу и перекрытым оператором []. Хотя я не уверен, что это будет работать. Потому что инструмент неподходящий.

Можешь ради любопытства посмотреть, как решаются сходные задачи, скажем, в ATL/WTL. Приходится использовать нешаблонный базовый класс с виртуальными методами, от которого наследуется шаблон, который диспетчеризирует вызовы своим специализациям-потомкам, требуя от них реализации дополнительных методов.

[Dimka]

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

Да, так тип Variant обычно описывают. Но в том-то и дело, что только наследование обеспечивает уменьшение информации о типе: все потомки сводятся к одному общему предку и через интерфейс предка неразличимы.

[lapulya]

Dimka, то что все потомки "сводятся" к одному (хотя не одному, но это детали) типу, это хорошо!, а не плохо. Все дело в проектировании. архитектура в идеале должна быть такова, что в качестве параметра функции и/или мембера класса должен передаваться объект только с необходимым интерфейсом и НИЧЕГО более (т.е. если клиент модуля/объекта предполагается работать только с интерфейсом IObject, то другая функциональность ему не нужна). Так что это не минус, а плюс. Да, есть случаи когда "невозможно" (или в 90% случаев просто у архитектора не хватает абстрактного мышления для того чтобы "разложения" объектов на интерфейсы) это сделать эффективно, тогда надо будет в обход строгой типизации "поднимать" тип до более высокого. Это плохо (медленно и потенциально не безопасно), но нет кода без изъяна. задача в том чтобы свести такие преобразования к минимуму (в идеале обойти или пересмотреть архитектуру).

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

При этом надо понимать, что статический "полиморфизм" никак не сможет заменить динамический полиморфизм, а вот обратный ворэрраунд без шаблонов возможен (в самом грубом приближении это ручная реализация каждого инстацирования, да отстой, НО можно и без потери безопасности, но с потерей гибкости).