M>>Если я тебя правильно понял, ты считаешь, что драйвера нужно писать на продвинутом C++ с STL и прочими наворотами?
WH>А почему нет?
Потому, что рантайм-библиотеки не писались для этого применения. Мало ли, каким образом там память выделяется, какие дополнительные функции вызываются.
В некоторых местах в драйвере нельзя никакой лишней работы делать. Чтобы не дай бог ни подкачки, ни задержки никакой не было. Ну, закрепишь ты свой собственный код в памяти от свопирования. Но служебные библиотеки мало ли как там закреплять — это отдельно тестировать нужно.
Здравствуйте, mihailik, Вы писали:
S>> а учитывая кроме всего прочего что SQL еще и интерпретатор то....
M>В MS SQL точно компилятор, а не интерпретатор.
M>Думаю, и в других "больших" серверах то же самое. http://www.rsdn.ru/Forum/Message.aspx?mid=370720&only=1
Здравствуйте, mihailik, Вы писали:
WH>>Ты нет а вот те кто придумывал COM почемуто видят. M>Те, кто придумывал COM, сейчас стараются его как можно скорее забыть.
Да. Но он еще живее всех живых.
WH>>А варианты? А строки их к стати тоже нужно в COM аллокатором размещать если вернуть хочешь. M>Ну, разве что строки. O.K., напишем отдельный классик для строк. Пока ничего серьёзного.
Да еще нужна типизированые массивы...
M>Замечаем разницу, но я пример приводил M>В том же C++ не всегда можно забить на время жизни.
В 99.999999% случаев. В то время как в дельфе надо в 100% случаев ручками.
WH>>Вот мне недавно надо было просканить папку и вернуть файлы удвалетворяющие маске. M>Это всё хорошо. Ручной труд — он ведь облагораживает
Мое решение разгрузило алгоритм а это многого стоит.
M>Ну что я тебе могу сказать про этот народ и этот сервер. Я ни того ни другого не знаю
Ну народ там нормальный, а вто OPC протокол хорошо что я на С++ пишу.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
WH>>Именно по этому и мало ручной работы ибо я пишу логику один раз, а ты каждый раз при использовании. M>Иногда этот "каждый раз" означает в точности "один раз".
Даже если и так то как правило основная логики становится прозрачней ибо не замусорена логикой работы с ресурсом, а работы практически столькоже но учитывая что алгоритм получился болие прозрачный с поддержкой будет меньше проблем. Факт. M>Но в остальном тенденция, конечно, полезная. Если меру знать
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
WH>>Ну и нахрена это надо? M>Для однообразности и простоты. Все объекты ведут себя с памятью одинаково. Мозги не парятся. Супер аргумент.
WH>>Вот и приходится городить try/finally постоянно. M>Не постоянно. В Дельфи тоже есть способ уйти от ручного вызова деструкторов к подсчёту ссылок. Интерфейсы всегда работают по учёту ссылок.
Ага это мне для каждого объекта придется писать интерфейсы... и всегда через них таскать
А слабо integer by ref сделать? Я не знаю зачем но в С++ это делается на раз boost::shared_ptr<int>
WH>>Это еще почему? M>А вот чтобы приколисты вроде Страуструпа не выдумывали разных новых значений оператора сдвига. Сдвиг — он в Дельфи всегда сдвиг.
Хм. А я уже не помню когда последней раз использовал << как сдвиг.
Но если тебя это не устраивает то не используй стандартные потоки и все.
К томуже под это попадают вектора для которых прегрузить + сам бог велел...
WH>>В том то и засада что не всегда объект можно просто скопировать. M>А все объекты byref, то есть ничего и не копируется. Чтобы сделать копию, нужно как и в .NET вызвать какой-нибудь Clone.
Да ради бога. В С++ можно тоже пользоваться только by ref и что? Просто я предпочитаю иметь выбор.
WH>>Ага. И использование полиморвных контейнеров ведет к чистоте, простоте и надежности M>Тут ты прав. Действительно удобно.
Тормоза, отсутствие контроля типов со стороны компилятора это без сомнения очень практично.
WH>>При написании ГУИ к БД согласен, а вот на счет всего остального. M>Ты что, предлагаешь и в браузерах скрипты на C++ писать? Или ты какое-то конкретное "остальное" имеешь ввиду?
Ты дурочку не валяй. Прекрасно понял о чем речь.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
WH>>А теперь представь что на разработка жабы или .НЕТ пришлось бы потратить примерно в двое больше ресурсов M>А причём здесь .NET? На .NET шаблоны себя не заставили ждать.
M>>Ага. Компилятор Java написали. Интерпретатор и JIT'тер написали. А шаблоны — нет, тут сложность невероятно высока.
M>А вот Java давно написана, а о шаблонах всё разговоры да разговоры.
Вот по тому и разговоры что задаче не тривиальная.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
M>>>RTTI (aka Reflection) WH>>Рефлекшен в дельфе... Бедные мои тапочки... Ну не надо сравнивать бумажный самолетик с истребителем пятого поколения. M>Почему не надо сравнивать?
M>RTTI решает те же проблемы, что и Reflection. Сериализация и ремотинг. Конечно, RTTI похилее Reflection'а, ну и что? Работает, функции выполняет.
см разговор с Синклером на счет сериализыции.
M>Свойства — это важная архитектурная особенность. M>Языки, в которых поддерживаются свойства являются компонент-ориентированными. Ну вот не могу сказать почему так выходит, а реальность такова.
Это ни как не связано. В С++ я могу эмулировать свойства, а некоторые компиляторы поддерживают их в качестве расширения.
M>А я не вижу ничего хорошего в том, что C++ не понимают люди без образования.
А я не вижу ни чего хорошего в том что людей без образования допускать к работе ибо всеравно глаз да глаз за ними нужен.
Ну не дело это домохозяйкам программы писать.
M>Если тебе непонятны эти преимущества, возможно они тебе и не нужны.
Преймущества .НЕТ это Reflection и Reflection.Emit это сильно, а все остальное фигня.
M>Мало ли у кого какая отрасль работы. А мне вот нужно, чтобы мой код был понятен [censured]'ам, и свойство-ориентированность тоже удобна. Вот это действительно круто.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
WH>>Что такое исключение? Это ФАТАЛЬНЫЙ сбой в алгоритме. Следовательно алгоритм не отработал. WH>>Вопрос нафига записывать мусор если надо просто сообщить о провале и подчистить ресурсы? M>А вот надо. Лог вести, или ещё какие предсмертные действия совершить.
Лог кидающий исключения. Гениально.
M>Ну и кто по твоему должен что сказать? Или для всех локальных объектов Dispose делать? M>
Здравствуйте, mihailik, Вы писали:
WH>>А почему нет? M>Потому, что рантайм-библиотеки не писались для этого применения. Мало ли, каким образом там память выделяется, какие дополнительные функции вызываются.
STL и CRT это немного разные вещи не находишь? M>В некоторых местах в драйвере нельзя никакой лишней работы делать. Чтобы не дай бог ни подкачки, ни задержки никакой не было. Ну, закрепишь ты свой собственный код в памяти от свопирования. Но служебные библиотеки мало ли как там закреплять — это отдельно тестировать нужно.
Слова человека не знающего о существовании такого понятия в STL как allocator.
Но даже если забить на STL то ни что не мешает просто пользоваться всеми благами шаблонов.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
M>А причём здесь .NET? На .NET шаблоны себя не заставили ждать. M>А вот Java давно написана, а о шаблонах всё разговоры да разговоры.
Судя по тому компилятору, который они сейчас попробовать дают, в Java будут на редкость отстойные шаблоны .
M>>В том же C++ не всегда можно забить на время жизни. WH>В 99.999999% случаев. В то время как в дельфе надо в 100% случаев ручками.
Ошибаешься слегка!
WH>Ага это мне для каждого объекта придется писать интерфейсы... и всегда через них таскать
Ну да, все время забываю, что ты знаток Delphi !
Здравствуйте, mihailik, Вы писали:
AD>>3. функции * M>Почему в Дельфи Процедуры и функции, причём даже "в т.ч. вложенные" не удостоились звезды, а в C++ простые функции удостоились?
Каюсь, забыл.
AD>>4. Классы * M>Почему в Дельфи Классы не удостоились звезды, а в C++ удостоились?
Ещё раз извиняюсь
AD>>7. Нормальная(!) перегрузка функций * M>В Дельфи, значит, ненормальная?
Да.
AD>>9. Понятие "объект класса" * M>Что такое за понятие?
Это значит, что объявляя переменную с типом класса, вот так:
ClassName variable;
мы сразу получаем объект класса (как только программный поток попадает в область видимости этой переменной). В OP мы получим лишь ссылку на объект класса, после чего класс нужно вручную создавать. Вследствие чего в OP невозможны "умные" указатели (если только на уровне языка)
AD>>10. Поименованные области * AD>>11. Шаблоны и STL:
M>Ну да, а для Дельфи есть VirtualTreeView — очень удобный компонент. Если уж пошли библиотеки сравнивать.
AD>> — типизированные контейнеры и массивы *
Какую-то я фигню написал про массивы. Любой массив типизирован, т.к. все его элементы имеют один и тот же тип. Сорри, видимо торопился. Но это к делу не относится.
M>В Дельфи, вроде бы отстутсвуют. В Дельфи все массивы, кажется, нетипизированные
Ага, значит, если мы объявляем массив
arr : array[1..200] of Integer;
то получаем массив неизвестно чего Ты бы, сначала, паскаль подучил, прежде чем спорить.
Да кстати, о шаблонах, забыл добавить в список одну замечательную вещь — стратегии, которые позволяют конструировать объекты с желанным типом поведения. Короче, Александреску рулит!
Здравствуйте, mihailik, Вы писали:
M>Если архитектура нормальная для C++, то на C++ работы меньше. Если архитектура нормальная для Дельфи — соотвественно.
Здравствуйте, mihailik, Вы писали:
M>Ладно, ладно, семь — магическое число. Согласен. Тут C++ переплюнул, у него число более знатное.
Да нет же. Это вопрос библиотеки хорошей. Вот я буду на каждое заявление говорить: VCL. И уверять, что там зашибастые визуальные контролы на все случаи. Их дофигаста. Компоненты пишет всякий, кому не лень. Дофигаста бесплатных компонентов. И это ну очень круто удобно. Кто будет спорить...
А если я скажу: SysUtils/Math/Classes/System — то перекроет это функционал STL? Я сомневаюсь... Но ведь эти 4 модуля никто не обозвал Delphi STL, а ведь могли бы.
И, например, уже написанной библиотеки с подобным функционалом невизуальным и для Дельфи я пока не вспомню. Вот и гнёт он нас этим STL.
А вот раньше помню приходилось делать свои PInteger, IntegerArray и др. В D6/D7 эти вещи завраппены, и можно пользоваться "стандартными" типами...
Здравствуйте, akasoft, Вы писали:
A>И, например, уже написанной библиотеки с подобным функционалом невизуальным и для Дельфи я пока не вспомню. Вот и гнёт он нас этим STL.
И не вспомнишь. Ибо не возможно.
A>А вот раньше помню приходилось делать свои PInteger, IntegerArray и др. В D6/D7 эти вещи завраппены, и можно пользоваться "стандартными" типами...
В том то и дело что в дельфе на каждый тип приходится писать враперы в то время как в С++ один раз шаблон.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ArtDenis, Вы писали:
AD> Ты бы, сначала, паскаль подучил, прежде чем спорить.
а я бы на твоем месте таких заяв не делал... бо чревато боком.
... << RSDN@Home 1.1 beta 2 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, mihailik, Вы писали:
M>>>Есть COM-объект. Необходимо вызывать какие-то его методы, использовать свойства при помощи позднего связывания, т.е. методов IDispatch. В скриптовых языках, в VB, в Дельфи это очень просто. ГВ>>Ну вот же ж блин. Ну нельзя на C++ наезжать по таким направлениям — не для того он предназначен. M>Ну так я о том же. Гнобят бедный Дельфи и в хвост и в гриву. В гриву я ещё согласен, но в хвост — это зря.
Ну дык. Сабжект топика такой.
ГВ>>Конечно, если накатать набор врапперов, то можно сделать и "по позднему связыванию". В результате код пользователя будет примерно таким: M>Ну да, на Дельфи тоже можно TLB импортировать. Только это куча лишних действий. Если нужно всего-то открыть Excel и бросить значения в пару ячеек, тут враппер как помеха какая-то.
Если относительно таких задач рассуждать, то для них и вовсе никакого враппера не нужно. Что ты будешь на каждом вызове HRESULT обрабатывать, что свой обработчик сделаешь; что напрямую через VMT-интерфейс, что через IDispatch — монопенисуально.
M>Кроме того, работа по позднему связыванию отличается от работы по интерфейсам тем, что освобождает от привязки к версиям. Если на C++ импортировать Office XP TLB, то с Office 2000 вполне полезут проблемы.
Проблемы и на VB иногда лезут. А с другой стороны, никто не мешает внутри С++ — врапперов сделать вызовы через IDispatch и вообще навернуть всё что угодно, хоть динамическое построение vmt, благо она там не ахти какая сложная — без множественного наследования-то.
ГВ>>Ну и наконец, если в твоей программе логики помимо подключения COM-объектов мало, то кой чёрт тогда тебе C++ использовать? Бери тот же VB и полный вперёд! M>Ага. Согласен. Для OLE Automation лучше использовать более соответствующий язык.
Правильно, только обрати внимание — для использования COM/OLE-объектов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Serginio1, Вы писали:
WH>>>Ну и нафига во все интерфейсы подсчет ссылок запихивать? В С++ это делается на раз, а для привидения типов служит dynamic_cast. S>> В классы а не в интерфейсы. И работа с приведением через интерфейсы как в Net очень удобна. WH>А чем чисто абстрактный класс без данных отличается от интерфейса?
Чем ??? Посмотри на реализацию придуманную M$. Дла каждого объекта (не класса) генерятся в памяти функции заглушки, которые генерят вызов методов класса с передачей данных объекта (Self) в методы класса.
Вот и поймешь в чем причина. Не прав. WH>>>Вот уж нафиг не упало все классы от одного наследовать. И dynamic_cast никто не отменял. S>>Аналог dynamic_cast Is плиз ??? WH>typeid
Гхы-Гхы. WolfHound хоть ты и RSDN но рассыждаешь как зеленоротый птенец. По сути объекты 1С++ схожи со структурами. Но виртуальность накладывает на обязательное поле ссылки на VMT, в Delphi с отрицательным смещение хранится куча информации о типе , интерфейсах итд. Кроме всего прочего вариантный подход, тоже требует определенных методов по преобразованию. Я лично ну ни как не пойму какие проблемы у С++ с БД.
А как насчет InheritedForm,,,, S>> Единая информация об объекте. Не прав. S>> А вот структуры объекты действительно нужны, но с возможность боксинга в объект как в Net WH>НАФИГА? Создал в стеке пусть лежит в стеке, создал в хипе пусть будет в хипе. Нафига это разделение?
Создал структуру как в Net и пусть себе лежит. Какие проблемы. Неотвечаешь на предыдущие вопросы. Единственный аргумент Шаблоны. И все???
Честно говоря, как оппонент Вы WolfHound, очень не интересны. Абсолютно нет никакого конструктивизма и анализа. Уперся рогом и все. Извини за столь резкие высказывания, но это Правда. Не важно на чем программируешь. Мне лично по барабану. Но в Net Я нашел, то что искал и ищу.
С++ умрет, а Виртовский Паскаль останется. И уже доказал свою состоятельнось, не взирая на свой возраст. Главное фундамент.
Если Ты в Москве готов в личном поединке обсудить общеязыковые проблемы за кружечкой Водки.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, mihailik, Вы писали:
M>>>Кроме того, все объекты сугубо by ref. Никаких объектов на стеке или ещё где ни попало.
L>>А как по твоему передаются параметры? По воздуху?
M>Все ОБЪЕКТЫ by ref. В C++ объекты (экземпляры классов) могут располагаться как в стеке, так и по адресу в памяти.
M>А в Дельфи переменная типа TObject — на самом деле указатель.
Спасибо. А причем тут Я???? А вот с FPU действительно Борланд покачал.
и солнце б утром не вставало, когда бы не было меня
хорошо что я на С++ пишу.
Супер аргумент.
