Здравствуйте, AndrewVK, Вы писали:
AVK>Ты фишку не понял — первый пример это то как можно реализовать и в С++. Вся закавыка именно во втором.
Я тут подумал на С++ можно так Найдите 10 отличий
AVK>Вот без этого точно можно прожить.
Тяжко.
WH>>А что ты постоянно используешь рефлекшен? AVK>Я например весьма часто.
А я шаблоны тотально.
AVK>Сравни AVK>
Здравствуйте, VladD2, Вы писали:
N>>Да, код кажется ужасным. Но этот код _не_ предназначен для того, чтобы его читали. VD> Я плякаль...
Фабрики получились так себе, а вот визитеры
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Погоди, к чему ты это? Ну да, я согласен, что ты продемонстрировал неплохой пример решения очень частной задачи. Согласен, что компилятор в .Net используется несколько отличающимся от C++ способом. Но rtti-то тут при чём ?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Оговорился, извиняйте. Вообще-то редактор в смысле стрелочки-буковки-циферки нужен для одного типа — строки. Остальные можно скомпоновать из такого редактора и верификаторов+конвертеров для разных типов. Собственно, такой агрегат я и называл редактором.
AVK>Ладно, едем дальше. Каким образом ты собираешься привязывать верификаторы+конверторы к типам?
К типам данных источника, надеюсь? Если так, то тривиально. Выбором нужного агрегата из набора имеющихся и привязкой его к позиции колонки. switch/case остаётся только в самом начале этой цепочки — при анализе SQL-типа. Хотя можно обойтись и без него — std::map<sql-type, editor*>, например. И в чём проблема?
ГВ>>Пример такого источника можно? А то что-то не верится.
AVK>SOAP
Понятно, началось передёргивание. Следующим вариантом, видимо, будет TCP/IP, а что? чем не источник? SOAP — это протокол обмена. Если очень приспичит, то я сделаю единый для клиентского приложения набор SOAP-сообщений, к которым и сведу обмен между приложением и клиентом. И при чём тут распознавание большого количества типов? Или ты имеешь ввиду, например, что для гридов Order и Employee, буде они получены через SOAP нужно обязательно писать два отдельных грида?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Куча ненужного кода, необходимость явно описывать и регистрировать сериализуемые классы. ГВ>>Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код? AVK>Описание и регистрация учавствующих классов, а зачастую еще и ручная реализация сериализации для каждого типа.
Упс? А почему этот код — ненужный?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
WH>Первый легко. ADO.
Конечно легко, он дан как раз как исходная позиция.
WH>И что теперь говорить что рефлекшен фигня? Если в .NET будут шаблоны уровня С++ и множественное наследование я сразу забью на С++.
У меня создаётся впечатление, что тебя просто засосало. Выйди из этого болотца и оглянись вокруг. Зачем тебе множественное наследование классов? Какую задачу без него нельзя решить? Шаблоны? Да будут у нас шаблоны Проблему контейнеров пока можно решить всевозможными генерилками, со сборкой реализации похуже. Но её, кстати, не Александреску придумал, я её на ура использовал в ATL ещё 3 года назад, и после перехода на C# она мне почему-то как-то не очень нужна
WH>К стати когда студент поймет что на "простом" и "понятном" языке придется писать в 10 раз больше и не будет дураком он пойдет читать Александреску.
Надеюсь он пойдёт читать что-нибудь про C#
IT>>В твоём примере трудно понять вообще для чего он нужен, WH>Обыкновенная сборка классов из кирпичиков причем один кирпичик может изменить реализацию другого причем даст компилятору кучу информации при помощи которой он может инлайнить методы из карпичика A в методе кирпичика B. Воспользовавшись этим я показал как можно писать кирпичи с учетом многопоточности и использовать в однопоточном приложении так что компилятор убьет весь код синхронизации.
Без привычки твой код нужно распечатать и сидеть с бумажками разбираться что он там делает. А лучше сразу сбегать в ларёк за пузырём
WH>Первый да второй нет(вернее догадаться по контексту могу, а повторить...даже на С#... ). WH>Таже проблема что и у тебя с моим кодом плохое знание матчасти.
Т.е. ты меня как и Влада отправляешь почитать Александреску? Ну, тут я такой сразу раскидываю пальцы и громко заявляю, что да я на этом вашем C++ пишу ешё больше Влада, лет 12, и ещё типа на Zortech C++ изучал реализацию типизированных контейнеров на макросах
В твоём же случае действительно присутствует плохое знание матчасти. Как тебе сказал AVK для того чтобы реализовать подобное нужно не больше месяца знакомства с .NET. Ключевых момента здесь два:
public ArrayList ExecuteList(Type type, string commandText, params IDbDataParameter[] commandParameters)
{
// ...object o = Activator.CreateInstance(type);
// ...
FieldInfo[] fields = type.GetFields(BindingFlags.Public | BindingFlags.Instance);
foreach (FieldInfo fld in fields)
{
string name = fld.Name;
object dbValue = // читаем данные из рекордсета по name
fld.SetValue(o, dbValue);
}
// ..
}
Т.е. я легко могу создать объект зная его тип и я могу не напрягаясь побраузить все его поля как и вообще любую другую информацию о типе.
WH>А к чьим можно прибегнуть для того чтобы понять пример с рефлекшеном?(В принципе я понимаю как это работает но хочется по подробней)
Надеюсь приведённого мной примера достаточно
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, WolfHound, Вы писали:
ГВ>>Где гарантия наличия реализации Save WH>Вто не надо... с темже успехом можно сказать,а где рарантия что компилятор сгенерирует правильный код?
Я не писал о гарантии правильной реализации. Какой там! Я имел ввиду просто наличие самой по себе реализации. О ней в данном случае можно попросту случайно забыть.
WH>Например в моей текущей практике почти половина ошибок на совести компилятора.(BCB6)
Ну... плохой компилятор, что тут можно сказать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Погоди, к чему ты это? Ну да, я согласен, что ты продемонстрировал неплохой пример решения очень частной задачи. Согласен, что компилятор в .Net используется несколько отличающимся от C++ способом. Но rtti-то тут при чём ?
AVK>Атрибуты без rtti невозможны в принципе
Если такие же, как в .Net, то да. Но они не всегда такие и нужны. А реализовать сопоставление метаинформации экземпляру можно и без rtti.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Да у меня нет вопросов. Мое знание С++ позволяет применять его для решения нужных мне задачь и чтения чужого кода. Я не фанат этого языка и оттачивать свое мастерство в нем не жалаю.
VD>Моих знаиний более чем достаточно чтобы заметить море мелких и не очень проблем этого языка. И уж точно достаточно, чтобы оценить его приемущества и недостатки по отношению к Шарпу.
Десять! Я такого перла, Влад, от тебя не ожидал!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
IT>Т.е. ты меня как и Влада отправляешь почитать Александреску? Ну, тут я такой сразу раскидываю пальцы и громко заявляю, что да я на этом вашем C++ пишу ешё больше Влада, лет 12, и ещё типа на Zortech C++ изучал реализацию типизированных контейнеров на макросах
Ну моя очередь распустить пальци. Взяли меня кодером под новый проект. Когда дело дошло до прототипа движка то мой сделал остальных по всем параметрам и сильно(те по простоте использования, функциональности, расширяемости, дурокаустойчивости...) Вобщем теперь я архитектор и ни кто не вспоминает что мой опыт реальных проектов около года, а у остальных 4-10 лет. К стати я настаивал на C# но по политическим мотивам высшие руководство выбрало BCB6. Ну да ничего следующий будет на C#/
А прочитать этукнигу ИМХО надо даже если на С++ писать не собираешся. Узнаешь много нового о С++.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Вобщем теперь я архитектор и ни кто не вспоминает что мой опыт реальных проектов около года, а у остальных 4-10 лет.
Эх молодость... Ладно, поговорим на эту тему через 10 лет
WH>А прочитать этукнигу ИМХО надо даже если на С++ писать не собираешся.
Кто бы спорил про книжки. Спор о том, что любая самая грамотная из них не может является панацеей. А в том ключе как ты ведёшь беседу, типа иди почитай, а прежде я с тобой даже и разговаривать не буду (хотя в тоже самое время сам не может внятно объяснить что к чему) всё желание углублятся в чтение подобной литературы пропадает.
WH>Узнаешь много нового о С++.
Я знаю о нём достаточно много, а так же знаю и много чего другого. Именно поэтому могу утверждать, что у него нет безоблачного будущего, если его серьёзно не доработают. Сегодня потребность в Java девелоперах уже заметно выше чем C++, если сюда добавить ещё VB а в России Дельфистов, то уже сейчас на C++ пишут только треть. Пять лет назад ситуация выглядела значительно более оптимистично. Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.
ЗЫ. Между прочим, поняв это в своё время, я провёл несколько бессонных ночей, нервно покуривая на кухне, запивая горе самогонкой и поминутно утирая скупую слезу сиплюсплюсника. Вот так вот
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mihailik, Вы писали:
VD>>Согласись, что шаблоны и средства подключения реализаций все же нужны. M>Не, генерики и баста. Хорошенько понемножку. M>Слишком большая гибкость только вредит. Ртуть вон гибче глины, зато из неё фигурки не лепятся.
Дык шаблонами подключение реализации впринципе решается. Только как всегда через ухо.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Я тут подумал на С++ можно так Найдите 10 отличий
Молодец, что-то в этом духе я и ожидал Отличий не 10, но парочка найдётся. Во-первых, зачем же так в наглую передавать список полей, во-вторых, на макросах это даже проще, а в-третьих, я легко могут усложнить задачу и ввести в неё атрибуты и вообще перевести разговор на AOP
WH>Даже короче вышло. И assembly_name указывать не надо.
А как быть если объявление класса находится в другой, возможно ещё даже не подгруженной, сборке?
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>ЗЫ. Между прочим, поняв это в своё время, я провёл несколько бессонных ночей, нервно покуривая на кухне, запивая горе самогонкой и поминутно утирая скупую слезу сиплюсплюсника. Вот так вот
Вот оветь на такой вопрос? Если С++ почти мертв как ты утверждаешь то почему МС вкладывает в развитие С++ компилятора кучу денег? Я не могу оценить изменения фреймворка но могу оценить изменения в С++ компиляторе и у меня такой чувство что вложения в него измеряются мегабаксами как минимум. Мало того что он понимает все что мне приходит в голову, компилирует boost лучше всех даже comeau сделал так он еще и не глючит.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>Молодец, что-то в этом духе я и ожидал Отличий не 10, но парочка найдётся.
IT>Во-первых, зачем же так в наглую передавать список полей,
По моему нормально, а как иначе?
IT>во-вторых, на макросах это даже проще,
Чесно говоря не вижу куда их можно прикрутить
IT>а в-третьих, я легко могут усложнить задачу и ввести в неё атрибуты и вообще перевести разговор на AOP
А я могу вспомнить о ручных менеджерах памяти, вычислениях времени компиляции, генерации кучи кода... У каждой среды свои плюсы и минусы. Правда тут есть некоторые товарищи (причем по обе стороны бурекад) которые и слушать о плюсах другой среды не хотят.
IT>А как быть если объявление класса находится в другой, возможно ещё даже не подгруженной, сборке?
В моей системе все грузится в самом начале (хотя возможно подгрузить длл и во время работы) и все классы попадают в одно пространство имен учитывая довольно жосткие правила именования конфликтов имен не происходит, но в случае чего вылетит исключение.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Хорошо, пускай о терминах, но это ты его начал.
Я? Я сказал, что любой С++ код можно скомплировать как менеджед, а ты докопался.
AVK>Тем не менее, возвращаясь к исходному спору, если мы хотим чтобы компоненты, писанные на МС++ использовались в других языках дотнета, то вынужденны лишиться возможности использовать некоторый набор фич.
Но это же не отменяет возможности компилировать старые приложения в MSIL и делать для них обертки в виде __gc-классов?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Они сознательно ограничивали его рассмотрение.
Ага. Вот только их аргументы (вернее его) выглядят как дешевые отмазки.
ГВ> И ИМХО, совершенно разумно, поскольку необходимость "самоанализа" (он же — rtti) в сущности, является ошибкой дизайна.
Ну, что я могу тебе сказать. По-моему, ты ошибаешся.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
K_O>На самом деле, RTTI нужен не столько программистам, пишущим на C++ (хотя есть некоторые задачи, где RTTI ну оччень бы пригодился), сколько самому компилятору С++. Если бы в объектные файлы помещалась информация о типах, то компилятору при компиляции каждого cpp-файла не приходилось бы обрабатывать сотни килобайт исходного кода, которые вставляются через #include.
Именно. Но ты все же однобоко смотришь на это. Тут есть еще один фактор. Компонентность. Языки типа Дельфи, Явы и Шарпа не только пораждают удобные объектники. Эти объектники в следствии наличия метаданных являются еще и контейнерами компоненотов которые можно использовать в рантайме и дизайнтайме. Вон посмотри на Билдер. Ребята из Борланда попытались приделать к С++ дизантайм и компоненты. В итоге получилась очень громоздкая и глючная реализаци. Причем без изменения языка так и не удалось обойтись. А ведь бидлер в отношении компонентности и дизайнтайма имеет все те же ограничения, что и Дельфи. МС пошли дальше и на сегодня МС++ — идеал компонентного С++.
K_O>Именно поэтому скорость компиляции программ на Delphi и Java на много порядков быстрее, чем на C++. Про скорость компиляции С# не скажу — не пришлось еще с ним плотно познакомится, но подозреваю, что тоже намного быстрее, чем С++.
Шарп компилирует исходники даже быстрее чем дельфи. Особенно кода кода много.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну, в общем — да, это было бы поудобней в чём-то, чем исходники, но тогда объектники (и библиотеки, кстати, тоже!) тащили бы груду лишней информации о тех же шаблонах. Хорошо это или плохо... трудно сказать. Мне, по крайней мере.
Да не так уж много эта информация занимает. Давай взгляенем на детища МС. На С++-овый и на Шарп-овый компиляторы. Их С++ в среднего размерах проектов генерирует гигабайты отладочной информации. А компилятор Шарпа несколько килобайт. Причем любая длл-ка Шарпа несет в себе полное описание реализованных в ней классов и кода.
МС обещает и шаблоны прикрутить. Причем они так же будут доступны на рантайме.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.