-управление преобразованиями типов
-нет друзей, т.е. нет например возможности запрета наследования класса
-вызов перекрытого метода
-отсутствие работы с кучей, переопределение операторов new и delete
-отсутсвие префикса наследования классов virtual
-(кажется) отсутсвие встраиваемых функций и методов
-отсутсвие упаковки классов при наследовании
-я, чесно гря, ничего не слышал о статической инициализации переменных

всего чичаз и не упомнишь. в с++ каждый день открываю до сих пор что-то новое.

ЗЫЖ звиняйте за глупый вопрос, а typedef есть в яве? плюс каковы там правила поиска имен в плане различных областей видимости?

ну значит мои данные устарели

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

Сергей Ильич
a и b инициализируются во время загрузки класса в память и в дальнейшем изменить их нельзя. Чтобы их можно было изменить, надо убрать final.

Это не статическая инициализация - это динамическая, т.е. при вызове конструктора класса. А т.к. в Яве классы могут располагаться только в куче, то ни о какой статической инициализации речи быть не может. Статическая инициализация, когда не создается никакого кода, когда эти "константы" известны еще на этапе компиляции и они сразу попадают при линковке в область данных ЕЩЕ до ЗАПУСКА программы. На этом основано несколько приемов программирования С++, правда почти все они связаны с generic programming.

ЗЫЖ С++ умирал уже сто раз. Завидую стабильности этих возгласов о его скорой прискорой смерти.

ЗЫЖ2 судя по MSVC 2005 микрософт не оставляет компилер с++ без внимания, делая его использование в управляемой среде более удобным.

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

Сергей ИльичНикакого вызова конструктора еще нет. Эти переменные инициализируются, как только класс загружается JVM. Класс загружается в JVM *ДО* любого создания экземпляров этого класса.
еще раз повторю, они известны на этапе компиляции, по сути они равносильный константам, но только обладают областью видимости. Т.е. инициализации как таковой у них нет, в противовес глобальным константам, которые наподобие статичных переменных Явы инициализируются на этапе загрузки до вызова main().

не вижу смысла дальше это обсуждать - на вопрос автору темы ответили. Тему можно и нужно закрывать. Кстати, в добавлении о разнице между Ява и С++. Первый является обычным ООП-языком. С++ же помимо технологий ООП вмещает в себя еще и generic programming. Приемы последнего ПРИ УМЕЛОМ ИСПОЛЬЗОВАНИИ позволяют вывести разработку приложений на более высокий уровень безопасности типов, чем Ява. Пример - контейнеры. Для того чтобы их реализовать в Яве придется прибегать к преобразованиям типов или полиморфизму( если разрабатывать контейнер под известную иерархию классов ). Однако все это откладывает проверку типов с этапа компиляции на этап выполнения. И чаще требует от разработчика большего опыта, нежели использование контейнеров С++.

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

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

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

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

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

во флейме никогда нету смысла. сори за многословность.

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

1)у вас неверные сведения. не те книжки читали.

2)Химичить? Т.е. для вас написать массив нетипизированных укзателей проще? а потом мучатся с кучей преобразований типов. а мне проще так

что ж тут такого трудного? и главное строгая проверка типов. И все на этапе компиляции. Напишите контейнер на Яве, КОТОРОМУ БЫЛО БЫ ПОФИГ какой тип хранить. и вам сможете сделать только две вещи:
1) взять какой-нить аналог variant и писать массив для него. НУЛЕВАЯ ПРОВЕРКА ТИПОВ
2) взять какой-нить класс от которого наследуют все остальные классы вашей проги. Но тогда для вызова неполиморфных методов вам придется проверять на тип и вызвать при правильном преобразовании типа нужный метод. ХА. но это все делается в рантайм.

Шаблоны лучше и это очевидно.

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

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

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

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

- а может ваша суперсреда спрограммирует за вас анонимные методы?

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

список можно продолжать долго.

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

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

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

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

Итак в С++ помимо удобного bind есть такой классный шаблончик, как function<T>. Аргумент шаблона здесь это сигнатура функции. Т.е. мы имеем в своем распоряжении класс, реализация которого для функци и методов не зависит от оных помимо строгой проверки типов. Пример

onClick я могу присвоить любую другую функцию возвращающую void без аргументов. Как видно из кода, классу можно присваивать как обычные функции так и методы классов с такой же сигнатурой.

Не сотавит труда написать и следующее vector< function<void> >, т.о. мы будем иметь несколько указателей, для последовательного их вызова. который может выглядеть так

