Удивительно малая активность в этом топике, да и то, больше по BCB.
А как насчет "честных" С++ программ?

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

Правда, это доля с каждым годом все уменьшается. Правомерный вопрос почему ?
Чем та же Java или C# лучше С++, что так активно его вытесняет? Попытаемся перечислить основные причины, и оценить степень их серьезности:

В пользу Java и С#:
1. Java и C# имеют систему автоматического сбора мусора. Это освобождает программиста от дополнительных затрат внимания при проектировании/кодировании.
2. Java и C# имеют способность оперировать мета-информацией, т.е. данными об устройстве классов.
3. Java и C# идут в поставке с мощнейшими и абсолютно бесплатными библиотеками пригодными практически на все случаи жизни.
4. Java и C# не могут работать с памятью напрямую (unsafe в C# пока не рассматриваем), что позволяет рассматривать это качество как "защиту от дурака"
5. Программы на Java и С# обычно при прочих равных условиях состоят из меньшего числа строк и требуют меньше времени на отладку (самое большое и стойкое заблуждение).

В пользу C++:
6. С++ позволяет использовать множественное наследование не только интерфейсов, но и реализации.
7. С++ позволяет работать с памятью напрямую, что при умелом использовании может дать приличный выигрыш в эффективности.
8. С++ имеет такое средство как шаблоны, уникальнейший и, к сожалению, плохо понимаемый большинством разработчиков механизм.

(пунктов в обоих списках могло быть гораздо больше, но и этого достаточно для начала обсуждения)

Теперь попробуем достойно ответить по пунктам-минусам.
>1. Для С++ можно использовать технологию COM для аналогичных целей. Однако, учитывая что эта технология совершенно не использует возможностей языка (т.к. предназначена для "межязыкового" общения), всерьез ее рассматривать не будем. На данный момент у меня есть отлаженная реализация классов и механизмов, которые решают эту проблему именно используя все возможности языка С++. Т.е. практически любые классы, которые написаны на C# или Java переводяться один-в-один (с точностью до мелких особенностей конструкций) на C++ c применением этой технологии. (правомерный вопрос про reflection - в следующем пункте).

>2. Какой процент классов в реальном приложении на Java и C# использует reflection? Если предположу, что 5% - это с запасом (я не беру специфические приложения) Использование для этих случаев в С++ такое понятие как Объект Класса, плюс применение всевозможных шаблонов проектирования (типа абстрактных фабрик) позволяет довольно легко решить проблему динамического создания различных экземпляров классов в зависимости от различных обстоятельств.

>3. На мой взгляд именно этот пункт (а не какие другие, учитывая только что сказанное) и является решающим. Эти библиотеки обеспечивают бОльшую начальную степень готовности пустого приложения для выполнения множества повседневных задач. Исторически, библиотеки под C++ стоят немало, и я еще не видел ни одной библиотеки хотя бы чуть-чуть сравнимой с тем, что дали нам Sun и Microsoft (.NET) сейчас. Причем, в пылу "горячей конкуренции", абсолютно даром . (чем весь мир и не преминул воспользоваться).

>4. Язык С++ можно рассматривать со многих сторон, и как довольно низкоуровневый и как довольно высокоуровневый. В этом его и сила и слабость. И здесь может помочь только строжайшая дисциплина кода. Могу предложить вариант, которым успешно пользуюсь много лет: когда кодируем участки кода, имеющие прикладной характер, строго придерживаемся стиля Java, C#, VB. Если тянет сделать что-то "нехорошее" ( п.7. ), нужно спросить себя "а возможно ли такое на этих языках". Если ответ "нет" - значит однозначно нет. Все более-менее сложные или близкие по характеру к системным задачи необходимо оформлять в виде самодостаточных абсолютно безопасных и имеющих простой внешний интерфейс классов. Все это, понятное дело, азы . Но имено нестрогое следование этим азам снискало такому мощному инструменту дурную славу. Почему программистам (а программист - это звучит "гордо", и это не пафос, это раздел человеческой деятельности требущий практически идеальных мозгов), так вот, почему программистам обязательно "давать линейкой по пальцам", в виде языков с заведомо и специально ограниченными возможностями, только для того, чтобы повышать надежность программ? Представьте только ход рассуждений разработчиков языка Java, когда они убирали оттуда все более-менее сложные и интересные конструкции языка С++ перед тем отправить Java в программистские "массы" (стадо). (Мне - обидно :)). Язык Java не люблю до сих пор, с С#, конечно, пообщаемся, там нам хоть что-то "вернули") .

