Ребята, не в целях пропаганды другого ресурса.
Наткнулся на интересную статью по поводу С++ от Криса Касперски. 
Можно и пообсуждать
http://www.xakep.ru//magazine/xs/065/022/1.asp

В принципе, Мыщъх говорит всё правильно... Не соглашусь только с одним:

По хорошему приходится использовать непереносимые решения только тогда, когда просто нет другого выбора.
А насчёт тормознутости - ИМХО, важнее именно переносимость, да и тормознутость - понятие субъективное и от продукта к продукту эта характеристика меняется.

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

Тем более тормоза в большой мере в продуктах Mozilla относятся к XUL, который вообще из другой степи.

JackYF, насколько я понимаю, FF(сделанный переносимым их собственными разработками) ставится в противоположность Opera, написанной на Qt-3.x. Отчасти тормознутостью опера обязана именно третьей версии Qt, отчасти, уже упомянутой кривости рук.
Но... Такие библиотеки как Qt(c таким размахом - охватывает большое кол-во областей программирования и работает почти на любой платформе) со своим "обобщённым" дизайном(каким бы он ни был) просто обязанны проигрывать нативным решениям. Просто очень спорный вопрос - что важнее: пара тиков процессора или свобода от вендора/компилятора/платформы/ОС. ИМХО второе.

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

Непонятно, чем cl.exe неправильный.
Вообще если нужна кроссплатформенная разработка то лучше C++ вообще не использовать, а использовать к примеру Java или Python. Потому-что используя кроссплатформенные библиотеки для С++ получишь примерно те-же тормоза, имхо. Да и для многих вещей вообще нет таких библиотек, например есть ли в Linux аналог WMI, а кроссплатформенная библиотека для его использования?
Для Pyton-a например есть модуль anydb через который можно общаться с любой СУБД одинаково, была так-же попытка создать модуль anyGUI (для работы с произвольными GUI тулкитами), но она оказалась неудачной.

ага, непонятно, может тем, что один из лучших компиляторов под Винду на сегодняшний день? 
Или потому что в удобную IDE встроен, типа настоящие мачо только из командной строки компилят?
Может просто потому что Made by Microsoft? Это ведь модно - кричать, что все от MS - г.
Кто такой Крис Касперски? 
Закрадывается сомнение в компетентности автора.

Думаю тем, что он пропускает код, который по стандарту не должен компилироваться. Не знаю такого ключа в настройках, который включал бы strict C++ режим(к примеру пропускает специализации member template in class scope).



В его компетентности можешь не сомневаться .
Те кто читает Хакер очень хорошо знают его интересные статьи .

Да я думаю, что просто имелось в виду, что GCC более точно соответствует стандарту и меньше содержит отсебятины. А cl.exe просто приведён в противовес. По-моему Касперски ничего плохого про MS VC++ и не сказал.

Касперски

Ы?
еще есть раздел: Compatibility and Compliance Issues in Visual C++ 


про это, правда, там не говорится..

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

Вообще-то Касперски сравнивая в других материалах компиляторы, как раз хвалит компилятор С++ от Майкрософт, отмечая его способности по оптимизации

Я тоже в последнее время работаю только с данным компилятором (из тех двоих, с которыми работал – VS и Borland, первый считаю «самым» удобным  ). Но мне показалось, что в статье как раз правильность указана в кавычках неслучайно. Более того, критическое отношение к самому стандарту и юношескому максимализму при отстаивании позиций типа: "Стандарт – единственный источник и критерий для оценки компиляторов", ИМХО, в статье выражено сильнее, чем порицание конкретных компиляторов.

Это сообщение отредактировал(а) Ln78 - 26.10.2007, 14:50

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

в восьмерке нормально все, хотя в прошлых версиях была такая фигня.

ну это на компилятор не стоит сваливать   

это как, можно пример простой?

в смысле?

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

но вообще впечатление о связке VS+Visual Assist отличнейшие

Виртуальных конструкторов не бывает в принципе

  Максимальная версия сейчас EVC 4.0



А на кого? Не я же генерю машинный код. Кто ему виноват, что он не знает того, что не все инлайны можно делать инлайнами, ведь стандарт утверждает что делать или нет оптимизацию инлайн на совести компилятора. Че это я должен убрать слово inline руками в тех местах, где он не сумел правильно подставить? Раз не можешь делай функцию! Так везде работает.


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

Добавлено через 2 минуты и 4 секунды

  Это еще почему? Очень даже есть, на них весь VCL держится. Просто их нет в С++.

И правильно делает, в таких случаях положено использовать модификатор static.

Что-то я не замечал в вцл такого, на этапе создания объекта всегда известен его тип.

Alexeis, 
В С++ нет метаклассов.
А виртуальный конструктор "через бубен" можено сделать, как предлагает Страуструп, метод Clone

  ХЗ. Недоделанный он и урезанный до нельзя.


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

упустил из виду. Тогда молчу.

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

Добавлено через 53 секунды
зы
никогда eVC не использовал

