Re[25]: Будущее C#
От: WolfHound  
Дата: 03.07.03 16:33
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Ты фишку не понял — первый пример это то как можно реализовать и в С++. Вся закавыка именно во втором.

Я тут подумал на С++ можно так Найдите 10 отличий
static boost::shared_ptr<std::vector<boost::shared_ptr<CategoryInfo> > > GetCategories(int min)
{
    return DBManager<CategoryInfo>(
                "Server=.;Database=Northwind;Integrated Security=SSPI"
            ,
                "SELECT"
                "    p.CategoryID,"
                "    c.CategoryName,"
                "    Count(p.CategoryID) Count"
                "FROM Products p"
                "    INNER JOIN Categories c ON c.CategoryID = p.CategoryID"
                "GROUP BY p.CategoryID, c.CategoryName"
                "HAVING Count(p.CategoryID) >= @min"
                "ORDER BY c.CategoryName"
            ,    
                DBFields<CategoryInfo>()
                    (&CategoryInfo::CategoryID,        "CategoryID")
                    (&CategoryInfo::CategoryName,    "CategoryName")
                    (&CategoryInfo::Count,            "Count")
            ,
                DBParams()
                    ("@min", min)
        );
}

Мне лень писать шаблоны для этого но вот ключь к реализации
struct Variant
{
    operator int()const
    {
        return 123456;
    }
    operator std::string()const
    {
        return "Hello";
    }
};

template<class T>
struct SetFieldBase
{
    virtual void Set(T&, const Variant&)const=0;
};
template<class T, class U>
struct SetField
    :SetFieldBase<T>
{
    SetField(U T::* ptr)
        :ptr_(ptr)
    {}
    void Set(T& val, const Variant& var)const
    {
        val.*ptr_=var;
    }
private:
    U T::* ptr_;
};
template<class T, class U>
SetField<T, U> MakeSetField(U T::* ptr)
{
    return ptr;
}
struct CategoryInfo
{
    int            CategoryID;
    std::string CategoryName;
    int            Count;
};
int main()
{
    CategoryInfo info;
    const SetFieldBase<CategoryInfo>& setField1=MakeSetField(&CategoryInfo::CategoryID);
    const SetFieldBase<CategoryInfo>& setField2=MakeSetField(&CategoryInfo::CategoryName);
    const SetFieldBase<CategoryInfo>& setField3=MakeSetField(&CategoryInfo::Count);
    setField1.Set(info, Variant());
    setField2.Set(info, Variant());
    setField3.Set(info, Variant());
    return 0;
}


AVK>Вот без этого точно можно прожить.

Тяжко.

WH>>А что ты постоянно используешь рефлекшен?

AVK>Я например весьма часто.
А я шаблоны тотально.

AVK>Сравни

AVK>
AVK>Activator.CreateInstance(Type.GetType("ClassName, assembly_name"));
AVK>

Ну сравнил.
    Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorClassName);

    I_Sensor sensor=(I_Sensor)Activator.CreateInstance(Type.GetType("ClassName, assembly_name"));

Даже короче вышло. И assembly_name указывать не надо.
Остальное просто демонстрация других возможностей движка.

AVK>А нужно?

Иногда приходится.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: Будущее C#
От: WolfHound  
Дата: 03.07.03 16:33
Оценка:
Здравствуйте, VladD2, Вы писали:

N>>Да, код кажется ужасным. Но этот код _не_ предназначен для того, чтобы его читали.

VD> Я плякаль...
Фабрики получились так себе, а вот визитеры
struct DocElement
    :BaseVisitable<>
{
    DEFINE_VISITABLE()
}
struct Paragraph
    :DocElement
{
    DEFINE_VISITABLE()
}
struct MyVisitor
    :BaseVisitor
    ,Visitor<DocElement>
    ,Visitor<Paragraph>
{
    void Visit(DocElement&)
    {
    }
    void Visit(Paragraph&)
    {
    }
}
int main()
{
    MyVisitor visitor;
    Paragraph par;
    DocElement* d=&par;
    d->Accept(visitor);
}

