Удивительно малая активность в этом топике, да и то, больше по 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.

А третьим игроком будут макросредства, типа MS Access, PB, Lotus Notes, развитые до голосового ввода бизнез-рулз. :)

Или докажем что то-то могём, или вымрем как динозавры.

.NET тоже на C++ написана, микрософт исходники вывалила, можно полюбоваться. Гарбадж-коллектор оттуда - зело серьезная фишка. Интересно, его можно юзать вне .NET? :)
Он там стек прочесывает на предмет поиска переменных в стеке, т.е. там нет счетчика ссылок на объект (обычно). Я насчитал 4 способа уборки мусора, когда просматривал. Кстати - он объекты в памяти двигает! Прикол? И все ссылки сохраняют целостность. Думаю эту фишку вне микрософт писали, уж больно академическая...

Насчет MFC - я тут того, либу объектную писал, с 0-ля. Типа эксперименты. Быстродействие вышло гораздо выше, чем у ATL/MFC. И код маленький получается. Нинавижу обе технологии - наелся. Тупо и то и другое. И WTL не сильно сглаживает впечатление. Надо что-то типа System.Windows.Forms по стилю и принципам. MC++ не предлагать! :)

Кто хочет поучаствовать в разработке GUI-либы для Win32 на C++?

ну, когда говорю про MC++ то имею ввиду __gc и __value классы. К этим классам неприменимо ничего интересного из C++, на них действуют такие же ограничения, как на классы C#. Можно прочитать отличия MC++ от С++ в MSDN.

напр.
1. __gc классы можно наследовать только от __gc классов
2. Множественное наследование позволительно только в виде множественного наследования __interface.
3. забыдь про шаблонные классы и функции.
4. вместо статического приведения типов используй динамический dinamic_cast<>(), при той же сигнатуре он работает по-другому для .NET классов, хотя его смысл остается прежним.
5. __gc классы можно создавать только по new, __value классы создавать по new бесполезно.

Я бы использовал MC++ как "связку" c .NET или wrapper, т.к. MC++ класс все же позволяет хранить обычные (не .NET) типы. Т.е. твой чистый С++ класс может быть мембером __gc класса.

2 alexey_1979

Желание "рукоблудить" пришло давно, по мере изучения внутренних принципов работы MFC/ATL/WTL.

На большинство приходящих в обычной работе собощений Windows, в этих библиотеках происходит следующее:
1. reflection всех Notifications
2. PretranslateMessage вдоль по всей иерархии окон.
3. Поиск объекта в MAP-ах по хендлеру.
4. линейное "прочесывание" message maps классов в ответ на КАЖДОЕ ПРИХОДЯЩЕЕ СООБЩЕНИЕ.

В моей либе среднее время обработки сообщения примерно на порядок меньше.

Да, очень много материала из ATL и WTL можно использовать вне проектов одноименных типов. (всякие EditImpl + тонна вспомогательных полезных классов и утилит)

2 alexey_1979

Меня можно смело считать еретиком, потому как:

1. reflection всех Notifications
Оказ от этого заметно усложнит реализацию и использование.
А я порой не использую встроенные классы окон, типа "Button", "ComboBox", "ListBox", т.к. имею с 0-ля написанные ООП-аналоги. И мне не нужен Reflection, достаточно наследования для переопределения СВОИХ СОБСТВЕННЫХ свойств или поведения.

2. PretranslateMessage вдоль по всей иерархии окон.
Не понял?
Если тебе не нравиться, что нужно вызывать m_view.PreTranslateMessage и PreTranslateMessage CMainFrema, то как реализовать, чтобы он автоматом вызывался?
В том то и дело, что не понял. НЕ ДОЛЖНО БЫТЬ НИКАКОГО PretranslateMessage вдоль по всей иерархии окон. Это как хук по смыcлу, т.е. "черный вход", т.е. слабость самой модели. В своем GUI оно мне ПРИНЦИПИАЛЬНО не нужно!