хм.. а другие компиляторы и без static не ругаются...


  Вот этот код и вызывает виртуальный конструктор, который создает нужный объект.

Тогда это уже фабрика классов, а не конструктор.

вот BCB6 к примеру не ругается, а вызывает какую либо одну реализацию функции. Для компоновщика они одинаковы, хоть и находятся в разных obj файлах. Он в принципе не может определить какую функцию вызывать, так как не обрабатывает исходники.

Хм, это плохие компиляторы.



Что именно он вызывает?
TButton::TButton(TControl *parent)? 

  Не буду утверждать, но предположу, что виртуальный конструктор Create у переменной метакалсса, ведь классы реализованы не на C++.

Alexeis, не буду утверждать, но предположу, что TButton.Create - это тоже никакой не виртуальный конструктор .
А вот создание объекта имеяя только метакласс - это уже виртуальный конструктор. Это легко реализуемо. Сложнее с получением самих метаклассов. В Delphi они есть. В С++ их нет, но, к примеру, Qt реализует их(и рефлексию вообще) посредством отдельных утилит. В BCB это делается точно также, только "отдельная" утилита "встроена" в компилятор.

  Все наследники TComponent по дефолту имеют виртуальный конструктор Create, а это вся палитра VCL, остальные его перекрывают.


  Боюсь что эта утилита называется Dcc32.exe.

Ок, сменим приоритеты: что такое виртуальный конструктор? В чём заключается его виртуальность(помимо, возможно, ключевого слова virtual)?

Добавлено через 37 секунд
Другими словами приведи пример, где будет видно, что конструктор виртуален.

сори, оговорился. Деструктор

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

отакие сразу наезды...

отэто по стандарту должно скомпилиться и слинковаться?


Это сообщение отредактировал(а) Alek86 - 26.10.2007, 19:42

Нет - ты же своим объявлением виртуального деструктора класс IC "отменил" его неявное определение(definition), а сам его определить не потрудился. А чтобы уничтожить объект деструкторы всех базовых классов должны быть доступны(не private) и определены(потому что деструктор твоего класса неявно вызывает деструкторы базовых классов).

нет.



чисто виртуальный деструктор? быть не должно, исправляйте:

Интересно, почему? 0_о

Добавлено @ 20:07
То ли я чё-т недопонимаю, то ли... вы надо мной издеваетесь? 
Вам религия не позволяет написать определение деструктора?
Это примерно то же самое что говорить "а почему вот это не линкуется?"


Либо напишите определение B::foo, либо не делайте явный вызов B::foo()(либо не задавайте вопросов почему это не линкуется ). Разница с деструктором только в том, что вы не можете не делать явный вызов IC::~IC() ибо за вас это сделает компилятор вам по любой придётся написать определение деструктора(если компилятор не делает это за вас).

Это сообщение отредактировал(а) archimed7592 - 26.10.2007, 20:10

а что будет вызывать компилятор?

foo ему вызывать не требуется, а вот деструктор - извольте.

IC::~IC(). А какие ты видишь в этом преграды? 0_о
Он и так его вызывает, только линкер определения ф-ции не находит.

Например такой гипотетический пример загрузки вида.

Ну, вот видишь - виртуальность конструктора проявляется только в случае создания через метакласс(как я и сказал ранее).
В С++ это реализуется очень просто - одна проблема: это нужно именно реализовывать. К примеру это реализованно утилитой moc в случае Qt. Это же реализованно частью компилятора bcc32(нет, нет, dcc32 тут не при чём - он же не понимает С++ код).

  И не нужно, VCL классы C++ Builder являются лишь интерфейсами делфийских классов, для которых есть метаклассы. Потому билдер просто использует этот отработанный механизм, не внося туда ничего от самого языка С++. А компилятор dcc32 поставляется с билдером и нужен для компиляции кода на Delphi (Object Pascal), который реально и реализует механизмы VCL.

Добавлено через 2 минуты и 6 секунд

  А я разве говорил что это не так? Я говорил лишь, что это интенсивно используется в VCL и все, опровергая доводы о том, что это мало где используется.

Мы друг друга не понимаем...
В С++ рефлексии нет.
Пользовательский компонент можно использовать как и любой другой VCL'овский(в т.ч. виртуальные конструкторы и рефлексию в общем).
Вывод: bcc32 добавляет к С++ рефлексию(в том или ином виде) и dcc32 тут не при делах .



А разве кто-то говорил, что это мало где используется? 

Пояснение было больше к этому.



  Пользовательский компонент не может не быть наследником TComponent. 
class PASCALIMPLEMENTATION TButton : public TButtonControl 
  Мне кажеться что для классов наследников в билдере тоже создаются метаклассы иначе это потребовало слишком значительной переделкой самого VCL.

Почему? Хочешь сказать в Builder'е невозможно создавать пользовательские контролы? 

  Лезем на Torry.net качаем первый попавшийся компонент, берем даже невизуальный, чтобы не было соблазна использовать классы высокого уровня, смотрим в объявление класса


  Хм... с чего бы тут нужен был наследник TComponent?

