Стоит ли учить Win32API? Или если я знаю основы, этого хватит для полноценной основы в builder'e?

учить стоит, но хватает и основ 

это кошерное деяние.


вполне. дебилдер в принципе самодостаточен. тут есть смысл глубже копать в VCL.

Metalex, ввиду того, что версия 2010 работает жутко нестабильно, я взялся за основы WinApi диалогов. Иногда неудобства билдера настолько перевешивают, что соглашаешься на то, чтобы отказаться от удобного VCL в пользу простого и стабильного VC. Но это уже другой холивар  . В целом, для билдера хватит минимальных знаний WinApi. Остальное можно подучить по ходу дела. 

а я бы взялся за изучение Qt 

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

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

  

oldcode, когда форма имеет много компонентов или компоненты вложенные. Различные способы привязки (по левому/правому краю...) изменение размеров компонентов при изменении размеров окна. Внутреннее перераспределение места с помощью сплитеров. Различные визуальные настройки окон типа бордюров (которые обычно не записываются в ресурс).
  Вот элементарный пример. Список вариантов Combobox. В ресурсе диалога его хранить нельзя, а на форме VCL запросто. При обилии компонентов все эти инициализации разрастаются до невообразимых размеров, в которых трудно ориентироваться. А если делать грамотно, то начинаешь писать свои обертки. Кому это нужно, когда VCL уже и есть готовая объектная обертка. Разница как между велосипедом и мерседесом. 

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

IMHO если и использовать VCL, то только в Delphi, потому что дебилдер - это отрыжка паскаля. Дебилдеровский VCL - это не Си++, поэтому я бы посоветовал как mrbrooks посмотреть на Qt.
Я сам лет 8 работал на VCL, затем перешёл на Qt и забыл о дебилдере как о страшном сне.

borisbn, билдер это не только визуальные кнопочки и рюшечки! Это еще функциональные классы, БД, сетевые протоколы Инди, это отчеты, это строковая библиотека и т.д. Так что переход на QT это не просто смена одного дизайнера форм на другой. Это изучение всего комплекса классов и его слабых и сильных мест. Для студента выбирающего на чем писать дипломный проект, может это несложно. Когда же речь о рабочих проектах зажатых рамками потеря кучи времени на поиск всех аналогов в QT неоправданный расход времени. 

Когда речь идёт действительно о рабочих проектах использовать VCL, а тем более дебилдер - вообще неразумно. У него куча глюков и ограничений.

P.S. QT == QuickTime, Qt == кроссплатформенная библиотека Си++ классов

  Эх сколько же не разумных людей по своему свету. Они платят по 800$ за лицензию чисто по приколу, совсем не для того чтобы вести разработку. И до сих пор не догадываются что делают невозможное. На счет глюков можно перефразировать поговорку: старый глюк лучше новых двух  .

  


Ох Alexeis, твои слова да, Богу в уши. Проблема современного Билдера в том, что начать то легко, да вот продолжить затем сложно.


на мой скромный взгляд - это не разумно.

Думаю потому, что они больше ничего не знают. И, надо признать, порог вхождения в билдер чуток пониже, чем в Qt. Но ! Назови пару-тройку крупных известных проектов, сделанных на билдере ...
IMHO даже на MFC больше, хотя мне лично от MFC плеваться хочется.

P.S. Проекты на билдере - не кроссплатформенные. их даже откомпилировать кроме как bcc нечем

Это сообщение отредактировал(а) borisbn - 23.11.2010, 16:21

  Мяу мяу мяу. Давай еще пиписьками померимся. Будь уверен что есть. Причем даже в таких ответственных областях как банковская сфера. Потому что не кросплатформенные... ну прям детский сад. Наверное поэтому C# попирает яву и С++. Потому что он шибко кросплатформенный  . Глупости все это. 
  Билдер не популярен 
1) Плохой маркетинг. Microsoft смогла бы продать и больше Г за большие деньги   .
2) Нестабильность больших проектов. Нестабильность среды разработки.
3) Несоответствие стандарту. (больше чем у других)
4) Большое время компиляции.
5) Слабая оптимизация. 

CLR / WinAPI / Qt , только не VCL   

  

И какой вывод ? Зачем нужна такая среда разработки ? Только потому, что знаешь её ?

borisbn, потому что есть много других плюсов. Удобство, гибкость, функциональность, простота, расширяемость. На самом деле на начальном этапе можно и не знать даже такого слова "WinApi" и писать на билдере.