Скачай Loki не поленись брать тут: google+loki+C++ и по линку на соурсфорш
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 16:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Погоди, к чему ты это? Ну да, я согласен, что ты продемонстрировал неплохой пример решения очень частной задачи. Согласен, что компилятор в .Net используется несколько отличающимся от C++ способом. Но rtti-то тут при чём ?


Атрибуты без rtti невозможны в принципе
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[29]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 16:52
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Оговорился, извиняйте. Вообще-то редактор в смысле стрелочки-буковки-циферки нужен для одного типа — строки. Остальные можно скомпоновать из такого редактора и верификаторов+конвертеров для разных типов. Собственно, такой агрегат я и называл редактором.


AVK>Ладно, едем дальше. Каким образом ты собираешься привязывать верификаторы+конверторы к типам?


К типам данных источника, надеюсь? Если так, то тривиально. Выбором нужного агрегата из набора имеющихся и привязкой его к позиции колонки. switch/case остаётся только в самом начале этой цепочки — при анализе SQL-типа. Хотя можно обойтись и без него — std::map<sql-type, editor*>, например. И в чём проблема?

ГВ>>Пример такого источника можно? А то что-то не верится.


AVK>SOAP


Понятно, началось передёргивание. Следующим вариантом, видимо, будет TCP/IP, а что? чем не источник? SOAP — это протокол обмена. Если очень приспичит, то я сделаю единый для клиентского приложения набор SOAP-сообщений, к которым и сведу обмен между приложением и клиентом. И при чём тут распознавание большого количества типов? Или ты имеешь ввиду, например, что для гридов Order и Employee, буде они получены через SOAP нужно обязательно писать два отдельных грида?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 16:57
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Куча ненужного кода, необходимость явно описывать и регистрировать сериализуемые классы.

ГВ>>Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код?
AVK>Описание и регистрация учавствующих классов, а зачастую еще и ручная реализация сериализации для каждого типа.

Упс? А почему этот код — ненужный?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[24]: Будущее C#
От: IT Россия linq2db.com
Дата: 03.07.03 17:10
Оценка:
Здравствуйте, 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 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 17:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Где гарантия наличия реализации Save

WH>Вто не надо... с темже успехом можно сказать,а где рарантия что компилятор сгенерирует правильный код?

Я не писал о гарантии правильной реализации. Какой там! Я имел ввиду просто наличие самой по себе реализации. О ней в данном случае можно попросту случайно забыть.

WH>Например в моей текущей практике почти половина ошибок на совести компилятора.(BCB6)


Ну... плохой компилятор, что тут можно сказать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[29]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 17:19
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Погоди, к чему ты это? Ну да, я согласен, что ты продемонстрировал неплохой пример решения очень частной задачи. Согласен, что компилятор в .Net используется несколько отличающимся от C++ способом. Но rtti-то тут при чём ?


AVK>Атрибуты без rtti невозможны в принципе


Если такие же, как в .Net, то да. Но они не всегда такие и нужны. А реализовать сопоставление метаинформации экземпляру можно и без rtti.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 17:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Да у меня нет вопросов. Мое знание С++ позволяет применять его для решения нужных мне задачь и чтения чужого кода. Я не фанат этого языка и оттачивать свое мастерство в нем не жалаю.


VD>Моих знаиний более чем достаточно чтобы заметить море мелких и не очень проблем этого языка. И уж точно достаточно, чтобы оценить его приемущества и недостатки по отношению к Шарпу.


Десять! Я такого перла, Влад, от тебя не ожидал!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Будущее C#
От: WolfHound  
Дата: 03.07.03 17:40
Оценка:
Здравствуйте, IT, Вы писали:

IT>Т.е. ты меня как и Влада отправляешь почитать Александреску? Ну, тут я такой сразу раскидываю пальцы и громко заявляю, что да я на этом вашем C++ пишу ешё больше Влада, лет 12, и ещё типа на Zortech C++ изучал реализацию типизированных контейнеров на макросах

