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

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.
_>Он не просто его, не любит, он его ненавидит. И других заразить пытается.
_>Вот, думаю, тролль Отличная приманка для священной войны.

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

1.

Впервые с зыком С++ я столкнулся почти 15 лет назад (почуствуйте какой стаж начав работать на Turbo C++. Тогда из доступной литературы по объектно-ориентированному программированию у меня было очень хорошее (как мне тогда казалсь) руководство по ООП на Turbo Pascal 5.5.

[0xC0000005]
Ха, вот имено столкнулся, лбами, и судя по всему скорлупа его мозга дала непоправимую трещину, сорри за лирику — не выдержал.
А по сути человек сам говорил что столкнулся впервые 15 лет назад, я тоже 15 лет назад столкнулся с бейсиком, но я считаю я не могу осуждать тот язык управляющий "Электроникой БК-10" за то что у меня что-то не получилось, что-то сломалось, и на экзамене я затёр учительскую дискету.
У него было руководство по ООП — книга по паскалю. Занятно, как такой гений (как о нём тут шарписты шаркают) выбрал имено Паскаль 5.5, ведь в нём небыло обьектов, если помните Pascal with Objects был введён с версии 7.0 борландовсой ИДЕ, и у меня в школе была эта замечательная книга, в которой строилась симуляция шахматной доски, и для Паскаля она была замечательной, но не для ООП, нет и ещё раз нет, ООП это не база для языка, ООП это методика организации логики которая может поддерживаться языком. Это как говорить о том, что я выучил курс гидромеханики разобрав медицинксий шприц или клизму — вы поймёте одно два правила, но не поймёте науки.

2.

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

И вот такого там 90%, изречения ничем не обоснованные, замете, что автор говорит сугубо о своём опыте, о неудачном опыте, он не говорит о том что этими корявыми средствами он делал шедевры, а говорит что в его кучерявом дизайне и коде виноват имено С++, это называется трезумция виновности, когда отталкиваются от обвинения, а не от защиты.
А примеры? Как такой крутой перец и гуру не наваял нам с десяток красивых примеров.


И вот тут я хочу остановиться на книге "Exceptional C++" в двух томах, где описывается как молодой девелопер может сделать криво, а как после прочтения это можно сделать шедеврально.


3.

Только вот как понимать ОО — я не думаю, что программисты, пишущие на Smalltalk'е, сочтут С++ объектно- ориентированным языком. Даже по сравнению с Java С++ явно в проигрыше — нет интерфейсов (зато есть множественное наследование со всеми его проблемами), объектная модель просто отсутствует.

Только вот как понимать ОО — это дядя Гуголь поможет, и лучше всех это опишет простая тётя Вика, которая скажет вам что ООП — парадигма программирования, в которой основными концепциями являются понятия объектов и классов. Вот она в чём парадигма, её база, и если копнуть глубже то основные её компоненты поддерживаются в С++.

Даже по сравнению с Java С++ явно в проигрыше

Вот это да, 4 года работаю с жабой в "огромных" (компания лидер в индустрии, не буду называть) индустриальных масштабах, и всегда видел интерфейс как "заплатку" на дырень моно-наследования. А дело было вот как, и это можно увидеть по эволюции, разработчики Явы сказали — нам не нужно множественное наследование, потому-что есть такие кучеряшки, которые могут при помощи паяльной лампы картошку варить, но при этом дерево иерархий превращялось в список, что делало из полиморфизма обрубок. Тогда решили сделать множественное наследование, и разрешить наследовать от одного класса, и одного и более недо-класса, который не мог бы вызвать испражнения из кучерявых пальцев говнокодеров, те никаких имплементаций, которые могут вызвать двоиственность сущностей, только описание метода, или словами микрософта — Pure Virtual Function.

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

Во первых зачем? А во вторых эти сахарные названия Persistence, Hibernate, DataObject, Serializable... как это всё напоминает ныне покойный билдер с его ВСПЛ(только не надо о его реинкорнации в кодгеар), и замете билдер был и под плюсы, и всё там было, но оказалось ненужным в настоящем языке, а всё потому-что плохому танцору... нужны контролы, компоненты, фичи, крутой язык, автоматика во всём, даже мозх автоматический, 500 крутых названий, зазубривши которые ты зовёшся гуру.

А много ли явошарпы знают удобных, простых и "интуитивно" понятных способов расширить функционал языка? Вот у меня требование к либе, я хочу регить callbackи вот таким способом:
alarmNotifier = GUIHandler::onAlarm + CoreRoutine::onAlarm
и что? у вас есть "костыль"? или всё чего нету нам не надо? Ха, это мертвецки неправильно, и обычно такое отмирает как несовершенное.

А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:
logger::log(__filename__, __line__, "log text")

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

А вот в Smalltalk'е или в Python'е таких библиотек полно.

Ага, а теперь скажите мне, у меня огромный обьект, но я хочу сериализовать только, замете слово ТОЛЬКО хидеры во всей иерархий, вот так я это использовал:
dataStream << Modifiers::HeadersOnly << hugeObject;

Слабо? или вы можете кичиться только готовыми фичами, но поверте мне, до 50% времени у больших команий использующих управляемые языки уходит на обход невозможности что-то сделать самому. И давайте честно, с примерами — сделайте мне на Яве универсальный алгоритм, да, который берёт генерик класс и делает с ним что-то своё, что есть общее для генерика. И не говорите мне что этот обрубок шаблонного метода вообще можно считать генерик, напишите-ка

public <T> void f()
{
T t = new T();
t.f();
}

Аааа, какой ужос, нельзя вызвать ничего из общего класса, ничего, есть только мега-костыли которые опустим здесь дабы не говнокодить.
Знаете что было придумано дабы обойти всё это? был сделан препроцессор для Явы, да, препроцессор, вернулись к яблони таки.

А как дела у С++ с интеграцией со скриптовыми языками

Вопрос должен стоять наоборот, а не почему все шурупы не поддерживают мою квадратную отвёртку.

Кроме того, С++ вообще не различает два существенно РАЗНЫХ понятия — абстрактнывй тип данных (АТД) и объект.

Те в С++ обьект и тип данных это одно и тоже? Не смешите мой зад.

А вот в Objective-C (другой вариант построения объектно-ориентированного языка на основе С, только в нем используется объектная модель языка Smalltalk) можно прямо на ходу узнать какие интерфейсы поддерживает объект, какие у него есть методы. Можно даже прямо на ходу добавить новый метод. И это компилируемый язык, весь графический интерфйес таких операционных систем как NeXTSTEP и Mac OS X построен именно на этом языке.

Хмм, всегда задавался вопросом о мозгах кодеров пишущих:
if(a instance of A1) ...
else if(a instance of A2) ...
else if(a instance of B) ...
else if(a instance of C) ...

Вот скажите мне серьёзно, хоть один реальный пример в рамках одного приложения(про распределённые системы отдельный разговор), когда на этапе компиляции тип обьекта не известен, а если он известен, то зачем его узнавать? Потеряли — плохой дизайн и кучерявые руки!!! + обрезанность языка.

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

А про шаблонные классы и алгоритмы автор видимо не читал, где вызов подставляется на этапе компиляции.

В С++ это практически невозможно сделать. Именно поэтому сперва в Delphi и C++ Builder, а затем и в остром С появилось возможность делегирования как расширение языка.

Именно поэтому два первых на сегодняшний день скончались а третий живёт только за счёт огромных вложений

void func1 ( A& a );

void func2 ( A a );

В чем разница между этими описаниями (кроме того, что возможно программист просто пропустил символ '&') ?

а в чём разница между func1(a) и func1(a.clone()), в том что в первом варианте кодер забыл вызвать клон
А как передать строку в Яве, чтобы она была output parameter? Вот смеху то, надо создавать холдеры, и почему в яве

void f(String s)
{
    s = "I'm dummy";
}

переданный параметр не поменяется? и Вообще ни один параметр не поменяется? ах сколько говна было сьедено на этом миллионами программистами и тестерами. И вы говорите о том что управляемые языки там просты?

Есть примеры на STL, когда эффективность на простых строковых операциях падала в десятки раз.

А так же примеры где производительность увеличивалась в 1000 раз, и тоже благодаря аллокаторам из СТЛя, а сделайте ка мне аллокатор на шарпе дорогой (только не надо что менеджер памяти мега умный и всё знает, он ничего не знает кроме вашего говнокода)

Т.е. на С++ МОЖНО писать очень эффективно. И НЕКОТОРЫЕ даже пишут. Вопрос только — относитесь ли Вы к их числу ?

Да, а вы?

TO BE CONTINUED!!!