>5. Самый-пресамый интересный момент. Правда жизни в том, что любые алгоритмы и любые иерархии классов, разработанные на C++, обычно оказываются как минимум вдвое меньше аналогичных на Java или там C#!!! (используя возможности 6 и 8 ). И занимают на разработку и отладку примерно вдвое меньше времени и сил. (Хотелось бы, чтобы проектировщики и системные аналитики обратили свое внимание на этот интересный факт).
Наследование реализаций и применение шаблонов - это уникальнейшие и мощнейшие инструменты, которые, почему-то нечасто используются прикладными программистами на С++. (может из-за "воспитания" на BCB?) В то время, когда програмистам на Java и C# приходится имплементить свои интерфейсы в КАЖДОМ классе-наследнике (или применять уродливые парадигмы адаптеров), в С++ мы имеем возможность лишь ОДНОКРАТНО реализовать и отладить интерфейс. Да и применение интерфейсов в чистом виде в среде чистого С++ неоправдано, я предпочитаю базовые библиотечные классы, выполняющие аналогичную роль - это экономит время, уменьшает размер программ и повышает эффективность.
Так почему же программы на С++ обычно столь громозки? А вы возьмите любую немаленькую программу на С++ и исследуйте ее на предмет соотношения количества кода общего назначения (который мог бы уже быть, как он есть в библиотеках .NET) и кода, относящегося непосредственно к прикладной области. Результат анализа обычно плачевный . Примерно 40%-80% это код, которого могло не быть . Т.е. каждый программист на С++ пишет свой очередной тысячный велосипед. И проектирование программы на С++ сводится к тривиальным и оскорбительным вещам: выбрать МИНИМУМ используемых средств и известных методологий общего назначения, дабы наша программа не превратилась в ходячую библиотеку. Т.е., на мой взляд, п.3 - это и есть тот камень предкновения. Таким образом, спорить о неких достоинствах языков в отрыве от среды, в которой они работают - бессмысленно. Языки типа Java и C# изначально по своим возможностям являются подмножествами языка С++, следовательно, утверждать, что эти языки мощнее - элементарно неграмотно . То же самое касается и насчет размера программ, написанных на С++. Повторюсь, при прочих РАВНЫХ условиях, программы на С++ гораздо короче и требуют гораздо меньше времени на разработку.

Резюме. Что дальше?
Дальше попытаемся представить себе примерный порядок работы программиста над прикладным проектом. Пусть проект будет не маленький, т.е. ситуацию написания программы в лоб отбрасываем. Прикладной программист/разработчик, исследуя полученные спецификации, пытается спроецировать сущности предметной области на разрабатываемые конструкции/типы (классы, структуры), а взаимодействия между этими сущностями описывает в виде процедур (в чистом ООП - методы классов). В конечном итоге, если разработчик шел по правильному пути, он получает отлаженный набор классов, в рамках которого решение любых задач из требуемой предметной области оборачивается весьма несложной задачей и обходиться в малое число строк исходного кода.
Т.е. на старе мы имеет некий уровень, "стартовый" уровень. Это то, что дано нам языком и библиотеками, имеющимися в распоряжении. И есть уровень некоей готовности под определенную прикладную область, "прикладной" уровень. Так вот, в случае языка С++, мы имеем возможность "подобраться" к прикладному уровню гораздо ближе, чем в случае Java и C#. Нам в этом помогает возможность переопределения практически ЛЮБЫХ операторов языка, что делает синтаксис программы наглядным а суть алгоритмов - очевидной, а так же теже самые шаблоны. Не стоит забывать, что в С++ шаблонными могут быть не только типы, но и отдельные функции, а так же отдельные методы классов внутри обычного не шаблонного класса, что позволяет нам обощать алгоритмы для работы с различными типами или специфировать их (частичная спецификация шаблонов) со сколь угодной степенью детализации.
Теперь насчет того самого "стартового" уровня. Ситуация такова, что за последние несколько лет сообщество С++ программистов так или иначе в меру своих сил и свободного времени решали отдельные задачи, т.е. уже имеется в наличии очень много исходного материала. (sourceforge, codeproject, codeguru, и еще миллион ресурсов). При желании, и наличии единомышленников, можно попытаться собрать некий framework, на основе этого самого материала, вместо того, чтобы каждый раз писать новый. У самого есть масса наработок, которые надо бы классифицировать, сделать легкий рефакторинг и (я надеюсь, с удовольствием) использовать.

Кто за - поднимите руки!

2 adb

К сведению поклонников Java - это язык с крайне низкой степенью типизации. Java-библиотеки сводят свои программы к оперирования над Object, что не есть очень быстро, т.к. динамические преобразования типов во время исполнения тоже чего-то да стоят (в доказательство своих слов могу отослать к исходникам Java VM: http://www.kaffe.org )

С 1997-го (поправьте, ели ошибаюсь) в С++ утверждена конструкция dynamic_cast (хотя реально использовалась гораздо раньше), которая динамически приводит типы не хуже, чем это делает Java. Конструкция typeid() позволяет узнать имя типа и сравнивать типы, так что, все это у нас есть.

Когда говорят, что C++ - это язык с сильной типизацией, то имеют ввиду, что это язык с сильной статической типизацией, позволяющий еще на этапе компиляции отлавливать массу ситуаций, которые Java-программисты отлавливают при отладке.

Более того, частое использование динамического приведения типа - это признак дурного тона для С++ программы. Если есть иерархия/семейство классов, требующие взаимного приведения, предпочитаю в этом случае в один из базовых классов включать виртуальные функции, типа:

а в наследниках их переопределять, причем делаю я это лишь однократно, в шаблоне, напр.:

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

2 WolfHound, 2 JibSkeart
Когда я говорил о применении шаблонов в своих программах, я не имел ввиду применение не только лишь STL или Boost , это само собой. :)
Я говорю о широком применении шаблонов как способа разработки, т.е. наряду с классами необходимо разрабатывать свои шаблоны под прикладную область в рамках своего проекта. Это дает массу преимуществ. Необходимость писать и отлаживать код шаблона лишь однажды - одно из них.

2 all

2 all

интервью с "родителем"

Наиболее интересна - вторая половина интервью.

2 WolfHound


Пример на "скорую" руку.
__uuidof работает для любых классов и структур.
для не VC++ компиляторов:


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

Давайте не будем спорить - можно обойтись или нельзя без dynamic_cast. Я в свое время 4 года писал вообще на С, и ничего. Так что обойтись можно. Но кто хочет, пусть на здоровье пользуются.

Но лично мне, увеличивать в два раза размер программы из 3-5 мест, где нужно динамическое приведение типа, неохота. Лучше я потрачу лишние 15 мин на имплементацию технологии типа QueryType.