Ну моя очередь распустить пальци. Взяли меня кодером под новый проект. Когда дело дошло до прототипа движка то мой сделал остальных по всем параметрам и сильно(те по простоте использования, функциональности, расширяемости, дурокаустойчивости...) Вобщем теперь я архитектор и ни кто не вспоминает что мой опыт реальных проектов около года, а у остальных 4-10 лет. К стати я настаивал на C# но по политическим мотивам высшие руководство выбрало BCB6. Ну да ничего следующий будет на C#/
А прочитать этукнигу ИМХО надо даже если на С++ писать не собираешся. Узнаешь много нового о С++.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: Будущее C#
От: IT Россия linq2db.com
Дата: 03.07.03 19:05
Оценка: :))) :)
Здравствуйте, WolfHound, Вы писали:

WH>Вобщем теперь я архитектор и ни кто не вспоминает что мой опыт реальных проектов около года, а у остальных 4-10 лет.


Эх молодость... Ладно, поговорим на эту тему через 10 лет

WH>А прочитать этукнигу ИМХО надо даже если на С++ писать не собираешся.


Кто бы спорил про книжки. Спор о том, что любая самая грамотная из них не может является панацеей. А в том ключе как ты ведёшь беседу, типа иди почитай, а прежде я с тобой даже и разговаривать не буду (хотя в тоже самое время сам не может внятно объяснить что к чему) всё желание углублятся в чтение подобной литературы пропадает.

WH>Узнаешь много нового о С++.


Я знаю о нём достаточно много, а так же знаю и много чего другого. Именно поэтому могу утверждать, что у него нет безоблачного будущего, если его серьёзно не доработают. Сегодня потребность в Java девелоперах уже заметно выше чем C++, если сюда добавить ещё VB а в России Дельфистов, то уже сейчас на C++ пишут только треть. Пять лет назад ситуация выглядела значительно более оптимистично. Теперь предположим, что через пару лет только настоящие патриоты не перейдут на .NET, и останется от C++ в результате несколько жалких процентов от всех программистов состоящих в основном из юниксоидов и Алесандресков. Ну пусть это произойдёт не за два года, а за пять, разница не большая, в любом случае дни C++ сочтены.

ЗЫ. Между прочим, поняв это в своё время, я провёл несколько бессонных ночей, нервно покуривая на кухне, запивая горе самогонкой и поминутно утирая скупую слезу сиплюсплюсника. Вот так вот
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 19:27
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Десять! Я такого перла, Влад, от тебя не ожидал!


Что десять? Ты о чем?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 19:28
Оценка:
Здравствуйте, mihailik, Вы писали:

VD>>Согласись, что шаблоны и средства подключения реализаций все же нужны.

M>Не, генерики и баста. Хорошенько понемножку.
M>Слишком большая гибкость только вредит. Ртуть вон гибче глины, зато из неё фигурки не лепятся.

Дык шаблонами подключение реализации впринципе решается. Только как всегда через ухо.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Будущее C#
От: IT Россия linq2db.com
Дата: 03.07.03 19:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Я тут подумал на С++ можно так Найдите 10 отличий


Молодец, что-то в этом духе я и ожидал Отличий не 10, но парочка найдётся. Во-первых, зачем же так в наглую передавать список полей, во-вторых, на макросах это даже проще, а в-третьих, я легко могут усложнить задачу и ввести в неё атрибуты и вообще перевести разговор на AOP

WH>Даже короче вышло. И assembly_name указывать не надо.


А как быть если объявление класса находится в другой, возможно ещё даже не подгруженной, сборке?
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Будущее C#
От: WolfHound  
Дата: 03.07.03 19:33
Оценка:
Здравствуйте, IT, Вы писали:

IT>ЗЫ. Между прочим, поняв это в своё время, я провёл несколько бессонных ночей, нервно покуривая на кухне, запивая горе самогонкой и поминутно утирая скупую слезу сиплюсплюсника. Вот так вот

Вот оветь на такой вопрос? Если С++ почти мертв как ты утверждаешь то почему МС вкладывает в развитие С++ компилятора кучу денег? Я не могу оценить изменения фреймворка но могу оценить изменения в С++ компиляторе и у меня такой чувство что вложения в него измеряются мегабаксами как минимум. Мало того что он понимает все что мне приходит в голову, компилирует boost лучше всех даже comeau сделал так он еще и не глючит.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: Будущее C#
От: WolfHound  
Дата: 03.07.03 20:00
Оценка:
Здравствуйте, IT, Вы писали:

