Разница между Visual C++ и C++ Builder

Вчем разница между Visual C++ и C++ Builder?

0

Сообщение от maxillion movsq

А rep movsq что не цикл чтоли? Размер небольшой, метра два. Ток там не movsq, stsq надо было использовать, т.е. конструкция вида while(dst<end) *dst++=value; Во всяком случае работало раза в 3-4 медленнее чем в x32 где stsd можно ручками прописать, и медленне чем memset. это к тому как он оптимизирует.

Добавлено через 13 минут
Да кстати SSIMD/AVX был выключен.

0

Сообщение от Evan222 В чем разница между Visual C++ и C++ Builder?

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

0

Ну разумеется Дельфистами, кем же еще? Не будем забывать, что флагманским продуктом Борланда изначально был Турбо Паскаль, ставший потом Борланд Паскалем, а потом уж Борланд Дельфи. Потом менеджеры Борланда решили откусить и кусочек C++ного пирога. В результате родился Билдер, с дельфийской идеологией (поскольку базировался на уже наработанной на дельфях VCL) и сишным синтаксисом. По мне, так получилось не очень.......

0

Сообщение от CheshireCat По мне, так получилось не очень.

Ну да, там язык оказался приложением к графике, а не наоборот. Поэтому считаю, что Страуструпу надо тряхнуть стариной и, как он включил когда-то STL в стандарт, так же и Qt нужно включить.

0

Вместо всяких слов: http://en.cppreference.com/w/cpp/compiler_support
Как видим borland в глубочайшем провале.

0

Сообщение от Mr.X о соответствии которого стандарту никто никогда и не думал заморачиваться.

Ну скажем так там нестолько проблема с несоответствием как "устарелость".

Добавлено через 3 минуты

Сообщение от Voivoid Вместо всяких слов: http://en.cppreference.com/w/cpp/compiler_support Как видим borland в глубочайшем прососе.

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

Добавлено через 3 минуты

Сообщение от Mr.X Поэтому считаю, что Страуструпу надо тряхнуть стариной и, как он включил когда-то STL в стандарт, так же и Qt нужно включить.

Ну у Qt cвои недостатки, свои расширения.

Добавлено через 5 минут
Что С++Buidler что Qt имеют средства для "свойств" и "событий" (Qt только не так просто все "глубоко вшито") которые в основном необходимы для дизайнтайма и вообще написания GUI, и которые не обеспечивает сам язык.

Так что как-то тяжело представляется это все "включить" в стандарт.

0

Сообщение от CheshireCat В результате родился Билдер, с дельфийской идеологией (поскольку базировался на уже наработанной на дельфях VCL) и сишным синтаксисом.

До билдера еще была Borland C++ с Turbo Vision а потом c OWL в комплекте. При этом для того чтобы VCL заработала не в C++ дельфийскую идеологию вносили а наоборот паскаль к возможностям C++ подтягивали.

0

Сообщение от Voivoid Вместо всяких слов: http://en.cppreference.com/w/cpp/compiler_support Как видим borland в глубочайшем провале.

http://docwiki.embarcadero.com... _Compilers

0

Сообщение от Avazart Что С++Buidler что Qt имеют средства для "свойств" и "событий"

Это в Qt их сам язык не обеспечивает. В С++ Builder что свойства что события (вернее делегаты) обеспечиваются средствами компилятора, и код логики использующий как делегатов так и свойства и компактнне и логичней и читабельней.

0

Сообщение от Fulcrum_013 Это в Qt их сам язык не обеспечивает.

Свойства есть, а события ~> сигнал/слоты.
И в отличии от С++Builder это не вмуровано намертво в сам компилятор.

0

Сообщение от Avazart И в отличии от С++Builder это не вмуровано намертво в сам компилятор.

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

Добавлено через 1 минуту

Сообщение от Avazart Свойства есть, а события ~> сигнал/слоты.

Ну да. только мелкомягкий синтаксис свойств хуже читабельный.

0

Сообщение от Fulcrum_013 А в компилятор "вмурованы" делегаты т.е указатели на методы объектов, а не события.

Чего?

Делегирование достигается механизмом сигналов и слотов. (В том числе и между разными потоками в отличии от С++Builder)

Добавлено через 46 секунд

Сообщение от Fulcrum_013 Ну да. только мелкомягкий синтаксис свойств хуже читабельный.

При чем тут мелкософт?

Qt provides a sophisticated property system similar to the ones supplied by some compiler vendors. However, as a compiler- and platform-independent library, Qt does not rely on non-standard compiler features like __property or [property]. The Qt solution works with any standard C++ compiler on every platform Qt supports. It is based on the Meta-Object System that also provides inter-object communication via signals and slots.

Q_PROPERTY В общем все как обычно, вы не знаете предмета о котором идет речь, и продолжаете нести фигню.

0

Сообщение от Avazart Делегирование достигается механизмом сигналов и слотов.

Это в Qt, и поэтому вмуровано в библиотеку. В Builder делегирование (указатели на методы) реализовано на уровне компилятора. Поэтому изменение механизма работы событий, в случае необходимости не проблема. В VCL используются события с одним получателем, но для визуально конструируемых GUI большего и не надо. А угадать какой именно нужен механизм "на все случаи жизни" - не реально. Как понимаю изменить или заменить механизм обработки сигналов в Qt, даже для вновь разрабатываемых компонентов будет достаточно проблемно. А средствами С++ Buildet таких проблем нет.