3. Поиск объекта в MAP-ах по хендлеру.
Чаво?
MAP разворачивается в большой if then else. Это самое эффективное в данной ситуации. Ты же не будешь создавать массив обработчиков на несколько тысяч элементов для того, чтобы обработать пару сообщений.
Вот пример расточительного использования возможностей языка. if-else, понимаешь...
Загляни в файлы с описанием WM_XXXX, сколько там реальных сообщений? (я спрашиваю именно про общие сообщения, всякие EM_XXXX не берем, потому как в моей модели их НЕТ). Так вот, там чуть больше 200 реально используемых сообщений.
Слушай внимательно:
В моей модели я использую всего только 3 класса окон: простой контрол, контрол-контейнер, форма. Все! Большинство сообщений (99.99% из общего приходящего потока) в своей оконной процедуре просто достают адрес объекта из самомого экземляра МОЕГО класса окна (а не из многотысячного ATL/MFC MAP-а) и переходят сразу на функцию из таблицы. Т.е. у меня примерно 200 функций-обработчиков. Очень простых функций. Каждая функция-обработчик просто вызывает виртуальную функцию объекта! Поэтому у меня нет "прочесывания" MAP-ов на предмет поиска сообщений или на предмет if-else.
Почему же мне потребовалось 3 класса окна? Все эти классы оперируют одними и теми-же процедурами, просто используют разный их набор в своем массиве указателей на функции-обработчики. Самый младший из них - "контрол" просто игнорирует приличную часть сообщений, для него не предназначенную, чтобы не вызывать лишний раз виртуальную функцию, т.е. определив всего еще 2 таблицы из 200 элементов я получил дополнительное повышение эффективности.
Разработчик может наследовать свой GUI-элемент от Control, ControlContainer и Form - классов, используя разные базовые классы для требуемого множества перехваченных сообщений.
Повторюсь - у меня все работает примерно на порядок быстрее, чем MFC/WTL.
В этих библиотеках на каждое приходящее сообщение происходит тонна всяких бесполезных вызовов, у меня - не происходит ничего (вызов одной виртуальной функции и то не всегда, см. Control, ControlContainer, Form).

Если у тебя есть конкретные предложения, милости просим в форум ATL/WTL на RSDN.
ok. Только насколько это приятно - обсуждение тонкостей - если немного тошнит от самой концепции. Правда, в своих коммерчесских разработках я пока использую WTL или MFC, потому как мой фреймворк требует разработки аналогов всех контролов (!!!).
Однако, посмотрите что твориться с C#! Не успел толком выйти, как под него народ уже написал тысячи и тысячи контролов. Почему? Да потому, что там нужно просто отнаследоваться и переопределить несколько виртуальных функций - это на порядок проще, а главное - на порядок типобезопаснее, чем MESSAGE_MAP-ы. В моей либе - та же самая ситуация. Написать новый контрол так же легко, как на C#. Поэтому и приглашаю единомышленников.

Программируя на MFC/WTL я изучил WinAPI практически наизусть. А не пошел бы он... Очень смешно - программируешь на ООП-библиотеке, при этом думаешь понятиями OS API.
У меня сообщения Windows "спрятаны" в самых базовых классах и о них можно забыть - это тонкости конкретной платформы.

Я сам не проч заняться созданием более продуманного фрейморка для GUI аплитух, но только
1. После выхода wtl7.1
2. После изучения и выявления недостатков всех существующих аналогов.
Изучал QT и WxWindows.
QT - весьма оторвана от чего бы то ни было, в то время как моя либа обладает общей событийной моделью для всех классов, а не только для GUI. Т.е. у меня событие (не сообщение!) может получить экземпляр какого угодно класса (как в C#) и даже просто CallBack - функция (как только в С++)

WxWindows - сильно, весьма... Но хочется сильнее :)

2 Фурников Юрий

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

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

Оказалось что сам язык сейчас значит далеко не все. Т.е ты же сам знаешь что если сказать что пишешь на C++ - обязательно спросят на чем именно - т.е. среда разработки/выполнения, подходы и т.д.
К счастью компиляторы "движуться" на встречу друг-другу, вернее навстречу стандартному С++. Свои программы я обычно компилю на VC.NET и GCC для пущей переносимости.

