Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?
В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Ээээ... согласен, да. Сигнатуры — одно из возможных, но не лучшее решение, поскольку в данном случае просто подменяют rtti.
VD>Гы. А дотнете нет ртти. Там это называется рефлекшеном. И это именно он и был.
Ну спасибо, просветил.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>>>Я тебя не удевлю если скажу, что все это можно сделать и на Шарпе (т.е. без шаблонов)? Причем решения будут даже более красивыми.
ГВ>>Затыкание дырок C#? Забавно.
VD>Демагогия вместо аргументов? Забавно... А если серьезно, то на Шарпе для большинства задач просто не нужно затыкать дыры. Есть красивые шаттные решения не приводящие к трехэтажным наворотам.
Что-то ты странное говоришь. Что ты подразумеваешь под словом "дыра"?
VD>>>Так что твои примеры скорее являются доказательством высказанной мною мысли, о том что 90% использования шаблонов в С++ является затыканием дырок языка. И вызваны прощетами в языке.
ГВ>>Эдак любую библиотеку можно назвать затыканием дырок языка, на котором она написана.
VD>Я про всю библиотеку в общем то и не говорю. Но вот сигналы бесспорно являются затыканием дыр. И TypeList-ы тоже.
Повторя вопрос — что есть "дыра"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
ГВ>>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?
IT>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.
Хммм... похоже, ты меня совсем не понял.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?
IT>>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.
ГВ>Хммм... похоже, ты меня совсем не понял.
Возможно, скорее всего ты имел ввиду рефлекшин, а не сериализацию. Правильно?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Я к тому, что исходники библиотек читаются и очень даже бурно. И чем проще читать код, тем больше людей смогут использовать эту библиотеку. Например, к дотнету в половине случаев исходников нет (есть SSCLI, но в нем многого нет). Дык любой серьзный специалист по дотнету в качестве основных шорткатов/иконок держит сслки на Анакрину и Эксплорел (декомпайлры).
Я и не спорю. Есть такой недостаток у обобщенного кода. Но принимая во внимание его полезность (хотя для меня сейчас — она теоретическая ), это не фатальный недостаток. А читать его все-таки можно привыкнуть.
Здравствуйте, VladD2, Вы писали:
AVK>>Хорошо, пускай о терминах, но это ты его начал.
VD>Я? Я сказал, что любой С++ код можно скомплировать как менеджед, а ты докопался.
Ну ж фиг там. Вот исходная цитата alexkro, из-за которой весь спор начался:
На C++ тоже можно для .NET программировать и при этом использовать большинство его (C++) идиом.
С чем я собственно и не согласился. Потому и написал:
A>На C++ тоже можно для .NET программировать
Ну и что? Если укладываться в рамки CLR то от С++ остануться рожки да ножки.
A>и при этом использовать большинство его (C++) идиом.
Большинство идиом в managed коде? Не получится.
И вот тут ты решил поиграться с терминами. Так что не надо перекладывать с больной головы на здоровую.
AVK>>Тем не менее, возвращаясь к исходному спору, если мы хотим чтобы компоненты, писанные на МС++ использовались в других языках дотнета, то вынужденны лишиться возможности использовать некоторый набор фич.
VD>Но это же не отменяет возможности компилировать старые приложения в MSIL и делать для них обертки в виде __gc-классов?
Не отменяет. Но называть это доступностью всех возможностей для программирования под дотнет имхо не стоит. Часть возможностей доступна, а для части нужны обертки, чтобы все это можно было использовать в нетовской инфраструктуре.
Здравствуйте, alexkro, Вы писали:
A>Это потому, что ты уже знал язык, который обладает большими возможностями. А человек, который программировал на языке с возможностями, перекрывающими C++, перепрыгнет на него с такой же легкостью.
Шарп по идеологии весьма серьезно отличается от плюсов, максимум что можно использовать это похожий синтаксис. С шарпом я таких наблюдений не проводил, но зачастую для получения качественного кода на джаве новичков приходится учить меньше, нежели зубров, писавших на плюсах и дельфи.
A>Значит ли это, что C++ сложнее изучать? Не факт. Просто изучать нужно правильно.
Ровно так же нужно правильно изучать дотнет. И тогда не будут приходить в голову мысли, озвученные в корне топика.
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>>>Куча ненужного кода, необходимость явно описывать и регистрировать сериализуемые классы. ГВ>>>Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код? AVK>>Описание и регистрация учавствующих классов, а зачастую еще и ручная реализация сериализации для каждого типа.
ГВ>Упс? А почему этот код — ненужный?
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Ладно, едем дальше. Каким образом ты собираешься привязывать верификаторы+конверторы к типам?
ГВ>К типам данных источника, надеюсь?
Естественно.
ГВ>Если так, то тривиально. Выбором нужного агрегата из набора имеющихся и привязкой его к позиции колонки.
Вот вот, выбор ты как будешь осуществлять и из чего?
ГВ> switch/case остаётся только в самом начале этой цепочки — при анализе SQL-типа. Хотя можно обойтись и без него — std::map<sql-type, editor*>, например. И в чём проблема?
Проблема в том что этот самый std::map при наличии rtti не нужен.
Ладно, продолжаем двигаться дальше. Теперь представь что на момент написания есть одна версия источника. Далее, когда ты уже свой софт написал и отдал билд клиенту у источника появился новый ип данных. Твои действия?
ГВ>>>Пример такого источника можно? А то что-то не верится.
AVK>>SOAP
ГВ>Понятно, началось передёргивание. Следующим вариантом, видимо, будет TCP/IP, а что? чем не источник? SOAP — это протокол обмена.
ОК, если действительно не понимаешь или делаешь вид, то пускай это будет веб-сервис. Так понятнее?
ГВ> Если очень приспичит, то я сделаю единый для клиентского приложения набор SOAP-сообщений, к которым и сведу обмен между приложением и клиентом.
А если сервис не ты писал? А если он изменился?
ГВ>И при чём тут распознавание большого количества типов?
При том что SOAP отнюдь не ограничен стандартным набором типов.
ГВ>Или ты имеешь ввиду, например, что для гридов Order и Employee, буде они получены через SOAP нужно обязательно писать два отдельных грида?
Нет, я имею ввиду что для отображения недетерминированных заранее источников данных rtti очень полезен.
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Гарантия в коде универсального сериализатора. Код сериализации автоматически сериализует состояние объектов на основании информации о них.
ГВ>Да фиг с ней, с сериализацией.
А, то есть таки сериализация красиво и лаконично без наличия rtti не выходит? Так как тогда быть с твоими заявлениям про неверный дизайн?
ГВ>Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации, а о чём-то ещё,
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации.
Неа. Форматтеры и XmlSerializer вполне могут быть написаны самостоятельно без использования фич clr. Точнее с использованием одной фичи, которая называется рефлекшен.
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.
ГВ>Хммм... похоже, ты меня совсем не понял.
Правильно он тебя понял. Нет там никакого специального механизма для сериализации, есть только рефлекшен, который ровно так же пригоден и для той же визуализации, о которой ты поминал. Сему пример тот же PropertyGrid.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Если такие же, как в .Net, то да. Но они не всегда такие и нужны. А реализовать сопоставление метаинформации экземпляру можно и без rtti.
Ага, при помощи монстроидальных мапов и шаблонов. Самое смешное что народ приводит громоздкий код на плюсах в доказательство того как на плюсах все просто. Вот только на шарпе все то же самое выходит в разы проще, понятнее и красивше.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну нет, почему же? Если сопоставление метаинформации реализуется для его дальнейшего использования, то чтение будет удобным. По-моему, это очевидно.
Так же совершенно очевидным является то что сопоставление этой самой информации руками не есть лучшее решение, поскольку все то же самое можно сделать автоматически.
Здравствуйте, IT, Вы писали:
IT>Без привычки твой код нужно распечатать и сидеть с бумажками разбираться что он там делает. А лучше сразу сбегать в ларёк за пузырём
Ой IT, оторвался ты совсем от российских реалий. Пузырьки теперича в ларьках не продают, запрещено. Так что придется бежать немножко подальше, в магазин. Правда в ларьке можно купить пиво.
Здравствуйте, WolfHound, Вы писали:
IT>>Т.е. ты меня как и Влада отправляешь почитать Александреску? Ну, тут я такой сразу раскидываю пальцы и громко заявляю, что да я на этом вашем C++ пишу ешё больше Влада, лет 12, и ещё типа на Zortech C++ изучал реализацию типизированных контейнеров на макросах
Эх, уж коль мы занялись пенисометрией, то я, коль скоро тоже являюсь явнообвиненным в незнании матчасти скажу что так же писал еще на TurboC лет эдак 9-10 назад. Лет 6-7 назад на BC++.
WH>Ну моя очередь распустить пальци. Взяли меня кодером под новый проект. Когда дело дошло до прототипа движка то мой сделал остальных по всем параметрам
Ну мы же не знаем кто такие остальные, согласен?
WH>и сильно(те по простоте использования, функциональности, расширяемости, дурокаустойчивости...) Вобщем теперь я архитектор и ни кто не вспоминает что мой опыт реальных проектов около года,
И после этого у тебя хватает смелости обвинять одних из самых опытных на rsdn программеров (я не себя имею ввиду, а Влада и Игоря) в незнании матчасти? Скажи, теперича все молодые программеры такие пальцастые?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Геннадий Васильев, Вы писали:
VD>Ты знаком с тем как сериализация делается в дотнете? Там это ровно одна строчка кода. Причем от самого класса практически ничего не требуется. Нужно всего лишь пометить класс отрибутм говорящим что класс сериализуемый. Уравлять тем, что не нужно сериализовать или нужно сериализовать особым образом так же можно атрибутами.
Такая сериализация имеет недостатком скорость. Если надо сохранить словарь терминов на 100,000, что например встречается у нас постоянно, все выглядит очень удручающе. Да и объем тоже не воодушевляет.
Если же сохранять в бинарном виде (в других не знаю), то если поменять сборку, то она уже ничего не загрузит, т.к. сереализованный объект будет от другой версии.
Так что для сохранения настроек такая технология подходит очень хорошо, а для сохранения реальных данных (по крайней мере в моем случае) как то не катит
Здравствуйте, VladD2, Вы писали:
IT>>ЗЫ. Между прочим, поняв это в своё время, я провёл несколько бессонных ночей, нервно покуривая на кухне, запивая горе самогонкой и поминутно утирая скупую слезу сиплюсплюсника. Вот так вот
VD>Я плякаль... узнавая себя... и мысленно заменяя С++ на COM.
А мне вот повезло, поскольку джавой я занялся, поскольку ничего приличного на тот момент в сфере веб-приложений больше не было. Всеобще увличение поделкой под названием php меня как то не воодушевило, а jscript и прочия я не любил с детства . Ну а потом как то само собой получилось что дельфи и С++ отнюдь не всегда лучше даже не в веб-проектах. После этого дотнет воспринимался уже как родной .