Здравствуйте, Vi2, Вы писали:
Vi2>Конечно, атрибуты — это метаданные отдельного объекта класса.
Вообще-то атрибуты — это метаданные. А метаданные относятся исключительно к типам, т.е. к классам. Ну и словом объект лучше вообще не пльзоваться, так как оно может выступать как в качетсве экземпляра, так и в качестве самого класса. Например, в КОМ обычно фраза "ком-объект" означает ко-класс...
Vi2>Причем, атрибуты отдельных объектов класса могут быть совершенно независимы и могут не иметь отношения к классу как таковому (в NET это не так).
А геде так? Тебе кстити само слово метаданные не смущает?
Vi2>Соответственно, описание метаданных должно быть привязано к отдельному объекту. А это уже неэффективно с точки зрения организации системы. Те же VB или Скрипты имеют TypeInfo на каждый свой объект.
Чё? Нда...
Vi2>Вообще, мне кажется, атрибутное программирование и компонентное — исключающие друг друга. Не находите?
Не. Попробуй вон на .NET попиши... и ты перестанешь находить.
Кстит, тебе в idl атрибуты не претят? Ты ведь компоненты описываешь!
Здравствуйте, VladD2, Вы писали:
S>>А не хватает, например, нормальных деструкторов,
VD>Мне в первое время тоже не хватало. Но во времением понимаешь, что это вобщем-то просто привычка. Хотя для вэлью-типов можно было бы добавить.
I can't believe it
S>>Что стоило для using statement другой синтаксис придумать?
VD>Я сперва тоже юсинг за виз принял. Но потом быстро привык.
Значит так. Тебе нужно ещё книжку по ADO.NET почитать и всё будет с тобой совсем хорошо
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>I can't believe it
От своих слов про деструкторы про вэлью-типы не отрекаюсь.
VD>>Я сперва тоже юсинг за виз принял. Но потом быстро привык.
IT>Значит так. Тебе нужно ещё книжку по ADO.NET почитать и всё будет с тобой совсем хорошо
Я это дерьмо чуть ли под микроскопом изучил. Дерьмо оно и есть дерьмо. Хуже глючного дизайнера для веб-формсов.
Здравствуйте, VladD2, Вы писали:
IT>>Мда, забавляются ребятки из мс-рисёч
VD>Ты бы что разумного, доброго, вечного скзал. А то не ясно забавно глупые или забавно забавные.
А что тут разумного можно сказать? Придётся опять в новом ковыряться...
В общем, с этим блин-дот-нетом, ближайшие пару-тройку лет журнал без статей не останется
Если нам не помогут, то мы тоже никого не пощадим.
VD>Вообще-то атрибуты — это метаданные. А метаданные относятся исключительно к типам, т.е. к классам. Ну и словом объект лучше вообще не пльзоваться, так как оно может выступать как в качетсве экземпляра, так и в качестве самого класса. Например, в КОМ обычно фраза "ком-объект" означает ко-класс...
Единообразия, конечно, нет, но в моей области деятельности (3Д моделирование), предположим, поверхности являются объектами, на которых я могу написать мне нужные ремарки (пометки), как на чистом листе бумаги. Для чего? Для того, чтобы потом с ними что-либо сделать. Эти ремарки имеют смысл атрибута поверхности, однако к классу "Поверхность" они никакого отношения не имеют и из него не выводимы. Даже более того, за пределами моего приложения эти атрибуты не имеют смысла (хотя и видны примерно так же, как .NET-овские Type).
То, что в .NET это ограничено классом, не умаляет достоинств .NET, но не является единственной реализацией атрибутов (также как СОМ — не единственная компонентная модель).
VD>А где так? Тебя, кстати, само слово метаданные не смущает?
Ты, наверное, полностью в мире .NET: все, что за ним, уже не существует. Без наезда, просто как констатация. Это не плохо, это нормально.
VD>А ты их на С++-ые аналоги замени. То-то посмеемся.
VD>Хочешь, например, соревнемся с тобой в скорости создания и объеме полученного кода в области ком-объектов? Я уже не говорю про простоту модификации и поддержки...
Соревноваться мы не будем, ибо бесполезно. Есть же разница между автоматической генерацией отчетов по меняющимся данным или создание одного отчета и последующее ручное изменение данных в самом отчете! Если здесь уместна такая аналогия с Документооборотом.
Мне пока по душе такая метафора. Кто-то придумал большой такой "шаблон" поведения объекта, в который пользователь вводит недостающие части. Куда идет информация от пользователя, куда она подставляется в "шаблон" и куда она в принципе может быть подставлена — является не очевидным и смахивает на шаманство.
Поэтому я и говорю о примерах, как о состязании в знаниях атрибутов. Знаешь атрибут — получишь результат, не знаешь — замучишься и спросить не у кого. Я не знаю, насколько доступна эта информация в самой IDE (как доступна, напрмер, информация о методах класса при IntelliSense). Это хорошо, что пока атрибутов мало — с десяток.
Здравствуйте, VladD2, Вы писали:
S>>Не въехал. У меня есть два библиотечных (читай — неизменяемых) классов A1 и B1. У класса A есть функция a(), у B — b(). Мне надо, чтоб обе они были у C. Твой пример я понял так:
S>>template <class Tb> S>>struct A : public A1 S>>{ S>> int a(); S>>};
S>>template <class Ta> S>>struct B : public B1 S>>{ S>> int b() const; S>>};
S>>class C: public A< B<C> > {};
VD> VD>Не так, а что-то вроде этого:
VD>
VD>template <T>
VD>class A : public T
VD>{
VD> int a();
VD>};
VD>class <T>
VD>struct B : T
VD>{
VD> int b() const;
VD>};
VD>class A < B < C > > {};
VD>
VD>Те мн. наследование разворачивается в последовательное одиночное. Кажное одиночное наследование добавляет нужную реализацию. По большему счету ведь пробема одиночного наследования заключается именно в том, что к классу нельзя добавить готовую реализацию некоторого интерфейса. Полиморфность (если таковая вообще нужна) может быть обеспечена путем множественного наследования интерфейсов. В шарпе кстит интерфейсы не переходят публичный (дефолтный) интерфейс класса. Объект можно будет привести к интерфейсу, но мтоды у него соотвествующие не появятся. Так что шаблоны решат эту проблему. Ну правда придется изменить несколько свои стереотипы.
Поменять придется не только стереотипы, но и библиотеки Твой метод хорош только если оба класса A и B пишешь сам. В случае, если их менять нельзя (и они не заточены изначально под такое "наследование"), можно с тем же успехом вызывать их методы напрямую из C — писанины даже меньше получиться.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте Sergey, Вы писали:
S>Поменять придется не только стереотипы, но и библиотеки Твой метод хорош только если оба класса A и B пишешь сам. В случае, если их менять нельзя (и они не заточены изначально под такое "наследование"), можно с тем же успехом вызывать их методы напрямую из C — писанины даже меньше получиться.
Здравствуйте, AndrewVK, Вы писали:
S>>Угу, не было, в том числе и множественного не было. Поэтому его отсутствие — шаг назад, к тем языыкам, где его не было.
AVK>И джава и object паскаль моложе плюсов. У обоих множественного наследования нет. Что это все так дружно назад шагают, не знаешь?
Трудно реализовать, особенно в сочетании с полиморфизмом, вот и шагают.
S>>Но даже при "бриллиантовом" наследовании дублирование контролируемое — с помощью виртуального наследования.
AVK>Это называется создаем себе проблемы а потом начинаем их решать.
Ну, мне пару раз встречались ситуации, где без "брилиантового" наследования пришлось бы писать в полтора раза больше кода, со всеми вытекающими из этого последствиями. А с помощью "брилиантового" наследования все решилось настолько просто и изящно, насколько это вообще возможно.
S>>using, конечно, частично исправляет ситуацию. Но он вводит область видимости, что не всегда удобно.
AVK>Не понял юмора. Так в плюсах тоже автоматические деструкторы работают по выходу из области видимости.
В С++ создание автоматического объекта не приводит к созданию новой области видимости. Скобки там можно отдельно от создания объекта написать.
S>>Там — это в MSDN. Оно — это argument-dependent name lookup. Задаешь поиск по фразе "argument-dependent name lookup", находишь в C++ language reference пункт 3.4.2 — Argument-Dependent Name Lookup. Объяснять, тем более по русски, долго.
AVK>Классная вещь наверное, что про русски объяснить что это такое очень сложно.
Угу. А в MSDN или стандарте C++ прочитать — еще сложнее
S>>Угу, это теперь самопальный стандарт. А простой и логичной обработки ошибок я пока не в одном языке не видел. Если этот долбаный рантам иногда молча глотает исключения
AVK>Ни разу не сталкивался.
А я вот почти сразу столкнулся.
S>>>>И которая хуже воровства Ну не делаются сложные вещи простыми инструментами, и все тут. Вернее, делаются, он это сложнее, чем делать их более сложным инструментом.
VD>>>И ты говоришь что это не демагогия?
S>>Это мое убеждение, основанное на личном опыте. Возможно, оно выглядит как демагогия, но обосновывать его чересчур долго и не интересно.
AVK>А мое убеждение, основанное на личном опыте, противоположное. Потому как когда из-за этих супер-пупер сложностей проект начинает захлебываться в собственной сложности то становиться не до наворотов. Могу тебе рассказать точку зрения с другой стороны, не программера а заказчика. Мне пофигу супер фичи. Мне главное чтобы продукт был написан быстро и при этом в нем не было глюков приводящих к неработоспособности, чтобы он был легко конфигурируем, причем чем больше автоматики тем лучше и легко модернизируем. И чтобы код был понятен даже недоучившемуся студенту. И в гробу я видал этот С++ с его множественным наследованием, крутыми указателями и прочия и прочия.
Это все здорово, но верно только в том случае, если предметная область простая — морды к базам данных или бухгалтерия какая, к примеру. Для сложной же задачи решение ее простыми средствами приводит обычно к раздуванию исходных кодов, массированному применению Cut'n'Paste и в конечном счете к появлению плохо поддерживаемого продукта. Вот взять шаблоны например — сложное средство, так? По крайней мере, недоучившихся студентов обычно повергает в ступор Ну так их отсутствие в языке программирования сам знаешь к чему ведет — тот же двоичный поиск недоучившиеся студенты каждый раз будут вынуждены писать заново, причем сделают это пятью разными способами, и каждый влепит по своей индивидуальной и неповторимой ошибке. Хорошенькое упрощение получается. Или вот нет в С++ поддержки мультиметодов — каждый, кому они потребовались (а что делать, если предметная область такая), лепит их на свой лад, производя массу глючного трудноподдерживаемого кода. Причем чем проще он их реализует, тем труднее поддерживать код Да взять те же ассемблер или С (который K&R, не только без плюсов, но и без проверки типов при вызове функций) — средства проще некуда, и что в этом хорошего? Ни один здравомыслящий человек не станет на них в наши дни ничего серьезного писать. Не, что ни говори, а доски пилить электропилой удобнее и проще, чем ножом, хоть она и сложнее.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[21]: Производительность Win2k на Duron 800/384...
Здравствуйте, VladD2, Вы писали:
A>>Ты сказал. VD>Тебе здесь уде все скзали,
Не все.
VD>что рассуждения твои о ОС мягко говря не корректны.
Аргументы моих уважаемых оппонентов в основном свелись к "Меня устраивает". А меня не устраивает.
VD>Отсуда я и делаю выводы что рассуждения о .NET тоже натянуты.
Здравствуйте VladD2, Вы писали:
VD>Тебе здесь уде все скзали, что рассуждения твои о ОС мягко говря не корректны. Отсуда я и делаю выводы что рассуждения о .NET тоже натянуты.
Влад, да бог с ним, пускай работает на 98. Через пару лет все равно NT поставит. 95 не поддерживается, а 98, 98SE и ME отличаются только косметикой. Офис вон уже не работает. 7 студия тоже. Дальше будет только хуже.
Здравствуйте Sergey, Вы писали:
AVK>>Ты эта, поменьше цитируй, а то читать тяжело.
S>Когда с Владом разговариваешь, цитировать приходиться побольше А то он то ли забывает, о чем речь шла, то ли притворяется...
Здравствуйте, AndrewVK, Вы писали:
VD>>Тебе здесь уде все скзали, что рассуждения твои о ОС мягко говря не корректны. Отсуда я и делаю выводы что рассуждения о .NET тоже натянуты. AVK>Влад, да бог с ним, пускай работает на 98. Через пару лет все равно NT поставит.
Конечно. Если к тому времени новый комп соберу .
AVK>95 не поддерживается, а 98, 98SE и ME отличаются только косметикой. Офис вон уже не работает. 7 студия тоже.
А зачем на домашнем компе офис и 7-ая студия? .
AVK>Дальше будет только хуже.
А... Этих программ уже сейчас — как собак. Выбирай любую.
Здравствуйте Sergey, Вы писали:
S>Трудно реализовать, особенно в сочетании с полиморфизмом, вот и шагают.
Ой ли. Не сложнее рефлекшена. Сотни мегабайт исходников, а множественное наследование трудно реализовать. Не смешно. А полиморфизм тут вобще не причем, множественное наследование интерфейсов есть и в джаве и в дотнете.
S>Ну, мне пару раз встречались ситуации, где без "брилиантового" наследования пришлось бы писать в полтора раза больше кода, со всеми вытекающими из этого последствиями. А с помощью "брилиантового" наследования все решилось настолько просто и изящно, насколько это вообще возможно.
Давай так — лично ты не смог найти решения. Если ты считаешь что твое решение было единственно правильным то описание твоей задачи в студию.
(Тут товарищи обижаться стали — я не имел ввиду что твоя квалификация недостаточна, может оно действительно так и было. Но приводить подобное в качестве аргумента некорректно, не правда ли?)
AVK>>Не понял юмора. Так в плюсах тоже автоматические деструкторы работают по выходу из области видимости.
S>В С++ создание автоматического объекта не приводит к созданию новой области видимости. Скобки там можно отдельно от создания объекта написать.
Так и в юзинге можно. Можешь объект создавать где угодно, иногда так и приходиться делать. Юзинг ограничивает опасную область. Вот такое вполне корректно
MyClass mc = new MyClass();
...
using(mc)
{
...
}
MyClass mc = null;
...
using(mc)
{
...
mc = new MyClass();
...
}
S>>>Угу, это теперь самопальный стандарт. А простой и логичной обработки ошибок я пока не в одном языке не видел. Если этот долбаный рантам иногда молча глотает исключения
AVK>>Ни разу не сталкивался.
S>А я вот почти сразу столкнулся.
Поподробнее можно?
AVK>>А мое убеждение, основанное на личном опыте, противоположное. Потому как когда из-за этих супер-пупер сложностей проект начинает захлебываться в собственной сложности то становиться не до наворотов. Могу тебе рассказать точку зрения с другой стороны, не программера а заказчика. Мне пофигу супер фичи. Мне главное чтобы продукт был написан быстро и при этом в нем не было глюков приводящих к неработоспособности, чтобы он был легко конфигурируем, причем чем больше автоматики тем лучше и легко модернизируем. И чтобы код был понятен даже недоучившемуся студенту. И в гробу я видал этот С++ с его множественным наследованием, крутыми указателями и прочия и прочия.
S>Это все здорово, но верно только в том случае, если предметная область простая — морды к базам данных или бухгалтерия какая, к примеру. Для сложной же задачи
О как, корпоративные системы стали уже простыми задачами? Как раз наоборот — это одни из самых сложных задач.
S> решение ее простыми средствами приводит обычно к раздуванию исходных кодов,
Исходные коды к примеру генерить можно. Еще можно много чего на лету создавать. В дотнете вобще очень много технологий направленных именно на уменьшение исходного кода. Рефлекшен позволяет кучу вещей делать автоматом а не писать код (в rsdn mag #3 наверное будет статья про конфигурирование, там очень хорошо это видно, добавление новой настройки начинается и заканчивается добавлением свойства к классу настроек. сохранение в xml и гуевый редактор подстраиваются автоматически). Эмиттинг кода позволяет отказаться от генерации всевозможных проксей и стабов, они генеряться на лету. Вот к примеру код создания удаленного объекта в ремоутинге
RemoteClass rc = new RemoteClass();
Давай, напиши на С++ короче. И это не какая то внутренняя фича, так ты можешь сделать и для своей библиотеки.
S> массированному применению Cut'n'Paste
Это от средства не зависит, это уже уродство дизайна.
S> и в конечном счете к появлению плохо поддерживаемого продукта.
По простоте поддержки и развития С++ с дотнетом и джавой даже рядом не стоял. Тут компоненты рулят.
S> Вот взять шаблоны например — сложное средство, так?
Да нет, не особо. Особенно когда его используют по прямому назначению а не для компенсации недостатков языка.
S>тот же двоичный поиск недоучившиеся студенты каждый раз будут вынуждены писать заново,
А вот в дотнете даже хеш-таблицы есть. А шаблонов пока нету. Шаманы наверное.
S> Или вот нет в С++ поддержки мультиметодов
Это кто ж такие, если не секрет?
S>Не, что ни говори, а доски пилить электропилой удобнее и проще, чем ножом, хоть она и сложнее.
Вот дотнет как раз по своим внутренностям несравненно сложнее С++, а вот пользоваться им проще и удобнее, как и электропилой. Так что очень правильная аналогия .
Здравствуйте Aquila, Вы писали:
AVK>>Влад, да бог с ним, пускай работает на 98. Через пару лет все равно NT поставит.
A>Конечно. Если к тому времени новый комп соберу .
Тебе и тепиерешнего хватит выше крыши. Я ж тебе пример привел компа под NT 4 на 486 процессоре. Очень неплохо работал.
AVK>>95 не поддерживается, а 98, 98SE и ME отличаются только косметикой. Офис вон уже не работает. 7 студия тоже.
A>А зачем на домашнем компе офис и 7-ая студия? .
Так комп то программиста. У меня к примеру есть. А офис — найди мне домашний компьютер без ворда. Очень редко встречаются, скажу тебе по секрету.
AVK>>Дальше будет только хуже.
A>А... Этих программ уже сейчас — как собак. Выбирай любую.
Если нам не помогут, то мы тоже никого не пощадим.
