Возразите мне если я не прав...
Возразите мне если я не прав, но помоему корпорация Borland, сильно опустила язык С++.
Во-первых, это библиотеки, которые либо надо таскать с собой или включать в проект с невероятным увеличение размеров последнего, мне кажется что это не совсем удобно, даже совсем НЕ удобно.
Во-вторых, может быть я конечно и заблуждаюсь, но как мне кажется, что интеграция такого мощного языка как С++ с несколько громозским языком Паскаль, не совсем уместна... И раз уж это С++, так пусть он и остается С++...
Как Вам кажется?
Зря ты так...
Borland дала возможность начать программировать даже новичкам не отпугивая их сложностями програминга под винду простеньких приложений. Например когда я первый раз сел за билдер и стал делать ну что-то типа калькулятора у меня возникла ассоциация с конструктором лего из глубокого детства - все интуитивно просто и понятно. А по мере совершенствования своих навыков програминга приходит понимание как это все работает. Так что билдер ИМХО рулит!!!
А если ты такой крутой спец пиши в машинных кодах как раз и размер проги не большой будет :)
Доброго времени суток!
Возразите мне если я не прав, но помоему корпорация Borland, сильно опустила язык С++.
Во-первых, это библиотеки, которые либо надо таскать с собой или включать в проект с невероятным увеличение размеров последнего, мне кажется что это не совсем удобно, даже совсем НЕ удобно.
Во-вторых, может быть я конечно и заблуждаюсь, но как мне кажется, что интеграция такого мощного языка как С++ с несколько громозским языком Паскаль, не совсем уместна...
А не наоборот???
Интеграция с паскалем это разве минус???
Да теперь нужно хорошо знать два языка и паскаль и с++ но это лишь повышает уровень а это только плюс :D
Зато я например просто в восторге от возможности использовать TString и основанные на нем компоненты... пусть те кто любит char возятся с ним а мне это не по душе когда вместо того что бы писать прогу все время думаешь "а не вышел ли я за пределы массива?"
Второй плюс это то что можно зайти на сайты любителей дельфи и почерпнуть много полезного... все что работает в дельфи можно без особых мучений заставить работать в билдере, причем я у них как то оставил ответ на вопрос так даже никто и не обратил внимания на то что он на С++, говорят все работает (изменили конечно -> на . и еще кое что подправили но даже не заикнулись об этом)
Этим самым были объединены два мощных клана программистов тех кто пишет на паскале и на с++, а при работе с Windows чем больше людей с ним борется тем более хороших результатов можно достигнуть...
Насчет присоединяемых библиотек которые нужно таскать с собой??? Это что такое??? :???: ничего не знаю :D я прекрасно работаю в первой версии билдера без всяких навесных библиотек... (вы ее теперь еще попробуйте найти, кстати если есть здесь кто из Ростова и у него есть ненужная лицензионная версия 1-го билдера (с коробочкой и бумажками) то очень прошу связаться со мной)
Америка для американцев... Антарктида для пингвинов... неа... не кажется... есть конечно иногда напряги... но под Windows лучше языка не вижу :D
P.S. Ну и не нам в России жаловаться на то что фирма Борланд как нам кажется халтурит ...
Я не имел в виду интерфейсное оформление, или автогенерацию кода, нет! Это все Borland сделала прекрасно, и по сравнению с Microsoft, просто потрясающе! Я говорил о том, что приложение построенное на C++ Builder все требует библиотеки (пакеты), ну типа VCL**.BPL, и тому подобное, я не знаю как вам, но мне это скажем так не очень нравиться таскать с прогой около 400 тонн заархированных пакетов, или само приложение, которое почти ни чего не делает, а весит 400 тонн... Разве я не прав?
И еще одна больная тема, бьюсь об заклад, что не только моя: БД в Delphi и c++ Builder, можно узнать ваше мнение уважаемые братья по разуму?
Кокретнее, факты?
browser> А если ты такой крутой спец пиши в машинных кодах как раз и размер проги не большой будет
При толковом использовании и на С++ можно писать проги небольшие по объёму исполняемого файла.
Felix> в пллане более прозрачности того что делаешь..
И в чем же прозрачность?
Felix>в вижуале нужно хорошо понимать как все работает а а билдере достаточно просто догадываться как тебе нужно сделать..
Видимо, ты не писал серьезные вещи, требуемые аттестации, лицензирования и т.п.
HexoGenus> Интеграция с паскалем это разве минус???
А почему бы не проинтегрировать ещё ВАСИК, ЛОГО, ФОРТРАН и 1С
HexoGenus> Зато я например просто в восторге от возможности использовать TString и основанные на нем компоненты...
А ты про string из STL что-нибудь слышал?
Lain> C++ Builder все требует библиотеки (пакеты), ну типа VCL**.BPL
Кстати, кто-нибудь знает, как устроены эти компоненты внутри? Я могу на их исходники глянуть? Почему они такие тяжеловестные? Почему такие глючные?
Кстати, кто-нибудь знает, как устроены эти компоненты внутри? Я могу на их исходники глянуть? Почему они такие тяжеловестные? Почему такие глючные?
Исходники почти всех компонентов есть в стандартной поставке Билдера, смотри диру Source.
Касательно таскания с собой библиотек или включения их а экзешник. Ну дело в том что разрабатывая в VC++ ты тоже таскаешь с собой библиотеки, только не явно(почти все необходимое уже есть в поставке винды), но все же лучше это делать явно, причин несколько:
1)Некоторые особи любят урезать винды по самое не балуйся. В итоге какой нить нужной библиотеки может не оказаться.
2)Могут не совпасть версии библиотек
Да, касательно БД в Стройке и Дельфи. ИМХО с DataAware, DataAccess И прочими компонентами работать удобнее и логичнее чем с SQLDMO
Ну дело в том что разрабатывая в VC++ ты тоже таскаешь с собой библиотеки, только не явно(почти все необходимое уже есть в поставке винды), но все же лучше это делать явно, причин несколько:
1)Некоторые особи любят урезать винды по самое не балуйся. В итоге какой нить нужной библиотеки может не оказаться.
2)Могут не совпасть версии библиотек
Да, касательно БД в Стройке и Дельфи. ИМХО с DataAware, DataAccess И прочими компонентами работать удобнее и логичнее чем с SQLDMO
Уважаемый, Вы, кажется, путаете VC++ и MFC. Лично я использую WTL,- это более тонкий и гибкий враппер Win32API, чем MFC. И какие же библиотеки я "тоскаю неявно"? Kernel32.dll?:D
Беда BCB в том, что либо приходиться пользоваться готовыми компонентами, либо писать их с нуля (чего подавляющая часть пользователей CBC не умеет). В BCB нет враппера над Win32API как такового.
Ещё одна проблема в том, что "продвинутый" пользователь BCB понятия не имеет (а только догадывается:D ) о механизмах в Windows, например о механизме оконных сообщений, о стандартных контролах, как их модифицировать под себя и т.п. Поэтому и возникают дебаты типа этих: что лучше BCB или VC++. Если VC++ - это всего-лишь среда разработки, а использовать в качестве компилятора и библиотек можно, что душе угодно, то BCB - "образ мышления", который слишком сильно абстрагирует от реальности.
HexoGenus> Интеграция с паскалем это разве минус???
А почему бы не проинтегрировать ещё ВАСИК, ЛОГО, ФОРТРАН и 1С
Хмммм.... бейсик в с++ ???
Нафиг??? Он там есть...
все конструкции бейсика там есть в почти неизменном варианте :)
И кстати долбежу при подключении к экселу или к ворду хватает... если бы сделали приятную и удобную в использовании оберточку из классов для интеграции я бы был двумя руками за...
насчет лого и фортрана - это языки на которых насколько я в курсе для виндовза не пишут следовательно - не вариант...
Под Виндовз пишут на АСМе на Паскале на С++ на ВизуалБейсике...
тех кто пишет на визуалбейсике под виндовз сразу отметаю... это не та категория по моему мнению, которую стоит серьезно рассматривать... (может кто объяснит почему я не прав?)
Те же кто пишут на паскале (имеется в виду Дельфи) под Виндовз серьезные ребята... и я весьма доволен тем что могу с ними обсудить почти любую тему...
АСМ интегрирован уже давно...
Ну и что осталось??? Что я пропустил???
HexoGenus> Зато я например просто в восторге от возможности использовать TString и основанные на нем компоненты...
А ты про string из STL что-нибудь слышал?
Нет ... может быть что-то хорошее...
Мне просто нравится что в любом месте программы можно без подключения любых библиотек использовать String (в котором есть все нужное для работы со строками) и не нужно дополнительно подключать какие либо библиотеки...
Кстати у каждого языка есть свое применение...
Если хотите писать микроскопические скоростные програмки добро пожаловать в ассемблер...
Если вам нужно что то под дос то мне кажется старый добрый с++ тут к самому месту...
А если вам нужна возможность быстро разрабатывать приложения для виндовз а особенно приложения для работы с базами данных обладающие удобным интерфейсом то тут билдер вполне к месту и в этом случае начхать на размер присоединяемых библиотек... программа для работы с БД должна быть не маленькой а удобной...
И кстати тут большинство программистов индивидуалы интересно есть ли у билдера преимущества перед другими языками при совместной разработке программ...? Кто знает?
Ну вообще то, я это с сарказмом сказал... :)
Да и не путайте язык и среду разработки. Чисто теоретически, писать можно на любом языке под любую платформу.
HexoGenus> тех кто пишет на визуалбейсике под виндовз сразу отметаю... это не та категория по моему мнению, которую стоит серьезно рассматривать... (может кто объяснит почему я не прав?)
На VB пишут многие высокоуважаемые компании и фирмы. В основном используют в связке с С++, например для написания различных клиентов, плагинов и т.п. Это обуславливается тем, что VB заточен под COM, точнее под ActiveX. Из серьезных продуктов могу назвать к примеру FoorPlan - CAD для дизайнеров помещений.
HexoGenus> Те же кто пишут на паскале (имеется в виду Дельфи) под Виндовз серьезные ребята... и я весьма доволен тем что могу с ними обсудить почти любую тему...
Попробуй обсудить такие темы, как умные указатели, паттерны стратегия, медиатор и т.п., множественное наследование, шаблоны...
Кстати, а в Делфи есть шаблоны, виртуальные ф-ции и т.п.?
Честно говоря, я не рассматриваю Делфи (паскаль), как серьезный полноценный язык программирования в виду его низкой функциональности, слабой расширяемости и отсутствия строгой спецификации.
HexoGenus> Мне просто нравится что в любом месте программы можно без подключения любых библиотек использовать String (в котором есть все нужное для работы со строками) и не нужно дополнительно подключать какие либо библиотеки...
Уверен? Не подключать библиотеки? Это значит, что в самом С++ есть реализация TString? :)
Я на 100%... нет на 120% уверен, что ты ошибаешься. Может тебе стоит подробнее изучить спецификацию С++?
HexoGenus> Кстати у каждого языка есть свое применение...
Согласен.
HexoGenus> Если хотите писать микроскопические скоростные програмки добро пожаловать в ассемблер...
Не согласен, можно и на С++ написать и маленькое и скоростное.
HexoGenus> Если вам нужно что то под дос то мне кажется старый добрый с++ тут к самому месту...
Что ты подразумеваешь под "старый добрый с++"
Кстати, для противников MS компилятора, могу подсказать его недостаток: до версии VC++ 7.0 он не подерживал инстанирование шаблона шаблоном, что входит в спецификацию С++. А компилятор BCB это может?
HexoGenus> интересно есть ли у билдера преимущества перед другими языками при совместной разработке программ...? Кто знает?
Честно говоря, не могу привести примера серьезной программы написанной на BCB или Делфи. Единственное применение, которое я знаю и видел, - это когда набрасывается интерфейс для согласования с заказчиком, а потом всё переписывается на VC++.
Это я серьёзно...
Давайте завалим Microsoft письмами с нашими просьбами...
Вы действительно правы уважаемый Green, если на то пошло почему вообще не выпустить язык где как в HTML - нужно скажем тебе Яву, ты взял и сказал, вот тут мно нужно наривость код при помощи явы... система с радостью тебе дает такую возможность... Но получиться такой балаган... Поэтому я не могу понять как они вообще посмели интегрировать два совершенно разных языка: Паскаль и С++!?! Ведь как Вы заметили, Паскаль это такой громозский инструмент, он настолько же громозок по сравнению с С (я уже молчу о С++, хотя еще не известно что пригоднее С или С++), как к примеру Васик по сравнению с Паскалем...
Green>Не согласен, можно и на С++ написать и маленькое и скоростное
Вынужден не согласиться!
Во-первых, маленькое скоростное только асм, С++ просто не множет это обеспечить, он с самого начала задумывался как объектный язык... В С может быть и можно, и то при наличии хорошего линковщика и сборщика...
Во-вторых, если прога меленькая, то где бы она не была написана скорость работы сильно не заметная...
SEDEGOFF>Давай напишим письмо в Microsoft...
Уважаемый, но вы же знеете дотошных американцев, взять, скажем, для примеру Монику Левински... Они если узнают чтовздули (а это письмо таковым и является), они подадут на все Россию в суд, за лож, обман, пиратство, производтсва оружия массового поражения с последующим его применением про США..., это факт...
Кстати насчет асм, если уж асм самый скоростной, как Вы смотрете на перспективу создания некого подобия "АСМ-Строитель"?
Да и вот еще: неужели Мастдай настолько беден на библиотеки, что всем приходится иметь с собой необхомимы, тогда что находится в тех 400-600 тонна котоые он может поставить на винт? (речь идет о всех версиях Мастдая) Это касается и БД...
Я уже не помню, но кто-то в мой адрес написал примерно следующее: "неужели Вы не умеете подключать библиотеки в проект", умею, но при этом он (проект) в итоге вырастает до размера библиотеки...
Уважаемый, Вы, кажется, путаете VC++ и MFC. Лично я использую WTL,- это более тонкий и гибкий враппер Win32API, чем MFC. И какие же библиотеки я "тоскаю неявно"? Kernel32.dll?:D
Беда BCB в том, что либо приходиться пользоваться готовыми компонентами, либо писать их с нуля (чего подавляющая часть пользователей CBC не умеет). В BCB нет враппера над Win32API как такового.
Ещё одна проблема в том, что "продвинутый" пользователь BCB понятия не имеет (а только догадывается:D ) о механизмах в Windows, например о механизме оконных сообщений, о стандартных контролах, как их модифицировать под себя и т.п. Поэтому и возникают дебаты типа этих: что лучше BCB или VC++. Если VC++ - это всего-лишь среда разработки, а использовать в качестве компилятора и библиотек можно, что душе угодно, то BCB - "образ мышления", который слишком сильно абстрагирует от реальности.
не понял. а кто тебе мешает вырезать
#include "vcl.h"
и радоваться жизни???
Вопрос для чего тогда VC++ если не использовать MFC, насколько я понимаю прочие радости жизни можно использовать и без него? Для такого варианта советую глянуть LCC Free Compiler меня он как-то более радует.
И не стоит всеже путать "пользователя BCB" и программиста использующего в качестве среды разработки BCB. Это две большие разницы как говорят в Одессе:D Вторые знают и о auto_ptr, и о наличии STL и ATL, смело пользуются RTTI, изучают сурцы и используют сообщения.
не понял. а кто тебе мешает вырезать
#include "vcl.h"
и радоваться жизни???
Вопрос для чего тогда VC++ если не использовать MFC, насколько я понимаю прочие радости жизни можно использовать и без него? Для такого варианта советую глянуть LCC Free Compiler меня он как-то более радует.
И не стоит всеже путать "пользователя BCB" и программиста использующего в качестве среды разработки BCB. Это две большие разницы как говорят в Одессе:D Вторые знают и о auto_ptr, и о наличии STL и ATL, смело пользуются RTTI, изучают сурцы и используют сообщения.
Ещё раз повторюсь. VC++ я рассматриваю, как среду разработки. И я не пользуюсь нетолько MFC, но и компилятором и STL стандартной поставки. Компилятор я беру IBM, а STL от SUN.
А в этом противостоянии я вижу две стороны: одна - CBC, как конструктор для маленьких программистов (а не среда разработки), который является маленьким мирком, защищающим от злобных оконных сообщений, ужастного и непостижого Win32API и "никому не нужной и занудной" спецификации С++; другая - реальный мир реальных компиляторов со всеми их достоинствами и недостатками, реальные механизмы ОС, виртуозность владения спецификациес С++, умелое проектирование программ, классов, использование паттернов проектирования.
Ещё раз повторюсь. VC++ я рассматриваю, как среду разработки. И я не пользуюсь нетолько MFC, но и компилятором и STL стандартной поставки. Компилятор я беру IBM, а STL от SUN.
А в этом противостоянии я вижу две стороны: одна - CBC, как конструктор для маленьких программистов (а не среда разработки), который является маленьким мирком, защищающим от злобных оконных сообщений, ужастного и непостижого Win32API и "никому не нужной и занудной" спецификации С++; другая - реальный мир реальных компиляторов со всеми их достоинствами и недостатками, реальные механизмы ОС, виртуозность владения спецификациес С++, умелое проектирование программ, классов, использование паттернов проектирования.
Угу... согласен целиком и полностью :-)))
Точно так же ассемблер в свое время защищал от необходимости самому писать в машинных командах...
С++ защищал от необходимости мучаться с передачей данных в подпрограмму...
Конструктор??? Да великолепно ... это может быть хорошим качеством не только для начинающих программистов :-))) Разве это плохо если можно быстро собрать программу из блоков???
Есть программы которые расчитаны на два три окошка и кучу кода... а если это база данных в которой десятки окон а кода должно быть совсем немного, если в программе все сводится к красивому и удобному интерфейсу???
И кстати я встречал такое описание:
Билдер - это язык для написания интерфейсов клиентских программ баз данных...
Мне кажется уже неплохо... И кстати на нем можно не только это делать... :-)))
Я кстати не против VC++ Я его с удовольствием изучу как время будет :-) (И тогда точно скажу он лучше или просто другой...) И если VC++ позволяет так хорошо структуру Windows изучить то может лучше просто с него начинать а потом к билдеру переходить...
Кстати есть примеры того что можно сделать на VC++ и нельзя сделать на Билдере?
И вообще чем говорить что билдер в чем то плох лучше дайте адресочек сайта где есть красивые примеры написания интересных программ на VC++
Мне будет очень интересно, может не только мне ...
Кстати говоря насчет навесных библиотек...
Если пишешь прикладную программу на продажу а не шпион, вирус, или еще что то для души то размер в 99% всех заказов значения
НЕ ИМЕЕТ!
И перед тем как показывать пальцем на увеличение размера результирующего кода сначала посмотрите на длину исходных текстов программ которые работают с окнами Виндовз напрямую... вот туда этот размер и уходит при использовании других библиотек...
Чем меньше должен быть результирующий код, тем больше времени уходит на написание исходника...
Почти аксиома! А билдер язык позволяющий ускорить процесс написания программ :-)
Дело в том, что С++ не может быть "лучше или просто другой". Есть определенные стандарты и спецификации языка. И конкретная реализация либо отвечает этим стандартам целиком (пока не встречал) или частично, либо не является данным языком. Дело же не в языке, а в его реализации, в библиотеках врапперах ОС и т.п.
HexoGenus> Кстати есть примеры того что можно сделать на VC++ и нельзя сделать на Билдере?
Давай, перефразируем: ... нельзя сделать используя стандартные средства (VCL) Билдера?
Ну, например, быстро написать свой контрол. К примеру, нужен контрол на базе стандартного List-view, в одной из колонок которого в кажой строчке справа была бы кнопочка с нарисованной папочкой, по нажатию на которую появляется стандартный диалог "Open File", а слева от кнопочки пишется имя выбранного файла.
HexoGenus> И вообще чем говорить что билдер в чем то плох лучше дайте адресочек сайта где есть красивые примеры написания интересных программ на VC++ Мне будет очень интересно, может не только мне ...
codeguru.com, codeproject и т.д.
HexoGenus> Если пишешь прикладную программу на продажу а не шпион, вирус, или еще что то для души то размер в 99% всех заказов значения
НЕ ИМЕЕТ!
Не верно. Небольшие по объему программы чаще требуют меньше машинных ресурсов, значительно быстрее, легче отлаживаются и распространяются. Сейчас большая часть коммерческого и др. ПО распространяется через интернет, а здесь размер имеет место.
HexoGenus> И перед тем как показывать пальцем на увеличение размера результирующего кода сначала посмотрите на длину исходных текстов программ которые работают с окнами Виндовз напрямую... вот туда этот размер и уходит при использовании других библиотек...
"Напрямую" никто уже с окнами не работает, всё это делается через те или иные врапперы. А размер исходников такого раппера, как WTL, к примеру ~900 кбайт, которые находятся в 16 файлах .h, и никаких lib, dll и т.п. Сейчас вы начнете придираться к "целым 900кб", но не спешите. В эти 900кб не входит почти ни одной реализации, только шаблоны, и в исполняемый код попадает ТОЛЬКО ТО, ЧТО НУЖНО и используется непосредственно в твоем коде. Кроме того все действительно ПРОЗРАЧНО.
HexoGenus> Чем меньше должен быть результирующий код, тем больше времени уходит на написание исходника... Почти аксиома!
Извини, но эта "аксиома" настолько локальна, что в более широком смысле выглядит, как бред.
На VB пишут многие высокоуважаемые компании и фирмы. В основном используют в связке с С++, например для написания различных клиентов, плагинов и т.п. Это обуславливается тем, что VB заточен под COM, точнее под ActiveX. Из серьезных продуктов могу назвать к примеру FoorPlan - CAD для дизайнеров помещений.
Согласен.
Попробуй обсудить такие темы, как умные указатели, паттерны стратегия, медиатор и т.п., множественное наследование, шаблоны...
Кстати, а в Делфи есть шаблоны, виртуальные ф-ции и т.п.?
Честно говоря, я не рассматриваю Делфи (паскаль), как серьезный полноценный язык программирования в виду его низкой функциональности, слабой расширяемости и отсутствия строгой спецификации.
Паскаль кстати разрабатывался как язык для обучений программированию. А потом в нем сделали возможность вставлять асм и у паскальщиков появился повод заявлять что Паскаль самый крутой язык.
Уверен? Не подключать библиотеки? Это значит, что в самом С++ есть реализация TString? :)
Я на 100%... нет на 120% уверен, что ты ошибаешься. Может тебе стоит подробнее изучить спецификацию С++?
#include <string>
...
std::string str;
...
Изучил бы ты сам вышеозначенную спецификацию :) string - класс из стандартной библиотеки C++ и должен быть в каждой реализации языка соответствующей стандарту.
Не согласен, можно и на С++ написать и маленькое и скоростное.
Угу. Даже если такой код и будет на пару десятых миллисекунд медленней асмовского, это с лихвой покроется затратами на разработку. Кстати тот же string - вызов его функций 10000 раз обходится в 0.1 мс на пне 4 (не всех функций конечно)
HexoGenus> Если вам нужно что то под дос то мне кажется старый добрый с++ тут к самому месту...
Что ты подразумеваешь под "старый добрый с++"
Кстати, для противников MS компилятора, могу подсказать его недостаток: до версии VC++ 7.0 он не подерживал инстанирование шаблона шаблоном, что входит в спецификацию С++. А компилятор BCB это может?
Ну HexoGenus ашипся ИМХО, он хотел сказать "старый добрый C".
А вобще спорить на тему типа "С лучше бейсика а асм круче всех остальных" все равно что спорить о том что молоток лучше топора а топор лучше пилы. Это разные языки, и создавались для разных целей.
P.S. Плюньте вы на Винду, пишите под Линуксом раз такие крутые :) gcc рулит :)
Аха, в связке с Qt
P.S.
Кстати а что за сокращение ИМХО. Подскажите, не очень разбираюсь в программерском сленге.
#include <string>
...
std::string str;
...
Изучил бы ты сам вышеозначенную спецификацию :) string - класс из стандартной библиотеки C++ и должен быть в каждой реализации языка соответствующей стандарту.
Ну и? Я не понял, что ты хотел сказать. Речь шла об TString. HexoGenus пишет, что он при этом не использует библиотеки. В чем и не прав (попробуйте меня переубедить).
А про STL я кое-какие представления (хотя бы в объеме Страуструпа :о) имею.
Кстати, объясните мне, темному, в чем преимущество использования TString по сравнению со string? В случае с использованием STL я всегда могу использовать STL другого разработчика (например SG вместо MS), а как быть с TString? Жестко привязаны к Борланду?
но VCL (как основа RAD tools BCB) это скорее завод Ford, а WinAPI это автоателье(Aston Martin etc.).
Не хочешь ли ты сказать, что VCL не юзает Win32API?
Я почему-то уверен, что VCL враппер над Win32API, как и MFC, WTL и т.д.
Беспредметный спор. Нужность из полезность любого языка программирования определяется широтой и масштабностью задач, которые они могут решать. Если дельфи позволяет быстро и с лёгкостью создавать не очень масштабные проекты, то почему он не имеет права на существование? Я знаю людей которые предпочитают дельфи стройке только за более быстрое время копиляции.
P.S.
Кстати а что за сокращение ИМХО. Подскажите, не очень разбираюсь в программерском сленге.
Думаю, этот спор не о языке программирования, а о технике платформозависимого программирования и о методах разработки программ.
Я не вижу здесь обсуждений по поводу реализации компиляторов MS или Borland, о их достоинствах и недостатках. Все споры вокруг VCL и MFC, к которым язык не имеет ни малейшего отношения.
А вот реальные вопросы по поводу компиляторов остались неотвеченными:
- поддерживает компилятор Борланда инстанирование шаблонов шаблонами?
- какже MS "надругалась" над С++ (конкретные факты)?
А по поводу методов разработки могу сказать, что нельзя создать качественный продукт не зная основ его механизмов. Вы можете спорить, но больше половины пользователей BCB не знают основ функционирования Windows.
Все это уже начинает превращаться в религиозную войну. Вот только пользователи многие BCB не понимают, в чем предмет спора, они считают, что BCB - это один язык программирования, VC++ - другой. :о)
Беспредметный спор. Нужность из полезность любого языка программирования определяется широтой и масштабностью задач, которые они могут решать. Если дельфи позволяет быстро и с лёгкостью создавать не очень масштабные проекты, то почему он не имеет права на существование? Я знаю людей которые предпочитают дельфи стройке только за более быстрое время копиляции.
P.S.
Кстати а что за сокращение ИМХО. Подскажите, не очень разбираюсь в программерском сленге.
Ну если уж переросла беседа в огромный набор различных мнений (хотя я много чего интересного почерпнул) то пусть от нее хоть кому то польза будет :D
IMHO
In My Humble Opinion. По моему скромному мнению. Метка в письмах, которая сигнализирует об интеллигентном общении. В российских сетях порой превращается в ИМХО.
http://xaksmurf.narod.ru/sFido.htm
Посмотри там чуть-чуть терминов есть...
вот еще...
AFAIK (As far as I know) Насколько мне известно
AKA (Also known as) Также известен как (например, "Эдмон Дантес AKA граф Монте-Кристо")
BRB (Be right back) Скоро вернусь
BTW (By the way) Кстати
CUL (See you later) Увидимся!
F2F (Face to face) Лицом к лицу, наедине
FYA (For your amazement) Чтобы вы порадовались
FYI (For your information) Для справки
IMHO (In my humble opinion) По моему скромному мнению
ROFL (Rolling on the floor laughing) Я валяюсь от смеха!
RTFM (Read the f..king manual) Прочти это долбаное описание
SY (Sincerely yours) Искренне ваш
TIA (Thanks in advance) Заранее спасибо
WBR (With best regards) С наилучшими пожеланиями
WRT (With respect to) С уважением к
Извините если засоряю, но уж очень часто это ИМХО на форуме встречается, вы бы хоть словарь выложили что ли ....
HexoGenus: Чем меньше должен быть результирующий код, тем больше времени уходит на написание исходника... Почти аксиома!
А вот хочеш опровергну твою аксиому?
Вот тебе код на С/C++ который минималем по времени написания и по размеру результирующего кода:
int main(){return 0;}
:D Шучу конечно, но в каждой шутке...
Green: Кстати, объясните мне, темному, в чем преимущество использования TString по сравнению со string? В случае с использованием STL я всегда могу использовать STL другого разработчика (например SG вместо MS), а как быть с TString? Жестко привязаны к Борланду?
Лучше использовать string. Хотя врядли ты так быстро перепишеш код из под броланда в визуал даже если не будеш пользоваться TString'ом :) Хотя в MFC есть свой CString, я им не пользуюсь, потому как я string хорошо знаю + мне не нравится стиль майкрософтовских названий функций типа SomeFunction. А вот some_function - другое дело! 8)
И еще: вот тут в основном обсуждают какая библиотека (ака враппер) лучше: MFC или какая другая. А вы никогда не задумывались зачем они вобще нужны? Почему, скажем на Си можно спокойно писать проги пользуясь тока WinAPI а на С++ нет? Да потому что винда изначально писалась на не объектно-ориентированном языке (их тогда не было просто) а теперь уже поздно - совместимость (ох уж эта совместимость, стока из-за нее бедная майкрософт настрадалась :) ). Вот представьте например что было бы, если бы все было наоборот: функции возвращали бы объекты и оперировали бы объектами и причем это все было бы реализовано на уровне системы, а не на уровне врапперов. Существуют объектно-ориентированные операционные системы, там все именно так.
В общем так: C++ не предназначен для написания программ под Windows, и обсуждать тут нечего.
И еще: вот тут в основном обсуждают какая библиотека (ака враппер) лучше: MFC или какая другая. А вы никогда не задумывались зачем они вобще нужны? Почему, скажем на Си можно спокойно писать проги пользуясь тока WinAPI а на С++ нет? Да потому что винда изначально писалась на не объектно-ориентированном языке (их тогда не было просто) а теперь уже поздно - совместимость (ох уж эта совместимость, стока из-за нее бедная майкрософт настрадалась :) ). Вот представьте например что было бы, если бы все было наоборот: функции возвращали бы объекты и оперировали бы объектами и причем это все было бы реализовано на уровне системы, а не на уровне врапперов. Существуют объектно-ориентированные операционные системы, там все именно так.
1. А что тебе мешает писать на С++, пользуясь только WinAPI ?
2. Врапперы пишуться для упрощения оперирования конкретной ограниченной части системы для необходимых нужд, система же в общем случае предоставляет более широкий и универсальный интерфейс, что невсегда удобно.
3. А оперирование объектами, кстати, реализованно в Windows - это COM.
В общем так: C++ не предназначен для написания программ под Windows, и обсуждать тут нечего.
Бред.
Не хочешь ли ты сказать, что VCL не юзает Win32API?Я почему-то уверен, что VCL враппер над Win32API, как и MFC, WTL и т.д.
Аха, именно это и хочу сказать, она млин сразу в ASM "транслируется"=)))Киргудук(копирайт "Кавказская пленница")
На самом деле есть такое понятие как уровень абстракции. И я говорил всего-лишь о том, что у VCL уровень абстракции относительно железа намного выше чем у WinAPI.
Насчёт вопросов касательно соответствия спецификации C++, то насколько я знаю каждая стройка проходит сертификацию на таковое, и вроде пока каждая версия проходила.По крайней мере Борланд таковое утверждает везде в каждой рекламке и акции, а ANSI это не отрицает. Если бы это было не верным то Борланд влетела бы на большие бабки. Есть за рубежом статья такая "Намеренное искажение информации о продукте с целью введения потребителя в заблуждение и извлечения комерческой выгоды" (примерно так звучит).
Аха, именно это и хочу сказать, она млин сразу в ASM "транслируется"=)))Киргудук
(копирайт "Кавказская пленница")
На самом деле есть такое понятие как уровень абстракции. И я говорил всего-лишь о том, что у VCL уровень абстракции относительно железа намного выше чем у WinAPI.
"Уровень абстракции относительно железа" ???
Гы! Относительно какого железа? Называй вещи своими именами, а то я щас подумаю, что ты про HAL говоришь. :D
VCL - нечто иное, как враппер WinAPI, т.е. всего лишь оборачивает WinAPI для удобности использования.
Насчёт вопросов касательно соответствия спецификации C++, то насколько я знаю каждая стройка проходит сертификацию на таковое, и вроде пока каждая версия проходила.По крайней мере Борланд таковое утверждает везде в каждой рекламке и акции, а ANSI это не отрицает. Если бы это было не верным то Борланд влетела бы на большие бабки. Есть за рубежом статья такая "Намеренное искажение информации о продукте с целью введения потребителя в заблуждение и извлечения комерческой выгоды" (примерно так звучит).
Вы на вопрос мне ответте! Поддерживает ли Борландовский компилятор инстанирование шаблонов шаблонами?
1. А что тебе мешает писать на С++, пользуясь только WinAPI ?
Хех да ничего не мешает, только придется написать собственную библиотеку классов. Я просто имел ввиду то что получить из функции не дескриптор окна, а, скажем, объект класса окна было бы логичнее для С++.
2. Врапперы пишуться для упрощения оперирования конкретной ограниченной части системы для необходимых нужд, система же в общем случае предоставляет более широкий и универсальный интерфейс, что невсегда удобно.
3. А оперирование объектами, кстати, реализованно в Windows - это COM.
Множественное наследование, полиморфизм, шаблоны...
Бред.
Ты видел вот такие конструкции в VC++?
BEGIN_MESSAGE_MAP(CMyView, CWnd)
//{{AFX_MSG_MAP(CMyView)
ON_WM_ERASEBKGND()
ON_WM_PAINT()
ON_WM_SIZE()
// ..........
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
Это ли не бред? :) С помощью них становится возможным реализовать события OnEraseBkgnd(), OnPaint() и т.д. как виртуальные функции соответствующих классов. Не знаю, как это реализовано в борланде, но врядли лучше. Вот еслиб без такого можно было обойтись, тогда б другое дело. Пример таких осей: NextStep, BeOS.
http://borland.xportal.ru/modules.php?name=News&file=article&sid=23
Под названием:
C++Builder : 4 причины, почему этот продукт нужен программистам на Visual C++
Вы на вопрос мне ответте! Поддерживает ли Борландовский компилятор инстанирование шаблонов шаблонами?
Я вот тут думал, думал, еще раз думал. Но так и не придумал задачу в которой бы было необходимо инстанирование шаблона шаблоном. Но знающие люди говорят что поддерживает. А потом это же и проверить не трудно. Стоит только один раз запустить билдер.
Я вот тут думал, думал, еще раз думал. Но так и не придумал задачу в которой бы было необходимо инстанирование шаблона шаблоном. Но знающие люди говорят что поддерживает. А потом это же и проверить не трудно. Стоит только один раз запустить билдер.
К примеру реализация паттерна "Стратегия" (см. Александреску http://www.moderncppdesign.com/).
Проверить не трудно, тока не стоит у меня Билдер. Пока как-то обхожусь... :D
К примеру реализация паттерна "Стратегия" (см. Александреску http://www.moderncppdesign.com/).
Проверить не трудно, тока не стоит у меня Билдер. Пока как-то обхожусь... :D
Нда, то что Александреску купить надо - факт. Если не трудно то залей сюда сурцы с данной проблемой, а я проверю и дам ответ.