IT>Молодец, что-то в этом духе я и ожидал Отличий не 10, но парочка найдётся.


IT>Во-первых, зачем же так в наглую передавать список полей,
По моему нормально, а как иначе?

IT>во-вторых, на макросах это даже проще,

Чесно говоря не вижу куда их можно прикрутить

IT>а в-третьих, я легко могут усложнить задачу и ввести в неё атрибуты и вообще перевести разговор на AOP

А я могу вспомнить о ручных менеджерах памяти, вычислениях времени компиляции, генерации кучи кода... У каждой среды свои плюсы и минусы. Правда тут есть некоторые товарищи (причем по обе стороны бурекад) которые и слушать о плюсах другой среды не хотят.

IT>А как быть если объявление класса находится в другой, возможно ещё даже не подгруженной, сборке?

В моей системе все грузится в самом начале (хотя возможно подгрузить длл и во время работы) и все классы попадают в одно пространство имен учитывая довольно жосткие правила именования конфликтов имен не происходит, но в случае чего вылетит исключение.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 20:18
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Хорошо, пускай о терминах, но это ты его начал.


Я? Я сказал, что любой С++ код можно скомплировать как менеджед, а ты докопался.

AVK>Тем не менее, возвращаясь к исходному спору, если мы хотим чтобы компоненты, писанные на МС++ использовались в других языках дотнета, то вынужденны лишиться возможности использовать некоторый набор фич.


Но это же не отменяет возможности компилировать старые приложения в MSIL и делать для них обертки в виде __gc-классов?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 20:18
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Они сознательно ограничивали его рассмотрение.


Ага. Вот только их аргументы (вернее его) выглядят как дешевые отмазки.

ГВ> И ИМХО, совершенно разумно, поскольку необходимость "самоанализа" (он же — rtti) в сущности, является ошибкой дизайна.


Ну, что я могу тебе сказать. По-моему, ты ошибаешся.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 20:18
Оценка:
K_O>На самом деле, RTTI нужен не столько программистам, пишущим на C++ (хотя есть некоторые задачи, где RTTI ну оччень бы пригодился), сколько самому компилятору С++. Если бы в объектные файлы помещалась информация о типах, то компилятору при компиляции каждого cpp-файла не приходилось бы обрабатывать сотни килобайт исходного кода, которые вставляются через #include.

Именно. Но ты все же однобоко смотришь на это. Тут есть еще один фактор. Компонентность. Языки типа Дельфи, Явы и Шарпа не только пораждают удобные объектники. Эти объектники в следствии наличия метаданных являются еще и контейнерами компоненотов которые можно использовать в рантайме и дизайнтайме. Вон посмотри на Билдер. Ребята из Борланда попытались приделать к С++ дизантайм и компоненты. В итоге получилась очень громоздкая и глючная реализаци. Причем без изменения языка так и не удалось обойтись. А ведь бидлер в отношении компонентности и дизайнтайма имеет все те же ограничения, что и Дельфи. МС пошли дальше и на сегодня МС++ — идеал компонентного С++.

K_O>Именно поэтому скорость компиляции программ на Delphi и Java на много порядков быстрее, чем на C++. Про скорость компиляции С# не скажу — не пришлось еще с ним плотно познакомится, но подозреваю, что тоже намного быстрее, чем С++.


Шарп компилирует исходники даже быстрее чем дельфи. Особенно кода кода много.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 20:18
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну, в общем — да, это было бы поудобней в чём-то, чем исходники, но тогда объектники (и библиотеки, кстати, тоже!) тащили бы груду лишней информации о тех же шаблонах. Хорошо это или плохо... трудно сказать. Мне, по крайней мере.


Да не так уж много эта информация занимает. Давай взгляенем на детища МС. На С++-овый и на Шарп-овый компиляторы. Их С++ в среднего размерах проектов генерирует гигабайты отладочной информации. А компилятор Шарпа несколько килобайт. Причем любая длл-ка Шарпа несет в себе полное описание реализованных в ней классов и кода.

МС обещает и шаблоны прикрутить. Причем они так же будут доступны на рантайме.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.