Здравствуйте, VladD2, Вы писали:
ГВ>>Ну давай так, сторонний компонент, как ты правильно заметил, для C++, это либо plain-api (значит-исходники), либо классы (значит — тоже исходники), либо какие-то самоописывающиеся интерфейсы (к примеру — COM). Самоописывание интерфейсов нужно для генерации исходников, которые затем будут использоваться мной. Это, фактически, единственный путь использования сторонних объектов в программах на C++. rtti или нечто похожее может понадобиться для анализа данных, получаемых извне, особенно, если дизайн стороннего компонента предполагает такой способ его использования. С точки зрения дизайна моей программы в данном случае rtti будет использован для задачи обработки внешних данных и, кстати, последствия в виде... ну я уже говорил, — никуда не денутся. И моя, кстати, негативная их оценка — тоже, несмотря на то, что это может оказаться единственным выходом. Ну сам посуди: что мне, радоваться что-ли, от того, что я, например получаю какой-нибудь IBase*, для которого надо клепать dynamic_cast<IDerived*>, обрабатывать потенциальные ошибки и т.п?
VD>Забавно ты расуждаешь. Тебе говорят, что это в некоторых случаях единственный виход, а в некоторых не еденственный но намного боле простой. А ты все криво, и криво. Этак я могу обвинить весь мир так как в нем нужно дышать воздухом и нельзя прыгать с небоскребов. Ну, право не серьезно.
Обвинять мир — твоё право. Я не говорю о том, что единственный выход — "кривой"... вот, лучше процитирую себя самого:
ГВ>С точки зрения дизайна моей программы в данном случае rtti будет использован для задачи обработки внешних данных и, кстати, последствия в виде... ну я уже говорил, — никуда не денутся. И моя, кстати, негативная их оценка — тоже, несмотря на то, что это может оказаться единственным выходом.
Разницу чуешь? Это может быть единственным выходом, но я оценивать его всё равно буду негативно (или, если хочешь — с грустью, тоской, щемящим сердцем, великоросской рефлексией, сквозь зелёную бутылку, с поллитрой в руках, скрипя зубами, с самурайским мечом меж зубами, — ряд синонимов можно продолжить), поскольку присущие ему черты неизбежно останутся.
Или ты считаешь, что я должен прыгать от счастья, раз мне пришлось воспользоваться этим, единственным выходом?
Поскольку моя личная негативная оценка не может быть предметом обсуждения, в силу субъективизма и возможной неадекватной её трактовки собеседниками то я: а) отказался от такой формулировки, но б) сформулировал описание характерных черт критикуемого мной подхода более точно.
Поскольку разработчики C++ (Страуструп, во всяком случае, насколько я это знаю) придерживались схожих взглядов, я счёл возможным в декларативной форме присоединиться к ним. Декларативную же и краткую форму выбрал сознательно, поскольку сообщение написал в форум.
Ну как, понятно объяснил? Или стрелочки логических связей нарисовать?
А относительно "в некоторых не еденственный но намного боле простой"... Так опять ты апеллируешь к тому, что разница простой-сложный настолько велика, что это фактически — единственный выход для которого либо справедливо то, что я уже сказал, либо... несправедливо вообще ничего, поскольку "простой" и "сложный" — тоже субъективные оценки.
PS. Да и вообще — иная простота она хуже воровства.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
WH>Можно подумать у меня сложнее WH>
CreateObject<IMyDeviceInterface>(className);
Конечно сложнее. Что там у тебя за CreateObject'ом скрывается? У меня за активатором стандартная библиотека
IT>>className можно в виде строки положить в базу или в любой конфигурационный файл по вкусу. WH>У меня тоже причем этим уже давно пользуются. И это было заложено с самого начала.
Заложено кем? Тобой? И куда? В твою библиотеку? А здесь заложено в платформу.
IT>>Всех описываемых тобой ограничений типа одна dll и пр. не существует в принципе. Хоть одна dll, хоть четыре. WH>Какие ограничения? Кто говорил об ограничениях? Да хот один класс-одна длл без разници. Просто классы отвечающие за одну железку лежат в одной длл. Что в этом плохого?
Да нормально всё, сойдёт для сельской местности. Правда я, если мне понадобится, могу для отдельной железяки сделать не просто отдельную dll'ку, а отдельную машину, т.к. активатор мне может спокойно создать объект и на другой машине, а тебе для этого придётся писать свой COM
IT>>При желании можно использовать и стандарные типы вроде "System.String" если они конечно поддерживают твой интерфейс. WH>Ну это мне нафик не упало.
Я знаю что не упало, а когда упадёт ты это обязательно эмплементируешь, даже не сомневаюсь.
IT>>В общем, в .NET это не "несколько проще", а совсем элементарно. У меня на подобной ерунде совместно с PropertyGrid'ом весьма навороченный визуальный редактор построен. Расширяется он во все стороны элементарно описанным выше способом. WH>Веришь нет но мое приложение тоже расширяется во все стороны знай себе дллки пиши.
Верю конечно, дело то не в этом. Дело в том, что я использую уже готовое, а ты сидишь и клепаешь всё это на коленке, в результате тратя на разработку всей системы гораздо больше времени. У меня всё моё время уходит на разработку бизнесс-логики, ну скажем так 95%. У тебя от силы 50%. Соответственно при прочих равных ты мне на этом рынке не конкурент, я за тоже время сделаю в два раза больше или мой продукт будет стоить в два раза дешевле. Вот такие пирожки. И это, между прочим, не пустые слова, а проверено на практике на живых людях
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, WolfHound, Вы писали:
VD>>Поздравляю. Ты изобрел COM. WH>В шарпе надо обьявить класс публичным, у меня занести в карту экспорта. Работы практически одинаково.
Тебе ещё надо метод в двух местах объявить: в .h и в .cpp
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sergey, Вы писали:
S>Шаблоны это и есть кодогенератор. Помнишь, я пример сериализации на С++ с кучей тайпдефов кидал? Вот там именно в компил-тайме в библиотеке генерируется код, перебирающий все (заданные в шаблоне) базовые классы и ищущий нужный тип у члена ddxMembers и возвращающий его значение (простым static_cast'ом), если в пользовательском коде была использована шаблонная функция data или field, принимающая параметр нужного типа.
Да ничего там не перебирается и не ищется. Все есть заранее. Шаблон есть шаблон. Просто универсальная параметризованная реализация.
S>Было бы чего перебирать. Обычная рекурсия с условиями за счет специализации с этим на раз справлятся. Книжку Александреску почитай для начала, или сразу в boost::mpl загляни (но там, блин, трудно что-то понять с наскоку).
Все равно это не кодогенерация. Это некий алгоритм выполняесый компилятором. Да и неудобно это ужасно.
VD>>В дотнете все обычно вуже в рантайме.... S>Это то и плохо.
Да ничего в этом плохого нет. Можно и код сгенирить если что.
S>Щаз. Я уже умею генерить его компилятором — но приходится дофига тайпдефов писать, и класс от шаблонного наследовать, и еще кучу ограничений соблюдать.
Все же это не генерация. Те самые ограничения слишком серьезные. Тогда уж макросы куда больше позволяют. И даже проще выходит.
S>Они, кстати, уже есть — OpenC++, например.
Ссылкой не поделишся? Чтыо за зверь?
S>Кто именно ?! Пока я только встречал возражения против автоматического вынесения такой информации в рантайм — и с ними полностью согласен. Это работа для стандартной библиотеки, а не для языка.
И как ты себе видишь "такую" работу при условии, что информация тебе становится доступна только в рантайме? Ну, не твой компонент, а алогоритм для работы с ним написать нужно.
S>Там что, есть иные средства генерации кода, кроме шаблонов и макросов?
CodDOM и Reflection.Emit. Гибче небывает.
S> Или шаблоны атрибуты в качестве параметров понимают? Если нет, то до метаинформации опять в компил-тайме не добраться — ну и нафиг мне такое щастье?
В компайл-тайме вызываются сами атрибуты. Для самих атрибутов это рантайм, но все же. Правда с шаблонами их спарить невозможно (шаблоны пока вообще только для не совместимого с CLI кода доступны). Но все же.
VD>>Вот только ортодоксы типа Страуструпа всю малину портят.
S>Чем же тебе так Страуструп не угодил?
А ты почитай, что он пишет про все нововведения. GC — можно раелизовать как библиоткеку... (Ака щаз!) Информации о типах достаточно... расширять язык дальше нельзя... Ну, а про рантайм и компоннтный подход вообще молчек. Какбодто таковго не существует. Впрочем как и АОП и т.п.
VD>>Думаю, то чем ты говоришь скорее напоминает время между компиляциями. S>Нет.
А иначе возникает проблема курицы и яйца. Хотя это тоже решаемо если подумть подольше. В общем, я не против если у кого-то получится вытащить метаинформацию в компайлтайм. Только метаинформцию в рантайме — это не заменит.
VD>>Тут спору нет. Метаданные могли бы сослужить огромную службу. Но стандрат плюсов просто таки борится с этой идеей.
S>С какой идеей? Просто идеи метапрограммирования на шаблонах слишком недавно появились — уже после принятия стандарта.
Дурака не включай. Идеей создания полноценного метаописания. Ну, а метапрограммирование на шаблонах, во-первых, не полноценно, во-вторых, в нынешнем виде очень сложно. Тут как я уже говорил, лучше бы ввести в язык срества типа алгоритмических компайлтайм-процедур. Чтобы они порождали виртуальный код. Хотя сразу возникает проблема отладки. Те же макросы для меня лично не являются стольк опасными как их расписывают разные орлы, но отладка макросов — это сущий ад. Даже при условии наличия опций препроцессинга в код.
S>Проверял на всех ?
На всех на ком проверял, у всех подымалась.
VD>>Программист пересаженный с плюсов на дотнет резко поднимает продуктивность. Это уже не слова. Это доказано практикой. S>Твоей практикой, заметь. Или еще чьей-то?
См. выше. Небыло ни одного человека пересевшего на Шарп у которого повысилось бы количество ошибок или замедлелась бы скорость разработки.
В конце концов метапрограммирование, генерация кода, анализ метаданных в рантайме и т.п. — это редкие в повседнвеной жизни выпендрежи. Они позоляют сделать некоторую (шаблонную) работу быстрее, но и без них можно жить. Более того 90% работы как раз не требует таких решений. И тут Шарп на коне. Ну, а про рантайм и говорить нечего. По сравнению с дотнетом в С++ он просто отсуствует.
S>Есть, конечно, некоторая доля программистов, которые на бейсике еще быстрее чем на шарпе, писать будут
Нет такой доли. Эти языки по простоте использования проактически одинаковы. Поверь, человеку написавшему не мало кода на ВБ. В последнее время ВБ использую только для написания макростов в ворде, и то исключительно из-за того, что в ворде нельзя подключить Шарп.
В общем, попробуй и сам поймешь, что Шарп это некий гибрид С и ВБ. Можно сказать С на стеройдах.
S>Просто на плюсах можно программировать по разному — не обращая внимания на надежность или прикладывая некоторые (как ни странно, очень небольшие) усилия для ее обеспечения. При втором подходе плюсовый код будет не менее (а, вернее, более) надежным, чем код в манагед языках.
Да. Соблюдая некоторые правила, можно сделать программирование на С++ значительно безопаснее. Но все равно проблем выше крыше. Любой кто написал большую систему на плюсах не даст соврать. Иначе зачем все эти баундчекеры и т.п.? При проектировании Шарпа очень многие аспекты вызывающие проблемы были учтены. Например, было введенв специальные ключевые слова для перекрытия методов — override и new. Так же был усилен контроль типов. Так int не приводится автоматически к bool и ошибку вроде:
if(ia = ib)
...
допустить становится практически невозможно. Зато писть:
if((ia = ib) != 0)
...
По прежнему можно. И совершенно безопастно. И таких примеров море. Огромным шагом вперед стал отказ от указателей. По этому поводу можно ерничать. Но это действительно невироятно защищает программу от сбоев.
S>Там есть четкий приговор метаданным в твоем понимании
Можешь считать так. Мне в общем то по барабану. Я уже привык, что фсе рьяные сторонники С++ отметают идею рантайма.
VD>>В общем, займись дотнетом и посмотрим на твои позиции чезе годик.
S>Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...
Извени, но это треп. Ты попробуй. Пересиль свои предубеждения на некоторое время. И когда немного проникнишся поговорим еще раз. Почему-то я полностью уверен, что твои слова изменятся и будут звучать так: да, порой чертовски нехватает шаблонов или МН, но черт побери (!) насколько же проще и удобнее писть на этом языке!
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sergey, Вы писали:
S>Мне несколько другая метаинформация нужна.
Интересно чем же? Думаю, ты просто не верно излагеешь свои желания. Тбе нужна не другая метаинформация. Тебе хочется иметь доступ к ней в компайлтайме. Собствнно я личто только за. Главное, чтобы при этом это был не еденственны способ работы с ней. Мне так нужно чтобы она была доступна и в рантайме и в дизайнтайме. Из этой мысли, кстати, вытекает мысль о том, что нужно так же узаконивать понятия дизйнтайма.
S>Шаблоны это и есть кодогенератор.
Не серьзяно это.
S> Помнишь, я пример сериализации на С++ с кучей тайпдефов кидал? Вот там именно в компил-тайме в библиотеке генерируется код, перебирающий все (заданные в шаблоне) базовые классы и ищущий нужный тип у члена ddxMembers и возвращающий его значение (простым static_cast'ом), если в пользовательском коде была использована шаблонная функция data или field, принимающая параметр нужного типа.
Помнишь как по уродски смотрелся этот код? И сколько лишнего кодирования он требовал? И помнишь какой код нужен для дотнета? Так вот для создания оптимального решения. Нужно чтобы в языке появились реальные и удобные средства компайлтайм-кодогенерации. Чтобы можно было создать некий мета-сериализатор. Который по информации о классе (причем без дополнительной разметки, или с минимумом таковой) генерировал бы код сериализации для класса. Согласен, что в дотнете минусом является необходимость работы в рантайме (Иногда этого можно избежать). Но на С++ вообще не удается создать 100%-но красивого решения. Хорошим примером является реализация того же GC. Если бы можно было перебирать члены класса (имея только указатель на класс) и получать данные о них, то создание GC на самом С++ было бы очень даже можно. А так каждую переменную тебе придется облочать кучей лишнего кода, и все равно результат будет не удовлетворительным.
S>Было бы чего перебирать. Обычная рекурсия с условиями за счет специализации с этим на раз справлятся. Книжку Александреску почитай для начала, или сразу в boost::mpl загляни (но там, блин, трудно что-то понять с наскоку).
Дык пока нет. Да и использование рекурсивных шаблонов — это очередной обход убогости языка средствами шаблона. Мне именно это не нравится. Раз появилась потребность в метапрограммировании, то лучше встроить в язык продуманные средства для этого. А компилятор (и возможно рантайм) оптимизировать под них.
VD>>В дотнете все обычно вуже в рантайме....
S>Это то и плохо.
Ничего в этом плохого. Рантайм просто необходим в современных условиях. Согласен, что и компайл тайм бы не помешал... ну, да об это я уже говорил не раз. К тому же всегда можно сгерерировать код в рантайме, а потом уже выполнять этот код. Тот же сериализатор может создать MAP тип/сериализатор и когда встречается новый тип генерировать код сериализации для него, а если тип уже есть использовть готовый. Можно и тулзу создать для этого, чтобы получать код во время компиляции. А вот отсутсвтие этого в плюсах никаких плюсов не дает .
S>Щаз. Я уже умею генерить его компилятором — но приходится дофига тайпдефов писать, и класс от шаблонного наследовать, и еще кучу ограничений соблюдать.
Ты ничего не гереришь. Ты все хардкодишь. Просто тебе шаблоны позволяют резко уменьшить этот процесс. Я уже устал это повторять.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Разницу чуешь?
Чую, что тебе ненравится, но почему обяснить ты не в силах.
ГВ> Это может быть единственным выходом, но я оценивать его всё равно буду негативно (или, если хочешь — с грустью, тоской, щемящим сердцем, великоросской рефлексией, сквозь зелёную бутылку, с поллитрой в руках, скрипя зубами, с самурайским мечом меж зубами, — ряд синонимов можно продолжить), поскольку присущие ему черты неизбежно останутся.
Так как ты не докозал, что "присущие черты" плохи. Будет считать это утверждение основанное на небоснованных спорных предпосылках. ОК?
ГВ>Или ты считаешь, что я должен прыгать от счастья, раз мне пришлось воспользоваться этим, единственным выходом?
Я считаю, что обчиняя нужно приводить доказательства вины. Хотя бы если об этом попросили несогласные. Или не обвинять.
ГВ>Поскольку моя личная негативная оценка не может быть предметом обсуждения
А зачем ты ее высказываешь? Раз высказал, значит она уже автоматом может стать предметом...
ГВ>, в силу субъективизма и возможной неадекватной её трактовки собеседниками то я: а) отказался от такой формулировки, но б) сформулировал описание характерных черт критикуемого мной подхода более точно.
И таки так и не дал доказательств своим критическим суждениям.
ГВ>Поскольку разработчики C++ (Страуструп, во всяком случае, насколько я это знаю) придерживались схожих взглядов, я счёл возможным в декларативной форме присоединиться к ним. Декларативную же и краткую форму выбрал сознательно, поскольку сообщение написал в форум.
Тбе декларативно и заявили, что ты не прав, в месте с Страуструпом. Что ты еще хочешь?
ГВ>Ну как, понятно объяснил? Или стрелочки логических связей нарисовать?
Такую позицию не стоило и озвучивать. Она ровным чсетом никому ничего не дает.
ГВ>А относительно "в некоторых не еденственный но намного боле простой"... Так опять ты апеллируешь к тому, что разница простой-сложный настолько велика, что это фактически — единственный выход для которого либо справедливо то, что я уже сказал, либо... несправедливо вообще ничего, поскольку "простой" и "сложный" — тоже субъективные оценки.
Твои рассуждения противоречат логике. Любой дизайн тем лучше чем проще и эффективнее он решает поставленную задачу имеющимися средствами. А понятие "криво" является сугубо отнсительным. Так что если решение единственное, то кривым его называть бессмысленно.
ГВ>PS. Да и вообще — иная простота она хуже воровства.
Ну, это аргументы из той же оперы.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sergey, Вы писали:
S>А как, кстати, подобный код на шарпе будет выглядеть? Скажем, вызов 2-х функций ( одна — с тремя, другая — с пятью параметрами) внутри некоторого обрамления. Способ, когда первая половина обертки — в конструкторе вспомогательного класса, а вторая — в деструкторе (финализаторе и т.д.), не катит.
Я не очень понял вопрос. Если речь идет о вызове некоторого кода после некотых действий, то для етого есть конструкции try/finally и using. Например, если нужно один раз:
Method1();
try
{
// Некий код, возможно с исключениями...
}
finally
{
Method2();
}
Если же пишется класс и нужно освобождать ресурсы отличные от памяти, то:
class ClassResourseHolder : IDisposeble
{
public ClassResourseHolder(){ /*занятие ресурсов.*/ }
IDisposeble.Dispose(){ /* Освобождение ресурсов. */ }
}
// ... Использование...using(ClassResourseHolder crh = new ClassResourseHolder())
{
// Используем crh...
} // Здесь вызовется Dispose() (даже если будет исключение).
S>Делегаты умеют "привязывать" параметры на ходу? А переставлять аргументы местами? Или придется вспомогательные классы/функции писать?
Что значит "привязывать к коду" и зачем унжно "переставлять местами"? Ты лучше задачу опиши. Тебе уже кажется гворили, что читать С++ не простое занятие. И ради развлечения этим занимаются только мазахисты.
Кстати, тоже рисование в дотнете сделано куда изящнее. Правда это скорее заслуга грамотности проектирования обертки над GDI+. Аналогичную можно использовать и на плюсах.
S>Да нет, не только. Шаблоны — почти такое же средство кодогенерации, как и макросы. Вот чего они (шаблоны) не умеют — так это работать со строками (и формировать новые читабельные имена) и подставлять код in-place (чтоб возврат из функции сделать, к примеру).
Да они многого не умеют. Назвать это кодогенерацией можно только с огромной натяжкой.
S>А, скажем, сгенерить тип, наследущийся от всех типов из перечисленного списка или функцию, вызывающую заданную статическую функцию функцию для каждого типа из списка — это запросто.
Это все же далеко не кодогенерация. Зачатки — согласен. Но все же не то. Ну, и опять таки проблемы отладки не хуже чем с макросами.
S>Нет, конечно. Почему ты счел такое сравнение "обратной аналогией"? На мой взгляд, вполне корректное сравнение.
Прямая аналогия — это когда ты не подразумеваешь приведение неких случаев/объектов к некому классу, как в твоем случае. А просто выражение, что мол это как то. Например, в C# есть разделители операторов, как в С++. А вот попытки сделать выводы на базе аналогий приводят к логическим ошибкам. Такие выводы можно делать только для полностью аналогичных вещей/действий. Ну, а аналогичность нужно доказывать. Иначе это обычная демагогия. Прямые аналогии пригодны исключительно для обяснений. Обраные вообще не следут (даже если они кажутся верными).
S>В этой статье нет даже слова "обратная"
Там рассказывается как делать правильные аналогии и выводы на их базе. Поищи на слово демагогия, и найдешь много материала об обратных аналогиях.
VD>>Ты тему внимательно читал? Тут именно с этим и спорят.
S>Цитату, плиз. Ничего такого я в этой ветке не заметил.
Ты серьезно хочешь, чтобы я за тебя еще раз перечитал всю эту немаленькую тему? Про клозур конечно тут небыло, но про делегаты не однократно.
VD>> А еще (и это самое противное) с этим спорят разные Страуструпы и другие хранители традиций из ANSI.
S>Страуструп — хранитель традиций? Не смеши. Он в основнем С++ и развивал, а пользователи его пинали, чтоб не слишком от С отходил
А ты почитай его последнии интерьвью. В них главной нитью следует, что изменять С++ не нужно. Традиции он естественно хранит свои. Просто его идеи уже отстают от времени.
S>Нет, конечно. Рекурсия — вполне приемлемый (для меня, по крайней мере ) способ записи алгоритмов. Впрочем, не нравится рекурсия — можно попробовать использовать алгоритмы из boost::mpl, там вроде компил-тайм циклы есть.
Все равно получается сложно и непонятно. Уж проще использовать явные генераторы кода. Вот только это как раз плохой подход.
VD>>Вот практика и показывает, что без указателей можно очено даже эффективно объодиться. А там где можно без них, то луче без них. От указателей кроме гемороя мало чего можно получить. Есть конечно обласи, где без них совсем трудно, но к щастью этих областей не так много.
S>Но уметь работать с ними — надо.
Я незнаю, твоих скилов в С++, но не думаю, что ты работал с указателями больше меня. Так что давай оставим разговоры о "умении" для барышень. Факт в том, что применение указателей усложняет код, а действенных средств кортроля за целостностью сущьнотей в С++ нет. Так что указатели неменуемо приводят к ошибкам. Шарп же (в сэйф-режиме) гарантирует целостность объектов и предоставляет действенные средства контроля. Причем эти действия очень малозатратны и доступны даже в релизе.
S>Извращения — это для тренировки мозгов. После которой простые и эффективные решения будут писаться куда проще и эффективней
Проблема, в том, что С++ заставляет тренеровать могзги вместо выполнения основной рабты.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, m.a.g., Вы писали:
MAG>Да очень просто: не сказано, что не меняет состояние объекта — значит меняет
А зачем все это? На ратайме JIT и так будет знать меняет или нет. Конст нужен исключительно для самоконтроля программиста. Тобы тот мог как бы заранее поставить галочку. Мог это я уже менять не буду.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Какие ограничения? Кто говорил об ограничениях? Да хот один класс-одна длл без разници. Просто классы отвечающие за одну железку лежат в одной длл. Что в этом плохого?
А как ты находишь нужную длл-ку? Я лично не вижу дургого способа как подгружать все подяд и пытаться вызвать кекую функцию отбрасывающую метаинформцию о классе. Собственно разница как раз в том, что в дотнете такая мтаинформация уже есть и она стандартна для всех CLR-языков. А ты изобрел свой ком. Причем изначально ограниченный так как полная его реализация — это море кода.
WH>Веришь нет но мое приложение тоже расширяется во все стороны знай себе дллки пиши.
И на дельфи можно?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>50%? Даумаю лично у него 99% уходит на свой энжин. Шутка ли создать собственную (пусть и ограниченную) реализацию ком-а?
Возможно. Просто я сужу по себе, когда писал комы на ATL, то 50% уходило именно на борьбу с ATL, COM и C++. Хотя когда используются накатанные решения, то этот процент гораздо меньше. Но что-бы взять тот же COM у меня ушло несколько месяцев, а в случае с Remoting'ом, например, это исчисляется несколькими днями, от силы пару недель.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Возможно. Просто я сужу по себе, когда писал комы на ATL, то 50% уходило именно на борьбу с ATL, COM и C++. Хотя когда используются накатанные решения, то этот процент гораздо меньше. Но что-бы взять тот же COM у меня ушло несколько месяцев, а в случае с Remoting'ом, например, это исчисляется несколькими днями, от силы пару недель.
Интересно сколько на это ушло бы если доэтого ты бы не занимался КОМ-ом? Да и не все, что было в КОМ реализовано в ремоутинге. Но несомненно он спроектирован более качественно чем ком. И заслуга тут именно в возможностях заложенных в дотнете.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
O>>Интересно, что скажут местные гуру? Было ли это компонентным программированием в зачатке или фигней полной? IT>Кашмар, какое извратство, почему бы просто не написать CreateInstance для этого.
Потому что:
1. Привычный синтаксис, всё прозрачно, плюс правильный вызов конструкторов. Единственное условие — в производном классе должен быть конструктор с такой же сигнатурой, как в базовом.
2. Кроме собственно этой фичи там было много еще чего. Например, можно было создать динамический объект и дать ему имя. Если имя это где-то референсилось, оно тут же ресолвилось и можно было прямо использовать (как статический объект, например, или функцию)
3. Были там элементы референсов (auto-load DLM). Т.е. в DLM было прописаное, чего ей надо. Если такое было — оно грузилось, если не было — только при попытке попользовать вылетало что-то вроде исключения.
Кстати, я соврал насчёт 95го, я тут поднял логи — это всё-таки 96ой был...
IT>ЗЫ. А вообще идея интересная
Собссно это был исследовательский открытый проект. Никакой особой коммерческой мысли в этом не было. Спустя лет 6 мне пришло письмо, что эта фигня используется оказывается в каком-то мега-научном биологическом проекте. А ничего не понял из описания проекта, но было приятно
И потом, я уже 3ий год порываюсь это чудо под win32 переписать, только всё руки не доходят... Но может придётся, тут надобно плагинную систему для WinCE рисовать, CF еще дури не хватает (производительности) — идеально подходит.
[RSDN@Home 1.1 beta 1] Сейчас 07:47, слушаю тишину
Здравствуйте, VladD2, Вы писали:
VD>Интересно сколько на это ушло бы если доэтого ты бы не занимался КОМ-ом? Да и не все, что было в КОМ реализовано в ремоутинге. Но несомненно он спроектирован более качественно чем ком. И заслуга тут именно в возможностях заложенных в дотнете.
Я могу сказать не только за себя. Люди с которыми я работал довольно тщетно пытались использовать COM долговое время, с ремоутингом таких проблем не было.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sergey, Вы писали:
S>>А как, кстати, подобный код на шарпе будет выглядеть? Скажем, вызов 2-х функций ( одна — с тремя, другая — с пятью параметрами) внутри некоторого обрамления. Способ, когда первая половина обертки — в конструкторе вспомогательного класса, а вторая — в деструкторе (финализаторе и т.д.), не катит.
VD>Я не очень понял вопрос. Если речь идет о вызове некоторого кода после некотых действий, то для етого есть конструкции try/finally и using. Например, если нужно один раз:
VD>
VD>
Не, нужно 5 раз. Или 500. Некоторый код — до, некторый — после. В общем случае, можно сказать, что у нас есть некоторый алгоритм, который должен вызвать внутри себя заданную мной функцию и передать ей 1 аргумент. Гадость в том, что функции нужно 5 аргументов — 4 из них надо зафиксировать до передачи функции в алгоритм. Писать функтор для каждого такого вызова не хочется. Высокая производительность не требуется. Как это делается на шарпе?
VD>Если же пишется класс и нужно освобождать ресурсы отличные от памяти, то:
Это я и так в курсе. Ты ж знаешь, что в С++ к этому случаю ровно тот же подход.
S>>Делегаты умеют "привязывать" параметры на ходу? А переставлять аргументы местами? Или придется вспомогательные классы/функции писать?
VD>Что значит "привязывать к коду" и зачем унжно "переставлять местами"?
"привязывать" параметры — это типа так:
есть функция void foo(int x, float y, const std::string &s);
Надо передать ее в алгоритм, который хочет void bar(int x), при этом y должен быть равен 4.5, а s — "asdf"; boost::bind позволяет создать нужный функциональный объект на ходу — то, что вернет boost::bind(&foo, _1, 4.5, std::string("asdf")) можно передавать в алгоритм вместо void bar(int x).
Описал чуть выше.
VD>Кстати, тоже рисование в дотнете сделано куда изящнее. Правда это скорее заслуга грамотности проектирования обертки над GDI+. Аналогичную можно использовать и на плюсах.
Тормоза.
S>>Да нет, не только. Шаблоны — почти такое же средство кодогенерации, как и макросы. Вот чего они (шаблоны) не умеют — так это работать со строками (и формировать новые читабельные имена) и подставлять код in-place (чтоб возврат из функции сделать, к примеру).
VD>Да они многого не умеют. Назвать это кодогенерацией можно только с огромной натяжкой.
Да, многого, к сожалению. Тем не менее, это именно кодогенерация.
S>>А, скажем, сгенерить тип, наследущийся от всех типов из перечисленного списка или функцию, вызывающую заданную статическую функцию функцию для каждого типа из списка — это запросто.
VD>Это все же далеко не кодогенерация. Зачатки — согласен. Но все же не то.
Это ровно то, что надо для генерации кода сериализации класса. А как это называть — кодогенерацией или ее зачатками, мне, в общем, по барабану.
VD>Ну, и опять таки проблемы отладки не хуже чем с макросами.
Не, с макросами отладка на порядок хуже.
VD>Прямая аналогия — это когда ты не подразумеваешь приведение неких случаев/объектов к некому классу, как в твоем случае. А просто выражение, что мол это как то. Например, в C# есть разделители операторов, как в С++. А вот попытки сделать выводы на базе аналогий приводят к логическим ошибкам. Такие выводы можно делать только для полностью аналогичных вещей/действий. Ну, а аналогичность нужно доказывать. Иначе это обычная демагогия. Прямые аналогии пригодны исключительно для обяснений. Обраные вообще не следут (даже если они кажутся верными).
А увиливание от ответа — тоже, кстати, один из приемов демагогии. Я тебя спросил, почему ты посчитал мою аналогию между шаблонной програмой, выполняемой компилятором и сервер-сайд скриптом обратной, а ты мне выдал целый трактат о том, когда можно и когда нет применять аналогии и ни слова в ответ на мой вопрос.
VD>Ты серьезно хочешь, чтобы я за тебя еще раз перечитал всю эту немаленькую тему? Про клозур конечно тут небыло, но про делегаты не однократно.
А я что, где то говорил, что делегаты в С++ нужны? Делегаты — лишняя сущность, вполне хватило бы __closure и шаблонов с переменным числом параметров. А то, блин,
VD>А ты почитай его последнии интерьвью. В них главной нитью следует, что изменять С++ не нужно. Традиции он естественно хранит свои. Просто его идеи уже отстают от времени.
Ссылку можно? Прочитаю, интересно.
S>>Нет, конечно. Рекурсия — вполне приемлемый (для меня, по крайней мере ) способ записи алгоритмов. Впрочем, не нравится рекурсия — можно попробовать использовать алгоритмы из boost::mpl, там вроде компил-тайм циклы есть.
VD>Все равно получается сложно и непонятно.
Это потому, что в одном куске кода смешиваются компайл-тайм и рантайм программа. (раз уж тебе аналогия с сервер/клиент сайд скриптом не нравится )
VD>Уж проще использовать явные генераторы кода. Вот только это как раз плохой подход.
Плохой. А третьего-то подхода нету...
VD>Я незнаю, твоих скилов в С++, но не думаю, что ты работал с указателями больше меня.
Я такого не утверждал, кстати. Это была очередная аналогия — между шаблонами и указателями в плане понятности кода
VD>Так что давай оставим разговоры о "умении" для барышень. Факт в том, что применение указателей усложняет код, а действенных средств кортроля за целостностью сущьнотей в С++ нет. Так что указатели неменуемо приводят к ошибкам.
Не уходи от темы — речь шла не об ошибках, а исключительно о сложности понимания кода.
VD>Шарп же (в сэйф-режиме) гарантирует целостность объектов и предоставляет действенные средства контроля. Причем эти действия очень малозатратны и доступны даже в релизе.
Не о том речь. Хотя с "очень малозатратны" вполне можно поспорить
S>>Извращения — это для тренировки мозгов. После которой простые и эффективные решения будут писаться куда проще и эффективней
VD>Проблема, в том, что С++ заставляет тренеровать могзги вместо выполнения основной рабты.
Для меня это как раз достоинство Не так скучно работать.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Я не говорю о том, что единственный выход — "кривой"... вот, лучше процитирую себя самого:
Или стрелочки логических связей нарисовать? 
Если нам не помогут, то мы тоже никого не пощадим.