2 Yossarian

> Для С++ можно использовать технологию COM для аналогичных целей.
Для каких ? Для сборки мусора ? Здесь что-то не так. >
Все так, и то и другое - подходы к контролю времени жизни объектов. И там и там используется общий смысл - объект уничтожается тогда, когда на него никто больше не ссылается.

>Язык Java не люблю до сих пор,
может быть в этом дело ?
А может, все же, яйцо раньше курицы... :)

>Самый-пресамый интересный момент.
Действительно, интересный. Фактически автор утверждает, что на С++
все пишут неправильно, кроме самого автора.
Нет. В том же посте ниже я приводил причину большого размера программ - это недостаточность существующих библиотек. При ПРОЧИХ РАВНЫХ условия программа на С++ обычно никак не меньше аналогов на Java или C#.

(а что не так - в Java есть общий предок для всех
объектов, а в С++ нет, отсюда описанная проблема)
Попал в точку! Почти...
Для всех объектов мне и не нужен один базовый класс, а вот для всех Exception - крайне необходим! Я бы запретил выброс Exception произвольного типа на уровне языка (фанаты С++ - не бейте), а оставил бы только унаследованные от некоторого одного класса (компилятор -> конкретный класс - не очень красивая связка, однако typeid использует тот же подход)

> Языки типа Java и C# изначально по своим возможностям являются подмножествами языка С++
Утверждать это - само по себе неграмотно. В строгом смысле слова "подмножество языка" это когда мы можем скомпилировать программу на подмножестве компилятором для надмножества, возможно с косметическими изменениями.
Именно так. Все вполне грамотно. (если, опять же, не иметь ввиду Reflection)

Я - за.
:)) угу, т.е. С++ все-равно умирать не собирается! (а иначе на чем будут .NET - фреймворки писать?)

в предыдущем посте читать:

>Самый-пресамый интересный момент. Действительно, интересный. Фактически автор утверждает, что на С++
все пишут неправильно, кроме самого автора.
Нет. В том же посте ниже я приводил причину большого размера программ - это недостаточность существующих библиотек. При ПРОЧИХ РАВНЫХ условия программа на С++ обычно никак не больше аналогов на Java или C#.

Да и с мнением Геннадия Васильева согласен - многие пишут так себе. В основном это то поколение, которое выросло на всяких Wizard-ах. (хотя, бывают исключения, у меня есть знакомый парень, 22 года, удивительно правильно мыслит и кодит).

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

Это может и хорошо, что есть Java и C#. Кому С++ кажется слишком сложным - просим туда. Не представляю грамотного С++-ника, который бы полностью разменялся на Java или C#. Я вот практически в совершенстве VB и VBScript знаю - писал несколько гибридных проектов, "стыковался" с ними при помощи COM. И что с того? VB-рулез?
Теперь активно изучаю .NET и C#, но "дно" уже видно. После изучения исходников .NET-а, и двоичного формата .NET-объектов, для меня вообще никаких интересных моментов относительно .NET не осталось. Мне откровенно импонирует язык C#, там где я раньше использовал VB, теперь буду использовать только его (учитывая беспланую VSA-engine). Но это все рассматриваю только как неплохое дополнение, которое очень экономит время в некоторых случаях. Просто полно ситуаций, когда на Java или C# поставленную задачу НЕВОЗМОЖНО РЕШИТЬ. Потому от С++ никуда не деться.

Любителям Delphi:\r
\r
Обратите внимание, народ 2 недели пишет DBImage - компонент (6-й пост и ответ тигра в 11-м)\r
\r
/topic/45348\r
\r
Очень показательно.\r
На с++ это примерно за пол-дня делается, если не за 2 часа...

2 alex_k

WxWindows, в и-нете с пол-пинка найдешь.

На чем компилишь?

Лучше потрать пару дней на изучение и компиляцию - это все вознаградится. Там не только GUI-либа. Еще тонна полезного материала.