Использование VCL
http://www.kolnmck.ru/lessons/Art_KOL.shtml
Ваши мнения...
И еще с большим удовольствием закомментировал
А вообще эта тема уже давно раскрыта. Все мощности Delphi в том самом VCL.
В KOL/MCK - их меньше, но и прога компактней.
Я тоже за обе библиотеки: для различных задач удобно использовать как одно так и другое.
Типа мегабайт двоичного кода это слишком тяжко для современных машин.
Сам факт того, что KOL использует модель object^ уже громаднейший минус для использования. Бредовая библиотека. Имхо.
Потора-два мегабайта для достаточно полноценной программы - много-ли? Не смешите мою коллекцию веников!
С другой стороны, если уж охота помучаться, но добиться маленького размера приложения, то может лучше вообще отказаться от использования Delphi.
Чем же Вам ВЦЛ то насолил?
Ай не скажи, братан. Я сам долгое время в MFC втыкал нехило, пока однажды не задумался: а нахЕра бы мне упал этот онанизм? Прогу, которую я делаю, скажем, две недели, какой-нить дельфиец замаклюет за три дня и даже парится не станет, потому что у заказчика абсолютно индифферентные взгляды на авторство кода и на красоту и логичность концептуального дизайна того самого приложения. И то, что мои панельки правильно стыкуются и сворачиваются, ему тоже по барабану.
VCL - не такое уж чмо, как ты себе представляешь. Реально, единственный недостаток, который мне сейчас на ум приходит - она не держит Unicode. Да и то, возможно, к данному времени он уже устранён и я жестоко ошибаюсь.
Подход бесит. Бесит, что, по сути, это - недопереписанная COM->ActiveX. Бесит подход ламеров, который выражается в вопросах на форуме типа "где скачать компонент распознавания голоса, чтобы текст зачитываешь, а он сам буквавки заполнял со знаками припинания?" Бесит былое позиционирование а-ля "не Майкрософт, но то же самое" (серьёзно, префикс T для типов данных вызывает улыбку). А ещё мне, как человеку, видавшему редактор Visual Basic в базовой поставке Windows 3.1 и умевшему им пользоваться, не нравятся претензии Borland на уникальность идеи. Но это моё субъективное. Реально, у грамотно написанного VCL-приложения показатель производительность*расширяемость/время разработки очень высок, а разница в производительности между MFC- и VCL- приложениями на современных компах не видна. Да и есть ли она, разница? Partition Magic написан с использованием VCL, а ведь у каждого есть и никто не жалуется.
Вот с Microsoft IDE ты прав на все 10 из 10 - чудо из чугез: не тупит, грузится 2 секунды, мощна и исчерпывающа (о какое слово!). А если ещё и Visual Assist прикрутить, то можно по тысяче строк кода за два часа набарабанивать (кстати, образец удивительной расширяемости). Ещё нравится продвигаемое в ней понятие "solution" (кто умеет этим пользоваться, тот поймёт). Вот от этой программулины я отказаться так и не смог, ответил для себя ".NET" и больше за MFC, поверь, не сяду никогда.
.NET это очень вкусный наркотик :rolleyes:
Сам на него подсел...
Ты не поверишь, но мне как раз наоборот - в студии быстрее, чем билдере работается.)
VCL - не такое уж чмо, как ты себе представляешь. Реально, единственный недостаток, который мне сейчас на ум приходит - она не держит Unicode. Да и то, возможно, к данному времени он уже устранён и я жестоко ошибаюсь.
Последний билдер все так же не дружит с юникодом, как и шестой, и по всем прогнозам дружить не будет еще долго.Сейчас опишу, почему я бы не стал програмить под VCL а выбрал бы MFC.(Много аргументов касаются не только самих библиотек, но и среды разработки, в которой они поддерживаются).
+ нету поддержки кода под х64.
+ никаких нормальных механизмов для программирования под КПК
+ отсутствие мощных утилит для профилирования кода. Стандартный Codeguard - конечно хорошо, что он есть, но вот даже до стандартных средств студии - ему далеко
+ раздражает постоянная глюкавость самой оболочки. Проэкт на пару миллионов строк часто умудряется крашануть IDEшку при загрузке
+ Билдеровский интеллисенс - для проэкта в пару миллионов строк кода - думает над подсказкой около минуты, тогда как в студии - мгновенно.
Подход бесит. Бесит, что, по сути, это - недопереписанная COM->ActiveX. Бесит подход ламеров, который выражается в вопросах на форуме типа "где скачать компонент распознавания голоса, чтобы текст зачитываешь, а он сам буквавки заполнял со знаками припинания?" Бесит былое позиционирование а-ля "не Майкрософт, но то же самое" (серьёзно, префикс T для типов данных вызывает улыбку). А ещё мне, как человеку, видавшему редактор Visual Basic в базовой поставке Windows 3.1 и умевшему им пользоваться, не нравятся претензии Borland на уникальность идеи. Но это моё субъективное. Реально, у грамотно написанного VCL-приложения показатель производительность*расширяемость/время разработки очень высок, а разница в производительности между MFC- и VCL- приложениями на современных компах не видна. Да и есть ли она, разница? Partition Magic написан с использованием VCL, а ведь у каждого есть и никто не жалуется.
Так все дело - именно в поддержке своего детища) Толку мне, как разработчику, с VCL, если он даже юникод толком не поддерживает? ;) Если его развитие осталось на уровне 2002-2003 года?
Вот с Microsoft IDE ты прав на все 10 из 10 - чудо из чугез: не тупит, грузится 2 секунды, мощна и исчерпывающа (о какое слово!). А если ещё и Visual Assist прикрутить, то можно по тысяче строк кода за два часа набарабанивать (кстати, образец удивительной расширяемости). Ещё нравится продвигаемое в ней понятие "solution" (кто умеет этим пользоваться, тот поймёт). Вот от этой программулины я отказаться так и не смог, ответил для себя ".NET" и больше за MFC, поверь, не сяду никогда.
.NET, не всегда позволяет начальство использовать. :) Приходится писать Win32 + STL + MFC. Но все-равно получается быстрее, чем с VCL. К тому же под студию мне пока-что хватало boost + wxwidgets для того, чтоб написать все, что мне было нужно, а под билдер - очень напрягает сидеть и искать компонентик, который делает что-то одно, причем довольно криво(сразу вспомнились Indy). Да и более серьезные библиотеки билдера - все-равно не отличаются стабильностью (jvcl, к примеру).
Просто, к чему я все это веду - что VCL - позавчерашний день, с соответствующими недостатками, тогда как, даже MFC развивается.
Последний билдер все так же не дружит с юникодом, как и шестой, и по всем прогнозам дружить не будет еще долго.Сейчас опишу, почему я бы не стал програмить под VCL а выбрал бы MFC.(Много аргументов касаются не только самих библиотек, но и среды разработки, в которой они поддерживаются).
+ нету поддержки кода под х64.
+ никаких нормальных механизмов для программирования под КПК
+ отсутствие мощных утилит для профилирования кода. Стандартный Codeguard - конечно хорошо, что он есть, но вот даже до стандартных средств студии - ему далеко
+ раздражает постоянная глюкавость самой оболочки. Проэкт на пару миллионов строк часто умудряется крашануть IDEшку при загрузке
+ Билдеровский интеллисенс - для проэкта в пару миллионов строк кода - думает над подсказкой около минуты, тогда как в студии - мгновенно.
Так все дело - именно в поддержке своего детища) Толку мне, как разработчику, с VCL, если он даже юникод толком не поддерживает? ;) Если его развитие осталось на уровне 2002-2003 года?
.NET, не всегда позволяет начальство использовать. :) Приходится писать Win32 + STL + MFC. Но все-равно получается быстрее, чем с VCL. К тому же под студию мне пока-что хватало boost + wxwidgets для того, чтоб написать все, что мне было нужно, а под билдер - очень напрягает сидеть и искать компонентик, который делает что-то одно, причем довольно криво(сразу вспомнились Indy). Да и более серьезные библиотеки билдера - все-равно не отличаются стабильностью (jvcl, к примеру).
Просто, к чему я все это веду - что VCL - позавчерашний день, с соответствующими недостатками, тогда как, даже MFC развивается.
Смотря чё пишешь. Если, например, замешан в индустрии автоматизации повседневной деятельности (скажем, организовать поток товара и связанного с ним финанса в огромном супермаркете), то на Unicode с x64 становится уже как-то пофиг - не оценят. И концепции типа "доукмент/вид" там тоже не очень-то котируются - серверная часть организована в виде СУБД и вся бизнес-логика организуется прямо в ней, а от проги твоей требуется лишь максимально эргономично представить хранимую в ней информацию.
Если же ты пишешь какое-нибудь автоматизированное рабочее место как часть корпоративного решения, то тебе и MFC не поможет - там фреймворки покруче требуются. И, кстати, попробуй как-нибудь на досуге OLE с автоматизацией с помошью MFC попрограммировать - проще застрелиться. А ведь, бывает, приходит такое наследство.
Просто не стоит забывать, что Delphi, например, появился как продукт, облегчающий работу с базами данных, и на место незаменимого помощника для создания редактора неуравновешенных параметрических кривых в пространстве VCL, в общем-то, никогда не ориентировалась. Каждому, как говорится, своё. У MFC уровень абстрагирования гораздо ниже, поэтому и системы на её базе можно более подходящим образом заточить под определённое "что-то".
А по поводу оболочки - оглянись: оно всё тупит. Я, помню, даже linux-кластер программировал на графической станции из-под Винды на VС++, и писал прогу, которая из vcproj-файла создавала пакетный коммандный файл, который через PuTTY перегонял на кластер сорцы, запускал там dos2unix для смены "типа кодировки", а затем интеловский компайлер. А всё потому, что KDevelop линовский мне по две минуты пустой проект создавал. Да и вообще, окошко immediate, напару с edit-and-continue, отражает всю красоту и мощь оладчика Студии для C++. Тем не менее вопроса о VCL это никак не касается.
Если же ты пишешь какое-нибудь автоматизированное рабочее место как часть корпоративного решения, то тебе и MFC не поможет - там фреймворки покруче требуются. И, кстати, попробуй как-нибудь на досуге OLE с автоматизацией с помошью MFC попрограммировать - проще застрелиться. А ведь, бывает, приходит такое наследство.
Как по мне то универсальность механизма - его сильная сторона.
Абсолютно согласен, но что осталось у Дельфи и Билдера от их заточености? Согласись, что намного легче и быстрее писать програмки под студию с использованием того же ADO.NET, чем топтаться на древнейших технологиях и пытаться, чтоб програмка работала нормально под дырявый Interbase. :)
К тому же, лично мне больше нравится MFC - именно из-за того, что он не заточен под что-либо. Если нет заточенности - получается конструктор, если есть - трансформер. По-моему конструктор - лучше :)
А по поводу оболочки - оглянись: оно всё тупит. Я, помню, даже linux-кластер программировал на графической станции из-под Винды на VС++, и писал прогу, которая из vcproj-файла создавала пакетный коммандный файл, который через PuTTY перегонял на кластер сорцы, запускал там dos2unix для смены "типа кодировки", а затем интеловский компайлер. А всё потому, что KDevelop линовский мне по две минуты пустой проект создавал. Да и вообще, окошко immediate, напару с edit-and-continue, отражает всю красоту и мощь оладчика Студии для C++. Тем не менее вопроса о VCL это никак не касается.
Все познается в сравнении. Пока-что, все с чем я сталкивался работало гораздо быстрее под VC, чем билдер. Но, не могу не согласиться - конкретно VCL это не касается. Хотя, я считаю, что рассматривать нужно связку VCL+Builder vs MF+Visual Studio, а не отдельно взятые библиотеки. :)
ADO .NET и всё, что с ним связано, я бы вообще сейчас оставил вне обсуждения, поскольку это - новый виток в развитии технологий доступа к данным, и в сравнении с ним и все предыдущие (мало-мальски претендующие на звание "поставщик данных") оказываются полным фуфлом, а не только Interbase. К тому же, подход к интеграции ADO .NET с VS вообще кардинально меняет способы разработки бизнес-приложений для Windows.
А ну их обе в баню.
"Страшен ты русский флейм, бессмысленный и беспощадный" :)
И не лень вам стока буков написать и все тему сисек не раскроете? Ужос нах.