самое главное. мне не надо по сто раз писать ОДИН и ТОТ ЖЕ код для разных типов callback функций. Суть generic programming состоит в том, чтобы также как в ООП увеличить удобства повторного использования кода и сделать это БЕЗОПАСНО. Для того чтобы изменить сигнатуру вызова callback функции изминения в случае с шаблонами минимальны, сохраняя главное условие СТРОГОЙ СТАТИЧЕСКОЙ проверки типов.

а теперь скажите мне:
1) Это такой сложный код, который я привел? Он опасен с точки зрения проверки типов?
2) если бы у вас был контейнер callback функций с множественными преобразованиями типов, то в случае с изминением типа callback-функтора ругался бы ваш компилер на все места, где нужно сделать изминения? НЕТ.

В случае с шаблонами компилятор не даст вам пропустить ни одного некорректного использования типов. Скажите разве это плохо? НЕТ! Это отлично.

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

Будьте последовательны. Давайте начнем с конструктива. Самый простой и часто используемый мной и моими друзьями, да и многим другими программистами, прием называемый СТРАТЕГИЯ. Скажите, что вам в нем не нравится? И почему вы считаете что он не имеет практического использования. Приведите пожалуста КОНКРЕТНЫЕ фрагменты кода это демонстрирующие в не просто голословные фразы типа: "Я ни разу его не использвал, значит он не нужен!"

Вопросик другой более сложный, скажите а вы знаете что такое фабрика объектов? Абстрастрактная фабрика? Вы считаете, что это не имеет практического использования? Или вы считаете, что реализация Александреску не подходит? Почему? укажите конкретные примеры. Желательно со ссылками на паттерн Фабрики(см.Гамму) а также с примерами кода.

www.boost.org - в большинстве своем будет включен в новый стандарт С++. уже есть в MSVC 2005 и MSDN 2005. В бусте реализованы многие приемы, которые описывал Александреску. Желающие воспользоваться только этими приемами могут найти библиотеку LOKI на сорцфорж. Но в бусте например гораздо лучше и богаче реализованы аллокаторы и функции выделения памяти для маленьких и средних объектов. Так например там есть выделение памяти для синглтонов. Но в тоже время boost не имеет реализации мультиметодов и генерации иерархий для фабрик. Хотя список типов в boost имеется mpl::vector. В локи также имеется очень удобная и гибкая реализация фабрики, абстрактной фабрики, rtti оболочки, синглтон-холдер с выбором стратегии уничтожения и оживления, ну и конечно визитер.

Сергей Ильич
Зачем нужны функции и методы? Почему не одни методы?

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

Сергей ИльичТвой пример вообще не соберется MSVC 6
надо же! только что собрал под MSVC 6. видимо мы живем в разных мирах.


Сергей ИльичКовыряние в носу.
Это практическая необходимость. Именно так работают делегаты C#.
удобный и читабельный код. Вобчем, я так понял на яве нельзя написать контейнер для указателей на метод или функцию. На любую. Интересно глянуть как вы будете реализовывать удаление типа из списка callback методов.

Сергей ИльичКонцептуально довольно сложный. С точки зрения проверки типов очень опасен, поскольку если там где-нибудь будет неподходящий тип, то появится столько ошибок, что будет проще его переписать, чем разобраться "что же не так" ?
Я приблизительно так и думал что вы ответите.
1) можно поподробней в чем его КОНЦЕПТУАЛЬНАЯ сложность. с примерами кода. а то вы льете много воды не подтвержденой словами.
2) ошибок будет несколько вы правы. но насчет разобраться увы не так. все легко читается и исправляется. Это лучше чем лазить отладчиком и смотреть где какое преобразование типов неверно. Вы везде используйте ложные постулаты о том что ТО-ТО и ТО-ТО черезвычайно замочрочено. Это неверный подход. Хотя бы потому что это не является правдой.

вам видимо сложно понять подход generic programming, но его суть состоит и в том числе в отвлечении алгоритмов от типов операндов при сохранении строгой типизации. Как в случае с контейнерами. Я рад за программистов Явы и C#, что у них тоже появились generic. Это сильно облегчит им работу.

Вот полный список компиляторов, на которых ставится boost

Borland C++, Comeau C++ (win, non win), Metrowerks CodeWarrior Pro 6.x, 7.x, 8.x, and 9.x, GCC, Digital Mars C++, Edison Design Group, GNU GCC, Intel C++ for Linux, Intel C++ for Windows, KAI C++, Borland C++ for Linux (Kylix), MinGW, SGI MIPSpro C and C++, Microsoft Visual C++ version 6, 7, 7.1 (в SMVC 2005 включан фициально), SunPRO C++, Compaq C++ for Tru64 Version 6.5 and less, IBM Visual Age C++

