WH>Мне нужен типизированый, автоматический массив созданный КОМовским аллокатором с возможностью вернуть его из функции. WH>А тепер скажи какой такой базовый класс может быть у массива?
Ага, ну тогда понял.
function CreateMyStructArray(count : integer) : PMyStructArray;
begin
Result := (PMyStructArray) КакТамПолучитьПамять( count*sizeof(TMyStruct) )
end;
Конечно, в отличие от шаблона тут придётся писать функцию CreateMyStructArray. Это, ясное дело, преимущество C++. Но считать такое мелкое преимущество чем-то гениальным и крутым — какой-то явный перекос.
M>>Бедные сишники! А как же они с WinAPI работают без try/finally? Сделали CreateFile, поковырялись, получили Exception — и файл остался висеть?
WH>Вот только жалеть нас не надо. Ибо с WinAPI без враперов работают только [censured]. А враперы уже и человеческий интерфейс предоставят и ресурс отдать не забудут.
Серьёзно? И что, на все тысячи функций WinAPI есть врапперы? И что, точно отражают семантику, не суживая способов применения? К примеру, есть такая утомительная область, как NT ACL. Наваляли на неё уже врапперы, или по старинке try/finally пишут?
Что-то не верится. Сдаётся мне, что подобные врапперы приходится писать самому программеру время от времени, когда оказывается, что поблизости нет готового.
А если вызвать-то нужно на всю программу два раза какой-нибудь "DeviceIOControlEx"? Тоже садишься и аккуратно пишешь враппер? О, это крутое преимущество C++. Избавление от ручного труда называется
Да, а ещё бывают сторонние библиотеки со своей дурацкой семантикой. На них что, тоже врапперы писать, если нужно некий try/finally — подход?
M>Ага. Компилятор Java написали. Интерпретатор и JIT'тер написали. А шаблоны — нет, тут сложность невероятно высока.
Вы когда-нибудь пробовали писать type checking и name analysis для кого-нибудь языка ?
Это само по себе не так просто, если язык поддерживает неявные преобразования и позволяет пользователю специфицировать дополнительные неявные преобразования. Добавление шаблонов увеличивает сложность реализации на порядок, а то и больше.
Здравствуйте, mihailik, Вы писали:
WH>> Разговорные языки по функциональности практически равноценны. Но С++ и WH>> делфи... ой не смешите мои тапочки.
m> Мне кажется, твоя обувь слишком много на себя берёт. m> По функциональности C++ опережает Дельфи только в возможности m> компилировать драйвера.
2mihailik: большая просьба, обдумывать свои ответы собеседнику, иначе есть
вероятность того, что модератор перенесёт эту ветку в "Коллеги, улыбнитесь"
Здравствуйте, WolfHound, Вы писали:
M>>Просто нужно всегда понимать что язык — инструмент, шаблоны,строгая типизация — это тоже инструменты. Это то, с помощью чего решают задачи. Дык вот правильным набор инструментов будет тот, который по возможностям максимально сверху приближен к достаточным условиям задачи. И цитата в твоей подписи об этом говорит:
WH>По мне так чем меньше РУЧНОЙ работы тем лучше.
Всегда приветствуется!
WH> В С++ ручками надо работать один раз при написании шаблона, а потом в сотне мест с различными типами использую.
согласен, но это только если задача подразумевает эту "сотню мест".
WH>Вот именно нельзя делать проще чем можно.
А про проще чем можно никто и не говорил.
Вот видишь, однобокий взгляд Я тебе про набор инструментов для решении задачи, а ты про шаблоны и про ручную работу. Согласен с тем, что все вот эти вещи: язык, шаблоны, строгая типизация, RTTI(Reflection), макросы и тд. — это иструменты? Так я о том, что без необходимости все мешать не надо. Задачу можно решить разными способами в контексте разных инструментов. Именно в контексте, поэтому нужно четко представлять пути решения с помощью разных наборов инструментов, и не пытаться применить методы из одного набора к другому! Решения могут быть совершенно разные, но итог — удовлетворение конечным требованиям, готовый продукт одинаковым по функционалу. Вот где творчество!
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, akasoft, Вы писали:
A>>Нет, ну как же тебе не понятно, с помощью буста можно C++ назвать другим языком, потому что он легко самостоятельно превращается во что ... нужно? ... угодно? ... в Дельфи? ... другой С++. Во что он САМ превращается, кстати? WH>Во что хотим в то и превращаем хотим EBNF грамматики пишим, хотим FSM задаем... WH>
WH> ...
WH>
WH>Причем используя туже систему FSM может быть задан динамически. Ну это я так для развлечения писал.
Ужас! FSM надо генерить из чего-нибудь более наглядного, например из UML statechart диаграмм.
В данном случае можно не заботиться о том, как оно все будет выглядить в генеренном коде, а сосредоточиться на эффективности сего генеренного кода.
Если необходима возможность reuse-а (например отнаследоваться от конкретной FSM), то можно предусмотреть возможность генерации FSM в ОО-виде, где transition суть виртуальная функция. (В UML 2.0 transition-ы могут быть виртуальными и переопределяться в наследниках FSM-а).
Если возможность reuse-а не нужна, то генерим простой double-switch (по state-ам и incoming events), такой подход даст максимальную эффективность.
Писать реализацию FSM-а ручками — это не правильно.
FWP>>Насчет многим это ты погорячился. Я к примеру 90% своих программ пишу для конечного пользователя (весьма далекого от программирования и компьютеров). Поэтому хороший GUI ОБЯЗАТЕЛЕН. WH>А слабо на дельфях нарисовать ГУЙ в ХР стиле?
Ты чего? Вообще без проблем делается.
В стиле Office XP, правда есть неурядицы. Borland'овское меню в из Delphi7 стиле Office XP глючит иногда.
WH>>>Конкретно пожалуйста. Ни разу не встречал. FWP>>Посмотри весь топик. Я приводил цитату вашего любимого папочки Страуструпа. Повторять лень. WH>Это про забытый сопиконструктор чтоли? Дык они нужны только помошникам. Классы логики в 99.99% случаев имеют правильный.
Чего-то я не пойму. Такое впечатление, что для тебя просто не существует процесса написания помощников и связанных с этим трудозатрат.
WH>>>Вот только шаблоны сводят ручную работу практически на нет. M>>Ну да, конечно. Найди-ка хоть одно приложеньице на C++ и COM, в котором нет ручной работы. WH>А что далеко ходить. Мой OPC server. Всю работу по поддержке COM сделали ATL'ные шаблоны.
Это хорошо.
WH>>>А если учесть что очень многим приложениям не нужно куча диалогов... M>>Ага. Многим. Давай посчитаем. Для строгости будем считать "приложением" только то, что устанавливается с помощью какого-нибудь инсталлера. Какой процент таких "приложений" на твоём компьютере использует меньше 4 окон? WH>Ну есть парачка. А большинство вобще собственные контролы используют.
Таким образом, большинству приложений нужна куча диалогов.
WH>>> и написать интерфейс при помощи WTL не состовляет большого труда... M>>Да и на Дельфи написать интерфейс не составляет труда. И на C# можно интерфейсы писать. Только почему-то все их рисуют в дизайнере. M>>Видимо, есть всё-таки разница между "не составляет труда" и "имеет смысл". Писать интерфейс вручную — такая дурь, которая практически не имеет смысла. WH>А ты попрубуй нарисуй на дельфе интерфейс как в седьмой студии...
Docking в Дельфи встроенный есть. Менюшки в стиле Ofice XP есть. Закладки есть, правда чуть другой формы. Даже редактор для тулбаров есть. Всё вроде, или ты ещё каких-нибудь рюшечек хочешь?
M>>Примерно так (псеводкод): WH>хъ M>>Объект file1 не освобождается до конца метода. Если файлы открываются в блокирующем режиме и str1==str2, на строке со звёздочкой получим ошибку.
WH>Просто гениальный пример. И что тебе мешает наступить на теже грабли в другом языке? Это уже ошибка ЛОГИКИ и на сколько мне извесно еще не создан язык который может поймать ВСЕ логические ошибки.
На теже грабли в другом языке я сознательно об этих вопросах беспокоюсь. А в C++ мне Wolfhound, авторитетно сказал, что о времени жизни беспокоиться не нужно.
WH>>>Именно. Оно реально бывает нужно раз в два года.
M>>Что вообще стоит писать на C++, если не низкоуровневый код, с использованием WinAPI и т.п.? А во всех этих WinAPI union'ы кругом торчат.
WH>КОМ серверы например. И вобще все что нужно. С++ дает неизмеримо больше возможностей и контроля чем дельфи.
Ага. А Delphi, Java и C# избавляют программиста от необходимости контроля. Контроль берёт на себя среда.
Возможностей и мощностей в C++, конечно, много. Но в метро и общественном транспорте не нужны альпинистские крючья и верёвки. Они там мешают.
M>>Мне кажется, твоя обувь слишком много на себя берёт. WH>Нда? M>>По функциональности C++ опережает Дельфи только в возможности компилировать драйвера. WH> Ржут даже мои носки у которых вобще нет чувства юмора. WH>Хотя что еще можно ждать от человека который не понимает зачем нужны и чем отличяются классы помошники от базовых классов. Но это и не удивительно в дельфе нет помошников.
Ага. Значит ты готов конкретно и чётко сравнить функциональность C++ и Дельфи? Без отвлечённых рассуждений?
Если ты считаешь, что шаблоны или множественное наследование — функциональностью языка, то я с тобой не соглашусь. Функция — это то, что можно применить наружу, а не внутриязыковые приколы.
Чем C++ может уделать Дельфи с позиций внешнего наблюдателя?
WH>>>А ну-ну. Напиши boost::spirit на дельфе. Можешь даже не пытаться. Не выдет. M>>Какой-то дыбильный boost::spirit. На Дельфи он попросту не нужен никому. Ты бы ещё попросил на C# Hashtable написать. WH>Вот когда тебе будет нужен парсер низкой или средней сложности я посмотрю как ты на дельфе будешь корячиться...
Чисто умозрительные утверждения. В интернете куча парсеров, написанных на Паскале. Дельфи-компилятор, насколько я помню, тоже на Паскале.
M>>А ты вот напиши на C++ доступ к COM-объектам по позднему связыванию. Хоть поприкалываемся над небывалой простотой C++
WH>Чаво?
Есть COM-объект. Необходимо вызывать какие-то его методы, использовать свойства при помощи позднего связывания, т.е. методов IDispatch. В скриптовых языках, в VB, в Дельфи это очень просто.
var Excel : Variant;
begin
Excel := CreateOleObject('Excel.Application');
Excel.OpenFile('sdfsdfsdfsd.xls');
Excel.Range("A1").Value=294;
end.
WH>>>Ну знаю я по using жутко не удобно. M>>Ну мало ли. Главное, что всем удобно. Ради одного человека менять не будут. WH>ОДНОГО? Да все мои знакомые С++ники плюются на этот изврат.
Ёжики плакали, кололись, но продолжали есть кактус. Чего вам на C++ не пишется?
WH>>>К томуже Dispose может бросать исключения M>>В отличие от деструкторов C++, как я понимаю? WH>Да. Или хочешь сказать не понимаешь по чему это плохо?
Да не понимаю. Если возникла ошибочная ситуация, почему не выбрасывается исключение?
WH>>>Что ты тут нагнал вобще не понятно. Если ты про хранение потомков какого либо класса в одном контейнере то в С++ это делается на раз. Вот только генерацию такого контейнера берут на себя шаблоны. M>>В Delphi есть готовый контейнер для потомков какого-либо класса. TObjectList. WH>А в STL их 7 штук с разными свойствами. Массив, список...
Круто! Семь штук! Кстати, а при чём здесь Дельфи vs C++?
Ну напишу я на Дельфи не 7, а 97 таких контейнеров — Дельфи станет от этого круче?
M>Что вообще стоит писать на C++, если не низкоуровневый код, с использованием WinAPI и т.п.? А во всех этих WinAPI union'ы кругом торчат.
Гм. У нас на нем (C++/C) написан CASE тул, который включает: GUI, внутренние представление для модели, парсеры, кодогенераторы, Debugger, run-time библиотеки, импорт из других языков, storage в XML и все остальное. И все это хозяйство работает и под Win и под Solaris и под Linux. Помимо всего прочего, мы имеем COM Api, просто Api и Tcl Api. Все немеряно расширяемо.
С Delphi-ями мы бы зависли на реализации эффективного и удобного внутреннего представления по причине отсутствия множественного наследования и шаблонов.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Гм. У нас на нем (C++/C) написан CASE тул, который включает: GUI, внутренние представление для модели, парсеры, кодогенераторы, Debugger, run-time библиотеки, импорт из других языков, storage в XML и все остальное. И все это хозяйство работает и под Win и под Solaris и под Linux. Помимо всего прочего, мы имеем COM Api, просто Api и Tcl Api. Все немеряно расширяемо.
Здравствуйте, Miem, Вы писали:
M>Здравствуйте, _Obelisk_, Вы писали:
M>Как называеться? Можно посмотреть?
http://www.taug2.com. Называется Tau/Developer, стоит $20 000, на сайте вроде бы была демо-версия, но она малость старая (версия 2.0, а сейчас уже выпустили 2.2.20 ) и сильно урезанная.
Здравствуйте, _Obelisk_, Вы писали:
WH>>Причем используя туже систему FSM может быть задан динамически. Ну это я так для развлечения писал.
хъ _O_>Писать реализацию FSM-а ручками — это не правильно.
Ы?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
WH>>>>Конкретно пожалуйста. Ни разу не встречал. FWP>>>Посмотри весь топик. Я приводил цитату вашего любимого папочки Страуструпа. Повторять лень. WH>>Это про забытый сопиконструктор чтоли? Дык они нужны только помошникам. Классы логики в 99.99% случаев имеют правильный.
M>Чего-то я не пойму. Такое впечатление, что для тебя просто не существует процесса написания помощников и связанных с этим трудозатрат.
Один раз забить все необходимое в помошник и пользоваться не задумываясь об освобождении ресурсов или постоянно писать try/finally для освобождения ресурсов.
Как ты думаешь в каком случае трудозатраты больше?
Причем практика показывает что написать помошник выгодней даже если используешь его один раз ибо логика работы с ресурсом не смешивается с основной логикой программы.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
>На теже грабли в другом языке я сознательно об этих вопросах беспокоюсь. А в C++ мне Wolfhound, авторитетно сказал, что о времени жизни беспокоиться не нужно.
M>Или всё-таки нужно?
Если тебя волнует будет ли освобожден ресурс до выхода из функции то не нужно. Но если есть какято очень хитрая логика которая случается раз в год...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
WH>>КОМ серверы например. И вобще все что нужно. С++ дает неизмеримо больше возможностей и контроля чем дельфи. M>Ага. А Delphi, Java и C# избавляют программиста от необходимости контроля. Контроль берёт на себя среда.
Где ты среду в дельфе нашол? Дельфи это unmanaged компилятор с произвольным доступом к памяти. Ни какого контроля.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
M>Ага. Значит ты готов конкретно и чётко сравнить функциональность C++ и Дельфи? Без отвлечённых рассуждений?
Да.
M>Если ты считаешь, что шаблоны или множественное наследование — функциональностью языка, то я с тобой не соглашусь. M>Функция — это то, что можно применить наружу, а не внутриязыковые приколы. M>Чем C++ может уделать Дельфи с позиций внешнего наблюдателя?
Ни чем. С точки зрения пользователя пофигу как написано приложение на дельфе, С++, асме или в машинных кодах.
А вот с точки зрения ПРОГРАММИСТА не первый план выходят "внутриязыковые приколы".
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