Добавлено через 6 минут

Сообщение от Avazart Делегирование достигается механизмом сигналов и слотов. (В том числе и между разными потоками в отличии от С++Builder)

И зачем? Чтобы потоки стояли в очереди на запись в общие ресурсы? Смысл тогда параллелить? А если записи в общие ресурсы нет то оно thread safe само по себе.

0

Сообщение от Fulcrum_013 Это в Qt, и поэтому вмуровано в библиотеку.

Блин, в библиотеку! А не в компилятор!
А это как раз причина "отсталости" билдера.
Одно дело просто сменить один компилятор на другой и совсем другое дело насильно расширять его. И тратить на это ресурсы.
Вот отсюда и следствие что денег хватило только на запиливание x64 платформы.
Добавлено через 3 минуты

Сообщение от Fulcrum_013 И зачем? Чтобы потоки стояли в очереди на запись в общие ресурсы? Смысл тогда параллелить? А если записи в общие ресурсы нет то оно thread safe само по себе.

Не будут они стоят, спорить с вами не о чем по тому что вы нибубум ... учите матчасть.
Отправка через очередь сообщений не тормозит поток.
Добавлено через 3 минуты

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

Не понимаете.
Qt куда более гибкий по части GUI и использует не только сигналы/слоты но и стандартные средства типа наследования, паттернов ООП, подмену виджетов итп.

Добавлено через 3 минуты

Сообщение от Fulcrum_013 А угадать какой именно нужен механизм "на все случаи жизни" - не реально.

Угадывают только те кто не умеет сображать.
Те кто умеют соображать пишут под конкретную задачу и выбирают соответствующие средства.

0

Сообщение от Avazart Одно дело просто сменить один компилятор на другой и совсем другое дело насильно расширять его.

А что значит насильно? Добавить ключевое слово которое обеспечивает как минимальные отличия от уже существующего стандартного синтаксиса указателей на свободные функции и наиболее производительную обработку. Или уродоваться с библиотеками обеспечивая нечитабельный синтаксис и низкую производительность? Компиляторы должны идти в ногу со временем и потребностями разработчиков. Понадобилось пользовать указатели на методы - добавили соответсвующее ключевое слово. то же самое со свойствами. Причем стандартизировали в ANSI.
т.е получается у всех кто указатели на методы делает средствами STL устаревший на 20 лет компилятор.

Добавлено через 3 минуты

Сообщение от Avazart Угадывают только те кто не умеет сображать. Те кто умеют соображать пишут под конкретную задачу и выбирают соответствующие средства.

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

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

Сообщение от Avazart но и стандартные средства типа наследования

А что в VCL чтоли наследования нет?

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

Сообщение от Avazart Qt куда более гибкий по части GUI

А если не брать GUI? У меня к примеру в текущем проекте VCL вообще отсутствует. Но свой механизм сдвоенных сигналов-слотов с программируемой задержкой передачи сигнала. Один головняк - как это в Qt портировать.

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

Сообщение от Avazart подмену виджетов итп.

в VCL контролы то же полиморфные.

Добавлено через 39 минут

Сообщение от Avazart Не будут они стоят, спорить с вами не о чем по тому что вы нибубум ... учите матчасть. Отправка через очередь сообщений не тормозит поток.

Очередь такой же общий ресурс. Поэтому для корректного помещения сообщения в очередь потоку тоже придется в очереди постоять. А тем более если очередь без приоритетов то ни о каком получении сигнала "четко во время" , а тем более обработки "четко во время" речи быть просто не может.
Мало того на кой ляд вообще многопоточность для GUI? Для лоссов на таск-свитчинге?

0

Сообщение от Fulcrum_013 Мало того на кой ляд вообще многопоточность для GUI?

1

Сообщение от Fulcrum_013 Причем стандартизировали в ANSI.

__closure не входят в стандарт это раширение иными словами приблуда, работающая только на одном компиляторе.
Какого копиляторы все должны равняться на С++Builder ???

Добавлено через 1 минуту

Сообщение от Fulcrum_013 в VCL контролы то же полиморфные.

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

Добавлено через 33 секунды

Сообщение от Fulcrum_013 Очередь такой же общий ресурс.

Садись два, вероятно многопоточноть не ваш конек...
Речь идет про системую очередь "оконных" сообщений.

0

Сообщение от Avazart Какого копиляторы все должны равняться на С++Builder ???

А какого все должны равняться на уродство под названием STL?

Сообщение от Avazart __closure не входят в стандарт это раширение иными словами приблуда, работающая только на одном компиляторе.

С++ Builder стандартизирован ANSI еще в 90-х вместе со всеми расширениями синтаксиса. Так же кстати и Visual C++. Только стандарты на кажого свой.

0

Сообщение от Fulcrum_013 а тем более обработки "четко во время" речи быть просто не может.

А зачем вовремя?

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

Сообщение от Fulcrum_013 С++ Builder стандартизирован ANSI еще в 90-х вместе со всеми расширениями синтаксиса. Так же кстати и Visual C++. Только стандарты на кажого свой.

Очередной бред.
Укажите мне источник откуда вы это взяли?
Расширения не входят в стандарт языка С++ так что нечего выдумывать.

0

Сообщение от Avazart Речь идет про системую очередь "оконных" сообщений.

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

0