Добавлено через 13 минут и 52 секунды
  Например, C# также дает не шибко большую скорость кода + время JIT компиляции при загрузке. C# тем более не соответствует стандарту С++   . А глюки среды + компилятора есть везде. И в 2008 и в 2010 студии. Просто не так много.   . 
  Так что ты зря выдернул из цитаты верхнюю строчку. Она самая главная. Пипл хавает ложкой то что ему дают. Сейчас писать на Qt стало в моде. А программеры старой школы продолжают использовать билдер, потому что удобно и знают каждую "трещинку". Ведь не все тянуться за нововведениями. Многие пишут используя язык, ставя во главу угла алгоритм, который они реализуют на том что ближе. Молодежь думает, что достаточно поставить очередную новомодную штучку и будет самый крутой код! А потом хвастать, мол да я пишу на Qt! Я крут! А вы все сидите на старье. Не все версии билдера одинаково косячные. Что-то больше, что-то меньше. Билдер 6 был стабильнее, 2009 тоже сносно, а 5й и 2010 получились Г .

CLR, Qt - это как автомобиль (иномарка) + обязательный прицеп, который Вам навязали тащить за собой пожизненно .  VCL - это  как советский автомобиль, который хоть и не совершенен, но зато прост и едет.  
Все тут обхаивают Builder, но когда приходит время быстро создать обычное Win32 приложение  с БД, с обычными формами и кнопками и без гмр. , - то все сразу вспоминаю, что есть такой Biulder и его простейший VCL и ничего, что он глючит, главное влезть в сроки   .
Это как по аналогии: если едем по хорошим дорогам - берем красивую иномарку (с прицепом) и ХВАЛИМммммм ее, а когда приходится ехать по трущобным дорогам,  садимся на советское авто и едемММММ и никому об этом не говорим, как будто это не мы.  
Простите за такие аналогии, но в большинстве случаев это именно так.
А теперь ближе к теме:
1. Если не хотите писать формы руками, то WinApi и не нужен, достаточно обверток, но справочник по WinApi должен быть при себе на случай - необычных действий по дополнительным функциям.
2. Подумайте, на сколько Вам нужна кроссплатформенность? Тут хоть все и кричат о кроссплатформенности, но на самом деле в 95% случаях Ваше приложение (обычные) юзверы будут запускать под Виндой, остальные 5% - это (продвинутые) юзверы, которым Ваше приложение и нафих не нужно...    
 

Тему во флейм.

Завершающий спор аргумент против бидлера.

Собственно как уже сказали покажите крупные проекты, использующие VCL, желательно за пределами пост-советского пространства. Сравните количество вакансий, новых / крупных проектов на C++ Builder, Delphi, VCL с вакансиями на C++ / Qt, C# / WPF и почувствуйте разницу.

Смысл в том что кроме как в пост-советском пространстве уже давно Delphi / C++ Bulder выбросили на помойку истории. Перспектив кроме поддерживать какой-нибудь старый проект десятилетней давности нет.

Добавлено через 3 минуты и 7 секунд
P.S. Также вспоминаем о том как bcb поддерживает стандарт, завязке на используемый инструментарий.
И самое удивительное, что ВНЕЗАПНО только  в 2010 году появилась поддержка юникода. С разморозкой...

А зачем называть? Посещайте официальный сайт, много интересного узнаете: http://www.embarcadero.com/rad-in-action/a...cation-showcase список конечно очень урезан.
CloneCD, WinRar, Alcohol 120%, EMS -менеджеры, Macromedia HomeSite, Скайп и многое многое другое создано на Делфи и Builder.


Это сообщение отредактировал(а) Лена - 23.11.2010, 20:36

  Версия 2009 вышла в 2008 году это раз. Во вторых поддержка юникода существует уже 100 лет в обед с момента появления класса WideString и символов wchar_t, также сто лет присутствуют функции преобразования в UTF16/UTF8 и обратно.  Можно говорить о тотальном переходе на юникод. Да и раньше еще можно было использовать альтернативный пакет юникодных контролов. Тот кто сильно хотел мог использовать. 
  

  Популярность это на 90% вопрос коммерции и рекламы. Кроме того не нужно забывать про область применения. Узкий инструмент не становиться плохим просто от того что он узкий. Поэтому популярность следует оценивать в своей сфере применения. 
  Если говорить о программировании приложений под Windows с богатым пользовательским интерфейсом, корпоративных приложениях, клиенты БД, то процент не так уж и мал. 
  Например, яркий представитель: TuneUp Utilities 2010 . Красочный интерфейс, выезжающие панельки, куча кнопочек пимпочек и т.д. Сложные диалоги. Открываем папку с программой. Не может быть   куча подозрительных файлов с расширением bpl . Судя по всему билдер не имеет ни какого отношения к ним. 

    

