| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > Крис Касперски по поводу С++ |
| Автор: Kuvaldis 25.10.2007, 21:06 |
| Ребята, не в целях пропаганды другого ресурса. Наткнулся на интересную статью по поводу С++ от Криса Касперски. Можно и пообсуждать http://www.xakep.ru//magazine/xs/065/022/1.asp |
| Автор: archimed7592 25.10.2007, 22:52 | ||
В принципе, Мыщъх говорит всё правильно... Не соглашусь только с одним:
По хорошему приходится использовать непереносимые решения только тогда, когда просто нет другого выбора. А насчёт тормознутости - ИМХО, важнее именно переносимость, да и тормознутость - понятие субъективное и от продукта к продукту эта характеристика меняется. |
| Автор: JackYF 25.10.2007, 23:34 |
проблемы криворукости разработчиков отдельных приложений к языку имеют мало отношения. Тем более тормоза в большой мере в продуктах Mozilla относятся к XUL, который вообще из другой степи. |
| Автор: archimed7592 25.10.2007, 23:47 |
| JackYF, насколько я понимаю, FF(сделанный переносимым их собственными разработками) ставится в противоположность Opera, написанной на Qt-3.x. Отчасти тормознутостью опера обязана именно третьей версии Qt, отчасти, уже упомянутой кривости рук. Но... Такие библиотеки как Qt(c таким размахом - охватывает большое кол-во областей программирования и работает почти на любой платформе) со своим "обобщённым" дизайном(каким бы он ни был) просто обязанны проигрывать нативным решениям. Просто очень спорный вопрос - что важнее: пара тиков процессора или свобода от вендора/компилятора/платформы/ОС. ИМХО второе. |
| Автор: ksili 26.10.2007, 05:59 |
| Свобода от ОС по-моему не настолько актуальна. Не так часто пишется ПО сразу для хотя бы двух осей. А вот свобода от вендора - это конечно очень неплохо. |
| Автор: Lazin 26.10.2007, 08:06 | ||
Непонятно, чем cl.exe неправильный. Вообще если нужна кроссплатформенная разработка то лучше C++ вообще не использовать, а использовать к примеру Java или Python. Потому-что используя кроссплатформенные библиотеки для С++ получишь примерно те-же тормоза, имхо. Да и для многих вещей вообще нет таких библиотек, например есть ли в Linux аналог WMI, а кроссплатформенная библиотека для его использования? Для Pyton-a например есть модуль anydb через который можно общаться с любой СУБД одинаково, была так-же попытка создать модуль anyGUI (для работы с произвольными GUI тулкитами), но она оказалась неудачной. |
| Автор: zkv 26.10.2007, 08:23 |
ага, непонятно, может тем, что один из лучших компиляторов под Винду на сегодняшний день? Или потому что в удобную IDE встроен, типа настоящие мачо только из командной строки компилят? Может просто потому что Made by Microsoft? Это ведь модно - кричать, что все от MS - г. Кто такой Крис Касперски? Закрадывается сомнение в компетентности автора. |
| Автор: ksili 26.10.2007, 08:38 |
Да я думаю, что просто имелось в виду, что GCC более точно соответствует стандарту и меньше содержит отсебятины. А cl.exe просто приведён в противовес. По-моему Касперски ничего плохого про MS VC++ и не сказал. |
| Автор: MAKCim 26.10.2007, 09:08 |
http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%81%D0%BF%D0%B5%D1%80%D1%81%D0%BA%D0%B8 |
| Автор: zkv 26.10.2007, 09:25 | ||||||
Ы? еще есть раздел: Compatibility and Compliance Issues in Visual C++
про это, правда, там не говорится.. |
| Автор: zkv 26.10.2007, 09:40 | ||
да, можно по разному трактовать, что он имел ввиду говоря в кавычках. Наверное просто неосознанно не понравился поклеп на инструмент, с которым работаю. |
| Автор: ksili 26.10.2007, 09:44 |
| Вообще-то Касперски сравнивая в других материалах компиляторы, как раз хвалит компилятор С++ от Майкрософт, отмечая его способности по оптимизации |
| Автор: Ln78 26.10.2007, 14:50 | ||
Я тоже в последнее время работаю только с данным компилятором (из тех двоих, с которыми работал – VS и Borland, первый считаю «самым» удобным |
| Автор: Alexeis 26.10.2007, 15:10 |
| Ну может виндовый компилятор и приличный, но EVC они сделали просто ужасным. Ужасно глючным + дебагер шаблоны не берет, часто блоки внаглую игнорирует (при дебаге), сам ставит брейки без спроса. После включения оптимизации неожиданно появляются ошибки. Родной STL, что есть, что нет никакой пользы! Имена функций в разных модулях не изолирует (это уже кривой линкер, но все равно стандарт языка не выполняется)! Переменные в цикле for создаются не в блоке, а в функции. По моему в таких элементарных вещах уж нужно придерживаться стандарта. |
| Автор: zkv 26.10.2007, 15:18 |
в восьмерке нормально все, хотя в прошлых версиях была такая фигня. ну это на компилятор не стоит сваливать это как, можно пример простой? в смысле? |
| Автор: Alek86 26.10.2007, 15:39 |
| меня тоже раздражают в VS некоторые моменты. но все они весьма мелочные. к примеру то, что в классе нельзя создать чисто виртуальный конструктор но вообще впечатление о связке VS+Visual Assist отличнейшие |
| Автор: Lazin 26.10.2007, 15:41 |
Виртуальных конструкторов не бывает в принципе |
| Автор: Alexeis 26.10.2007, 15:42 |
Максимальная версия сейчас EVC 4.0 А на кого? Не я же генерю машинный код. Кто ему виноват, что он не знает того, что не все инлайны можно делать инлайнами, ведь стандарт утверждает что делать или нет оптимизацию инлайн на совести компилятора. Че это я должен убрать слово inline руками в тех местах, где он не сумел правильно подставить? Раз не можешь делай функцию! Так везде работает. В двух cpp шниках если объявить функцию с одинаковым именем, то линкер ругается, хотя в заголовочных файлах прототипы функций не объявлены! Добавлено через 2 минуты и 4 секунды Это еще почему? Очень даже есть, на них весь VCL держится. Просто их нет в С++. |
| Автор: Lazin 26.10.2007, 15:51 | ||||
И правильно делает, в таких случаях положено использовать модификатор static. Что-то я не замечал в вцл такого, на этапе создания объекта всегда известен его тип.
|
| Автор: Kuvaldis 26.10.2007, 16:06 | ||
Alexeis,
В С++ нет метаклассов. А виртуальный конструктор "через бубен" можено сделать, как предлагает Страуструп, метод Clone |
| Автор: Alexeis 26.10.2007, 16:07 | ||
ХЗ. Недоделанный он и урезанный до нельзя.
А вот среда не знает тип объекта, потому при мышкоделии юзает виртуальный конструктор для создания необходимого класса. |
| Автор: zkv 26.10.2007, 16:07 |
упустил из виду. Тогда молчу. |
| Автор: Lazin 26.10.2007, 16:14 |
| среда не знает, но код который его создает знает, иначе как-бы выделялась память под объект. Добавлено через 53 секунды зы никогда eVC не использовал |
| Автор: Alexeis 26.10.2007, 16:22 | ||||
хм.. а другие компиляторы и без static не ругаются...
Вот этот код и вызывает виртуальный конструктор, который создает нужный объект. |
| Автор: Lazin 26.10.2007, 16:29 | ||
Тогда это уже фабрика классов, а не конструктор. вот BCB6 к примеру не ругается, а вызывает какую либо одну реализацию функции. Для компоновщика они одинаковы, хоть и находятся в разных obj файлах. Он в принципе не может определить какую функцию вызывать, так как не обрабатывает исходники. |
| Автор: archimed7592 26.10.2007, 16:34 | ||
Хм, это плохие компиляторы.
Что именно он вызывает? TButton::TButton(TControl *parent)? |
| Автор: Alexeis 26.10.2007, 16:41 |
Не буду утверждать, но предположу, что виртуальный конструктор Create у переменной метакалсса, ведь классы реализованы не на C++. |
| Автор: archimed7592 26.10.2007, 17:31 |
| Alexeis, не буду утверждать, но предположу, что TButton.Create - это тоже никакой не виртуальный конструктор А вот создание объекта имеяя только метакласс - это уже виртуальный конструктор. Это легко реализуемо. Сложнее с получением самих метаклассов. В Delphi они есть. В С++ их нет, но, к примеру, Qt реализует их(и рефлексию вообще) посредством отдельных утилит. В BCB это делается точно также, только "отдельная" утилита "встроена" в компилятор. |
| Автор: Alexeis 26.10.2007, 17:52 | ||||
Все наследники TComponent по дефолту имеют виртуальный конструктор Create, а это вся палитра VCL, остальные его перекрывают.
Боюсь что эта утилита называется Dcc32.exe. |
| Автор: archimed7592 26.10.2007, 17:56 | ||
Ок, сменим приоритеты: что такое виртуальный конструктор? В чём заключается его виртуальность(помимо, возможно, ключевого слова virtual)? Добавлено через 37 секунд Другими словами приведи пример, где будет видно, что конструктор виртуален. |
| Автор: Alek86 26.10.2007, 19:06 | ||
сори, оговорился. Деструктор |
| Автор: archimed7592 26.10.2007, 19:12 |
| Alek86, студия позволяет делать чисто виртуальные деструкторы(точно так же, как и любой другой компилятор, утверждающий, что он соответствует Стандарту). Скорее всего их не умеешь делать ты |
| Автор: Alek86 26.10.2007, 19:42 | ||
| отакие сразу наезды... отэто по стандарту должно скомпилиться и слинковаться?
|
| Автор: archimed7592 26.10.2007, 19:57 |
Нет - ты же своим объявлением виртуального деструктора класс IC "отменил" его неявное определение(definition), а сам его определить не потрудился. А чтобы уничтожить объект деструкторы всех базовых классов должны быть доступны(не private) и определены(потому что деструктор твоего класса неявно вызывает деструкторы базовых классов). |
| Автор: JackYF 26.10.2007, 19:59 | ||
нет. чисто виртуальный деструктор? быть не должно, исправляйте:
|
| Автор: archimed7592 26.10.2007, 20:03 | ||
Интересно, почему? 0_о Добавлено @ 20:07 То ли я чё-т недопонимаю, то ли... вы надо мной издеваетесь? Вам религия не позволяет написать определение деструктора? Это примерно то же самое что говорить "а почему вот это не линкуется?"
Либо напишите определение B::foo, либо не делайте явный вызов B::foo()(либо не задавайте вопросов почему это не линкуется |
| Автор: JackYF 26.10.2007, 20:22 |
а что будет вызывать компилятор? foo ему вызывать не требуется, а вот деструктор - извольте. |
| Автор: archimed7592 26.10.2007, 20:29 |
IC::~IC(). А какие ты видишь в этом преграды? 0_о Он и так его вызывает, только линкер определения ф-ции не находит. |
| Автор: Alexeis 26.10.2007, 21:01 | ||||
Например такой гипотетический пример загрузки вида.
|
| Автор: archimed7592 26.10.2007, 21:07 |
Ну, вот видишь - виртуальность конструктора проявляется только в случае создания через метакласс(как я и сказал ранее). В С++ это реализуется очень просто - одна проблема: это нужно именно реализовывать. К примеру это реализованно утилитой moc в случае Qt. Это же реализованно частью компилятора bcc32(нет, нет, dcc32 тут не при чём - он же не понимает С++ код). |
| Автор: Alexeis 26.10.2007, 21:15 | ||||
И не нужно, VCL классы C++ Builder являются лишь интерфейсами делфийских классов, для которых есть метаклассы. Потому билдер просто использует этот отработанный механизм, не внося туда ничего от самого языка С++. А компилятор dcc32 поставляется с билдером и нужен для компиляции кода на Delphi (Object Pascal), который реально и реализует механизмы VCL. Добавлено через 2 минуты и 6 секунд
А я разве говорил что это не так? Я говорил лишь, что это интенсивно используется в VCL и все, опровергая доводы о том, что это мало где используется. |
| Автор: archimed7592 26.10.2007, 21:25 | ||||
Мы друг друга не понимаем... В С++ рефлексии нет. Пользовательский компонент можно использовать как и любой другой VCL'овский(в т.ч. виртуальные конструкторы и рефлексию в общем). Вывод: bcc32 добавляет к С++ рефлексию(в том или ином виде) и dcc32 тут не при делах
А разве кто-то говорил, что это мало где используется? |
| Автор: Alexeis 26.10.2007, 21:51 | ||||||
Пояснение было больше к этому.
Пользовательский компонент не может не быть наследником TComponent. class PASCALIMPLEMENTATION TButton : public TButtonControl Мне кажеться что для классов наследников в билдере тоже создаются метаклассы иначе это потребовало слишком значительной переделкой самого VCL. |
| Автор: archimed7592 26.10.2007, 21:54 | ||
Почему? Хочешь сказать в Builder'е невозможно создавать пользовательские контролы? |
| Автор: Alexeis 26.10.2007, 22:19 | ||||
Лезем на Torry.net качаем первый попавшийся компонент, берем даже невизуальный, чтобы не было соблазна использовать классы высокого уровня, смотрим в объявление класса
Хм... с чего бы тут нужен был наследник TComponent? Смотрим ниже, секция __published !!! епрст, как же мы увидим свойства Enabled, Interval и OnTimer в object inspector, если их не будет в RTTI метакласса? Их же извлекают по названию. Все это на 100% повторяет объявление класса в Delphi. Очевидно, что и для TAnimTimer будет создан метакласс. |
| Автор: archimed7592 26.10.2007, 22:30 | ||
Гхм... Да я не спорю... Я лишь говорю, что bcc32 расширяет язык С++, добавляя к нему рефлексию(чтобы было видно в object inspector'е, чтобы можно было делать метаклассы, и т. д.). |
| Автор: powerfox 27.10.2007, 21:24 | ||
Не объясните, что это значит? Стандартный промежуточный код - понятие и .NET. Если не ошибаюсь, то в "чистом" С++ такого нет. А вызывать API программ на других языках -- не проблема. Вставлять код... Компановка объектных файлов -- это не промежуточный код. И тут надо юзать связки, наподобие g++ + gpc, и то... Это не всегда просто (если сравнивать с .NET). |
| Автор: MAKCim 28.10.2007, 10:14 |
| powerfox, тот же GCC генерирует промежуточный код с целью дополнительной оптимизации т. е сначала код на ЯВУ преобразуется во внутреннее представление компилятора, далее идет его оптимизация, (архитектуро-независимая (основное назначение промежуточного кода)) потом из оптимизированного внутреннего представления идет генерация кода целевой машины, далее его архитектуро-зависимая оптимизация и наконец на последнем шаге - формиование объектного файла |
| Автор: archimed7592 28.10.2007, 10:23 | ||
Я не очень хорошо знаком с вопросом кодогенерации современными компиляторами, но, если учесть, существование name mangling и кучу других не специфицированных стандартом ньюансов, то, осмелюсь предположить, что, даже при наличии промышленных стандартов на объектники, склеивание объектников от разных компиляторов - весьма не тривиальная задача. |
| Автор: ksili 28.10.2007, 10:30 | ||
В свете всего этого Крис Касперски хвалит (не в этой статье) линкер ulink от Юрия Харона, |
| Автор: MAKCim 28.10.2007, 10:34 | ||
не вижу ничего нетривиального |
| Автор: archimed7592 28.10.2007, 10:40 |
| Думаю, проблема больше не в нормальном линкере а в том, что делая это ты накладываешь множество ограничений на свой код. В частности: 1) нельзя выпускать исключения за пределы модуля 2) нельзя освобождать память в модуле, отличном от того, в котором она была выделена. 3) нужно заставлять компилятор какие-нибудь распространённые правила вызова ф-ций(calling conventions), т.о. связывая руки оптимизатору. 4) список думаю можно продолжить - если бы я сталкивался с этим на практике, то скорее всего что-нибудь добавил бы. Добавлено @ 10:41 MAKCim, я же сказал "осмелюсь предположить" В частности, я не представляю как можно "нетривиально" решить проблему с name mangling. |
| Автор: MAKCim 28.10.2007, 11:18 | ||
с объектниками, которые были сгенерировали С компиляторами, проблем нет, согласен? в случае с С++ компиляторами можно сравнивать имена символов и находить одинаковые подстроки в них (связано с тем, что С++ компиляторы добавляют суффиксы и/или префиксы к именам символов) |
| Автор: archimed7592 28.10.2007, 11:32 |
Ну дык статья то про С++ foo(int, char); foo(const A &, int); ... Как выбрать сравнениями выбрать одну из нужных? ;-) С шаблонами вообще труба. |
| Автор: powerfox 28.10.2007, 13:56 |
| MAKCim, спасибо. Понял. |
| Автор: Mayk 28.10.2007, 14:55 | ||
Это достаточно легко. Нужен стандарт mangling'а и ......................... extern "C++"[та да!], который можно вставлять перед определенными классами/ф-циями[как справделиво заметили в C++ FQA Lite, свзяать си и си++ легче, чем с++ и с++]. |
| Автор: archimed7592 28.10.2007, 17:30 |
Вообще говоря, стандарт не оговаривает даже то, что может указываться после extern в кавычках |
| Автор: Mayk 28.10.2007, 17:34 | ||
ну вот, значит будет лет так через 50. |
| Автор: archimed7592 28.10.2007, 18:23 |
| А в чём предполагаемая разница между extern "c++" и обыкновенными c++ объявлениями? |
| Автор: MAKCim 28.10.2007, 21:04 | ||
да, тут я задумался может и никак |
| Автор: Lazin 30.10.2007, 13:03 | ||
кстати стандарт Embedded C++ не включает в себя, множественное наследовани пространства имен RTTI и абстрактные базовые классы и многое другое |
| Автор: archimed7592 30.10.2007, 15:01 |
Что за стандарт такой? Я только о 14882 слышал... |
| Автор: Alexeis 30.10.2007, 15:07 |
| фигасе |
| Автор: zkv 30.10.2007, 15:13 |
похоже Lazin прав, не нашел ничего совсем "официального", но аргументы имеются: http://en.wikipedia.org/wiki/Embedded_C%2B%2B http://www.caravan.net/ec2plus/index.html |
| Автор: archimed7592 30.10.2007, 15:19 |
| Alexeis, я не думаю, что в embeded delphi(если такой существует) возможностей больше... zkv, да я не говорю, что он не прав |
| Автор: Lazin 30.10.2007, 16:06 |
| Ну может это и не совсем стандарт, но в WinAVR(порт gcc для AVR) эта приблуда входит. eVC - скорей всего то-же что-то в этом роде. зы я сам никогда Embedded C++ не использовал |
| Автор: archimed7592 30.10.2007, 16:34 |
| Lazin, ты об http://www.caravan.net/ec2plus/question.html? Насколько я понимаю, это промышленный стандарт. Это так? |
| Автор: Alexeis 30.10.2007, 20:24 | ||||
Ну там есть и абстрактные классы и множественное наследование и нэймспэйсы и даже шаблоны (хоть и кривые). Добавлено через 5 минут и 50 секунд
Существует только дополнение для разработки под compact framework Windows Forms, но имхо это извращение... |