Это еще в опровержении ваших поспешных высказываний.

Кстати относительно ваших поспешных высказываний, вы так и не ответили про книгу Александреску. Я вам задал пару наводящих вопросов. Делаем выводы...

Сергей ИльичMSVC 6 довольно слабо поддерживает стандарт. Готов ли ты нести ответственность за поведение boost в этих условиях ?
ну во-первых готов. Во-вторых это ответственность на самом деле несут разработчики буста. С самого ее первого появления она дружила с MSVC 6. И до появления 7.1 я спокойно юзал буст на шестерке. Никаких нареканий.

Сергей ИльичНо фича в том, что в контейнер *невозможно* положить сущность неправильного типа, не используя reflection или JNI
ктож спорит. я о другом. о том, что благодаря шаблонам я пишут ОДИН КЛАСС, который отвечает за использование callback функций и методов. Я полностью инкапсулирую все что мне нужно для этого класса. Ну там вызовы виртуальных функций (указатели на функцию или метод этого делать не могут), операции сравнения и т.д. Я делаю эту работу один раз. Далее я оформляю это в качестве шаблона. И в коде, потом просто указываю нужную сигнатуру. ВСЕ! Это как раз УМЕНЬШЕНИЕ СУЩНОСТЕЙ. Потому что мне не надо пложить классы для функций с другими сигнатурами. Понимаете, нет?

аналогично с контейнером. я беру vector и передаю ему нужный тип. мне не надо беспокоится о выделении памяти, синхронизации и прочее. Тот же прием. Мне не надо писать массив или копировать из другого файла что-то - УВЕЛИЧИВАЯ СУЩНОСТИ. я использую ОТЛАДЕННЫЙ КОД. Безопасно использую без всяких преобразований типов.

Сергей ИльичСлишком много сущностей. не больше чем в вашем варианте. Если вас так смущает ПРОСТЕЙШИЙ bind, то можно вместо boost::function написать boost::mem_fn. И код менять ОСОБО не надо, только убрав BIND. Просто в случае с function мы можем использовать не только методы, но обычные функции или СТАТИЧЕСКИЕ МЕТОДЫ. В вашем варианте такое совместное использование не возможно. Это(тип функтора) можно убрать в typedef, это можно спрятать в стратегию. Сущностей будет еще меньше. И код мне не придется почти менять. И читабельность не пострадает. Вы ИМХО предвзяты ОЧЕНЬ. Более подробно относительно УМЕНЬШЕНИЯ СУЩНОСТЕЙ см выше.

Теперь относительно больших сообщений обшибках, за которые вы ухватились как за соломинку бросив все остальное. Если посмотреть мое сообщение в этой ветке но страницей раньше, я уже сказал что все это флейм. Я написал, что помимо ООП есть generic programming и многие с ним не знакомы. Привычки выработанные годами вызвают бурю эмоций отторжения, которые зачастую ничем другим не мотивированны. Этим и объясняется большое колво ЛОЖНЫХ данных, которые даются о С++. Происходит как бы ИДЕОЛОГИЧЕСКОЕ ЗАПУГИВАНИЕ, особенно тех кто не знает что такое generic programming. Всему можно научится но обсуждать это в сравнении с принципиально другим языком - это флейм. так же я написал, что не считаю С++ идеальным языком. Как и любой другой язык и уж тем более яву. Но, во-первых это не дает право никому на ОБОБЩЕНИЯ. и, во-вторых, надо помнить о оптимальных решениях, когда кол-во плюсов, который дает инструмент превышает кол-во минусов. В той или иной ситуации.

Да, редко но случается большой дамп ошибок. ОН связан с глубиной иерархии шаблонного класса. Т.е. один класс инстанцирует другой, тот третий и т.д. и ВЕСЬ СТРАХ-ТО в том что компилятор печатает полное имя класса, которое получается нехилым. Страшно ли это? Да нет. я бы не назвал это армаггедоном.
1) умело проектируйте классы и используйте их с умом
2) есть такая штучка concept_check, которая в сочетании с static_assert побеждает этого зверя достаточно легко. Вы можете придумать свое сообщение об ошибке и ограничит глубину проверки. Используя те же шаблоны. Оба этих шаблона есть в boost, достаточно подробное их описание имеется у Александреску.
3) это была беда древних компилеров, теперь в большинстве своем они печатают сообщения более сжато, как бы ступенчато.