Смотрим ниже, секция __published !!! епрст, как же мы увидим свойства Enabled, Interval и OnTimer в object inspector, если их не будет в RTTI метакласса? Их же извлекают по названию.

Все это на 100% повторяет объявление класса в Delphi. Очевидно, что и для TAnimTimer будет создан метакласс. 

Гхм... Да я не спорю... Я лишь говорю, что bcc32 расширяет язык С++, добавляя к нему рефлексию(чтобы было видно в object inspector'е, чтобы можно было делать метаклассы, и т. д.).

Не объясните, что это значит? Стандартный промежуточный код - понятие и .NET. Если не ошибаюсь, то в "чистом" С++ такого нет. А вызывать API программ на других языках -- не проблема. Вставлять код... Компановка объектных файлов -- это не промежуточный код. И тут надо юзать связки, наподобие g++ + gpc, и то... Это не всегда просто (если сравнивать с .NET).

powerfox, 
тот же GCC генерирует промежуточный код с целью дополнительной оптимизации
т. е сначала код на ЯВУ преобразуется во внутреннее представление компилятора, далее идет его оптимизация, (архитектуро-независимая (основное назначение промежуточного кода))
потом из оптимизированного внутреннего представления идет генерация кода целевой машины, далее его архитектуро-зависимая оптимизация и наконец на последнем шаге - формиование объектного файла

Это сообщение отредактировал(а) MAKCim - 28.10.2007, 10:15

Я не очень хорошо знаком с вопросом кодогенерации современными компиляторами, но, если учесть, существование name mangling и кучу других не специфицированных стандартом ньюансов, то, осмелюсь предположить, что, даже при наличии промышленных стандартов на объектники, склеивание объектников от разных компиляторов - весьма не тривиальная задача.

В свете всего этого Крис Касперски хвалит (не в этой статье) линкер ulink от Юрия Харона,    даже вроде говорит, что он единственный может делать это нормально

не вижу ничего нетривиального   


Это сообщение отредактировал(а) MAKCim - 28.10.2007, 10:35

Думаю, проблема больше не в нормальном линкере а в том, что делая это ты накладываешь множество ограничений на свой код. В частности:
1) нельзя выпускать исключения за пределы модуля
2) нельзя освобождать память в модуле, отличном от того, в котором она была выделена.
3) нужно заставлять компилятор какие-нибудь распространённые правила вызова ф-ций(calling conventions), т.о. связывая руки оптимизатору.
4) список думаю можно продолжить - если бы я сталкивался с этим на практике, то скорее всего что-нибудь добавил бы.

Добавлено @ 10:41
MAKCim, я же сказал "осмелюсь предположить" . Если ты имел с этим дело на практике, то тебе виднее.
В частности, я не представляю как можно "нетривиально" решить проблему с name mangling.

Это сообщение отредактировал(а) archimed7592 - 28.10.2007, 10:54

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

Ну дык статья то про С++ .

foo(int, char);
foo(const A &, int);
...
Как выбрать сравнениями выбрать одну из нужных? ;-)
С шаблонами вообще труба.

MAKCim, спасибо. Понял.

Это достаточно  легко.  Нужен стандарт mangling'а и   ......................... extern "C++"[та да!], который можно вставлять перед определенными классами/ф-циями[как справделиво заметили в C++ FQA Lite,  свзяать си и си++ легче, чем с++ и с++].

Вообще говоря, стандарт не оговаривает даже то, что может указываться после extern в кавычках .

ну вот, значит будет   Ставлю десятку, что когда-нибудь extern "cpp" или extern "c++"  станет стандартным.   
лет так через 50.

А в чём предполагаемая разница между extern "c++" и обыкновенными c++ объявлениями? 

да, тут я задумался
может и никак

кстати стандарт Embedded C++ не включает в себя, множественное наследовани пространства имен RTTI и абстрактные базовые классы и многое другое

Что за стандарт такой? 
Я только о 14882 слышал...

фигасе   , значит я зря матюгался на отстутствие исключений и кривой STL .

похоже Lazin прав, не нашел ничего совсем "официального", но аргументы имеются:
wiki
homepage

Alexeis, я не думаю, что в embeded delphi(если такой существует) возможностей больше...


zkv, да я не говорю, что он не прав . Я спрашиваю, что это за стандарт такой...

Ну может это и не совсем стандарт, но в WinAVR(порт gcc для AVR) эта приблуда входит. 
eVC - скорей всего то-же что-то в этом роде.
зы
я сам никогда Embedded C++ не использовал

Lazin, ты об этом?

Насколько я понимаю, это промышленный стандарт. Это так?

  Ну там есть и абстрактные классы и множественное наследование и нэймспэйсы и даже шаблоны (хоть и кривые).

Добавлено через 5 минут и 50 секунд

  Существует только дополнение для разработки под compact framework Windows Forms, но имхо это извращение...