Lepsik,
В целом по твоему постингу... К сожалению, ты не увидел главного. Впрочем, как и dima. Пост был главным образом про
простые задачи, а
не сравнение языков вцелом. Было сказано,
простые задачи решаем
простыми средствами (например, VB), сложные задачи - более сложным инструментом. А ты STL .... Хотя ... Может просто тебе показалось, что задачи, что у меня решают девочки на VB - это сложные для тебя задачи. Ну, тогда да.... Извини. Но тогда и STL не поможет ...
Теперь несколько замечаний по твоему постингу в мелочах.
--1) скорость разработки гораздо выше
в чем ? a = B + 3 пишется однаково быстро.
Не очень понятна математическая формула.
отсутствие ООП в VB делает кода на 90% больше.
Надо понять для чего нужен VB. Если недостаточно тех COM, что есть - напиши дополнитель свои на VB, или на C (кстати не обязательно ++). Можно и купить эти библиотеки.
Попробуй разок использовать COM в VB. А в целом на VB не принято писать сервера, могутные приложения с GUI. Другими словами, меру надо знать. К чему ты про ООП - я не пойму
Я вообще искренне жалею программистов не знавших что такое STL и програмирование с патернами.
Не обижайся. Но мне кажется, что ты не знаешь, что такое паттерны проектирования. Шаблоны STL, ATL и т.д. с одной стороны и паттерны с другой стороны - это разное. Современные IDE для Windows платформ не имеют встроенной поддержки паттернов. Да и не могут иметь. Паттерны используют и определяют, как правило, спецификации интерфейсов IDL (interface defenition language). Имплементация паттернов - вообще десятое дело. И ещё, строго говоря, паттерны вообще не имеют отношения к ООП модели программирования. Ты спутал pattern и temlate.
У нас уже конкурс был в конторе с VB программерами. (есть у нас один бразильский проект, ии захотелось все на VB иметь).
собственно я могу сравнивать - я делаю на С++ примерное тоже самое что они на VB.
Функциональность у низ ниже хотя толковые ребята.На более примивный query builder для фиксированной структуры базы у них ушло месяц у меня для меняющейся структуры неделю.
В C++Builder ты можешь использовать TQuery или TADOQuery (обётка борланда для ADO) и соответствующие компоненты DataBase, если есть необходимость управления транзакциями. В VB используй рекордсеты ADO или ADO.NET.
Ничего писать и соревноваться не нужно.
3) ты будешь смеяться, но крутые "С++" перцы нам не нужны для выполнения этой части проекта. В отпуск их, или пусть ищут работу в Канаде. Платим немного, программирующим на VB. Выгодно.
неправильный вывод. Язык не не должен влиять на стоимость оплаты - только профессиональный уровень.
Ну будешь ты платить в двое меньше - так и качество разработки в 5 раз ниже.
Это только твоё мнение. Деньги наши и программеры Магаданские, а не Берлинские. Нам виднее кому и как платить в России.
ты просто давно не программировал на С++. Сейчас уже другое время
Я же постил, что не такой профессиональный, как ты. Буду стараться.
dima,
если от .NET ташишся, то бери C# (оказалось что не все что можно сделать на C# с такой-же элегантностью делается на VB).
Ты прав в части простоты и эффективности разработки на C# приложений средней сложности. Но мне удобнее, если те
протые приложения, о которых шла речь были сделаны на VB. Моей команде удобне будет разбираться потом с сорцами VB, а не С#.
Что ж до меня, то мне удобнее в С. Хотя шарп безусловно проще. Более того, такое ощущение, что поддержка Window::Forms в IDE VS.2003 более устойчива для #, чем для С++. Это просто мои наблюдения. Основаны наблюденя на том, что сложная форма Window::Forms эксплорер-подобного приложения в C++.NET "разваливается" в дизайнере. Таких эффектов нет в С#.
Я C# пробовал - просто класс. Сделал что-то вроде WinSql (для ODBC только), но этот .NET framework рушится с постоянной завидностью. .. и не у меня одного, в news groups народ жалуется на те-же проблемы при использовании ODBC.
ODBC достаточно старая технология. Используй ADO или ADO.NET. Кстати, ADO поддерживает и сокеты к ODBC (см. ConnectionString ). Ты можешь использовать DSN ODBS в конекшен стринг ADO.
И ещё.... Не хочу возбуждать словесную диарею некоторых здешних деятелей (не буду показывать пальцем), но мне, кажется, разумно написать свои обёртки, которые конфигурировались бы из текстовых файлов на клиенте. Там ты можешь указать текстовой строкой, какие имеенно объекты доступа к данным должны быть использованы на клиенте, и там же прописать конекшен стринг. Другими словами, если устойчиво работает ODBC - в конфиге просто указывешь тип объектов="ODBC", конекшн_стринг="Твой DSN ODBC". Если увидел , что в существующей инфраструктуре на клиенте ODBC работает не устойчиво, то в конфиге указываешь тип объектов="ADO", конекшн_стринг="Строка твоего OLEDB провайдера". Всё. Никаких изменений в код клиента вносить не надо. Отруливается только изменениями в текстовом конфиге на клиенте. Я давно уже это использую. Работает. Очень удобно. Если интересно, то можешь написать в приват своё мыло. Пришлю вордовский файл (дока для программеров к одному из моих проектов с сорцами). Рагмер файла около мегабайта.