Итак, это происходит редко, это можно обойти, и это не ПЕРЕВЕШИВАЕТ кол-во ПЛЮСОВ использования шаблонов.

ЗЫЖ нучто ж. с контейнером функторов выяснили? вы поняли что вам придется пложить сущности в отличии от шаблонов? могу предложить еще задачку - анонимные методы. 8-))

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

А она потоково - безопасна? А если мне
1) нужна многопоточность?
2) не нужна многопоточность, но нужна скорость?

1) исключения в С++ никто не отменял, да кидает
2) про конструктор ваще смешно, стандартное раскручивание стека. никакой утечки памяти не бует. уничтожатся все объекты, кторые успели создаться. это стандарт. не только для буста.
3) если хотите без исключений ставьте опцию компилятора без исключений
4) да, буст потоково безопасна. многопоточность можно отключить.

Сергей ИльичА если обобщенному классу A нужен обобщенный класс В, а обобщенному классу B нужен обобщенный класс A?
конкретно, что вы имеете ввиду. если речь о форвардных декларациях в шаблонах они возможны.

Сергей Ильич Но в MSVC так с шаблонами делать нельзя.
я не знаю кто вам нашептывает на ушко. дайте кнкретный код, я его скомпилирую в MSVC.

Сергей ИльичПочему бы и не поплодить. Ведь в Java есть пакеты. По крайней мере я 100% знаю, что мне в качестве параметра будут передавать org.sergey.ilyich.sql-forum-conversation.Listener, а не какую-то сигнатуру.
да вы имеет право плодить сущности ради бога, я вас по рукам не бью. Однако меня вы очень рьбъяно и принципиально обвиняли в плодении сущностей. вы чертовски придирчивы и непоследовательны в своих высказываниях. не применяте свои же методы оценки к своим же методам решения. это идеализация.

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

итог - не одного трезвого аргумента против использования шаблонов.

Сергей ИльичЛямбда чтоли?
ну наверное, я понятия не имею что вы конкретно подразумеваете под этим словом. опять возвращаясь к вашему любимому критерию, который два поста назад был для вас принципиальным, а теперь вы его отторгнули. я о кол-ве сущностей. 8-) анонимные методы, тоже ИНОГДА удобный способ не плодить чего-то понапрасну.

Достаточно восторженная статья о генериках в сравнении с шаблонами. без комментариев.

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

1) объекты в яве всегда по сути указатели на их место в куче. поэтому когда вы пишете в яве vector<MyObj>, то это по сути вектор указателей. Указатели в С++ обладают тем же свойством, т.е. возможность присвоения полиморфных объектов. неверно наверное выразился. За исключением канечно даункастинга. Вопрос: а нафига так смешивать две разные технологии? Их взаимодействие необходимо, они т.о. компенсируют недостатки друг друга и услиливают преимущества. Вобчем возможно есть какие-то приемы программирования, для которых такая возможность нужна. Буду рад если мне о них кто-нить расскажет.

2) если бы мы написали полиморфные классы. Т.е. класс имеющий виртуальные функции и имеющий потомков. Ну это я к примеру. Можно ли в С++ такой класс распологать в динамических массивах или контейнерах напрямую без указателей? Нет нельзя. Потому что размер объекта в этом случае может быть разный. Вобчем это давняя ошибка начинающих программеров. В таких случаях как раз хранят только указатели на объекты.

Сергей Ильич
пирмеры форвардинга шаблонов полно в инете. сегодня меня не будет, вернее буду только поздно вечером. поэтому в добавок к способам применения generic programming, могу привести достаточно удачный и удобный способ управления преобразованием типов.

нам не надо писать кучу операторов для всех возможных типов. Мы пишем один шаблонный метод обычного класса. И теперь на этапе компиляции все ошибки нерадивых пользователей библиотеки или наши собственные будут присекаться. А если учесть, что методы можно перекрывать, то можно рарешать преобразования только для ОДНОГО или НЕСКОЛЬКИХ типов. Для остальных запрещать.

вот вам еще один удобный способ применения шаблонов. до вечера.

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

между прочим это связано не с шаблонами а опциями линковщика. 8-)))
Распухание EXE из-за шаблонов это миф. Известно ли вам в кратце механизм инстанцирования шаблонов? Известно ли вам, что инстанцируются, т.е. компилируются только те методы которые вызываются, все остальное так и остается простым текстом программы. Т.е. если мы бы писали контейнер на Яве и с теми методами которые есть у std::vector и его итераторов, то класс получился бы толще, чем std::vector на С++ именно, потому что инстанцируется только то что мы используем.