Чтобы не быть голословным http://ru.wikipedia.org/wiki/%D0%A8%D0%B8%...%B2%D0%BE%D0%BB

  >Соответственно, приложения, которым требуется сохранять переносимость на различных C и C++ компиляторах, не должны использовать wchar_t для хранения Unicode-текста
  Билдер не заявляет переносимость поэтому вполне может использовать тип wchar_t для хранения символов UTF16. Достаточно того что он совместим с WinApi. Строки билдера прекрасно сочетаются с типами Windows поэтому позволяют использовать юникод как для внутренних нужд, так и для взаимодействия с ОС в том числе и для отображения строк в различных элементах интерфейса. Возможность обеспечена чего не хватает?

Возможно и не имеет. Скорее всего Delphi 



как я уже говорил





зашёл. посмотрел. честно говоря, список оч. кислый:

Cabriolet Dynamic Geometry, Cambridge CAD, Clone CD, BitZipperBitZipper, AVS Video Tools, Complete Time Tracking, ASUS PC Probe сделаны на билдере. остальные на Delphi. Да и из этих знаю только Clone CD и ASUS PC Probe, да и то не сказать, что серьёзные проекты.


Ну не пишут серьёзные прокты на билдере, да и вакансий на него ( как сказал cutwater ) практически нет.
Повторю: для начинающего программиста-разработчика интерфейсного ПО VCL - отличная штука, и начинать нужно с нативного для неё языка - Delphi, но начинать, вести и поддерживать большие и сложные проекты на билдере - IMHO нелепо.

Скайп написан на Дельфи, а то это значит, что это не возможно сделать в С++ Builder?  

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

Пишем на "Дебилдере", что ещё.

а что? 

Гм.. А позвольте спросить, в визуал студио можно создать такой же интерфейс как с помощью билдера? И какой проект для такого нужно создавать?

При такой постановке вопроса ответ положительный - WinForms

всё же CLR ?

Если установишь Qt, то можно гораздо лучше: builder'овские Anchor'ы сильно уступают Layout'ам, в builder'е нет понятия стиля ( skin'а ), в Qt это встроенная вещь, и т.д. и т.п.

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

ЭТО ОЧЕНЬ ВАЖНОЕ ЗАМЕЧАНИЕ! Теперь брошу все усилия на Qt.  



  

А ещё у qt хайлайтинг кода лучше ! 

  Тогда хотелось бы уточнить на счет производительности интерфейса. Известно, что формы билдера работают быстрее. Чего стоит вызов сигнала в качестве обработчика и чего стоит вызов эвента. Опять же за универсальность всегда приходиться платить скоростью и объемом. Делаем большую, активную, сложную форму опять же плюс к билдеру. 

Бесконечный холивар, а вывод всегда остается одним - каждый кулик хвалит свое болото.  

Бесполезно спорить когда оба оппонента знакомы только лишь с одним предметом спора.

какбэ нелогично:

QT использует CLR или компилит в машинный код?

QT = Quick Time, и я хз, как он работает, а Qt вообще не компилит, т.к. это - библиотека. Компилит компилятор Си++ ( на windows - msvc или minGW, на linux - gcc ). И компилит, да, в машинный код

Спасибо! Значит .NET или другая прокладка не используется, т.е. не будет потери драгоценной скорости.   

Да, если не учитывать, 5 мб dll(ешек), которые надо везде за собой тягать или впихивать все в один exe(шник)... 

  Да ерунда эти 5Мб, давно уже не живем в век Dial Up-a. Windows Forms также работает не хуже. Очевидно, что все визуальные классы попадают в кеш сборок еще на этапе установки .NET, поэтому эти библиотеки не требуют JIT компиляции и работают точно также как VCL/Qt/WinApi . 

Существенные аргументы
1) Стабильность
2) Структурная организация библиотеки
3) Заложенная функциональность
4) Быстродействие

Очевидно, что ни одна из библиотек не дает преимущества по всем 4м пунктам. 
WinApi - Стабильность + Быстродействие
VCL      - Структурная организация библиотеки + Заложенная функциональность
Qt        - Стабильность(?) + Структурная организация библиотеки + Заложенная функциональность
.NET     - Стабильность + Структурная организация библиотеки + Заложенная функциональность

В области энергетики, банковском секоре, в промышленности ПОЧТИ ВСЕ ПИШЕТСЯ НА Builder + Oracle (в России).
Изза легкости разработки и легкости поддержки.
это очевидно и споры не уместны.