Re[18]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 13:32
Оценка: 104 (6) +1 -2
Здравствуйте, Геннадий Васильев, Вы писали:

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


Если ошибочный дизайн приводит к более простому и ясному коду, чем правильный, то пора пересмотреть методы оценки дизайна.
Re[14]: Будущее C#
От: IT Россия linq2db.com
Дата: 01.07.03 20:20
Оценка: 12 (1) +1 -1 :))) :))
Здравствуйте, WolfHound, Вы писали:

WH>Короче пока вы с Владом не прочитаете Александреску я с вами на тему C++ vs C# разговаривать не буду ибо ваши знания о С++ очень поверхтносны.


Неужели один прочитанный учебник может сделать из вчерашнего студента закоренелого профи?
Определённо надо будет почитать Александреску... наверное и в резюме себе потом запишу — "Читал Александреску".
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Будущее C#
От: IT Россия linq2db.com
Дата: 02.07.03 15:20
Оценка: 24 (4) +1
Здравствуйте, WolfHound, Вы писали:

WH>Былабы возможность,а применение найдется. Нука изобрази на C#


[skip]

Мда... печальное зрелище... без пузыря не разберёшся.
А вот ответь мне, мил человек, сможешь ли ты на C++ (не MC++) сделать из чего-то типа первого примера, что-то типа второго?

Голый ADO.NET:

public class CategoryInfo
{
    public int    CategoryID;
    public string CategoryName;
    public int    Count;
}

static ArrayList GetCategories(int min)
{
    string connectionString =
        "Server=.;Database=Northwind;Integrated Security=SSPI";
    string commandText = @"
        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";

    using (SqlConnection con = new SqlConnection(connectionString))
    {
        con.Open();

        using (SqlCommand cmd = new SqlCommand(commandText, con))
        {
            cmd.Parameters.Add("@min", min);

            using (SqlDataReader rd = cmd.ExecuteReader())
            {
                ArrayList al = new ArrayList();

                while (rd.Read())
                {
                    CategoryInfo ci = new CategoryInfo();

                    ci.CategoryID   = Convert.ToInt32 (rd["CategoryID"]);
                    ci.CategoryName = Convert.ToString(rd["CategoryName"]);
                    ci.Count        = Convert.ToInt32 (rd["Count"]);

                    al.Add(ci);
                }

                return al;
            }
        }
    }
}

А теперь добавим немного рефлекшина внутрь и получим:

public class CategoryInfo
{
    public int    CategoryID;
    public string CategoryName;
    public int    Count;
}

static ArrayList GetCategories(int min)
{
    using (DbManager db = DbManager.Open())
    {
        return db.ExecuteList(
            typeof(CategoryInfo), @"
            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",
            db.Parameter("@min", min));
    }
}

В твоём примере трудно понять вообще для чего он нужен, в моём надеюсь тебе не просто будет всё понятно, а даже тривиально с первого взгляда. И прибегать к услугам Александреску чтобы понять этот код не надо.

Я конечно понимаю, что поступаю не совсем честно, в C++ нет нормального RTTI и видимо никогда не будет, но я хочу сказать, что в 99.99% задач твои знания шаблонов вряд ли пригодятся. А если бы ты и попытался их где-либо применить, то работая, к примеру, в моей команде, я тебе просто элементарно запретил бы это делать. Хотя на досуге мы могли об этом с увлечением поболтать. А вот упростить приведённую мной стандартную задачу до вызова одной функции у тебя на C++ не получится, сколько не читай Александреску. И проблема здесь, как тебе уже говорили, в ограниченности самого гибкого на свете языка C++, который следовал модным тенденциям и потребностям аж 20 лет назад, а сейчас просто элементарно устарел.

Кто-то из умных сказал — "Усложнять просто, упрощать сложно". Не спорю, почитав Александреску (вполне допускаю, что это весьма захватывающий акшин), можно легко научиться строить трёх-этажные шаблоны, но, ошибкой было бы думать (c) Ленин, что это сделает твои программы лучше, качественнее, сопровождабельнее. Это сделает их как раз только запутаннее и непонятнее и будем им грошь цена, после того как какой-нибудь студент, идущий за тобой, не поняв что там происходит, просто перепишет твой код на нормальный понятный язык. И будет, между прочим, прав.

Для меня эталоном программы уже давно является не виртуозное владение указателями, свитчами и шаблонами, а ясный и понятный, хорошо оформленный и откомментированный код. Впрочем, может это я просто старею...
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Будущее C#
От: alexkro  
Дата: 04.07.03 07:57
Оценка: 60 (4)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, alexkro, Вы писали:


A>>Спорный вопрос. C# generics ничего общего с шаблонами не имеют.


VD>Да? Ты хоть гуру CLI-gyro (проект МС-ресерча добавляющий generics к SSCLI)? Один к одному шаблоны. Только слегка упрощенные, ну, и идея шаблонов развита так что шаблонными можно делать даже интерфейсы.


OK. Будем основываться на следующей статье: http://www.gotdotnet.com/team/csharp/learn/Future/VCS%20Language%20Changes.aspx. Если есть какие-то различия с SSCLI, скажи. Но основная идея заключается в том, что generics — это не просто слегка упрощенные шаблоны, а ОЧЕНЬ упрощенные.

1) Generic параметр обладает только методами класса System::Object. Возмем следующий класс:

public class Accumulator< T > {
    private T val_;
    public void Add( T x ) {
        val_ = val_ + x;  //  oops!  what +?
    }
}


Приходится обходить это ограничение с помощью constraints:

public interface Addable< T > {
    void Add( T x, T y );
}

public class Accumulator< T, AddT > where AddT : Addable< T > {
    private T val_;
    public void Add( T x ) {
        AddT addt = new AddT();        //  even this is impossible
        val_ = addt.AddT( val_, x );
    }
}

public class AddableInt : Addable< int > {
    public void Add( int x, int y ) { return x + y; }
}

//  now I can do this
Accumulator< int, AddableInt > acc;


Но даже такую простую вещь трудно реализовать с помощью generics! Из-за невозможности вызова new для generic типа.

Хотя и это можно обойти, но так (compromises, compromises):

public class Accumulator< T, AddT > where AddT : Addable< T > {
    private T val_;
    private AddT addt_;
    public Accumulator( AddT a ) { addt_ = a; }    //  come on!
    public void Add( T x ) {
        val_ = addt_.Add( val_, x );        //  virtual function call!
    }
}


Но тогда, где же приемущество перед следующим, более простым вариантом:

public class Accumulator< T > {
    private T val_;
    private Addable< T > addt_;
    //  ...
}


А на C++ легко и элегантно:

template < typename T >
class Accumulator
{
    T val_;
public:    Accumulator< T > & operator+=( T const & x ) {
        val_ = val_ + x;    //  even val_ += x;
                    //  this call will be resolved at compile time
        return * this;
    }
};


Ta da!

2) Generics имеют constraints. Зачем, спрашивается? А вследствие (1).

Опять же, в C++ template параметры обычно должны удовлетворять каким-либо требованиям (requirements (per Standard)). В C# — это constraints, базирующиеся на интерфейсах. Например, возьмем такое требование, как "сравнимые" для класса Derived (:public Base). В C++ это выразится любым из следующих методов:

bool operator<( Derived const & a, Derived const & b );
или так:
bool operator<( Derived a, Derived b );
или так:
bool operator<( Base & a, Base & b );

Пойди, попробуй выразить это через интерфейсы.

3) Нет typedef, значит затрудненно написание обобщенных алгоритмов таких, как (C++):

template< typename Iter >
Iter find( Iter begin, Iter end
    , typename Iter::value_type const & what
        // this is impossible in C# with generics,
        // because value_type is a typedef
    ) {
    for ( Iter it = begin; it != end; ++it )
        if ( * it == what )
            break;
    return it;
}

//  usage
vector< int > v;
vector< int >::iterator pos = find( v.begin(), v.end(), 5 );


Черт! Что-же делать? Ага, вот так:

public class Finder< EnumT, ElemT, CompT > where
    EnumT : IEnumerator< ElemT >
    , CompT : IComparable< ElemT >
{
    public Finder( CompT comp ) { comp_ = comp; }
    public EnumT Find( EnumT it, ElemT x ) {
        while ( it.MoveNext() )
            if ( ! comp_.CompareTo( it.Current, x ) )
                break;
        return it;
    }
}

//  usage
class CompareInt : IComparable< int >
{
    public int CompareTo( int x, int y ) { return x - y; }
}

//  Enumerator< int > should be already defined

ArrayList< int > v;
Finder< Enumerator< int >, int, CompareInt > find = new Finder < Enumerator< int >, int, CompareInt >( new CompareInt() );
Enumerator< int > pos = find.Find( v.GetEnumerator(), 5 );



И результат: в C# в три раза больше generic параметров при меньшей функциональности и гораздо более неудобном использовании. К тому же MoveNext, Current и CompareTo — это опять-же виртуальные вызовы.


A>> Пока что я для них одно применение вижу — типизированные контейнеры.


VD>Почему только контейнеры? Любые алгоритмы толерантные к типам можно будет выражать с их помощью. Хотя бесспорно, что коллекции — это самое важное место где можно применять шаблоны.


Алгоритмы, типа того, что наверху. После написания второго такого, C++ покажется милым и хорошим .

A>> Никакой новой парадигмы программирования они не откроют.


VD>А новой парадигмы и не нужно. Нужно расширение дотнета позволяющее писать более эффективные и безопастные приложения. Парадигмы же достаточно и той что есть.


Очень уж эффективным не получится. Остаются виртуальные вызовы, к которым приводит наличие constraints.

A>> Даже такая простая вещь как policy-based programming не станет возможна в C#.


VD>Что ты под этим понимаешь?


http://www.google.com/search?q=policy-based+programming&amp;hl=en&amp;lr=&amp;ie=UTF-8&amp;oe=UTF-8&amp;start=10&amp;sa=N.
Кстати, я наврал, что это невозможно в C#. Конечно, возможно. Недоступена будет лишь простота и эффективность (по скорости и использованию), с которой это делается в C++.
Re: Будущее C# - вот это флейм!!!!!!!
От: LaptevVV Россия  
Дата: 14.07.03 14:42
Оценка: 3 (1) :)))
Цитата из письма моего друга, активно действующего программиста, руководителя лаборатории и нескольких проектов. Заранее прошу извинения за эмоциональность монго друга, но видимо, у него сильно накипело!

Мы пишем все на строгом ANSI (старом) Си, и всячески пресекаем бл@@@во ++.
Потому что оно и есть бл@@@во, а не обеспечение безопасности.
Сам посуди — написать на чистом Си объектно ориентированный текст — нет
проблем.
В чем тут может дать выигрыш ++ — я не понимаю. Особенно если учесть, что
написание программы составляет 0.05 % от времени разработки.
В чем экономия? Где деньги, Зин?
Разве что для написания действующих (как бы) прототипов — ну и что?
От прототипа до продукта — ср@ть и ср@ть!!!!
Мы применяем компилятор Борланд 3.1 и 4.5, еще MS 4.1. Проверены.
Лицензий не надо.
Я лично ЗАПРЕТИЛ применение Борланда 5 и выше, когда исследовал
несколько объектных файлов. На х@@. Я хочу спать спокойно.
Про # — не знаю. Это финт сына самой популяроной женщины в мире.
И от этого финта она станет еще популярней. Зачем???????
Ты хоть можешь мне пояснить — хоть три причины — что именно я получу
при переходе на эту пое@@@нь?????
Я вижу единственный козырь у них — новые платформы будут поддержаны
только этим компилятором. Х@й в нюх! Фортран жил, жив и будет жить!
А почему? Потому, что много его, написано много. И на Си написано много.
Так что пусть не вые@@@@@@@ся. Но тема очччччень забавная! Пиши!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[17]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 13:28
Оценка: +4
Здравствуйте, VladD2, Вы писали:

[...]

VD>Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.


Они сознательно ограничивали его рассмотрение. И ИМХО, совершенно разумно, поскольку необходимость "самоанализа" (он же — rtti) в сущности, является ошибкой дизайна.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
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[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 06:47
Оценка: -2 :))
Здравствуйте, WolfHound, Вы писали:

WH>

WH>Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.

WH>Scott Meyers

WH>

WH>Что нового можно сказать о языке С++, Оказывается, очень много.

WH>John Vlissides

WH>

WH>Современное проектирование на С++ — важная книга. По существу, "обобщенные шаблоны", или "шаблонные шаблоны", в ней представлены как новый мощный метод гибкого проектирования на языке С++ — новый способ комбинирования шаблонных классов и шаблонов поектирования, о котором мы и мечтать не могли. Если вы проектируете и программируете на языке С++, вам следует прочесть эту книгу. Очень рекомендую...

WH>Herb Sutter

Можно продолжить?

Кофе Гранд лучший кофе ...
Какой то известный актер советского кино

Вода Архыз ...
Армен Джигарханян

Циркониевые браслеты ...

Сок Чемпион ...

Продолжать?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[3]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 21:10
Оценка: :))) :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Или мы считаем по количеству рюшечек, которые мышкой можно перетянуть на форму?


А ты сомневался? Причем все рюшечки обязанны быть халявными. Ну, не разговаривать же о компонентах вроде тех же тулбаров от Infragistics? Пусть они в несколько раз лучше чем то что есть в дельфи, но ведь их нужно устанавливать отдельно!

Кстати, какое все это отнешение к дотнету имеет я не пойму. Тот же борланд уже склепал среду для Шарпа и срубает бабки продавая в месте с ней компоненты от компонент-ван. Там менюх те что надо.

AVK>А где собственно аргументы подразумеваемому неудобству компонентной модели дотнета?


Не. Ну ты тупой! Ты ламер думешь, что компонентная модель — это некая идеология построения и взаимодействия с компонентами. А — это грамотное наклепывание и складывание по закладкам обертон над МС-ными контролами из момон-контролс.

AVK>

вроде бы сильно защищены (ага, так я и поверил)

AVK>Аргументы?

Где? Да и зачем?

AVK>Просто ложь. Фреймворк работает и под 98 и под МЕ. Далее куча выводов, основанных на этой лжи идет в корзину.


Ну, опять ты обежаешь заслуженных гуру. Что такое фрэймворк? Как его установить? Не, не. Не надо про какие-то инсталляторы на 20 мег. Фрэймвор это же VS.NET! А она не работает. Значит и приложения создать и запустить нельзя.

AVK>Ну что тут можно сказать? Абсолютно неаргументированные вопли.


Ты чё? Какие аргумнты. Это же крик души? Ну, в смысле призыв душить.

AVK>

На данный момент С# программисту абсолютно не нужен. В нём нет ничего такого, ради чего можно было бы программировать на этом языке.


AVK>Собственно ни одного аргумента мы так и не услышали. одни эмоции и наглая ложь.


Как? В Шарпе нет банальных бегинов с эндом! Как без этого жить? А это обявление переменных внутри кода! Это же форменный изврат!

AVK>

Корпорацию Borland всегда ругали за то, что программы, скомпилированные на нём, получаются большого размера. Я чисто для примера создал пустой проект с помощью MFC Wizard со статической компиляцией, когда всё необходимое встраивается в один exe файл. Когда я скомпилировал проект (напоминаю, он был пустым), то на выходе получил запускной файл размером чуть более 2 метров. Это не шутка. Я чуть ли не упал со стула, когда увидел такие размеры


AVK>Скомпилял бы тогда уж и минимальный проект на шарпе. Наверное тоже упал бы со стула (3К, если мне не изменяет память)


Не, ты уже переходишь все границы. MFC является главным средством доказательства ущербнсоти дотнета. А ты пытаешся опошлить святое!

Причем я бы еще понял, бы если ты издевался над каким то ламером. Но этот парень и в правду истенный талант. Так как у меня как я не крутил так и не удалось создать (визардом) на MFC исполняемый файл размером больше 989 килобайт. Возможно моя ошибка была в том, что я компилировался в релизе, но не в этом суть... Ты замхнулся на незыблимые факты! Ты бы еще преплел, что ATL-проект можно довести до размера в 3 килобайта вообще без внешних длл-ей. Это же не честно!
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будущее C# - вот это флейм!!!!!!!
От: IT Россия linq2db.com
Дата: 15.07.03 14:25
Оценка: 22 (1) +1 :)
Здравствуйте, LaptevVV, Вы писали:

LVV>Если Вы следите за РАЗНЫМИ областями информационных технологий, то должны знать так называемое АВТОМАТНОЕ программирование. При правильном его применении 99,95% работы ДЕЙСТВИТЕЛЬНО делается до кодирования. Более того, кодирование можно автоматизировать по автоматной модели. Почитайте ШАЛЫТО — апологета данной технологии. У мего друга в конторе так и принято. Более того, чем больше программер кодит, тем подозрительнее относятся к его квалификации. По из понятиям ХОРОШИЙ программист делает свою часть "с первого предъявления" — то есть, после автономной отладки и тестирования система в комплексе СРАЗУ начинает работать. Ошибки — это описки по невнимательности, которые быстро выявляются и исправляются.


Видимо твой друг работает в какой-то очень узкой, годами устоявшейся области с очень редко изменяющимися требованиями и отработанными технологиями. Думаю, что в таком случае можно вообще состряпать какую-нибудь софтинку и исключить труд программиста совсем. Но видимо на C это сделать не так просто

LVV>Вот такой подход к программированию. Новые технологии сами по себе абсолютно не нужны, если они не приводят к резкому увеличению производительности труда. Поэтому старая, но НАДЕЖНО и БЫСТРО работающая технология изготовления ПО ЛУЧШЕ новой, но недоделанной.


"Лучшее — враг хорошего" как любил поговаривать мой бывший шеф, пока мы не потеряли двух жирных нефтяных заказчиков, у которых было требование — Windows (мы тогда под DOS сидели).

LVV>Производство ПО — это не столько программирование, сколько производство.


Именно. И как в любом производстве качество и стоимость результата производства сильно зависит от средств производства. Как любил поговоривать мой другой бывший (ещё бывшее) шеф "Какое-либо свойство продукта не может превышать на порядок соответствующего свойства, заложенного в средство, на котором этот продукт изготовлен". Твой друг занимается выпиливанием фигурок из фанерки лобзиком для индивидуального клиента? Молодец, надеюсь, это на 100% устраивает его заказчиков. Но только не надо переносить такие технологии на производство автомобилей или массового ширпотреба в условиях постоянно меняющейся конъюнктуры рынка.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.03 15:13
Оценка: 1 (1) -2
Здравствуйте, <Аноним>, Вы писали:

А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?


Не не реально. Буст — это затычка проблем языка. В Шарпе и так все неплохо работает. Шаблоны конечно приведут к появлению более безопастных и производительных аналогов существующих классов не не более.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.06.03 06:43
Оценка: 1 (1) :))
Здравствуйте, WolfHound, Вы писали:

_>>Удивляюсь, как можно приводить абсолютно чудовищный код и утверждать, что это круто.

WH>Я это привел к тому что: Делегаты в .NET не позволяют цеплять функции с другими сигнатурами даже если существует не явное приведение,

И это правильно. Типобезопасность рулит

WH>нельзя из делегата вернуть значение,


Кто сказал? А я не знал, возвращал. Теперь буду осторожнее.
... << RSDN@Home 1.1 alpha 1 >>
AVK Blog
Re[20]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.07.03 07:40
Оценка: 22 (2)
Здравствуйте, WolfHound, Вы писали:

PE>>Значит у тебя аргумент — Александруску и своей головой думать не надо ?

WH>Хочешь знать что можно сделать на шаблонах?
WH>Без проблем попробуй разберись
Автор: WolfHound
Дата: 22.06.03
. Хотя для меня и тех кто освоил идеи Александреску проблем не составит.

WH>Можно почитать эти ветки По мотивам SWL
Автор: WolfHound
Дата: 27.04.03
, Виртуальные конструкторы 2
Автор: WolfHound
Дата: 09.06.03
, Быстрое сохраниние/восстановление членов класса
Автор: Keeper_andrew
Дата: 15.04.03
.



Несколько гвоздей в гроб подхода Александруску.

1. Сам факт, что книга такого масштаба появилась только сейчас говорит о том, что C++ многогранен.
2. Этот же факт говорит о том, что мало кто понимает всю мощь этого языка.
3. Это же означает, что не только новичек, но и середнячек не потянет все рулезы концентрированного С++.
Такая техника сродни уровню гросстмейстера мирового класса в шахматах — их очень мало.
4. Я не вижу отражения существующих тенденций — компонентное программирование и тд.
__declspec(__dllexport) — это далеко не то, что надо сейчас.

В тех примерах, что ты привел, много интересного. Но все те же вещи можно сделать настолько просто, что любой новичек сразу подхватит проект. В примере про виртуальные конструкторы ты(или не ты) изобрел моникеры и интерфейсы, которые есть в COM, которые есть в других средах под такими же или другими именами, например локаторы.

Я не вижу реальной неоходимости внедрять это. Невозможно заставить людей выучить все.
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.03 18:42
Оценка: 12 (1) +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Доказательство наличия оверхеда

ГВ>Время исполнения вызова (T) при использовании rtti: Trtti = Ta + Tc, где Ta — время анализа полученного типа, Tc — время собственно вызова.
ГВ>Время исполнения вызова (T) без использовании rtti, а именно — compile-time type information для статической типизации, ctti: Tctti = Tc, где Tc — время собственно вызова.

ГВ>Вывод: Trtti > Tctti


И какое отношение этот вывод имеет к теме? Задачи выполняемые в рантайме, при условии правильного проектирования не могут быть выполнены в компайлтайме. Следователно "Trtti > Tctti" в этом случае пустое сотрясение воздуха.

По отношению к требовательным к скорости участкам кода конечно любая интерпретация — это плохо. Но... 1) в большем коиличестве случаев время затрачивамое на интепретацию не критично (ведь относительно понятий о времени людей эта интерпретация происходит очень быстно), 2) на базе информации о типах можно создавать код (компоненты) и использовать его. Причем код можно создавать как JIT, так и в процессе компиляции.

Таким образом, можно сделать вывод, что при безкрамотном использовании информации о типах можно получить ощутимое снижение производительности. Но при грамотном, все бедет в пордке. Так что меняй катигоричность утверждений. Вводи слово "может".

ГВ>Доказательство снижения надёжности композиции


ГВ>Надёжность композиции — вероятность корректного сочетания типов данных во время выполнения программы.


Не детерминированы "композиция" и "корректное сочетание типов". Да и вообще утверждение выглядит спорно. Так что эго мы отбрасывам до уточнения.

ГВ>Оценим надёжность композиции на основе оценки надёжности выполнения вызова метода некоторого интерфейса.


Дальще идут какие-то цыфры взятые с потолка и замалчивание реальной правды. Так что я пропущу все эти бессмысленные рассуждения и отвечу просто на вывод...

ГВ>Вывод: D > 1, т.е., использование ctti обеспечивает бОльшую надёжность композиции, чем использование rtti.

ГВ>Вот я и доказываю свою правоту.

Попробуем не пудрить себе и другим мозги, а проанализировать, что же конкретно делается с помощью информации о типах и как это можно сделать без нее.

Случай 1. Мы имеем некие компоненты полная информация о которых нам не доступна в компайлтайме. При наличии полноценного TypeInfo (ти), мы можем написать универсальный механизм позволяющий решить поставленную задачу. Без оного мы вынуждены изобрести не универсальный механизм (или универсальный, но это еще сложнее [по закону сохранения энергии]).

Посмотрим минусы прдхода с ти. Собственно их нет. Вернее они могли бы быть если бы метаинформация не позволяла бы нам заложить всю необходимую информацию. Но так как мы предпологаем качественную реализацию ти, то проблем нет. Заметим, что подсистема ти написанна заведомо высококвалифицированными людьми и отлажена (тысячами людей). Заметим так что что нам не потребовалось создавать собственные механизмы и мы смогли больше времени потратить на прикладные алгоритмы, а стало быть лучше их отладить.

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

Таким образом мы получаем:
1. Велосипедостроение, так как все равно от изобретения своих метаданных никуда не деться.
2. Менее надежный код, так как его стало намного больше, а время на написание и отладку фиксированно.
3. Надежность еще больше уменьшается в следствии того, что рантайм проверки или попросту не делаются, или их создание еще больше усложняет и затягивает написание кода.
4. Резко возврастает требования к квалификации и усилиям программиста, так как увеличивается объем работ и их сложность.

Короче, в случае 1 твои доводы являются чистейшей неправдой.

Случай 2. В условиях задачи есть четкое формальное описание структур данных и алгоритмов их обработки. Эта информация может быть описана в некой форме (например матрицы), но информация может часто меняться, объем информации очень велик, или информация еще не доконца определена в момент кодирования. Решаемая задача может быть выполна методом тупого кодирования. При этом решение задачи можно облегчтить макросами и шаблонами. Но задача так же решается путем создания интерпретатора (или кодогенератора) анализирующего ти.

Если задача легко формализуется шаблонами/макросами, то спору нет. Их применение будет лучшим выбором. Но если создаваемые алгоритмы тяжело описать статически, или просто плохо лажатся на шаблоны, то решение на базе кодогенератора (полноценного) или интерпретатора становится менее трудаемким, и более простым в реализации/откладке/поддержке.

Хорошим примеро такой задачи может являться любая динамическая система коничных автоматов. Под динамически имеется в виду, что конечный автомат неизвестен в полном объеме на момент компиляции. Примером такой машины может быть машина регулярных варжений. Хотя она имеет небольшое отношение к метаданным, но тем не менее аталогичные задачи где можно будет использовать метаданные найти не сложно. Главное, на сей момент для нас доказать, что работа в компайл-тайме может привести к меньшей надежности.

Итак, такая машина может быть описана как набор методов, атрибутов и (возможно) внешних данных. В случае кодирования без информации о типах, нам придется все алогоритмы жестко кодировать (хардкодить). Объем кода будет прямо порпрционален сложности автомата. Любой нюанс будет умножать сложность системы. Скорее всего программист отчаяшись захардкодить такую сложную систему (ведь она может и измениться!) попросту делает интерпретатор и опять же начинает клепать для него метаданные.

В случае же с генерацией кода нужно лишь написать систему которая будет анализировать метаданные и генерировать специализированный код описывающий требуемую машину.

Случай 3. Задача легко решается банальным кодированием, но зада очень тепичная и встречающаяся нарачито часто. Заранее известно, что скорость работы алгоритма основанного на ти будет намного выше требуемой. Примерами могут являються многие типичные действия хорошо поддающиеся декларативному описанию.

При решении задачи лобовым кодированием код засоряется ничего не значацими подробностями и становится плохо читаемым.

При решении задаче средствами макросов и шаблонов, получается упростить внешний вид кода, но:
1. Его количество все же больше чем при чисто декларативном методе.
2. Код получается разнесенным по разным местам программы. Иногда удается сконцентрировать код в одном месте. Но не всегда.
3. Часто в следствии проблем с реализацией (что греха таить, гибкость шаблонов и макросов в области магии не беспредельна) часть кода скрывается от глаз программиста (или усложняется и запутывается) настолько сильно, что появляются проблемы с отладкой кода созданного в следствии такого дизайна.
4. Резко усложняется динамическое добавление нужных функций (это или вообще не воможно или появляется громоздкий АПИ).

За счет проверки компилятора уменьшается вероятность сделать ошибку типа опечатки. Но соложность реализации востанавливает паритет. А меньшая декларативность даже увеличивает вероятность рантайм-ошибок.

Решение на базе ти позволяет достить реальной декларативности. Код анализируещий метаданные является обычным. Его можно легко читать и отлаживать. В виду того, что ти доступно даже внешним модулям появляется возможность добавлять такие описания динамически (из модулей о которых еще не известрно в рантайме). Причем никаких особо сложных действий со стороны программиста делать не нужно все универсально.

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

ГВ>>>Ну как, понятно объяснил? Или стрелочки логических связей нарисовать?

VD>>Такую позицию не стоило и озвучивать. Она ровным чсетом никому ничего не дает.

ГВ>Не надо за всех расписываться.


Конструктива в ней небыло.

ГВ> Дискуссия на самом деле небезынтересная получается.


Для меня уже нет. Я снова вижу людей из последих сил защищающих свой стрый уклад жизни. Сказки про то, что рантайм — это зло не состоятельны. Их опровергает жизнь. Ну, а наезды на метоинформацию вообще смешны. И при всем при этом против постулата, что если задачу аналогичко легко решить как средствами кодирования, так и анализом метаинформации, то лучше применить кодирование, никто не спорит.

Короче, надоело.

VD>>Твои рассуждения противоречат логике. Любой дизайн тем лучше чем проще и эффективнее он решает поставленную задачу имеющимися средствами. А понятие "криво" является сугубо отнсительным. Так что если решение единственное, то кривым его называть бессмысленно.


ГВ>Почему?


Покачену. Вот у нас есть такой поц Paul Poloziouk. Он на все подряд посты лепит минусы. Ему все криво. Это из этой же серии.

ГВ> Представь, например, что некто свалился в лужу дерьма. Измазался относительно слабо (во чудо-то!). Выбираться можно только вброд, но измазаться придётся ещё больше. Единственное это решение? Скорее всего — да. Будет он материться по этому поводу? Будет, я думаю.


Оно будет единственно верным. Так как другое будет остаться в луже этого дерьма. Ты же предлагаешь именно это и дель. Оставать в луже дерьма потому, что идти в брод криво.

Заметь я тебя на аналогии не подбивал.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Будущее C#
От: WolfHound  
Дата: 01.07.03 08:06
Оценка: +1 :)
Здравствуйте, AndrewVK, Вы писали:

AVK>А как его должны дооценивать?

Короче пока вы с Владом не прочитаете Александреску я с вами на тему C++ vs C# разговаривать не буду ибо ваши знания о С++ очень поверхтносны.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.07.03 09:09
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

AVK>>А как его должны дооценивать?

WH>Короче пока вы с Владом не прочитаете Александреску я с вами на тему C++ vs C# разговаривать не буду ибо ваши знания о С++ очень поверхтносны.

Расскажи неучам, объясни на пальцах.
Re[16]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.07.03 15:30
Оценка: +1 -1
Здравствуйте, WolfHound, Вы писали:

PE>>Расскажи неучам, объясни на пальцах.

WH>Я уже много раз говорил про книгу. Там написано очень подробно и куда длоходчевей чем я смогу расказать.

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

Там подробнее == а мой папа лучше знает и тд и тд.
Это демагогия.
Re[14]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 18:48
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

WH>А тебе не кажется что если бы разговор шол о просто коллекциях то Мейерс бы не свалился со стула?


А мне все равно. Короче, мой вопрос остался без ответа.

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


Еще раз настоятельно рекомендую не пытаться оценивать мои знания. Ты попросту неимеешь на это ни права, ни авторитета. И выглядит это как тухлый наезд.

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

WH>Ну если только в дизайне программы, а где не так в этом случае?

Попробуй членораздельно сформулировать вопрос.

VD>>Шарп же полная противоположенность. Приятно было бы если Шарп стал ближе к С++ по возможностям. Но пусть это будет не в ущерб простотое и удобству.

WH>К сожалению это не возможно. Либо возможности либо простота. Также я не спорю что для некоторых задачь шарп лучше подходит я сам настоял не переходе нашей конторы на шарп ибо для нашей АСУТП самое то.

Это не невозможно. Это сложно. Нужно иметь обостренное чувство меры и огромный опыт. Надеюсь, что у ребят и МС эти качества есть.

WH>Однако если нужно выжать из машины все что возможно то у шарпа против плюсов нет шансов.


Как сказать. Сам язык не может определять производительность. Производительность кода зависит от оптимизаций и качества транслятора. Нетрудно найти реализациции С++ которые будут порождать код более медленный чем компилятор Шарпа (от МС).

К тому же, тормоза в реальных приложениях — это в 99% случаев не проблемы низкой скорости кода, а непаравильно выбранные алогоритмы.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 13:20
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Я тебя не удевлю если скажу, что все это можно сделать и на Шарпе (т.е. без шаблонов)? Причем решения будут даже более красивыми.


Затыкание дырок C#? Забавно.

VD>Так что твои примеры скорее являются доказательством высказанной мною мысли, о том что 90% использования шаблонов в С++ является затыканием дырок языка. И вызваны прощетами в языке.


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

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

WH>По моему нормально, а как иначе?

А побраузить структуру слабо? Ну там почитать какие у неё поля, их типы, имена и всё такое.

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

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

Не надо их никуда прикручивать. Макросы — это зло, так сказал Страуструп, но местами они могут выполнять свою работу даже лучше шаблонов.

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

WH>А я могу вспомнить о ручных менеджерах памяти, вычислениях времени компиляции, генерации кучи кода... У каждой среды свои плюсы и минусы.

А зачем это всё? Я привёл тебе простейший пример, который позволяет свести к минимуму программирование Data Access Layer, сделать это наглядным и сопровождабельным. Добавляя в эту схему, например, атрибуты я могу сделать элементарным управление маппингом, отображением данных из БД на термины моей программы. Т.е. я всё больше и больше упрощаю процесс разработки. Твой же ручной менеджер памяти скорее всего будет являтся какой-нибудь затычкой к неправильному дизайну

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


Скорее всего они уже знают все плюсы и минусы. Самое печальное, что твоя позиция изначально проигрышная, ты споришь не с представителями вражеского лагеря как тебе кажется, а с теми кто уже давно прошёл твой путь, кто так же как ты сейчас когда-то восхищался возможностями языка, кто честно заработал свои шрамы в боях C++ vs Паскаль

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

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

Понятно, скажем так, это не самое эффективное решение, но если реализация другого потребует больших затрат, то сойдёт для сельской местности.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[37]: Будущее C#
От: Sergey Россия  
Дата: 07.07.03 10:59
Оценка: +2
Здравствуйте, AndrewVK, Вы писали:

S>>Я, в отличие от тебя, не утверждаю, что к синтаксису шарпа привык.


AVK>А я где то утверждал что привык к синтаксису С++?


А что, уже забыл? Три твоих сообщения назад: "Я, как человек привыкший к синтаксису и шарпа, и дельфи, и плюсов могу тебе сказать — разница в читаемости огромная" Демагог ты, однако.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re: Будущее C#
От: Аноним  
Дата: 11.07.03 08:22
Оценка: -2
C# мёртвый язык и жизни ему не будет. Прочти — http://www.cydsoft.com/vr-online/3_2003/hvsms.htm и http://www.cydsoft.com/phpBB2/viewtopic.php?t=64
Re[2]: Будущее C# - вот это флейм!!!!!!!
От: Воронков Василий Россия  
Дата: 14.07.03 21:50
Оценка: :))
Здравствуйте, LaptevVV, Вы писали:

Почитал я тут соседнюю ветку про XML, где все говорят — сжатие нужно, сжатие, дескать много повторяющихся данных и пр. Вот я и думаю, если из этого текста весь мат выкинуть, то ведь какое сжатие получится-то! Одни только названия стандартов да языков останутся. В общем товарищи выкинем весь мат из XML! Впрочем, я лучше спать пойду.
... << RSDN@Home 1.1 beta 1 >>
Re[4]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.06.03 14:13
Оценка: 21 (1)
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Знаешь, тут один мой знакомый мой первый проект (сапер на дотнете) практически без правок запустил на PPC.


PE>А что такое PPC


PocketPC

PE>и кто cli mуда прикрутил,


Microsoft

PE>где бы это посмареть можно ?


www.microsoft.com, Compact Framework
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[12]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 08:19
Оценка: 14 (1)
Здравствуйте, AndrewVK, Вы писали:

AVK>О том и речь куда этот переходник засунуть, чтобы потом рефлекшен всякую чешую не показывал.


Кстати, с появлением анонимных методов нелогичность становится очевидной:

delegate void op(Form ctl);

static void MyOp(Control f){}

op oper1 = new op(MyOp); // не компилится
op oper2 = new op(ctl){MyOp(ctl)}; // будет компилиться
Re[25]: Будущее C#
От: WolfHound  
Дата: 03.07.03 08:55
Оценка: 12 (1)
Здравствуйте, VladD2, Вы писали:

VD>А кто это говорил? Тебе говорят, что он тяжел и во многом отстал от жизни. Цитату можешь привести?

Re[9]: Будущее C#
Автор: VladD2
Дата: 27.06.03
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 14:00
Оценка: 12 (1)
Здравствуйте, AndrewVK, Вы писали:

_>>У них все еще хуже — они даже не позволяют value-типу быть параметром шаблона. Виртуальная машина не меняется, и шаблоны остаются чисто синтаксической конструкцией. Они не могут поднять производительность,

AVK>Ну ты все таки поменьше верь рекламным лозунгам МС. Они не поднимут производительность при работе с value-типами путем отбрасывания боксинга просто потому что там боксинга нет. Все остальные аспекты повышения производительности, применимые к шаблонам С++ точно так же применимы и к дженерикам джавы.

Повышение производительности там если только у труда программиста.

http://www-106.ibm.com/developerworks/java/library/j-djc02113.html

   Hashtable<Integer, String> h = new Hashtable<Integer, String>();

One limitation to type variables in Tiger is that they must be instantiated with reference types -- primitive types won't work. So, in the example above, if we wanted to instead create a Hashtable mapping ints to Strings, we couldn't do it.

That's unfortunate, because it means that you have to wrap primitive types whenever you want to use them as arguments to a generic type. On the other hand, that's no worse than the current situation; you can't pass an int as a key to Hashtable because all keys must be of type Object.

What we'd really like to see would be automatic boxing and unboxing of primitive types, similar to what is done in C# (except better). Unfortunately, Tiger is not scheduled to include autoboxing of primitives (but one can always hope for Java 1.6!).

Good news! After this article was written, autoboxing was added to the Java 1.5 spec!


Integer — это и есть забоксенный int.
Re[35]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 23:12
Оценка: 10 (1)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, AndrewVK, Вы писали:


AVK>>Ты упускаешь важный момент — закрытие сеттеров отнюдь не означает отсутствие публичных конструкторов, которые устанавливают все необходимые поля.

WH>Допустим есть у тебя какой то массив ты хочешь его кому то дать почитать и при этом быть спокойным что этот кто то его не изменит. Ы?

Варинат 1: Возвращую копию массива.
Варинат 2: Возвращую этумератор (IEnumerable).
Аариант 3: Возвращу обертку реализаующиую индексатор и дургие методы и свойства позволяющие только читать этот массив.

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

ГВ>Так... значит, когда ты создаёшь курсор, ты не знаешь, для какого типа данных он создаётся? Т.е., если исходно у тебя что-то вроде:


Представь, что не весь код может быть доступен во время компиляции. И изходи из этого.

Ну, а примеры удоства динамического определения и работы с типами можно поглядеть в том же Хоуме. Не сурер опытный программист за неделю написал полностью универсальный механизм подключения шорткатов. Писать плагины тоже очень неудобно без полноценной поддержки информации о типах в рантайме. Да и просто не выходно храть весь код в одном модуле. Те же контролы позволяют использовать чужой код и резко укорить компиляцию.

Интересно ты работал с дотнетом, явой или COM+-ом? Судя по твоим словам нет. Попробуй. Ну, ради разнообразия. Думаю после того как ты втянешся тебя уже не придется убеждать в том, что использование метаданных не является ошибкой дизайна.

Лучший пример тут дотнет. В нем даже придумали специальное расширение метаданныж — атрибуты. Представсь себе помещаешь ты метод атрибутом:
[MenuText("Открыть файл"), Shotrcut(Keys.Ctrl & Keys.O), Img("FileOpen")]
void OpetFile(){ ... }


И у тебя как по мановению волшебной плочкой в программе появляется менюшка, шоткат и иконка в тубларе.

И никакого кодирования и отладки. Даже дизайнер не нужен.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Будущее C#
От: WolfHound  
Дата: 02.07.03 09:44
Оценка: 3 (1)
Здравствуйте, AndrewVK, Вы писали:

AVK>Вопрос не в том что можно, вопрос в том что нужно. хъ

Былабы возможность,а применение найдется. Нука изобрази на C#

#pragma once
#define MINIX_SELF()\
        SelfType* Self()        {return static_cast<        SelfType*>(this);}\
const    SelfType* Self()const    {return static_cast<const    SelfType*>(this);}


#pragma once
template<class SelfType>
struct SingleThread
{
    struct Locker
    {
        Locker(SelfType*){}
    private:
        Locker(const Locker&);
        Locker&operator=(const Locker&);
    };
    struct StaticLocker
    {
        StaticLocker(SelfType*){}
    private:
        StaticLocker(const StaticLocker&);
        StaticLocker&operator=(const StaticLocker&);
    };
};
template<class SelfType>
struct MultiThread
{
    struct Locker
    {
        Locker(SelfType* self)
            :self_(self)
        {
            self_->cs_.Lock();
        }
        ~Locker()
        {
            self_->cs_.Unlock();
        }
    private:
        Locker(const Locker&);
        Locker&operator=(const Locker&);
        MultiThread* self_;
    };
    struct StaticLocker
    {
        StaticLocker(SelfType* self)
            :self_(self)
        {
            self_->scs_.Lock();
        }
        ~StaticLocker()
        {
            self_->scs_.Unlock();
        }
    private:
        StaticLocker(const StaticLocker&);
        StaticLocker&operator=(const StaticLocker&);
        MultiThread* self_;
    };
private:
    struct CS{void Lock(){}void Unlock(){}};
    CS cs_;
    static CS scs_;
};
template<class SelfType>
typename MultiThread<SelfType>::CS MultiThread<SelfType>::scs_;

#define SelfLock()            SelfType::Locker        locker(Self());
#define SelfStaticLock()    SelfType::StaticLocker    staticLocker(Self());


#pragma once
#include "mixin.h"
#include "Thread.h"
struct ITest1
{
    virtual void Test1Fn1()=0;
    virtual void Test1Fn2()=0;
    virtual void Test1Fn3()=0;
};
template<class SelfType>
struct ImplTest1:ITest1
{
    MINIX_SELF()
    void Test1Fn1()
    {
        SelfLock()
        Self()->Impl2();
    }
    void Test1Fn2()
    {
        Self()->Impl3();
    }
    void Test1Fn3()
    {
        SelfLock()
        Self()->Impl1();
    }
    void Impl1()
    {
    }
};


#pragma once
#include "mixin.h"
#include "Thread.h"
struct ITest2
{
    virtual void Test2Fn1()=0;
    virtual void Test2Fn2()=0;
    virtual void Test2Fn3()=0;
};
template<class SelfType>
struct ImplTest2:ITest2
{
    MINIX_SELF()
    void Test2Fn1()
    {
        Self()->Impl3();
    }
    void Test2Fn2()
    {
        SelfLock()
        Self()->Impl1();
    }
    void Test2Fn3()
    {
        SelfStaticLock()
        Self()->Impl2();
    }
    void Impl2()
    {
    }
};


#pragma once
#include "mixin.h"
#include "Thread.h"
struct ITest3
{
    virtual void Test3Fn1()=0;
    virtual void Test3Fn2()=0;
    virtual void Test3Fn3()=0;
};
template<class SelfType>
struct ImplTest3:ITest3
{
    MINIX_SELF()
    void Test3Fn1()
    {
        SelfStaticLock()
        Self()->Impl2();
    }
    void Test3Fn2()
    {
        SelfStaticLock()
        Self()->Impl1();
    }
    void Test3Fn3()
    {
        SelfLock()
        Self()->Impl3();
    }
    void Impl3()
    {
    }
};
template<class SelfType>
struct Impl2Test3:ITest3
{
    MINIX_SELF()
    void Test3Fn1()
    {
        SelfStaticLock()
        Self()->Impl2();
    }
    void Test3Fn2()
    {
        SelfStaticLock()
        Self()->Impl1();
    }
    void Test3Fn3()
    {
        SelfLock()
        Self()->Impl3();
    }
};


#include "stdafx.h"
#include "ITest1.h"
#include "ITest2.h"
#include "ITest3.h"

struct Test1
    :MultiThread<Test1>
    ,ImplTest1<Test1>
    ,ImplTest2<Test1>
    ,ImplTest3<Test1>
{
};

struct Test2
    :SingleThread<Test2>
    ,ImplTest1<Test2>
    ,ImplTest2<Test2>
    ,Impl2Test3<Test2>
{
    void Impl3()
    {
    }
};

int main()
{
    Test1 t1;
    Test2 t2;
    return 0;
}

Типовая реализация интерфейсов вполне реальная вещь. А Self()->Impl3(); и тп могут быть даже инлайнены.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Будущее C#
От: _vovin http://www.pragmatic-architect.com
Дата: 25.06.03 07:54
Оценка: 2 (1)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, VladD2, Вы писали:


VD>>Именно что сравнивал. Делегаты намного удобнее. Жаль что медленнее.

WH>И мение функциональны.

Удивляюсь, как можно приводить абсолютно чудовищный код и утверждать, что это круто.
Лубой язык с функциями высшего порядка позволит все это сделать с десятой частью тех усилий.
Например:

| list |
list := #(10.0 20.0).
#(+ - / *) collect: [:op | list fold: [:a :b | a perform: op with: b]]


Выдаст

#(30.0 -10.0 0.5 200.0)


--

Владимир.
Re[11]: Будущее C#
От: WolfHound  
Дата: 30.06.03 16:38
Оценка: 2 (1)
Здравствуйте, VladD2, Вы писали:

VD>Да я вроде и без него в С++ разбирался.

Я тоже так думал...

Из предисловия Скотта Мейерса

Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.


Со стула я не свалился но долго был в шоке.

ЗЫ 190р за эту книгу не деньги.
ЗЗЫ Я не против C# мне он самому нравится. Но мне не нравится то что С++ недооценивают и сильно.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Будущее C#
От: mihailik Украина  
Дата: 26.06.03 15:18
Оценка: 1 (1)
VD>Делегаты делают то ради чего они и были созданы. Делают они это элегантно, но не шустро.

Я ещё немного поковырялся в Rotor. Значит, делегатский метод Invoke компилируется в x86-инструкции. В этих инструкциях проверка количества подцепленных функций (multicast/signlecast) и вызов.

То есть, это пара лишних indirection и одна проверка — для signle-cast.

Интерестно, что мультикасты в Rotor хранятся в linked list, а в Mono в массиве. Вроде бы в массиве лучше, ведь при создании объекта-делегата точно известно количество "кастов".

Кроме того, в Mono делегатский метод Invoke компилируется не в x86, а в IL — в отличие от Rotor.

Подробности:

Rotor 2002-11-01
— clr\src\vm\i386\cgenx86.cpp
— строка 3633
— StubLinkerCPU::EmitMulticastInvoke

Mono mono-024
— mono\metadata\marshal.c
— строка 1442
— mono_marshal_get_delegate_invoke
... << RSDN@Home 1.0 beta 7a >>
Re[22]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.07.03 10:04
Оценка: 1 (1)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, AndrewVK, Вы писали:


AVK>>Вопрос не в том что можно, вопрос в том что нужно. хъ

WH>Былабы возможность,а применение найдется. Нука изобрази на C#

Изоразить можно.Но мне волм разбирать по коду, какая цель твоих примеров.
Если цель — показать крутой полиморфизм, то пиши сам.
Если конкретная задача для пользователя — можно попробовать.

Мне вот не нгадо выписывать чудеса всякие. Заказчик пришел и сказал — напиши аппликацию для специфического HTMLа, что можно было легко расширять ее плагинами, скриптами и тд.
Этим следует заняться.

А если — напиши мне это

// --------------------------------------------------------------------
// A little helper class for setting a boolean flag and clearing it
// on destruction.
class BoolLock
{
    bool* _pFlag;
public:
    BoolLock(bool* pFlag)
    {
        _pFlag = pFlag;
        *pFlag = true;
    }
    ~BoolLock()
    {
        *_pFlag = false;
    }
};



То я пас.


Итак, какова цель того кода, который я поскипал ?
Re[22]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 21:02
Оценка: 1 (1)
Здравствуйте, WolfHound, Вы писали:

PE>>3. Это же означает, что не только новичек, но и середнячек не потянет все рулезы концентрированного С++.

WH>Если человек хочет его можно дотяуть до этого уровня очень быстро.

Ага годика за 3 минимум.

PE>>Такая техника сродни уровню гросстмейстера мирового класса в шахматах — их очень мало.

WH>Лесть тебя не спасет.

Это стеб.

PE>>4. Я не вижу отражения существующих тенденций — компонентное программирование и тд.

PE>>__declspec(__dllexport) — это далеко не то, что надо сейчас.
WH>Согласен. Но во первых и на этом можно очень много, во вторых есть много задачь где это не актуально.

Вот С++ скоро и останется в нишах где "это" не актуально. А реально он останется в области низкоуровневого программирования.

WH>Ну сериализация очень практична,


Ага. Особенно по сравнению с дотнетной.

WH> SWL это потенциально очень мощьная, гибкая и лаконичная оконная библиотека только надо комуто ее написать.


Я бы сказал не некому, а никому на фиг не нужно. Все равно до приметивной WinForms ей будет, как раку до Пекина.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.06.03 22:19
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Скорее не опытный ИМХО. Александреску читал? boost потрошил?


Он Дельфист... в прошлом.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Будущее C#
От: Lloyd Россия  
Дата: 27.06.03 09:14
Оценка: +1
Здравствуйте, desperado_gmbh, Вы писали:

_>Для случая с делегатами компилятор в состоянии сделать thunk, который сейчас приходится делать руками. В boost/signal это работает.


C++ в этом плане более статичен. В Net-е можно создать делегат на метод, который в момент компиляции вовсе недоступен.
Re[8]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 27.06.03 14:09
Оценка: +1
Здравствуйте, VladD2, Вы писали:

_>> Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно?

VD>В С++ int и long синонимы (под 32-битными платформами).

Я про c#, раз уж написал про implicit operator.

VD>А вообще приведение безопастно если оно не может привести к переполнениям или обрезаниям. В дотнете приведения тоже работают. Ты можешь передать в делегат int вместо double-а. Но вот приводить один делегат к другому (имеющему другой список параметров) — это опасное действие.


Безопасное действие при контравариантности типов параметров. Вон Form[] можно привевсти к Control[] — работает ковариантность. Здесь же наоборот — у нас есть метод void(Control) и мы хотим прицепить его к делегату void(Form). Где здесь опасность?

_>> Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)?

VD>В отличии от С++ в дотнете без проблем код вызывающий делегаты из массива может находиться в другом исполнимом файле. А код запихивающий методы в массив в дурогом. И кроме контроля типов нет никакой гарантии, что в рантайме не "грохнет".

Для понимания строки "op oper = new op(Add)" в этом самом другом файле компилятору c# необходимо знать тип делегата op и тип функции Add. Если они совпадают, все компилится. Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас, если даже на стандартных плюсах можно соорудить типобезопасный signal, делающий то же самое?
Re[17]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.03 15:32
Оценка: +1
Здравствуйте, desperado_gmbh, Вы писали:

_>Никакой связи нет. Сигналы, например, построены на типобезопасных указателях на члены. Небезопасными в c++ являются static_cast на потомка и reinterpret_cast, которые не используются в реализации сигналов. Есть, правда, одно исключение (внутри any_cast используется static_cast вместо dynamic_cast), но оно сделано в целях эффективности и перед ним явно проверяется, что тип правильный.


Любой указатель можно обойти тем или иным способом.
Никто не спорит, что буст для С++ — рульная вещь. Предложи дизайн для шарпа.
Буст — это С++ вариант. Как ты сможешь использоваться это для компонентов ?
Re[4]: Будущее C#
От: alexkro  
Дата: 01.07.03 03:08
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Да конечно появление шаблонов откроет пути к совершенству.


Спорный вопрос. C# generics ничего общего с шаблонами не имеют. Пока что я для них одно применение вижу — типизированные контейнеры. Никакой новой парадигмы программирования они не откроют. Даже такая простая вещь как policy-based programming не станет возможна в C#.
Re[9]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.03 10:33
Оценка: +1
Здравствуйте, alexkro, Вы писали:

AVK>>Вот о том и речь что ты пытаешься мерять дотнет плюсовым аршином. В отличие от С++ рассматривать C# отдельно от его рантайма не имеет смысла, обычный язык почти без изысков.


A>Да, я сравниваю языки программирования. Среда исполнения мне не особенно важна.


В дотнете крайне важна. Без нее языки не имеют смысла. В дотнете по сути все сделано наоборот — шарп разрабатывался под рантайм, а не рантайм под шарп. Собственно это в той или иной степени имеет отношение ко всем языкам дотнета.

A>Нехороший сайт попался. Нужно поискать "policy basic_string" на www.cuj.com. Первая ссылка — это она и есть.


Чего то там много, нет времени все это читать. Объясни на пальцах что это такое и какие у него бенефиты.

AVK>>Языки как раз отличаются не очень сильно, сильно отличается рантайм.


A>На C++ тоже можно для .NET программировать


Ну и что? Если укладываться в рамки CLR то от С++ остануться рожки да ножки.

A>и при этом использовать большинство его (C++) идиом.


Большинство идиом в managed коде? Не получится.

A>Кстати, этот подход (C++ для .NET) будет еще более сильно развит в следующей версии VC++.


Откуда дровишки?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[15]: Будущее C#
От: WolfHound  
Дата: 02.07.03 05:11
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Неужели один прочитанный учебник может сделать из вчерашнего студента закоренелого профи?

Нет но начальные знания дать может, а у них и этого нет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.07.03 06:13
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Хочешь знать что можно сделать на шаблонах?


Вопрос не в том что можно, вопрос в том что нужно. На асме к примеру можно так извратнуться что народ будет кипятком писать, вот только в практическом плане пользы от этого ноль. Главное отличие моего и твоего отношения к С++ в том что мне не шашечки, мне ехать. А вот ехать на С++ не очень удобно, вне зависимости от того читал ты Александреску, или не читал. В полезности шаблонов никто не сомневается, но очень большой кусок их применения в С++ это не столько какой то особенный функционал, сколько залатывание дыр самого языка. Раньше, до шаблонов, подобным образом применяли макросы.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[23]: Будущее C#
От: WolfHound  
Дата: 02.07.03 10:04
Оценка: +1
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Таких, к сожалению, большинство. Новозможно всем сразу стать профессионалами уровня Александреску.


Это проще чем кажется. Стоит только захотеть.

А если не хочешь то по крайней мере не надо орать что С++ примитивин. Именно это меня раздражает.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 15:07
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

AVK>В них нет определенного функционала темплейтов,


Можно узнать какого?

AVK>И еще, писать на дотнете, так как ты это делал на С++ не стоит, ничего хорошего из этого не выдет. Другая идеология, другие паттерны.


Ну, ну. Это уже ты загнул. Писать можно так же. Просто нужно помнить, что многое уже написано.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 15:07
Оценка: :)
Здравствуйте, alexkro, Вы писали:

A>Мне, вообщем-то, не очень интересны различия в runtime. А вот с точки зрения языков программирования, что есть в generics, чего в шаблонах нет?


Дык то самое что тебе не интересно. Они не нарушают идеологию компонентного программирования. Я обявляю шаблооный интерфейс, размещаю его в одной длл-е, ты создаешь релизацию этого интерфейса, а кто-нибудь еще использует его. Причем никто не обязан предоставлять исходники.

Ну, и экономнее это. Можно создавать универсальные реалзации.

A>Вот хороший пример.


Да неплохой. Возьмусь его процитировать:

File Not Found
cujcexp1906alexandr

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

WH>Здравствуйте, VladD2, Вы писали:


VD>>Да я вроде и без него в С++ разбирался.

WH>Я тоже так думал...

WH>Из предисловия Скотта Мейерса

WH>

WH>Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.


Что понимается под списками? Реализация коллекций? Я вроде все более менее известные изучал по исходинкам. Не думаю, что товаришь может больше чем разработчики библиотек вроде stl, ATL, Boost...

WH>ЗЗЫ Я не против C# мне он самому нравится. Но мне не нравится то что С++ недооценивают и сильно.


Кто тебе сказал? Многие его оценивают очень даже по заслугам. Я зык без сомнения мощьный и гибкий, но так же без сомнения он тяжелый для чтения и узучения, а так же в виду упущений в дизайне слишком часто приводит к трудноуловимым ошибкам. Шарп же полная противоположенность. Приятно было бы если Шарп стал ближе к С++ по возможностям. Но пусть это будет не в ущерб простотое и удобству.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 18:10
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, WolfHound, Вы писали:


IT>>>Неужели один прочитанный учебник может сделать из вчерашнего студента закоренелого профи?

WH>>Нет но начальные знания дать может, а у них и этого нет.

VD> Я плякаль.


Ты в следующий раз прежде чем так выпендриваться зади в топ и погляди кто рядом с тобой стоит. И это при том, что кое-кто уже больше года туда не заходил по серьезному.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 06:14
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>
IT>    using (SqlConnection con = new SqlConnection(connectionString))
IT>    {
IT>        con.Open();

IT>        using (SqlCommand cmd = new SqlCommand(commandText, con))
IT>


Двойка тебе за знание адонета . Чтобы создать команду нет необходимости открывать коннекшен, открывать нужно только для Execute, Prepare и BeginTransaction.

IT>Для меня эталоном программы уже давно является не виртуозное владение указателями, свитчами и шаблонами, а ясный и понятный, хорошо оформленный и откомментированный код. Впрочем, может это я просто старею...


Мужаешь
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[23]: Будущее C#
От: WolfHound  
Дата: 03.07.03 08:36
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>А вот ответь мне, мил человек, сможешь ли ты на C++ (не MC++) сделать из чего-то типа первого примера, что-то типа второго?

Первый легко. ADO.
    struct CategoryInfo
    {
        int            CategoryID;
        AnsiString     CategoryName;
        int            Count;
    };
    static boost::shared_ptr<std::vector<boost::shared_ptr<CategoryInfo> > > GetCategories(int min)
    {
        boost::shared_ptr<TADOConnection> connect(new TADOConnection(0));
        connect->ConnectionString=
            "Server=.;Database=Northwind;Integrated Security=SSPI"
        ;
        connect->Open();
        boost::shared_ptr<TADODataSet> dataSet(new TADODataSet(0));
        dataSet->Connection=connect.get();
        dataSet->CommandText=
            "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"
        ;
        TParameter* param=dataSet->Parameters->AddParameter();
        param->Name="@min";
        param->DataType=ftInteger;
        param->Value=min;
        dataSet->Open();
        boost::shared_ptr<std::vector<boost::shared_ptr<CategoryInfo> > > al(new std::vector<boost::shared_ptr<CategoryInfo> >);
        while(!dataSet->Eof)
        {
            boost::shared_ptr<CategoryInfo> ci(new CategoryInfo);
            ci->CategoryID   = dataSet->FieldValues["CategoryID"];
            ci->CategoryName = dataSet->FieldValues["CategoryName"];
            ci->Count        = dataSet->FieldValues["Count"];
            al->push_back(ci);
            dataSet->Next();
        }
        return al;
    }

Правда имена типов страшнее, но болие типобезопасно.

IT>А теперь добавим немного рефлекшина внутрь и получим:

Мда... печальное зрелище... без пузыря не разберёшся.

Это сделает их как раз только запутаннее и непонятнее и будем им грошь цена, после того как какой-нибудь студент, идущий за тобой, не поняв что там происходит, просто перепишет твой код на нормальный понятный язык. И будет, между прочим, прав.

И что теперь говорить что рефлекшен фигня? Если в .NET будут шаблоны уровня С++ и множественное наследование я сразу забью на С++.
К стати когда студент поймет что на "простом" и "понятном" языке придется писать в 10 раз больше и не будет дураком он пойдет читать Александреску.

IT>В твоём примере трудно понять вообще для чего он нужен,

Обыкновенная сборка классов из кирпичиков причем один кирпичик может изменить реализацию другого причем даст компилятору кучу информации при помощи которой он может инлайнить методы из карпичика A в методе кирпичика B. Воспользовавшись этим я показал как можно писать кирпичи с учетом многопоточности и использовать в однопоточном приложении так что компилятор убьет весь код синхронизации.

IT>в моём надеюсь тебе не просто будет всё понятно, а даже тривиально с первого взгляда.

Первый да второй нет(вернее догадаться по контексту могу, а повторить...даже на С#... ).
Таже проблема что и у тебя с моим кодом плохое знание матчасти.

IT>И прибегать к услугам Александреску чтобы понять этот код не надо.

А к чьим можно прибегнуть для того чтобы понять пример с рефлекшеном?(В принципе я понимаю как это работает но хочется по подробней)

IT>Я конечно понимаю, что поступаю не совсем честно,

Я тоже
IT>в C++ нет нормального RTTI и видимо никогда не будет, но я хочу сказать,
В C# не шаблонов и судя по слухам нормальных не будет.
К стати тоже судя по слухам рефлекшен в С++ хотят делать.
IT>что в 99.99% задач твои знания шаблонов вряд ли пригодятся.
А что ты постоянно используешь рефлекшен?
IT>А если бы ты и попытался их где-либо применить, то работая, к примеру, в моей команде, я тебе просто элементарно запретил бы это делать.
А в своей конторе я написал фрейморк на шаблонах такой что получилось практически нормальное компонентное программирование. И ни кто не назвал меня извращенцем ибо по сравнению с тем что было до меня все много проще, понятней и удобней.

IT>Для меня эталоном программы уже давно является не виртуозное владение указателями, свитчами и шаблонами, а ясный и понятный, хорошо оформленный и откомментированный код. Впрочем, может это я просто старею...

А у меня клиетский код ясный, понятный, хорошо оформленный и откоментированый. Библиотека к стати тоже правда только после прочтения Александреску.

Ни какой адресной арифметики(сразу по бошке), ни каких свитчей, а шаблоны явно используются толко в смартпоинтерах, при кастовании и создании обьектов(смартпоинтеры не избежно, а кастование и создание я решил что лучше указать явно нужнай тип)

Создание обьекта по имени класса прочитаному из какого либо конфига. Причем реализация обьекта можнет находится в либой из оформлкнных по (очень простым) правилам длл(ессно прицепленных к приложению).
    Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorClassName);
    ENFORCE(sensor, X_InvalidClassName)("Class Name =\"")(sensorClassName)("\"");//Исключение будет автоматом записано в лог 
    sensor->Name=sensorName;//Что грузить
    sensor->DataBase=dataBase;//От куда грузить
    ENFORCE(sensor->Load(), X_InvalidSensorName)("Class Name =\"")(sensorClassName)("\"; Sensor name =\"")(sensorName)("\"");
    //    Messge    : Class Name ="MyCoolSensorClass"; Sensor name ="MyCoolSensor"
    //См ниже


Блин ну и аппликуха у меня исключений не дождешся проще всего форсировать это
        ENFORCE(startPlugin, X_Terminate)("No start class");

А так исключение выглядит в логе
!!!TERMINATED!!! 
    Exception : X_Terminate
    File      : W:\mlevel\kernel\C_Application.h
    Line      : 96
    Condition : startPlugin
    Messge    : No start class
    Date&Time : 03.07.2003 13:25:29

Конечно не C# но информации вполне достаточно

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

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


Это из серии реализуй вон ту кучу кода и тогда поговорим. Там можно и ворд на шарпе послать писать.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 12:04
Оценка: -1
Здравствуйте, VladD2, Вы писали:

AVK>>Да? И ты берешься сделать к примеру класс с МН менеджед?


VD>Легко. Компилируются даже шаблонные навароты ATL-я.


Нет, gc-классы не могут использовать МН.

AVK>> Не путай пожалуйста IL-код и-managed код.


VD>Не путаю. IL == managed.


Ничего подобного. Цитата из MSDN

Compilers and tools expose the runtime's functionality and enable you to write code that benefits from this managed execution environment. Code that you develop with a language compiler that targets the runtime is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.


Слабо сделать класс с МН, чтобы его можно было использовать из C# или VB.NET?

VD> То о чем говоришь ты называется "CLS-совместимый".


Нет, CLS совместимый это отвечающий стандарту CLI. Вот к примеру uint вполне себе менеджед, но не CLS-compliant. Комплиантность к CLS обозначается атрибутом CLSCompliant.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[27]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 13:47
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А. Экономия микросикунд...


VD>Может лучше о запросах думать?


О запросах тоже надо думать, но съэкономить микросекунды когда это ничего не стоит имхо тоже имеет смысл.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[18]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 13:49
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

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


Ну расскажи тогда как правильно реализовать, к примеру, сериализацию классов.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[23]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 15:27
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

_>>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.

DG>Это связанно с тем, что каждый отдельный obj хранит всю информацию, которая встречалась в данном cpp-ишнике и всех H-ников, которые в него include-ились, что сейчас как раз приводит к раздуванию obj-ей.

Я просто неправильно тебя понял. Я полностью с тобой согласен — система раздельной компиляции через obj напрочь устарела, и скомпилированные модули с метаданными рядом с кодом, впервые увиденные мной в турбопаскале, увеличивают скорость компиляции на порядки.
Re[24]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:31
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код?


Описание и регистрация учавствующих классов, а зачастую еще и ручная реализация сериализации для каждого типа.

AVK>>Все что я видел


ГВ>Т.е., все реализации, которые ты видел


Все реализации без RTTI естественно.

ГВ>содержали как минимум, кучу ненужного кода? Не верю! (c) Станиславский.


Твое право
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[11]: Будущее C#
От: mihailik Украина  
Дата: 03.07.03 16:22
Оценка: :)
AVK>>Что то последнее время больше не по делу.

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


Не, генерики и баста. Хорошенько понемножку.

Слишком большая гибкость только вредит. Ртуть вон гибче глины, зато из неё фигурки не лепятся.
... << RSDN@Home 1.1 beta 1 >>
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[18]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 20:18
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

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


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

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


Ну, что я могу тебе сказать. По-моему, ты ошибаешся.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Будущее C#
От: alexkro  
Дата: 03.07.03 20:41
Оценка: +1
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Здравствуйте, alexkro, Вы писали:


PE>>> Новичку в нем тяжело.

A>>Как и везде.

PE>Нет. Не везде. На шарп я перепрыгнул езо всяких книг, мануалов и тд. Просто нача писать. Потом были курсы, которые я проспал. В жаве тож самое. Парень ушел от нас и пересел без проблем на жаву. В вот на С++ так не перепрыгнешь.


Это потому, что ты уже знал язык, который обладает большими возможностями. А человек, который программировал на языке с возможностями, перекрывающими C++, перепрыгнет на него с такой же легкостью.

Значит ли это, что C++ сложнее изучать? Не факт. Просто изучать нужно правильно.

PE>>>Нынче хороший С++ программист сродни хорошему шахматисту — и тех и других мало. Разница лишь в том, что программисты на С++ зарабатывают деньги этим самым С++, а шахматисты зарабатывают чаще всего не шахматами.

PE>>>С одной стороны это хорошо — мощь потрясающая. С другой — изучать этот язык надо долго.
PE>>>Новичку нельзя доверить суппорт проекта на С++ — дохлый номер.

A>>Чистая дискриминация. Ты подразумеваешь, что остальные C++ не поймут?

PE>Это не дискриминация. Больше всего рядовых игроков, рядовых программистов.

Я же вижу, ты себя считаешь выдающимся программистом, а остальных — рядовыми, которые C++ не поймут. Вот и дискриминация.

PE>Даеко не всякий сможет подойти к помосту и выжать 300 кг. Хотя теоретически это по плечу каждому.

PE>С шахматами и С++ тоже самое.


PE>>>Такие чудеса, что демонстрирует Александреску, нельзя, к сожалению, внедрять повсюду.


A>>Это не чудеса, а просто новая парадигма дизайна и программирования. Можно ее принять и использовать, а можно программировать как раньше. C++ все поддерживает, недаром его называют multi-paradigm.

PE>В дизайне я не увидел ничего нового. Все это было, только реализовывалось более громоздко, но более наглядно.
PE>Я называю подход Александреску — концентрированный С++

Эта книга из тех, что за один раз не берутся. Там — новые идеи по дизайну, однозначно. Как все новое, они сначала отторгаются, так как тебе кажется, что это либо коряво, либо не нужно. Но потихоньку понимание приходит.
Re[26]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 20:47
Оценка: +1
Здравствуйте, Sergey, Вы писали:

S>Вот такой стиль устраивает?


S>
S>class TestA : public ddx::controller<TestA, Loki::NullType>, public CDialog
S>{
S>    typedef ddx::controller<derived_type, base_type> parent_t;
S>protected:
S>    typedef ddx::member<CString, IDC_SERVER, Ser, &DDX_CBString> m_Server;
S>    typedef ddx::member<CString, IDC_PROCESS_NAME, Ser, &DDX_Text> m_ProcessName;
S>    typedef ddx::members<TYPELIST_2(m_Server, m_ProcessName)> members_info;
S>public:
S>    TestA(CWnd *wnd) {}
S>    members_info ddxMembers;
S>};

S>class TestC : public ddx::controller<TestC, TestA>
S>{
S>    typedef ddx::controller<derived_type, base_type> parent_t;
S>protected:
S>    typedef ddx::members<Loki::NullType> members_info;
S>public:
S>    TestC(CWnd *wnd) : parent_t(wnd) {}
S>    members_info ddxMembers;
S>};

S>class TestB : public ddx::controller<TestB, TestC>
S>{
S>    typedef ddx::controller<derived_type, base_type> parent_t;
S>protected:
S>    typedef ddx::member<BOOL, IDC_CREATEMM, Ser, &DDX_Check> m_CreateMM;
S>    typedef ddx::members<TYPELIST_1(m_CreateMM)> members_info;
S>public:
S>    TestB(CWnd *wnd) : parent_t(wnd) {}
S>    members_info ddxMembers;
S>};
S>




О том и нечь что нет! Ни в коем случе не устривает. Это мазохизм.

Да и этот код использует ртти (как я понимаю).

Вот такой стиль намного лучше:

[Serialize]
class TestA
{
    public TestA(CWnd wnd) {}
    public string m_Server;
    public string m_ProcessName;
};

[Serialize]
class TestC : TestA
{
    public TestC(CWnd wnd) : bsae(wnd)
};

...
    TestC с = new TestC(xxx);
    ... // Что-то тварим с объектом...
    // Это весь код необходимый для сериализации!
    MemoryStream ms = new MemoryStream(1024);
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(ms, ds);


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

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


Я плякаль... узнавая себя... и мысленно заменяя С++ на COM.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Будущее C#
От: IT Россия linq2db.com
Дата: 04.07.03 02:23
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?


IT>>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.


ГВ>Хммм... похоже, ты меня совсем не понял.


Возможно, скорее всего ты имел ввиду рефлекшин, а не сериализацию. Правильно?
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:42
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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


Эх, уж коль мы занялись пенисометрией, то я, коль скоро тоже являюсь явнообвиненным в незнании матчасти скажу что так же писал еще на TurboC лет эдак 9-10 назад. Лет 6-7 назад на BC++.

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


Ну мы же не знаем кто такие остальные, согласен?

WH>и сильно(те по простоте использования, функциональности, расширяемости, дурокаустойчивости...) Вобщем теперь я архитектор и ни кто не вспоминает что мой опыт реальных проектов около года,


И после этого у тебя хватает смелости обвинять одних из самых опытных на rsdn программеров (я не себя имею ввиду, а Влада и Игоря) в незнании матчасти? Скажи, теперича все молодые программеры такие пальцастые?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[32]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 07:08
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну нет, почему же? Если сопоставление метаинформации реализуется для его дальнейшего использования, то чтение будет удобным. По-моему, это очевидно.


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

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


VD>>Это уже снобизм и шовинизм. Мне почему-то знание С++ не мешает писать на шарпе. Я еще и С знаю. И на нем много писал. Этак мы дойдем, что все кто знают старые зыки на новые уже могзги переглючить не могут.


AVK>Да и сам ты поначалу очень сильно против дотнета возражал, достаточно почитать твои споры с мной и IT на эту тему полуторагодичной давности . А вот у новичков этого нет, они сразу воспринимают особенности шарпа как единственно верные.


А я и сейчас против многого возражаю. Вон шаблоны уже далеют. Глядишь и остальное доделают.

AVK>В общем это давно известный эффект. Ранее много народу наступило на грабли, когда изучать структурное программирование после васика было тяжелее нежели изучать его с нуля.


Да уж. Факт извеснейший. Те кто ничего в жизни не видел, и ничего не знает обысно со всем согласны.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:07
Оценка: +1
Здравствуйте, <Аноним>, Вы писали:

А>Это оффлайновый клиент. Как ему еще работать?


Гы. Голлеги.

А>Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла


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

ГВ>Да ну? А как же run-time analysis: "Если символ типа — X, то использовать алгоритм Z"? Или мы с тобой подразумеваем под rtti разные вещи.


Ну, да. Ты под ним понимаешь того убогого урода что есть в С++ и для С++ который по своей природе тяготеет к монолитности. А АВК говорит о рефлекшоне который по сравнению с ртти, как Феррари и трехколесный велосипед.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:33
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>На каком основании такие предположения? Единственное, что придётся сделать — написать mapping колонок, т.е. — что-то вроде:


На том, что я тебе могу два своих грида показать хоть сейчас. А ты можешь?

ГВ>Притом такой маппинг описывать проще, чем прыгать по десяти Property-box-ам. Так что, кто из нас будет что-то-там как папа Карло — ещё не известно.


Жаль мне тебя. Это уже синдром Рыбинкина.

ГВ>Ещё круче. Это-то зачем? Обычного SysListView32 вполне хватит.


А. Ну-ну. Вот такие смелые и затягивают приметивные проекты на полугодия.

ГВ>My God! Да почему?!


По жизни.

Сходство между нами в том, что и ты и я прошли через разработку на плюсах (а возможно и на сях). А, разница между нам в том, что я уже попробовал новые компонентные технологи, а ты пытаешся цепляться за старье обеждая себя и других в том, что все новое — это фигня и кроме проблем и неудобств ничего не дает. Общего мы зяка не найдем. По крайней мере пока ты не вникнеш в компонентный подход. Возможно тебе он и не нужен. Возможно в твоей работе старого подхода хватает за глаза. Но это не значит, что все должны цепляться за старое любой ценой.

ГВ>В данном случае — пока скорее так, чем не так.


В данном случае кому-то влом посмотреть на новое и он ищет любые аргменты чтобы этого не далеть.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 15:07
Оценка: +1
Здравствуйте, desperado_gmbh, Вы писали:

_>Цель — дать возможность обработать исключения при инициализации базовых классов. А раз уж появился такой синтаксис, почему он должен быть специфичным для конструкторов?


А нафига стройность языка портить? Еще раз повторю, что тогда уж нужно было и if-ы разрешать.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 21:43
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>А я бы предоставил программеру самому решать где размещать класс — в стеке или на куче.


Ну, тогда С++ рулит. Там программист имеет полный контрольк над этим впоросом.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.03 17:51
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Тогда попробуй предствить, что вся метаинформация делается именно для того, чтобы ее читали.


ГВ>По-моему, я этого и не отрицал. Это прикольно — приписывать мне отрицание моих собственных взглядов.


Ты утверждаешь, что алгоритмы основанные на чтении метаданных являются кривым дизайном. В то время, как метаданные предназначены исключитально для этого. Следовательно она сама по себе являются кривостью. Обычные логические выводы.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 06:40
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Не. Реализация указателей в Паскале не совместима с жинью.


Чем тебе паскалевские указатели не угодили? Ровно такие же как и в С++, кроме наличия в последнем адресной арифметики.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[33]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.07.03 21:42
Оценка: -1
Здравствуйте, VladD2, Вы писали:

ГВ>>Возможность взаимодействовать с экземпляром за счёт атрибутов. RTTI-сугубо информационная сущность. Поскольку RTTI — это runtime type information, а не например — objects,

VD>Нда. Атрибуты — это средства расширения метаинформации. И атрибуты всегда ассоциируются с метаданными классов/методов. К объектам же они отношения не имеют.

Да ну?

VD>Так что рефлекшон и есть информация о типах. Правда от rtti он отличается... тем, что информация доступна не таолько на рантайме, но и во время разработки и даже компиляции.


Интересно, VC-шный class browser вероятно не предоставляет информации о классах в период разработки? Странно...

То, что информация о типах доступна в design-time говорит только о развитости среды и относительной легкодоступности этой информации. Ну это как бы и очевидно.

С другой стороны, reflection имеет ещё кучу отличий от rtti. Хотя бы в том, что у него можно спросить не только имя типа.

ГВ>>то рефлекшн хоть и включает в себя rtti, но в рамках оценки rtti-based-подхода использовать особенности рефлекшена, ИМХО, неверно.

VD>Ты снова судишь с позиции С++. А АВК говорит с позиции чистого термина. То что rtti в С++ — это убогий уродец с тобой никто не спорит. Но сама концепция равитая в дургих средах/языках от этого хуже не становится.

Может быть и так. Но от свойственных ей недостатков (sorry — особенностей ) как оверхед (всегда) + ненадёжность (почти всегда) она от этого не избавляется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[35]: Будущее C#
От: Sergey Россия  
Дата: 08.07.03 07:44
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Я тебе скажу так. Хотя синтаксис шаблонов в С++ меня полностью устраивает. Но в общем и целом я согласен с АВК. Читать исходники на С++ намного сложнее чем на Шарпе.


Смотря какие исходники . Мы-то про вполне конкретный пример кода говорили, который, на мой взгляд, одинаково прост хоть на плюсах, хоть на шарпе.
А вообще, конечно, да — но это потому, что на С++ можно некоторые более сложные вещи записать меньшим объемом кода. Тут прямая аналогия с сервер-сайд скриптом, генерирующим клиентский скрипт — понимать его труднее, чем просто клиентский скрипт. Программа, выполняемая компилятором, генерирующая программу на "бесшаблонном С++", часто выглядит сложнее, чем код на "бесшаблонном С++", расписанный для всех требуемых случаев. Вот только пользоваться такой программой обычно довольно просто, особенно если она имеет грамотный интерфейс.

VD>А эмуляций остуствущей в функциональности на шаблонах еще больше усугубляет это положение.


Есть такое дело. Хотя если эту функциональность прятать в библиотеку с удобным интерфейсом, получается очень даже читабельно. Взять тот же boost::bind — внутри сущий кошмар, снаружи — лепота.

VD>На плюсах последий раз неделю назад. Вообще написал на них радимых кучу кода. А читать приходилось вообще ороменные листинги.


А это я не тебя спрашивал. У тебя знаний С++ поболее, тебе и вопросы другие Например, когда ты впервые узнал, что на плюсах можно посчитать факториал в компил-тайме? И сколько раз писал рекурсивные шаблоны? Но это так, в порядке подколки Книжку Александреску прочитать тебе не зря советовали.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[37]: Будущее C#
От: Sergey Россия  
Дата: 09.07.03 08:27
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Sergey, Вы писали:


S>>Кстати, а VisualAssist по этому критерию чем не подходит? Большая часть того, чем он занимается — это предоставляет информацию о типах в design-time


VD>1. Он не предаставляет метаданные, т.е. решает совершенно другие задачи.


Список членов класса — это метаданные или что?

VD>2. Безбожно врет и глючит.


угу.

S>>IMHO, в плюсах правильным (в том числе идеологически правильным ) было бы иметь полную метаинформацию о типах во время компиляции, и при необходимости вытаскивать ее в рантайм традиционным плюсовым путем — с помощью библиотек (ну и библиотека для этого нужны бы была стандартная). Я б тогда midl куда подальше закинул...


VD>Выкидывай. В дотнете МС++ прекрасно работает без него.


А не нужен мне ни MC++, ни дотнет. А нужна только метаинформация в компил-тайме.

VD>При этом метаданные на порядок лучше. Ну, а метаданые в компайлтайме нужный не очень сильно. sizeof-а более чем достаточно.


Кому как. Мне так и typeof нужен, и список членов класса, и граф наследования. А дальше уж я б на них шаблоны бы натравил.

VD>Шаблоны и макросы позволяют делать универсальный код вообще без метаданный.


Здрасте. А про то, что сериализацию в шарпе проще и надежней делать, не ты ли распинался? Если б С++ была возможность получить хотя бы список членов класс и перебрать предков класса (в компил-тайме, само собой), сгенерить код сериализации класса на С++ не совтавляло бы почти никакого труда. Пока же приходится для такого перебора изгаляться по всякому. Самое обидное, что у компилятора эта информация есть, но он ей ни за что не поделится...

S>>А тут — уже не прав. Анализ в компил-тайме позволяет...


VD>Никаого анализ в компайлтайме у него небыло.


Естественно, потому как С++ такой информации и не предоставляет.

VD>Он прдлагал создавать структуры орписывающие метаинформацию и анализировать уже ее.


А можно было бы — просто структуры, соответсвующие входным данным. А метаинформацию, сгенеренную для них компилером, вытаскивать в рантайм и анализировать уже ее. Одним шагом меньше — ошибок тоже будет меньше.

VD>А анализировать при компиляции особо нечего.


Это как сказать.

S>> кучу проверок переложить с программиста на компилятор, при этом будет проверен весь сгенерированный код — а в рантайме вполне можешь пару-тройку процентов редко используемого кода, анализируещего метаинформацию, оставить с ошибками.


VD>Звучит здорово. Но реально в приложениях созданных на строкомпайлтаймном С++ рантайм ошибок в разы больше чем чем созданных на шапре.


Ну это у кого как.

VD>Причем приложение переживает такие ошибки куда болезнеей нежели созданное на Шарпе.


Есть живучесть, а есть надежность. Живучесть у шарпного кода может и выше, а вот с надежностью все не так однозначно.

S>>Да никто с ней в плюсах не борется.


VD>А ты почитай постинги Геннадия Васильева повнимательнее.


Мы, видимо, на его постинги с разных позиций смотрим.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[24]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 12:38
Оценка: +1
Здравствуйте, <Аноним>, Вы писали:

А> Сполне нормальная политика. Есть стандарты, которые работают многие годы.


Странно только что с появлением дотнета они вдруг резко перестали В 1.5 планируется столько изменений языка что диву даешься — одни шаблоны с боксингом чего стоят.

А>И если уж написали, то будет собираться и работать всегда и у всех. И не надо каждые полгода грузить себе громадный фреймворк.


Почему не надо? Такая же история.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[37]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.07.03 15:56
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Хорошо, я готов заменить определение "...в сущности является ошибкой дизайна." как двусмысленное на "...провоцирует на дизайн, который влечёт за собой неоправданную потерю быстродействия и снижение надёжности, поскольку контроль целостности перекладывается на время исполнения."

ГВ>>И что от этого изменилось?
AVK>Опять какой то налет необъективности. Почему провоцирует? Я ведь точно так же могу сказать что шаблоны провоцируют создание некомпонентных слабоконфигурируемых приложений.

Хорошо, пусть не "провоцирует", а "...упрощает реализацию такого дизайна, который...".

AVK>>>Вот когда С++ научится распознавать хотя бы свои собственные типы в рантайме из чужих модулей тогда и поговорим. А пока плюсовые шаблоны даже такого не обеспечивают.

ГВ>>Образно выражаясь, плюсовые шаблоны "направлены" не в сторону runtime-распознавания типов, а в сторону "исключения ситуации" распознаывания.
AVK>Вот ты уперся и ничего не хочешь видеть. Еще раз повторяю — наличие или отсутствие такой ситуации никак не зависит от тебя. Если тебе нужно использовать сторонний компонент без исходников то хоть на голове стой — все равно никак rtti ты шаблонами не заменишь.

Ну давай так, сторонний компонент, как ты правильно заметил, для C++, это либо plain-api (значит-исходники), либо классы (значит — тоже исходники), либо какие-то самоописывающиеся интерфейсы (к примеру — COM). Самоописывание интерфейсов нужно для генерации исходников, которые затем будут использоваться мной. Это, фактически, единственный путь использования сторонних объектов в программах на C++. rtti или нечто похожее может понадобиться для анализа данных, получаемых извне, особенно, если дизайн стороннего компонента предполагает такой способ его использования. С точки зрения дизайна моей программы в данном случае rtti будет использован для задачи обработки внешних данных и, кстати, последствия в виде... ну я уже говорил, — никуда не денутся. И моя, кстати, негативная их оценка — тоже, несмотря на то, что это может оказаться единственным выходом. Ну сам посуди: что мне, радоваться что-ли, от того, что я, например получаю какой-нибудь IBase*, для которого надо клепать dynamic_cast<IDerived*>, обрабатывать потенциальные ошибки и т.п?

ГВ>>>>Нет проблем. Ты приписываешь мне категоричное утверждение — "использование рефлекшена = кривой дизайн".

AVK>>>Я не приписываю, оно так и есть. Или ты уже от своих слов отказываешься?
ГВ>>Не отказываюсь. Просто они не означают того, что ты думаешь.
AVK>Это демагогия. Я тебе уже объяснял — смысл у твоей фразы один. Все кто читает этот топик именно так его и восприняли. Да и разъяснять смысл, который ты якобы имел ввиду ты стал далеко не сразу, сначала ты доказывал что именно любое использование rtti суть кривой дизайн.

Если бы смысл моей фразы был один, то и спорить было бы не о чем. И извини, но: а) на каком основании ты расписываешься за всех, кто читает этот топик, и б) смысл своей фразы буду объяснять я, особенно, если собеседники меня не поняли сразу. И ещё раз, я не говорил, что rtti — это абсолютно "кривой" дизайн.

ГВ>>Угу, и ещё о том, что отсутствие рефлекшена в C++ — его чудовищный недостаток.

AVK>Так и есть. В его отсутствие приходиться рожать ужасных монстров вроде СОМ. Достаточно сравнить любой СОМ-класс и аналогичный ему класс дотнета и сразу все становиться понятно. Ты конечно опять будешь возражать, мол это просто СОМ такой кривой, но вот тебе пример:

AVK>
AVK>[Serializable]
AVK>public class TestClass
AVK>{
AVK>    private string _someData;
    
AVK>    public TestClass(string someData)
AVK>    {
AVK>        _someData = someData;
AVK>    }
    
AVK>    public string SomeData
AVK>    {
AVK>        get { return _someData; }
AVK>    }
AVK>}
AVK>


AVK>А вот теперь напиши аналогичный класс на плюсах, так чтобы он:


AVK>1) Мог использоваться отдельно в любом проекте без исходных кодов


Исходный код — необходимое условие для C++ и ты это отлично знаешь. Выполнение этого условия невозможно. Исключение составляет ситуация, когда исходник или информация, достаточная для его восстановления "спарены" с бинарным кодом.

Условие неправомерно.

AVK>2) Мог сериализоваться в бинарный поток и xml


Реализовать схему сериализации несложно, проблема в другом — ты в данном случае требуешь невыполнимого, — реализовать сериализаци на основе описания структуры типа, как это делает дотнет. Верно? Если так, то

Условие неправомерно.

AVK>3) Его экземпляр можно было бы передать по сети


При наличии приёмника на другой машине — несложно.

AVK>4) Обеспечивался бы контроль версий класса


Реализуемо соответствующей инфраструктурой.

AVK>5) Можно было бы создать экземпляр по имени


1. Где создавать?
2. По имени типа или экземпляра?

AVK>6) Можно было бы визуально отредактировать его свойства.


Не надо путать IDE и язык. Напиши-ка мне то же самое на дотнете, но без использования визуального редактора?

Условие неправомерно.

AVK>Вот когда напишешь тогда и сравним. Результаты я думаю будут забавными


Сначала разберёмся с предметом спора, а там посмотрим.

AVK>>>Я тебе ничего не навязываю, я тебя цитирую. Уж извини, но никакими приемами ты не докажешь что твоя абсолютно односмысленная фраза выражала что то совсем другое.

ГВ>>Фраза на самом деле не "абсолютно односмысленная", поскольку содержала неопределённое понятие "в сущности".
AVK>Опять ты пытаешься перевести спор на термины. В общем неубедительно.

Да, но ты, в частности, демонстрируешь или непонимание, или упорное нежелание понять. Вот я и объясняю. Я согласен, мы все не идеальны и у всех разные стереотипы, потому я, например, и склонен уточнять и разъяснять формулировки ровно столько, сколько необходимо.

AVK>>>Твои приравнивания просто не правомерны. Рефлекшен — это технология, RTTI это принцип. Сравнивать их нельзя.

ГВ>>Но тем не менее:
ГВ>>Т.е., рефлекшен реализует rtti.
AVK>Да. Где здесь противоречие?

Нет здесь противоречия. Связка "Но тем не менее" добавлена для выразительности, чтобы лишний раз привлечь внимание читателя к:

...последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti


Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[39]: Будущее C#
От: Sergey Россия  
Дата: 10.07.03 07:22
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Это еще не клинический случай. Бывает куд страшнее. Хтя даже этот код на шарпе был бы короче и понятнее.


А как, кстати, подобный код на шарпе будет выглядеть? Скажем, вызов 2-х функций ( одна — с тремя, другая — с пятью параметрами) внутри некоторого обрамления. Способ, когда первая половина обертки — в конструкторе вспомогательного класса, а вторая — в деструкторе (финализаторе и т.д.), не катит.

VD>Скорее выигрыл. Так как без буста тут бы было еще строк 30-40 кода. Но вот в скорости компиляции проиграл сильно. Ведь если были бы делегаты, то все тоже самое стало бы проще и быстрее.


Делегаты умеют "привязывать" параметры на ходу? А переставлять аргументы местами? Или придется вспомогательные классы/функции писать?

S>>Макросы тоже бывают полезны. Но значительно реже, чем шаблоны.


VD>Шаблонами можно только универсальный код создавать. Это конечно очень часто удобнее.


Да нет, не только. Шаблоны — почти такое же средство кодогенерации, как и макросы. Вот чего они (шаблоны) не умеют — так это работать со строками (и формировать новые читабельные имена) и подставлять код in-place (чтоб возврат из функции сделать, к примеру). А, скажем, сгенерить тип, наследущийся от всех типов из перечисленного списка или функцию, вызывающую заданную статическую функцию функцию для каждого типа из списка — это запросто.

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


Угу.

VD>>>Это не прямая, а обратная аналогия.


S>>Поясни.


VD>Что? Что такое обратная аналогия?


Нет, конечно. Почему ты счел такое сравнение "обратной аналогией"? На мой взгляд, вполне корректное сравнение.

VD>http://www.i-u.ru/biblio/arhiv/books/chelpanov_ul/ec24.asp


В этой статье нет даже слова "обратная"

VD>Ну, и в ya.ru на слова "обратная аналогия" и демагогия.


Уж послал так послал

S>>А кто с этим спорит? __closure, или как она там называется, давно пора в язык.


VD>Ты тему внимательно читал? Тут именно с этим и спорят.


Цитату, плиз. Ничего такого я в этой ветке не заметил.

VD> А еще (и это самое противное) с этим спорят разные Страуструпы и другие хранители традиций из ANSI.


Страуструп — хранитель традиций? Не смеши. Он в основнем С++ и развивал, а пользователи его пинали, чтоб не слишком от С отходил

S>>При чем здесь частичная специализация? Для написания рекурсивных шаблонов обычно вполне хватает полной специализации. Хотя, конечно, часто код в отсутствии поддержки частичной специализации компилятором получается сложнее, чем с частичной специализацией. Но все равно — получается.


S>>А смысл в таком преобразовании? Алгоритм что, понятней от этого стал, что ли?


VD>А то нет? Или читать эзопов язык это щастье?


Нет, конечно. Рекурсия — вполне приемлемый (для меня, по крайней мере ) способ записи алгоритмов. Впрочем, не нравится рекурсия — можно попробовать использовать алгоритмы из boost::mpl, там вроде компил-тайм циклы есть.

S>>А некоторым жалко бошку с указателями работать Про них еще Дейкстра кажись писал.


VD>Вот практика и показывает, что без указателей можно очено даже эффективно объодиться. А там где можно без них, то луче без них. От указателей кроме гемороя мало чего можно получить. Есть конечно обласи, где без них совсем трудно, но к щастью этих областей не так много.


Но уметь работать с ними — надо.

S>>Не, не зря. Там новый (ну не для всех, конечно, он новый) подход к шаблонным извращениям описан.


VD>Заметь, к извращениям. А я бы хотел получать просые и эффектинве решения без оных.


Извращения — это для тренировки мозгов. После которой простые и эффективные решения будут писаться куда проще и эффективней
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[39]: Будущее C#
От: Sergey Россия  
Дата: 10.07.03 07:54
Оценка: -1
Здравствуйте, VladD2, Вы писали:

S>>А не нужен мне ни MC++, ни дотнет. А нужна только метаинформация в компил-тайме.


VD>Дык похоже, что это тперь будет только в дотнете и Яве. Так что выбор не велик. Да и не ясно в чем проблема то? С++ там тот же, только с метаданными.


Мне несколько другая метаинформация нужна.

S>>Кому как. Мне так и typeof нужен, и список членов класса, и граф наследования. А дальше уж я б на них шаблоны бы натравил.


VD>Оно все есть. Вот только шаблны в виду их статичности, ну, никак не прикрунишь. Скорее кодогенератор.


Шаблоны это и есть кодогенератор. Помнишь, я пример сериализации на С++ с кучей тайпдефов кидал? Вот там именно в компил-тайме в библиотеке генерируется код, перебирающий все (заданные в шаблоне) базовые классы и ищущий нужный тип у члена ddxMembers и возвращающий его значение (простым static_cast'ом), если в пользовательском коде была использована шаблонная функция data или field, принимающая параметр нужного типа.

S>> Если б С++ была возможность получить хотя бы список членов класс и перебрать предков класса (в компил-тайме, само собой),


VD>Не батенька. В компайл тайме перебрать — это конечно концепция интересная, но пока никем не реализованная.


Было бы чего перебирать. Обычная рекурсия с условиями за счет специализации с этим на раз справлятся. Книжку Александреску почитай для начала, или сразу в boost::mpl загляни (но там, блин, трудно что-то понять с наскоку).

VD>В дотнете все обычно вуже в рантайме....


Это то и плохо.

S>> сгенерить код сериализации класса на С++ не совтавляло бы почти никакого труда.


VD>Но генерить ты будешь его уже в рантайме или в отдельном тулзе.


Щаз. Я уже умею генерить его компилятором — но приходится дофига тайпдефов писать, и класс от шаблонного наследовать, и еще кучу ограничений соблюдать.

VD>Хотя конечно при наличии полноценного TypeInfo сдалать такую утилиту было бы можно.


Они, кстати, уже есть — OpenC++, например.

S>> Пока же приходится для такого перебора изгаляться по всякому. Самое обидное, что у компилятора эта информация есть, но он ей ни за что не поделится...


VD>Во-во. Тут я полностью согласен. Собственно о том и речь. Просто некоторпые товарищи такой подход считают мовитоном.


Кто именно ?! Пока я только встречал возражения против автоматического вынесения такой информации в рантайм — и с ними полностью согласен. Это работа для стандартной библиотеки, а не для языка.

S>>Естественно, потому как С++ такой информации и не предоставляет.


VD>Ну?! О том и речь. Тот же МС++ дает полную информацию о себе. Т.е. сделать то можно.


Там что, есть иные средства генерации кода, кроме шаблонов и макросов? Или шаблоны атрибуты в качестве параметров понимают? Если нет, то до метаинформации опять в компил-тайме не добраться — ну и нафиг мне такое щастье?

VD>Вот только ортодоксы типа Страуструпа всю малину портят.


Чем же тебе так Страуструп не угодил?

VD>>>А анализировать при компиляции особо нечего.


S>>Это как сказать.


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


Нет.

VD>Тут спору нет. Метаданные могли бы сослужить огромную службу. Но стандрат плюсов просто таки борится с этой идеей.


С какой идеей? Просто идеи метапрограммирования на шаблонах слишком недавно появились — уже после принятия стандарта.

VD>Поверь, у всех.


Проверял на всех ?

VD>Программист пересаженный с плюсов на дотнет резко поднимает продуктивность. Это уже не слова. Это доказано практикой.


Твоей практикой, заметь. Или еще чьей-то?

VD> Есть конечно некоторая доля задачь, которую проще далеть на плюсах, но она все время уменьшается.


Есть, конечно, некоторая доля программистов, которые на бейсике еще быстрее чем на шарпе, писать будут

S>>Есть живучесть, а есть надежность. Живучесть у шарпного кода может и выше, а вот с надежностью все не так однозначно.


VD>Очень даже однозначно. При проектировании еще Явы этот пункт ставили в приоритеты. А уж о дотнете и говорить не приходится.


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

S>>Мы, видимо, на его постинги с разных позиций смотрим.


VD>И тем неменее. Там есть четкий приговор метаданным.


Там есть четкий приговор метаданным в твоем понимании

VD>В общем, займись дотнетом и посмотрим на твои позиции чезе годик.


Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[39]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 10.07.03 15:16
Оценка: +1
Здравствуйте, VladD2, Вы писали:

ГВ>>Ну давай так, сторонний компонент, как ты правильно заметил, для C++, это либо plain-api (значит-исходники), либо классы (значит — тоже исходники), либо какие-то самоописывающиеся интерфейсы (к примеру — COM). Самоописывание интерфейсов нужно для генерации исходников, которые затем будут использоваться мной. Это, фактически, единственный путь использования сторонних объектов в программах на C++. rtti или нечто похожее может понадобиться для анализа данных, получаемых извне, особенно, если дизайн стороннего компонента предполагает такой способ его использования. С точки зрения дизайна моей программы в данном случае rtti будет использован для задачи обработки внешних данных и, кстати, последствия в виде... ну я уже говорил, — никуда не денутся. И моя, кстати, негативная их оценка — тоже, несмотря на то, что это может оказаться единственным выходом. Ну сам посуди: что мне, радоваться что-ли, от того, что я, например получаю какой-нибудь IBase*, для которого надо клепать dynamic_cast<IDerived*>, обрабатывать потенциальные ошибки и т.п?



VD>Забавно ты расуждаешь. Тебе говорят, что это в некоторых случаях единственный виход, а в некоторых не еденственный но намного боле простой. А ты все криво, и криво. Этак я могу обвинить весь мир так как в нем нужно дышать воздухом и нельзя прыгать с небоскребов. Ну, право не серьезно.


Обвинять мир — твоё право. Я не говорю о том, что единственный выход — "кривой"... вот, лучше процитирую себя самого:

ГВ>С точки зрения дизайна моей программы в данном случае rtti будет использован для задачи обработки внешних данных и, кстати, последствия в виде... ну я уже говорил, — никуда не денутся. И моя, кстати, негативная их оценка — тоже, несмотря на то, что это может оказаться единственным выходом.


Разницу чуешь? Это может быть единственным выходом, но я оценивать его всё равно буду негативно (или, если хочешь — с грустью, тоской, щемящим сердцем, великоросской рефлексией, сквозь зелёную бутылку, с поллитрой в руках, скрипя зубами, с самурайским мечом меж зубами, — ряд синонимов можно продолжить), поскольку присущие ему черты неизбежно останутся.

Или ты считаешь, что я должен прыгать от счастья, раз мне пришлось воспользоваться этим, единственным выходом?

Поскольку моя личная негативная оценка не может быть предметом обсуждения, в силу субъективизма и возможной неадекватной её трактовки собеседниками то я: а) отказался от такой формулировки, но б) сформулировал описание характерных черт критикуемого мной подхода более точно.

Поскольку разработчики C++ (Страуструп, во всяком случае, насколько я это знаю) придерживались схожих взглядов, я счёл возможным в декларативной форме присоединиться к ним. Декларативную же и краткую форму выбрал сознательно, поскольку сообщение написал в форум.

Ну как, понятно объяснил? Или стрелочки логических связей нарисовать?

А относительно "в некоторых не еденственный но намного боле простой"... Так опять ты апеллируешь к тому, что разница простой-сложный настолько велика, что это фактически — единственный выход для которого либо справедливо то, что я уже сказал, либо... несправедливо вообще ничего, поскольку "простой" и "сложный" — тоже субъективные оценки.

PS. Да и вообще — иная простота она хуже воровства.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[40]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.03 18:51
Оценка: +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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Будущее C#
От: IT Россия linq2db.com
Дата: 11.07.03 15:42
Оценка: :)
Здравствуйте, Sergey, Вы писали:

S>Ну тут он отчасти прав Но вот если одновременно с расширением анахронизмы сишные повыкидывать, то мог бы полный рулез получиться.


C#?
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[46]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.07.03 06:06
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>К стати в .NET когда надо около сотни проперти подобных полей это придеться писать сотню пропертей в каждом кучу кода к каждому еще по полю с данными, а в моем случае не одно...


Сотня пропертей в одном классе это надо что то в консерватории поправить
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 14.07.03 07:24
Оценка: +1
Здравствуйте, VladD2, Вы писали:

S>>Не, нужно 5 раз. Или 500.


VD>Про for слышал? Удивительно помогает в таких случаях.


Ты дурака-то не включай. Это в разных местах программы надо

S>> Некоторый код — до, некторый — после. В общем случае, можно сказать, что у нас есть некоторый алгоритм, который должен вызвать внутри себя заданную мной функцию и передать ей 1 аргумент. Гадость в том, что функции нужно 5 аргументов — 4 из них надо зафиксировать до передачи функции в алгоритм. Писать функтор для каждого такого вызова не хочется. Высокая производительность не требуется. Как это делается на шарпе?


VD>По разному. Самый правильный выход не доводить до такого маразма. Обычно вместо такого метода делается объект у каторого устанавливаются свойства. Продумывается ОО-модель... Ну, а если вдруг придется вызвать метод... то можно и метод вызвать. Нет особых проблем передать нужные пармаетры.


Круто. Надо еще и сортировку через объектные обертки делать — как это я сразу-то не додумался

VD>Тут лучше приводить примеры описывая, что они делают на словах. А тебе будут прводить примеры того как это решается на шарпе.


Я тебе пример уже в коде привел. И на словах описал. Чего еще не хватает?

S>>Это я и так в курсе. Ты ж знаешь, что в С++ к этому случаю ровно тот же подход.


VD>Не совсем. Там нет finally.


И нафиг не надо.

VD>И единственным не кривым выходом является создание обертки.


Именно. finally — криво.

VD>Что многих ленивых орлов наталкивает на идею использовать goto.

Ну, на то они и орлы

S>>boost::bind(&foo, _2, _1)(5, 10) вызовет foo(10, 5).

VD>Тебе не кажется, что это кривое решение? Не проще ли объявить отдельную функцию-врапер?

Я предпочитаю объявлять объект-враппер. С помощью bind'а, в той же строчке, где этот объект используется И мне не кажется, что это более кривое решение, чем замусоривание кода ненужными врапперами.

VD>В Шарпе тоже хотят ввести подобную фичу. Но в отличии от С++ никто даже не думает, о реализации ее через задницу, ой извени, шаблоны . Будут инлайн-методы. Выглядеть будет примерно так:

VD>
VD>foo(){ foo(10, 5) };
VD>


Вот это действительно будет непонятно

VD>Честно говоря я за всю свою зинь как то ни разу не нуждался в подобных наворотах.


А еще честнее говоря, ты про них и не знал, так?

VD>Видимо не очень часто нужная вещь.


Естественно, легко можно обойтись и без подобных удобств. Но это не значит, что нужно обходится без удобств...

VD>Ты некое решение на заплатках описал. А задачу — нет. Задача — это: вывести некий графический объект...

Ну, уморил... Там работы всего-то на пару месяцев было, щаз ты мне простое и элегантное решение на шарпе через пять минут после получения ТЗ сбацаешь

VD>Это тормоза ГДИ+. Они к нету отношения не имеют. На С++ скорость будет той-же.

Ну дак а че ты его сюда приплел?

VD>Недавно видел генератор отчетов на ГДИ+. Работал не медленнее чем аналоги нэйтивные, но насколько же он их обганял по графическим наворотам?! Да и тормоза не на всех опирациях. А если учесть, что рано или поздно ГДИ+ акселерируют...


Вот когда акселерируют, тогда про него и поговорим А пока мне с профайлером приходится код полировать, никакой GDI+ я использовать не буду.

VD>Нет. И твой пример этому доказательство. Ты вынужден был изпещрить весь код кучей ненужных оберток.


Это были не обертки, а разметка. И делала она в 4 раза больше, чем атрибут "сериалайз".

VD>Посмотри код генерируемый VS в Шарповом или ВБ-эшном проекте.


Вот-вот, генерируемый средой. Концептуально это такие же костыли, как VC'шные класс-визарды. Мне надо все фичи на уровне языка, а не среды.

VD>Код сгенерированный макросами хотя бы можно посмотреть. В шаблонах же это в принципе невозможно.

Зато через шаблоны отладчик нормально ходит, если имена не черезчур длинные.

VD>Скрипты и шаблоны имеют значительно больше отличий чем сходст. Ты пытаешся обощить шаблоны до скриптов. Это подмена понятий.

Ты просто не понял

VD>Ну, так отдал бы предпочтение делегатам в том виде как они есть в дотнете. Хотя это бы потребовало создания человеческого рантайма для С++. Но на худой конец хотя бы клосюр. Хотя это по сути указатель на метод. Только не бездарный как в С++, а грамотный да еще и с неким намеком на объектно-ориентированность.


Одни эмоции. Указатели на члены класса и "клосюр" — принципально разные вещи и друг друга не заменяют. Более того, отсутствие "клосюр" — явная дыра в языке, поскольку то, что у борландов называется __closure, согласно нынешним правилам С++, не имеет типа, однако к нему может быть применен оператор ().

S>>Ссылку можно? Прочитаю, интересно.

VD>Я такю бредатину в фавориты не складываю. Попробуй гуглем. Или спрости у С++-гурьев. Они обычно такие ссылки имеют.

Ладно, буду считать это твоей фантазией, возникшей на почве стойкой личной неприязни к Страуструпу, которого ты считаешь главным виновником несовершенства мира

S>>Это потому, что в одном куске кода смешиваются компайл-тайм и рантайм программа. (раз уж тебе аналогия с сервер/клиент сайд скриптом не нравится )


VD>Это потму, что когджа для решения проблем применяются не предназначенные для этого инструменты, то обычно выходит криво и непонятно. Попробуй открыть консервную банку обычным нажем, а потом консервным и почуствуй разницу. Если не прочуствуещь, то попробуй тоже сделать вилкой. Та же фигня с шаблонами. Не для того их проектировали.


Обратная аналогия, не находишь?

S>>Я такого не утверждал, кстати. Это была очередная аналогия — между шаблонами и указателями в плане понятности кода


VD>Ты сказал, что непонятны они только тем кто с ними работать не умеет. Так вот я умею с ними работать очень неплохо.


С шаблонами? Вряд ли.

S>>Не уходи от темы — речь шла не об ошибках, а исключительно о сложности понимания кода.

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

Перенос проверок в рантайм приводит к тому же — хотя читабельность при этом и не страдает.

VD>Так же фигня с типобезопастностью. Хотя в С++, и в C# можно писать присвоения внутри ифов, но тем не менее читая C#, я уверен, что проблем с этим не будет. А в С++ я вынужден напрягаться, что не пропустить детские ошибки. Для обхода этих проблем многие программисты стараются ставить в if-ах в качестве первого операнда сравнения rvalue. Тагда код вроде: if(WM_XXX = a) однозначно даст ошибку компиляции. Но, во-первых, такой код тяжелее воспринимать, а во-вторых, можно нечяно упустить это из виду и получить час отладки с выпученными галзами. Так что сложность понимания обратно пропорционально безопастности языка.


Вот насчет if'ов и неявных преобразований я с тобой согласен. Раз в пару-тройку месяцев сам на такую граблю наступаю.

S>>Не о том речь. Хотя с "очень малозатратны" вполне можно поспорить


VD>Вперед. Я это проверял на тестах и был паражен насколько эффективно делаются эти проверки.

Угу, только в С++ эти проверки вообще делаются во время компиляции.

VD>>>Проблема, в том, что С++ заставляет тренеровать могзги вместо выполнения основной рабты.

S>>Для меня это как раз достоинство Не так скучно работать.
VD>Знаешь почему пилоты делятся на смелых и старых?

Тебе кода-нибудь мало-мальски сложные вычислительные алгоритмы приходилось реализовывать? Так вот, шаблоны по сравнению с ними — детские игрушки. Но, однако, помогают держать мозги в форме до того момента, когда приходится писать что-нибудь действительно крутозагнутое. А то пишешь месяца два всякие диаложки-окошки, а потом бац — подавай TABU search какой-нибудь...
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[3]: Будущее C# - вот это флейм!!!!!!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 04:04
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Похоже что твой друг — воинствующий динозавр и убеждать его в обратном не стоит

IT>Сори, не в обиду, но выглядит это никак не иначе.

Все динозавры начинают с маленького. Непонравился новый компилятор/рантайм/среда... забил на нее... прошли годы... нужно обосновывать свое пребывание в каменном век...

PS

Все имена вымышленные, а совподения не предномеренные.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будущее C# - вот это флейм!!!!!!!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.07.03 23:53
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

ГВ>>Мда... Слушайте, мож это шутка такая?

LVV>Нет, не шутка. Пишут системы реального времени. Все прошивается, видимо связано с риском крупных аварий.

Я бы сказал, что дело здесь в стереотипах, ну да ладно, не стОит...

LVV>И я своего друга прекрасно понимаю, так же как и Михаила Донского (одного из авторов Каиссы — первого чемпиона по шахматам среди компьютеров). Он, когда переходил с Лексикона на Word, тоже говорил: мне не нравится, когда меня ВЫНУЖДАЮТ платить за то, что мне не фактически НУЖНО.


Да, такую позицию можно понять, но очень не хочется принимать.

LVV>Так и С# — не вижу я особых преимуществ ни перед С++, ни перед Java. У этих языков переносимость на 3 порядка выше, чем у до диеза.


У C# как у языка преимуществ перед C++ никаких нет, но фишка в том, что C# нельзя противопоставлять C++. Это бессмысленно по определению. C# — неотъемлемая часть системы .Net, один из многих языков, которые на ней работают, а C++ — сам по себе язык. Вот здесь
Автор: Геннадий Васильев
Дата: 23.08.02
и здесь
Автор: SergeMS
Дата: 20.08.02
и ещё где-то в "работе" был уже флейм по этому и смежным поводам. Кстати, именно AVK тогда это вполне предметно доказал.

Ровно потому же не стоит заниматься противопоставлениями C++ <-> Java. Java уже достаточно давно позиционируется как платформа, а не как язык.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Будущее C#
От: pidolas  
Дата: 29.09.04 20:17
Оценка: -1
Здравствуйте, Аноним, Вы писали:

А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?


Они уже сейчас существуют.
Будущее C#
От: Аноним  
Дата: 24.06.03 09:38
Оценка:
Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?

02.07.03 08:28: Перенесено модератором из '.NET' — TK
Re: Будущее C#
От: 4D man Россия  
Дата: 24.06.03 10:45
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?


ИМХО, вполне реально.. язык-то, как и сама .NET, очень молодой, если сравнить с C или C++...
Re[2]: Будущее C#
От: Shulapov Россия  
Дата: 24.06.03 11:40
Оценка:
Здравствуйте, 4D man, Вы писали:

--

ну не такой уж и молодой оказывается... для меня было почти шоком
Автор: Plutonia Experiment
Дата: 20.06.03
Одинаковые ошибки не обязательно делать каждый раз, достаточно сделать одну, а затем обращаться к ней по мере необходимости из любого места программы.
Re[3]: Будущее C#
От: 4D man Россия  
Дата: 24.06.03 14:11
Оценка:
Здравствуйте, Shulapov, Вы писали:

S>Здравствуйте, 4D man, Вы писали:


S>--


S>ну не такой уж и молодой оказывается... для меня было почти шоком
Автор: Plutonia Experiment
Дата: 20.06.03

Мда.... хотя и не так уж и удивительно...раз уже была Джава. Вот родись C# до Джавы — было бы круто. А так — всё-равно молодой...даже 5 лет — это не срок...
Re: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.03 15:12
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?


Не не реально. Буст — это затычка проблем языка. В Шарпе и так все неплохо работает. Шаблоны конечно приведут к появлению более безопастных и производительных аналогов существующих классов не не более.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Будущее C#
От: WolfHound  
Дата: 24.06.03 19:34
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Не не реально. Буст — это затычка проблем языка. В Шарпе и так все неплохо работает. Шаблоны конечно приведут к появлению более безопастных и производительных аналогов существующих классов не не более.

Да я бы так категорично не стал высказываться. Например сравни boost\signal и делегаты в C#.
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.03 19:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Да я бы так категорично не стал высказываться. Например сравни boost\signal и делегаты в C#.


Именно что сравнивал. Делегаты намного удобнее. Жаль что медленнее. Зато делегаты позволяют сразу делать асинхронные вызовы и прозрачно использоваться при междоменном взаимодействии. В общем-то это даже проблема не Буста. Это уже общая проблема С++. Все уши и хвосты из-за того, что этот язык не заточен на компонетную разработку.

А на счет катигоричности. Да конечно появление шаблонов откроет пути к совершенству. Вот только завявление о том, что "мощных библиотек, аналогов boost" намного более котегорично, так как по сравнению с Фрэймворкмом Буст мелка библиотечка.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будущее C#
От: WolfHound  
Дата: 25.06.03 04:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Именно что сравнивал. Делегаты намного удобнее. Жаль что медленнее.

И мение функциональны.
template<typename T>
struct list_result
{
    typedef std::list<T> result_type;

    template<typename InputIterator>
    result_type operator()(InputIterator first, InputIterator last) const
    {
        result_type result;
        for(;first!=last;++first)
            result.push_back(*first);
        return result;
    }
};
float Add(int i, float f)
{
    return i+f;
}
float Sub(double i, float f)
{
    return i-f;
}
double Div(double i, float f)
{
    return i/f;
}
double Mul(double i, int f)
{
    return i*f;
}
int main()
{
    namespace lm=boost::lambda;
    boost::signal<float(float,float), list_result<float> > sig;
    sig.connect(&Add);
    sig.connect(&Sub);
    sig.connect(&Div);
    sig.connect(&Mul);

    std::list<float> test=sig(10, 20);
    for_each(test, std::cout<<lm::_1<<"\n");

    return 0;
}

Вывод
30
-10
0.5
200

А на делегатах такое можно?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Будущее C#
От: Poudy Россия  
Дата: 25.06.03 05:07
Оценка:
WH>
WH>template<typename T>
WH>struct list_result
WH>{
WH>    typedef std::list<T> result_type;

WH>    template<typename InputIterator>
WH>    result_type operator()(InputIterator first, InputIterator last) const
WH>    {
WH>        result_type result;
WH>        for(;first!=last;++first)
WH>            result.push_back(*first);
WH>        return result;
WH>    }
WH>};
WH>float Add(int i, float f)
WH>{
WH>    return i+f;
WH>}
WH>float Sub(double i, float f)
WH>{
WH>    return i-f;
WH>}
WH>double Div(double i, float f)
WH>{
WH>    return i/f;
WH>}
WH>double Mul(double i, int f)
WH>{
WH>    return i*f;
WH>}
WH>int main()
WH>{
WH>    namespace lm=boost::lambda;
WH>    boost::signal<float(float,float), list_result<float> > sig;
WH>    sig.connect(&Add);
WH>    sig.connect(&Sub);
WH>    sig.connect(&Div);
WH>    sig.connect(&Mul);

WH>    std::list<float> test=sig(10, 20);
WH>    for_each(test, std::cout<<lm::_1<<"\n");

WH>    return 0;
WH>}
WH>

WH>Вывод
WH>
WH>30
WH>-10
WH>0.5
WH>200
WH>

WH>А на делегатах такое можно?

А на фиг такое нужно?
Re[6]: Будущее C#
От: m.a.g. Мальта http://dottedmag.net/
Дата: 25.06.03 08:09
Оценка:
Здравствуйте, _vovin, Вы писали:

_>
_>| list |
_>list := #(10.0 20.0).
_>#(+ - / *) collect: [:op | list fold: [:a :b | a perform: op with: b]]
_>


Smalltalk? А то что-то я давно его не видел...
... << RSDN@Home 1.1 alpha 1 >>
Re[6]: Будущее C#
От: WolfHound  
Дата: 25.06.03 12:20
Оценка:
Здравствуйте, _vovin, Вы писали:

_>Удивляюсь, как можно приводить абсолютно чудовищный код и утверждать, что это круто.

Я это привел к тому что: Делегаты в .NET не позволяют цеплять функции с другими сигнатурами даже если существует не явное приведение, нельзя из делегата вернуть значение, тем болие нельзя скомбинировать возвращенные значения, если один из методов кинул исключение то остальные не выполнятся, и могое другое что в boost\signal можно сделать легко.
_>Лубой язык с функциями высшего порядка позволит все это сделать с десятой частью тех усилий.
Мы вроде о C# и шаблонах говорим?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Будущее C#
От: mihailik Украина  
Дата: 25.06.03 15:46
Оценка:
VD>Именно что сравнивал. Делегаты намного удобнее. Жаль что медленнее.

Жаль, что на CodeProject нету статьи Delegates Undocumented, в дополнение к Strings Undocumented и Arrays Undocumented. Я поколупался немного в исходниках Rotor и Mono — там есть интерестные детали. Забавные различия.

Делегаты Mono должны работать сильно медленнее Микрософтовских, например.

VD>А на счет катигоричности. Да конечно появление шаблонов откроет пути к совершенству.


А нет ли какой-нибудь толковой статьи на эту тему? Почему шаблоны так уж "откроют путь к совершенству"? Вроде вполне ограниченная технология на непредвзятый взгляд.
... << RSDN@Home 1.0 beta 7a >>
Re[5]: Будущее C#
От: WolfHound  
Дата: 25.06.03 19:00
Оценка:
Здравствуйте, mihailik, Вы писали:

M>А нет ли какой-нибудь толковой статьи на эту тему? Почему шаблоны так уж "откроют путь к совершенству"? Вроде вполне ограниченная технология на непредвзятый взгляд.

Скорее не опытный ИМХО. Александреску читал? boost потрошил?
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.06.03 22:19
Оценка:
Здравствуйте, mihailik, Вы писали:

M>А нет ли какой-нибудь толковой статьи на эту тему? Почему шаблоны так уж "откроют путь к совершенству"? Вроде вполне ограниченная технология на непредвзятый взгляд.


Ненужны никакие статьи. Достаточно научиться писать шаблонизированный код и потом их (шаблонов) все время будет нехватать.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.06.03 22:19
Оценка:
WH>И мение функциональны...

Мусье любитель извращений? Их есть у меня.

using System;
class SignalsTest
{
    delegate double op(double i, double f);

    static double Add(double i, double f){ return i + f; }
    static double Sub(double i, double f){ return i - f; }
    static double Div(double i, double f){ return i / f; }
    static double Mul(double i, double f){ return i * f; }

    static double[] CallAll(op[] opers, double i, double f)
    {
        double[] res = new double[opers.Length];
        for(int k = 0; k < opers.Length; k++)
            res[k] = opers[k](10, 20);
        return res;
    }

    static void PrintDouble(double[] ary)
    {
        foreach(double val in ary)
            Console.WriteLine(val);
    }

    static void Main(string[] args)
    {
        op[] opers = new op[4] 
        {
            new op(Add),
            new op(Sub),
            new op(Div),
            new op(Mul)
        };

        PrintDouble(CallAll(opers, 10, 20));

        Console.ReadLine();
    }
}


Причем это решение еще и боле типбезопасно.

PS

Делегаты делают то ради чего они и были созданы. Делают они это элегантно, но не шустро. Чтобы опнять вес кайф дотнета достаточно попытаться запустить этот пример через сетку (когда вызываемые методы находятся в другом процессе). Или в другом процессе.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Будущее C#
От: ExtraLamer  
Дата: 25.06.03 22:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Скорее не опытный ИМХО. Александреску читал? boost потрошил?


А что такое "Александреску"? {jxe gjxbnfnm
Re[7]: Будущее C#
От: WolfHound  
Дата: 26.06.03 04:48
Оценка:
Здравствуйте, ExtraLamer, Вы писали:

EL>А что такое "Александреску"? {jxe gjxbnfnm

Сам такой
http://www.moderncppdesign.com/
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Будущее C#
От: mihailik Украина  
Дата: 26.06.03 15:18
Оценка:
M>А нет ли какой-нибудь толковой статьи на эту тему? Почему шаблоны так уж "откроют путь к совершенству"? Вроде вполне ограниченная технология на непредвзятый взгляд.

WH>Скорее не опытный ИМХО. Александреску читал?


Не читал. Это статья или толстая книга? Статью бы.

WH>boost потрошил?


Ха! Это получается заплатить вперёд, раньше чем увижу, нужны ли мне стулья.
... << RSDN@Home 1.0 beta 7a >>
Re: Будущее C#
От: Mikhail_T  
Дата: 26.06.03 15:56
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?


Шаблоны в С# вполне реальны я бы даже сказал что их поевление это гарантировано.
На МСДН есть стать про будашее C# так шаблоны собираються реализовать в самом ближайшем будощем работы над ними уже ведуться.
Re[7]: Будущее C#
От: WolfHound  
Дата: 26.06.03 18:14
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Не читал. Это статья или толстая книга? Статью бы.

Это книга А5 на 330 страниц. Не много но читать тяжело крышу сносит особенно по началу.
http://www.moderncppdesign.com/

M>Ха! Это получается заплатить вперёд, раньше чем увижу, нужны ли мне стулья.

А до прочтения книги ты там ни чего не поймешь, да и после трудно.
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.06.03 06:14
Оценка:
Здравствуйте, Mikhail_T, Вы писали:

M_T>Шаблоны в С# вполне реальны я бы даже сказал что их поевление это гарантировано.

M_T>На МСДН есть стать про будашее C# так шаблоны собираються реализовать в самом ближайшем будощем работы над ними уже ведуться.

Работы над ними уже проведены и шаблоны доступны в специальной версии ротора.
... << RSDN@Home 1.1 alpha 1 >>
AVK Blog
Re[6]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 27.06.03 08:30
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Причем это решение еще и боле типбезопасно.


Какие-то странные у некоторых людей понятия о типобезопасности. Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно? Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)?
Re[7]: Будущее C#
От: Lloyd Россия  
Дата: 27.06.03 08:37
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Какие-то странные у некоторых людей понятия о типобезопасности. Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно? Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)?


Потому что компилятор в состоянии увидеть, что передали параметр не того типа и сделать приведение. Для случая с делегатами это не так.
Re[8]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 27.06.03 08:51
Оценка:
Здравствуйте, Lloyd, Вы писали:

_>>Какие-то странные у некоторых людей понятия о типобезопасности. Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно? Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)?

L>Потому что компилятор в состоянии увидеть, что передали параметр не того типа и сделать приведение. Для случая с делегатами это не так.

Для случая с делегатами компилятор в состоянии сделать thunk, который сейчас приходится делать руками. В boost/signal это работает.
Re[10]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 27.06.03 10:23
Оценка:
Здравствуйте, Lloyd, Вы писали:

_>>Для случая с делегатами компилятор в состоянии сделать thunk, который сейчас приходится делать руками. В boost/signal это работает.

L>C++ в этом плане более статичен. В Net-е можно создать делегат на метод, который в момент компиляции вовсе недоступен.

Разница между delegate double op(double i, double f) и boost::signal<double(double,double)> op чисто синтаксическая, никакой большей статичности не наблюдается.

Ключевое место — op oper = new op(Add). Там все доступно.
Re[3]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.06.03 13:28
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Работы над ними уже проведены и шаблоны доступны в специальной версии ротора.


Это не те шаблоны, что будут в дотнете. Все из МС в одни голос говорят, что ресерч ресерчем, а МС МС-ом.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.06.03 13:28
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Какие-то странные у некоторых людей понятия о типобезопасности.


Нормальные.

_> Вот, скажем, implicit operator T() типобезопасен? А встроенное преобразование int в long типобезопасно?


В С++ int и long синонимы (под 32-битными платформами). А вообще приведение безопастно если оно не может привести к переполнениям или обрезаниям. В дотнете приведения тоже работают. Ты можешь передать в делегат int вместо double-а. Но вот приводить один делегат к другому (имеющему другой список параметров) — это опасное действие. И правильно, что оно запрещено.

_> Почему мы можем вызвать метод с параметром типа long, передав ему int, но не можем присвоить delegate void d(int) свою void f(long)?


В отличии от С++ в дотнете без проблем код вызывающий делегаты из массива может находиться в другом исполнимом файле. А код запихивающий методы в массив в дурогом. И кроме контроля типов нет никакой гарантии, что в рантайме не "грохнет".
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.06.03 13:28
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Для случая с делегатами компилятор в состоянии сделать thunk, который сейчас приходится делать руками. В boost/signal это работает.


Главная твоя проблема, что твой ум привык к примитивности С++ в котором компилятор всегда знает все. Дотнет же проектировался как компонентная среда. И обязан обеспечивать функциональность в отсуствии исходников. Плюсы я уже перечислял: компонентность, прозрачность для RPC и асинхронной обработки.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.06.03 13:28
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Разница между delegate double op(double i, double f) и boost::signal<double(double,double)> op чисто синтаксическая, никакой большей статичности не наблюдается.


_>Ключевое место — op oper = new op(Add). Там все доступно.


Да? Ну, тогда создай нам такой же код но чтобы сигнал был объявлен и вызывлся в одной длл, а в другой к нему добавлялся метод (из другой же длл-и).
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.06.03 13:28
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А до прочтения книги ты там ни чего не поймешь, да и после трудно.


Забавное достоинство.

Это кстати одна из главных проблем С++ как языка.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 27.06.03 13:59
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>Разница между delegate double op(double i, double f) и boost::signal<double(double,double)> op чисто синтаксическая, никакой большей статичности не наблюдается.

_>>Ключевое место — op oper = new op(Add). Там все доступно.
VD>Да? Ну, тогда создай нам такой же код но чтобы сигнал был объявлен и вызывлся в одной длл, а в другой к нему добавлялся метод (из другой же длл-и).

А в чем проблема-то, кроме того, что работа с dll вообще в c++ сделана криво? __declspec(dllexport) boost::signal<double(double,double)> op.
Re[4]: Будущее C#
От: sergerus  
Дата: 27.06.03 20:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, AndrewVK, Вы писали:


AVK>Работы над ними уже проведены и шаблоны доступны в специальной версии ротора.


VD>Это не те шаблоны, что будут в дотнете. Все из МС в одни голос говорят, что ресерч ресерчем, а МС МС-ом.


C# Programming Language &mdash; Future Features

это некий документ от microsoft о будущем языка с#

надеюсь что пригодится
... << RSDN@Home 1.0 beta 7a >>
Re[9]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.06.03 20:55
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Для понимания строки "op oper = new op(Add)" в этом самом другом файле компилятору c# необходимо знать тип делегата op и тип функции Add. Если они совпадают, все компилится. Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас, если даже на стандартных плюсах можно соорудить типобезопасный signal, делающий то же самое?


А на кого возложить type casting при вызове такого делегата?
... << RSDN@Home 1.1 alpha 1 (np: тихо) >>
AVK Blog
Re[9]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.06.03 21:46
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Для понимания строки "op oper = new op(Add)" в этом самом другом файле компилятору c# необходимо знать тип делегата op и тип функции Add. Если они совпадают, все компилится. Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас, если даже на стандартных плюсах можно соорудить типобезопасный signal, делающий то же самое?


Да на фиг это никому не нужно. Высасываешь пробему из поальца. Я на практике не разу не видил таких проблем. Если уж один раз возникнет такая проблема, то напишу переходник.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.06.03 21:46
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>А в чем проблема-то, кроме того, что работа с dll вообще в c++ сделана криво? __declspec(dllexport) boost::signal<double(double,double)> op.


Сделай, узнаешь.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Будущее C#
От: WolfHound  
Дата: 28.06.03 09:33
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это кстати одна из главных проблем С++ как языка.

Надо было написать сразу после прочтения трудно.
Например у меня уже почти не возникает вопросов как и почему.

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

VD>Сделай, узнаешь.

Это дефест boost'а, а не С++.
Багрепорт ушол.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 07:34
Оценка:
Здравствуйте, AndrewVK, Вы писали:

_>Если не совпадают, но имеют контравариантные типы, то сейчас происходит ошибка, и, чтобы ее избежать, нам надо руками писать переходник. Полностью типобезопасный, кстати. Почему бы эту рутинную работу не сделать компилятору за нас,

AVK>А на кого возложить type casting при вызове такого делегата?

Я же говорю — на сгенерированный компилятором/джитом переходник. В бусте же как-то все работает.
Re[11]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.06.03 07:48
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Я же говорю — на сгенерированный компилятором/джитом переходник.


О том и речь куда этот переходник засунуть, чтобы потом рефлекшен всякую чешую не показывал.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[10]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 07:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Да на фиг это никому не нужно. Высасываешь пробему из поальца. Я на практике не разу не видил таких проблем. Если уж один раз возникнет такая проблема, то напишу переходник.


Возможно. В форуме по с++ как-то утверждали, что делегаты нафиг никому не нужны.

Разговор начинался вообще с полезности шаблонов, signal — это просто пример. В c++ с помощью шаблонов удалось стандартными средствами реализовать делегаты, по возможностям не уступающие дотнетовским, исходя только из убогого указателя на член класса. С другой стороны, примеры в gyro/samples радуют, и многие вещи из stl/boost в .net не нужны вообще, особенно из-за сборки мусора (конкретнее, из-за отсутствия бардака с указателями/ссылками). Но пока непонятно, многие ли красивости и полезности, зависящие от отсутствующей в gyro явной специализации, перенесутся туда без потерь.

Хотя аналог boost/spirit
Автор: WolfHound
Дата: 31.05.03
, надеюсь, получится
Re[12]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 08:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>О том и речь куда этот переходник засунуть, чтобы потом рефлекшен всякую чешую не показывал.


MS уже смирился с этой чешуей — анонимные методы и, возможно, итераторы реализуются так же. К тому же только на c# до сих пор все было по принципу "что вижу, о том и пою", при компиляции других языков мусора и так хватает.
Re: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.03 13:02
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?


Шаблоны будут, как я понимаю. Не в том виде, как в С++, но все же чтото будет.
Boost имхо смысла нет вводить, тут другой дизайн.
Билиотеки появятся однозначно — от сторонних производителей, от MS и тд.
Они уже появляются.
Уже сейчас некоторые люди начинают портировать в .Net особо вкусные вещи.
Проще всего с COM. Тут в ряде случаев портировать и не надо.
Еще можно ожидать, что перфоманс повысится, может соптимизуют делегаты какие и тд.
Еще момент — .Net можно портировать куда попало.
Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.
Жаву же засунули в телефоны и КПК. .Net тож можно вкинуть.
Вопрос времени.
Re[2]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.06.03 13:23
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

А>>Как считает общественность, реально ли появление в будущем, когда в C# будут введены шаблоны и другие средства, мощных библиотек, аналогов boost?


PE>Шаблоны будут, как я понимаю. Не в том виде, как в С++, но все же чтото будет.


В общем то даже шаблонами их наверное называть не стоит, лучше generic types.

PE>Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.


Знаешь, тут один мой знакомый мой первый проект (сапер на дотнете) практически без правок запустил на PPC.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[3]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.03 13:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.


AVK>Знаешь, тут один мой знакомый мой первый проект (сапер на дотнете) практически без правок запустил на PPC.


А что такое PPC и кто cli mуда прикрутил, где бы это посмареть можно ?
Re[10]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.03 14:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>ЗЫ А ты сам читал Александреску?


Да я вроде и без него в С++ разбирался.

Вот только читать Шарп в разы приятнее.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.03 14:26
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Возможно. В форуме по с++ как-то утверждали, что делегаты нафиг никому не нужны.


Это их проблемы.

_>Разговор начинался вообще с полезности шаблонов,


Про их полезность никто не спорит. Спор идет про виличие Буста и т.п.

_>signal — это просто пример.


Плохой пример. signal — это замазка проблемы. В С++ нет красивого ОО-решения для callback-ов (интерфейсы все же не удобны). Делегат является прямым и законченым решением. Шаблоны в этом случае в общем то не нужны. В С++ же они являются способом решить проблему.

У Шарпа тоже есть свои проблемы которые видимо тоже будут решать шаблонами. Но чем меньше будет таких замазок, тем более чистыми удобным останется язык. И уж точно никакой Буст не сравнится по количеству возможности с библиотекой фрэймворка.

_> В c++ с помощью шаблонов удалось стандартными средствами реализовать делегаты, по возможностям не уступающие дотнетовским,


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

Ты же пытаешся строгую типизацию причислить к недостаткам технологии и на этом основании делашь выводы о их ущербности.

_> исходя только из убогого указателя на член класса. С другой стороны, примеры в gyro/samples радуют, и многие вещи из stl/boost в .net не нужны вообще,


Во-во. О том и речь. В дотнете от шаблонов нужен только полиморфизм типов и параметров.

_> особенно из-за сборки мусора (конкретнее, из-за отсутствия бардака с указателями/ссылками). Но пока непонятно, многие ли красивости и полезности, зависящие от отсутствующей в gyro явной специализации, перенесутся туда без потерь.


Я честно говря вижу только проблему которую возможно помогут обойти шалоны. Это как не странно отсуствие множественного наследования (МН). Мне лично МН нужно только для подключения к классам готовых реализаций. Будем надеяться, что шаблоны помогут обойти ее (за счет обратного наследования, ну, как ATL).

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

_>Хотя аналог boost/spirit
Автор: WolfHound
Дата: 31.05.03
, надеюсь, получится


Возможно. Но предпочел бы более классическую запись. Самое главное что мне нарвится в Шарпе — это удивительная простота чтения исходников написанная другими. И очень охота чтобы это свойство не ушло в небытие.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.03 14:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Сделай, узнаешь.

WH>Это дефест boost'а, а не С++.
WH>Багрепорт ушол.

А. Ну-ну. Интересно как я погу знать о таких вещах даже не пробовав?
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 14:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Плохой пример. signal — это замазка проблемы. В С++ нет красивого ОО-решения для callback-ов (интерфейсы все же не удобны). Делегат является прямым и законченым решением. Шаблоны в этом случае в общем то не нужны. В С++ же они являются способом решить проблему.


Делегат в .net не является прямым решением, это затычка, встроенная в компилятор:

    .class auto ansi sealed nested family AboutBoxDelegate
           extends [mscorlib]System.MulticastDelegate
    {
      .method public hidebysig specialname rtspecialname 
              instance void  .ctor(object 'object',
                                   native int 'method') runtime managed
      {
      } // end of method AboutBoxDelegate::.ctor

      .method public hidebysig virtual instance void 
              Invoke() runtime managed
      {
      } // end of method AboutBoxDelegate::Invoke

      .method public hidebysig newslot virtual 
              instance class [mscorlib]System.IAsyncResult 
              BeginInvoke(class [mscorlib]System.AsyncCallback callback,
                          object 'object') runtime managed
      {
      } // end of method AboutBoxDelegate::BeginInvoke

      .method public hidebysig newslot virtual 
              instance void  EndInvoke(class [mscorlib]System.IAsyncResult result) runtime managed
      {
      } // end of method AboutBoxDelegate::EndInvoke


И для каждого делегата такая бодяга генерится заново именно из-за отсутствия шаблонов.

В отличие от делегатов, boost/signal — прямое и законченное решение на шаблонах (тут рассказали про глюки с dll, но это поправимо и естественно для такой молодой и некоммерческой библиотеки, как boost), не требующее специальной поддержки компилятора.

VD>И уж точно никакой Буст не сравнится по количеству возможности с библиотекой фрэймворка.


Это ортогональные вещи, одно другому только помогло бы.

VD>Это не првада. И тебе уже это гворили.


Про глюк в boost 1.30.0? Говорили, что багрепорт ушел.

VD>На С++ вообще нельзя создать 100%-ой замены делегатам. Делегаты принципиально компонентно-ориентированны. Их можно использовать без исходных кодов


Что значит "принципиально компонентно-ориентированны"? Для использования делегата необходимо на момент компиляции иметь доступ к типу делегата и переменной этого типа. При этих условиях на c++ можно использовать сигналы, не имея исходников чужой dll. Различия только в синтаксисе.

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


Это достоинство не делегатов, а автоматического маршалинга параметров, работающего через рефлексию и атрибуты.

_>> исходя только из убогого указателя на член класса. С другой стороны, примеры в gyro/samples радуют, и многие вещи из stl/boost в .net не нужны вообще,

VD>Во-во. О том и речь. В дотнете от шаблонов нужен только полиморфизм типов и параметров.

В бусте от шаблонов тоже нужен только полиморфизм типов и параметров

VD>Я честно говря вижу только проблему которую возможно помогут обойти шалоны. Это как не странно отсуствие множественного наследования (МН). Мне лично МН нужно только для подключения к классам готовых реализаций. Будем надеяться, что шаблоны помогут обойти ее (за счет обратного наследования, ну, как ATL).


Спешу расстроить. gyro/docs/generics/csharp.html:

The base class and base interfaces of a class may not be type parameters:

class Extend<V> : V { ... } 
    // Error, the base class may not be a 
    // type parameter
Re[13]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.03 15:02
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Делегат в .net не является прямым решением, это затычка, встроенная в компилятор:


_>

_>


Это не затычка. Не туда смотришь. Написано же — рантайм менеджед вместо IL менеджед
Кроме того, многие методы разных объектов в шарпе сделаны в нативном коде.
Таже болезнь и в жаве.
Так нельзя сравнивать. Эдак получится, что все, окромя С++ — затычки.
Re[14]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 15:12
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Так нельзя сравнивать. Эдак получится, что все, окромя С++ — затычки.


Далеко не всегда. Попытки сделать на C++ рефлексию или сборку мусора — тоже затычки.
Re[15]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.06.03 15:17
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

PE>>Так нельзя сравнивать. Эдак получится, что все, окромя С++ — затычки.


_>Далеко не всегда. Попытки сделать на C++ рефлексию или сборку мусора — тоже затычки.


В С++ другая парадигма. Для С++ нужен только компилятор.
Для шарпа этого уже недостаточно.

Потому и нежен рефлекшн и тд. Поскольку язык сделан максимально безопастным, делегаты сделаны в нем нативными средсвами.
Re[16]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 30.06.03 15:25
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Поскольку язык сделан максимально безопастным, делегаты сделаны в нем нативными средсвами.


Никакой связи нет. Сигналы, например, построены на типобезопасных указателях на члены. Небезопасными в c++ являются static_cast на потомка и reinterpret_cast, которые не используются в реализации сигналов. Есть, правда, одно исключение (внутри any_cast используется static_cast вместо dynamic_cast), но оно сделано в целях эффективности и перед ним явно проверяется, что тип правильный.
Re[16]: Будущее C#
От: WolfHound  
Дата: 30.06.03 16:38
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А. Ну-ну. Интересно как я погу знать о таких вещах даже не пробовав?

А что ты хотел? boost _бесплатная, эксперементальная_ библиотека.
Там просто мелкий недочет который можно исправить за пару часов.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Будущее C#
От: WFrag США  
Дата: 01.07.03 02:52
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Да я вроде и без него в С++ разбирался.

WH>Я тоже так думал...

WH>Из предисловия Скотта Мейерса

WH>

WH>Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.


Я не свалился , я был в восторге . Там, кстати, явно проглядывается лямбда-исчисление и функциональное программирование, по-моему. typedef — введение переменной, Func<A,B,C>::Result — вызов функции. Извращенно немножко, но похоже.
... << RSDN@Home 1.1 beta 1 >>
Re[6]: Будущее C#
От: alexkro  
Дата: 01.07.03 03:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, mihailik, Вы писали:


M>>А нет ли какой-нибудь толковой статьи на эту тему? Почему шаблоны так уж "откроют путь к совершенству"? Вроде вполне ограниченная технология на непредвзятый взгляд.

WH>Скорее не опытный ИМХО. Александреску читал? boost потрошил?

А что, Александреску C# with generics в своей книге использует? Generics & templates — это разные вещи. Не нужно их возможности приравнивать.
Re[5]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.03 06:13
Оценка:
Здравствуйте, alexkro, Вы писали:

A>Спорный вопрос. C# generics ничего общего с шаблонами не имеют.


Ну насчет ничего общего это ты загнул, но действительно — дженерики и плюсовые шаблоны это не одно и то же.

A>Пока что я для них одно применение вижу — типизированные контейнеры. Никакой новой парадигмы программирования они не откроют. Даже такая простая вещь как policy-based programming не станет возможна в C#.


Дженерики сделаны специально под дотнет. В них нет определенного функционала темплейтов, зато есть кое что, чего в темплейтах нет. Напиример темплейты в рантайме не видны, а дженерики видны. В общем каждому свое. Что такое policy-based programming я не знаю, если объяснишь что ты под этим подразумеваешь то народ подскажет как подобное реализуется в дотнете.
И еще, писать на дотнете, так как ты это делал на С++ не стоит, ничего хорошего из этого не выдет. Другая идеология, другие паттерны.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[12]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.03 06:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>ЗЗЫ Я не против C# мне он самому нравится. Но мне не нравится то что С++ недооценивают и сильно.


А как его должны дооценивать?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[13]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.03 06:23
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Делегат в .net не является прямым решением, это затычка, встроенная в компилятор:


Ты не путай делегат и событие, это не одно и то же. event в шарпе это действительно фича компилятора, а вот делегат поддерживается рантаймом. Достаточно поглядеть в исходники ротора.

_>В отличие от делегатов, boost/signal — прямое и законченное решение на шаблонах (тут рассказали про глюки с dll, но это поправимо и естественно для такой молодой и некоммерческой библиотеки, как boost), не требующее специальной поддержки компилятора.


Шаблоны ущербны в принципе — это не компонентное решение и никогда им не будет. Шаблоны вон в МС++ есть, только от этого толку никакого. Для дотнета нужно решение, которое способно работать в многокомпонентной и распределенной среде. Все на шаблонах красиво и хорошо, пока мы работаем в пределах одного процесса. Как только нам нужно вылезти за пределы процесса то все становится намного печальнее и вся красота пропадает. А если еще нам нужно чтобы было взаимодействие разных машин то все становится совсем печально.
Затычка на шаблонах для С++ для работы в распределенной среде тем не менее есть, только называется она не boost а ATL.
Вот когда в дотнете появяться дженерики тогда и будем посмотреть.

_>Что значит "принципиально компонентно-ориентированны"?


Значит что вызовы делегата из другого домена, процесса, машины типизированные и прозрачные.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[14]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 01.07.03 07:13
Оценка:
Здравствуйте, AndrewVK, Вы писали:

_>>Делегат в .net не является прямым решением, это затычка, встроенная в компилятор:

AVK>Ты не путай делегат и событие, это не одно и то же. event в шарпе это действительно фича компилятора, а вот делегат поддерживается рантаймом. Достаточно поглядеть в исходники ротора.

Конечно, поддерживается. И поддержка логично разделена на несколько частей — в bcl сам MulticastDelegate, в vm — магия, а компилятор генерит обертку над MulticastDelegate, подставляя туда параметры метода. И вдруг появляются generics, которые именно для того вроде и нужны, чтобы подставлять в шаблоны конкретные типы, но делегаты уже сделаны без них. Неортогональный дизайн

_>>Что значит "принципиально компонентно-ориентированны"?

AVK>Значит что вызовы делегата из другого домена, процесса, машины типизированные и прозрачные.

Вызовы методов из другого домена, процесса, машины в дотнете тоже типизированные и прозрачные, но это не повод говорить, что в c++ нельзя создать полноценную замену методам.

Если не доходить до утверждений, что на c++ нет даже классов и методов, потому что нет рефлексии и сериализации, то чего из делегатов не хватает в сигналах?
Re[15]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.07.03 07:23
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>>>Делегат в .net не является прямым решением, это затычка, встроенная в компилятор:

AVK>>Ты не путай делегат и событие, это не одно и то же. event в шарпе это действительно фича компилятора, а вот делегат поддерживается рантаймом. Достаточно поглядеть в исходники ротора.

_>Конечно, поддерживается. И поддержка логично разделена на несколько частей — в bcl сам MulticastDelegate, в vm — магия, а компилятор генерит обертку над MulticastDelegate, подставляя туда параметры метода. И вдруг появляются generics, которые именно для того вроде и нужны, чтобы подставлять в шаблоны конкретные типы, но делегаты уже сделаны без них. Неортогональный дизайн


Еще ничего не извесно, а ты паникуешь. Шаблонов пока нет и спорить об это смысла нет, что это плохой дизайн.
На данный момент все сделано хорошо.


_>>>Что значит "принципиально компонентно-ориентированны"?

AVK>>Значит что вызовы делегата из другого домена, процесса, машины типизированные и прозрачные.

_>Вызовы методов из другого домена, процесса, машины в дотнете тоже типизированные и прозрачные, но это не повод говорить, что в c++ нельзя создать полноценную замену методам.


Расскажи как это можно сделать по простому в С++. Всегда нужно писать чтото еще дополнительно и много. Или использовать COM\DCOM, что тоже не всегда просто.
Re[15]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.03 07:33
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Конечно, поддерживается. И поддержка логично разделена на несколько частей — в bcl сам MulticastDelegate, в vm — магия, а компилятор генерит обертку над MulticastDelegate, подставляя туда параметры метода. И вдруг появляются generics, которые именно для того вроде и нужны, чтобы подставлять в шаблоны конкретные типы, но делегаты уже сделаны без них. Неортогональный дизайн


Твой вариант?

_>Вызовы методов из другого домена, процесса, машины в дотнете тоже типизированные и прозрачные,


Естественно. А в чем проблема?

_>но это не повод говорить, что в c++ нельзя создать полноценную замену методам.


Делегат это замена скорее не методу, а интерфейсу.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[16]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 01.07.03 07:42
Оценка:
Здравствуйте, AndrewVK, Вы писали:

_>>Конечно, поддерживается. И поддержка логично разделена на несколько частей — в bcl сам MulticastDelegate, в vm — магия, а компилятор генерит обертку над MulticastDelegate, подставляя туда параметры метода. И вдруг появляются generics, которые именно для того вроде и нужны, чтобы подставлять в шаблоны конкретные типы, но делегаты уже сделаны без них. Неортогональный дизайн

AVK>Твой вариант?

В идеале класс Delegate вполне может оставаться магией, а MulticastDelegate должен быть нормальным классом, параметризованным типом метода. Сейчас, если хочется сделать свою обработку результатов вызовов зарегистрированных в делегате методов (например, не вываливаться после первого исключения или скомбинировать возвращаемые значения), приходится руками делать GetInvocationList и Invoke. Так как делегаты sealed, это приходится писать в отдельном методе. В бусте сигналы параметризуются обработчиком возвращаемых значений.

_>>Вызовы методов из другого домена, процесса, машины в дотнете тоже типизированные и прозрачные,

AVK>Естественно. А в чем проблема?

Если признать, что делегаты в c++ неполноценны из-за отсутствия сериализации, то приходится признать, что классы и методы тоже неполноценны. Но тогда говорить вообще не о чем.

AVK>Делегат это замена скорее не методу, а интерфейсу.


Делегат — замена указателю на функцию или член класса.
Re[17]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.03 08:03
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

AVK>>Делегат это замена скорее не методу, а интерфейсу.


_>Делегат — замена указателю на функцию или член класса.


Ты путаешь причину со следствием — указатель на функцию это уже следствие. Главная обязанность делегата — обеспечить типизированный колбек. Ровно то же можно сделать используя интерфейсы, что с успехом демонстрирует тот же свинг, да и в дотнете кое где встречается. Просто интерфейсы не очень удобны, поскольку приходится описывать отдельный класс. Вот для упрощения и вводится указатель на член класса или делегат. С такой точки зрения бустовский signal выглядит несколько ущербно, не согласен?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[18]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 01.07.03 08:19
Оценка:
Здравствуйте, AndrewVK, Вы писали:

_>>Делегат — замена указателю на функцию или член класса.

AVK>Ты путаешь причину со следствием — указатель на функцию это уже следствие. Главная обязанность делегата — обеспечить типизированный колбек. Ровно то же можно сделать используя интерфейсы, что с успехом демонстрирует тот же свинг, да и в дотнете кое где встречается.

Про нетипизированные колбеки говорить вообще не будем, потому что они не используются даже в с++. То, что для обратного вызова можно использовать несколько механизмов — хорошо, но интерфейс в c# синтаксически аналогичен базовому классу с чисто виртуальными методами в c++, а делегат в c# — некоей конструкции на основе указателя на член, называемой signal.

AVK>Просто интерфейсы не очень удобны, поскольку приходится описывать отдельный класс. Вот для упрощения и вводится указатель на член класса или делегат.


Указатели на члены беднее делегатов — они не multicast и не содержат внутри this для вызываемого метода. В билдере были нестандартные closure, но с приближением компиляторов к стандарту стал возможен и прямой путь — написать аналог делегата на стандартном c++, используя указатели на члены.

AVK>С такой точки зрения бустовский signal выглядит несколько ущербно, не согласен?


Как он может выглядеть ущербно, если выполняет ту же задачу и даже имеет похожий синтаксис?
Re[6]: Будущее C#
От: alexkro  
Дата: 01.07.03 09:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


A>>Спорный вопрос. C# generics ничего общего с шаблонами не имеют.


AVK>Ну насчет ничего общего это ты загнул, но действительно — дженерики и плюсовые шаблоны это не одно и то же.


A>>Пока что я для них одно применение вижу — типизированные контейнеры. Никакой новой парадигмы программирования они не откроют. Даже такая простая вещь как policy-based programming не станет возможна в C#.


AVK>Дженерики сделаны специально под дотнет. В них нет определенного функционала темплейтов, зато есть кое что, чего в темплейтах нет. Напиример темплейты в рантайме не видны, а дженерики видны.


Мне, вообщем-то, не очень интересны различия в runtime. А вот с точки зрения языков программирования, что есть в generics, чего в шаблонах нет?

AVK>В общем каждому свое. Что такое policy-based programming я не знаю, если объяснишь что ты под этим подразумеваешь то народ подскажет как подобное реализуется в дотнете.


Вот хороший пример.

AVK>И еще, писать на дотнете, так как ты это делал на С++ не стоит, ничего хорошего из этого не выдет. Другая идеология, другие паттерны.


Я думаю, ты имеешь в виду "на C# как на C++". Тогда согласен. Языки очень сильно различаются.
Re[7]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 01.07.03 09:29
Оценка:
Здравствуйте, alexkro, Вы писали:

Так ведь на C++ сейчас тоже писать нормально нельзя.

Как язык C++ хорош, но вот наследие прошлого....

Сколько времени приходится тратить хотя бы на то, чтобы определение было бы перед использованием...
Re[8]: Будущее C#
От: alexkro  
Дата: 01.07.03 09:49
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>Здравствуйте, alexkro, Вы писали:


DG>Так ведь на C++ сейчас тоже писать нормально нельзя.


Интересно, а это к чему было сказано? Вопрос вкуса: мне можно, тебе нельзя...

DG>Как язык C++ хорош, но вот наследие прошлого....


DG>Сколько времени приходится тратить хотя бы на то, чтобы определение было бы перед использованием...


Раздельная компиляция, понимаешь . Эх, сколько я сегодня времени на forward определения потратил. Определял-определял, определял-определял, душили-ду... к чему это я?!
Re[7]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.03 09:53
Оценка:
Здравствуйте, alexkro, Вы писали:

AVK>>Дженерики сделаны специально под дотнет. В них нет определенного функционала темплейтов, зато есть кое что, чего в темплейтах нет. Напиример темплейты в рантайме не видны, а дженерики видны.


A>Мне, вообщем-то, не очень интересны различия в runtime. А вот с точки зрения языков программирования, что есть в generics, чего в шаблонах нет?


Вот о том и речь что ты пытаешься мерять дотнет плюсовым аршином. В отличие от С++ рассматривать C# отдельно от его рантайма не имеет смысла, обычный язык почти без изысков.

AVK>>В общем каждому свое. Что такое policy-based programming я не знаю, если объяснишь что ты под этим подразумеваешь то народ подскажет как подобное реализуется в дотнете.


A>Вот хороший пример.


404

AVK>>И еще, писать на дотнете, так как ты это делал на С++ не стоит, ничего хорошего из этого не выдет. Другая идеология, другие паттерны.


A>Я думаю, ты имеешь в виду "на C# как на C++".


Нет, именно на дотнете.

A>Тогда согласен. Языки очень сильно различаются.


Языки как раз отличаются не очень сильно, сильно отличается рантайм.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[14]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.03 09:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>А как его должны дооценивать?

WH>Короче пока вы с Владом не прочитаете Александреску я с вами на тему C++ vs C# разговаривать не буду ибо ваши знания о С++ очень поверхтносны.

Не хами. Я точно так же могу сказать что пока ты не напишешь проект размером больше 1М на шарпе я с тобой на тему C++ vs C# разговаривать не буду.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[9]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 01.07.03 09:54
Оценка:
Здравствуйте, alexkro, Вы писали:

DG>>Так ведь на C++ сейчас тоже писать нормально нельзя.


A>Интересно, а это к чему было сказано?


К тому, что C++ выбирать в качестве языка разработки не удобно(не выгодно и т.д.)

Одна из основных проблем, что C++ стал слишком тяжелым и слишком уж с тяжелым наследием прошлого.


зы
A> Вопрос вкуса: мне можно, тебе нельзя...

Попробуйте, пожалуйста, без личных наездов
Re[10]: Будущее C#
От: alexkro  
Дата: 01.07.03 10:02
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>Здравствуйте, alexkro, Вы писали:


DG>>>Так ведь на C++ сейчас тоже писать нормально нельзя.


A>>Интересно, а это к чему было сказано?


DG>К тому, что C++ выбирать в качестве языка разработки не удобно(не выгодно и т.д.)


DG>Одна из основных проблем, что C++ стал слишком тяжелым и слишком уж с тяжелым наследием прошлого.


Это твое личное мнение.


DG>зы

A>> Вопрос вкуса: мне можно, тебе нельзя...

DG>Попробуйте, пожалуйста, без личных наездов


Не принимай близко к сердцу. Вопрос, действительно, вкуса.
Re[19]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.03 10:13
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>>>Делегат — замена указателю на функцию или член класса.

AVK>>Ты путаешь причину со следствием — указатель на функцию это уже следствие. Главная обязанность делегата — обеспечить типизированный колбек. Ровно то же можно сделать используя интерфейсы, что с успехом демонстрирует тот же свинг, да и в дотнете кое где встречается.

_>Про нетипизированные колбеки говорить вообще не будем, потому что они не используются даже в с++. То, что для обратного вызова можно использовать несколько механизмов — хорошо, но интерфейс в c# синтаксически аналогичен базовому классу с чисто виртуальными методами в c++,


Не совсем. Но с точки зрения колбеков и с учетом наличия в плюсах МН примерно похоже. Хотя есть конечно некоторые различия вроде explicit реализации интерфейсов. Или например метод интерфейса на дотнете можно реализовать подходящим по сигнатуре методом базового класса.

_> а делегат в c# — некоей конструкции на основе указателя на член, называемой signal.


А вот это уже не факт. Делегат совершенно отдельная конструкция. В целях упрощения его конечно можно считать указателем, но при рассмотрении собственно сущности такое приближение не очень корректно. Делегат это совершенно особая конструкция. Точно так же его можно назвать упрощенным вариантом интерфейса с единственным методом и встроенным мультикастингом.

AVK>>Просто интерфейсы не очень удобны, поскольку приходится описывать отдельный класс. Вот для упрощения и вводится указатель на член класса или делегат.


_>Указатели на члены беднее делегатов — они не multicast и не содержат внутри this для вызываемого метода.


Именно. Потому и говорю что делегат лучше рассматривать как интерфейс.

_> В билдере были нестандартные closure, но с приближением компиляторов к стандарту стал возможен и прямой путь — написать аналог делегата на стандартном c++, используя указатели на члены.


Все равно это как то через задний проход, опять же непонятки с тем как сделать указатель и на метод экземпляра и на метод класса (static в терминах дотнета). closure в борланде были все таки более честным решением и лучше было бы если бы их добавили в стандарт языка.

AVK>>С такой точки зрения бустовский signal выглядит несколько ущербно, не согласен?


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


Ну знаешь, ту же задачу можно и на ассемблере выполнить. И синтаксис именно что похожий, но все таки более неудобный. Не говоря уж о том чтов рантайме вобще с шаблонами все печально.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[8]: Будущее C#
От: alexkro  
Дата: 01.07.03 10:15
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>Дженерики сделаны специально под дотнет. В них нет определенного функционала темплейтов, зато есть кое что, чего в темплейтах нет. Напиример темплейты в рантайме не видны, а дженерики видны.


A>>Мне, вообщем-то, не очень интересны различия в runtime. А вот с точки зрения языков программирования, что есть в generics, чего в шаблонах нет?


AVK>Вот о том и речь что ты пытаешься мерять дотнет плюсовым аршином. В отличие от С++ рассматривать C# отдельно от его рантайма не имеет смысла, обычный язык почти без изысков.


Да, я сравниваю языки программирования. Среда исполнения мне не особенно важна. И потом под одну и туже среду на разных языках писать можно.

AVK>>>В общем каждому свое. Что такое policy-based programming я не знаю, если объяснишь что ты под этим подразумеваешь то народ подскажет как подобное реализуется в дотнете.


A>>Вот хороший пример.


AVK>404


Нехороший сайт попался. Нужно поискать "policy basic_string" на www.cuj.com. Первая ссылка — это она и есть.

AVK>>>И еще, писать на дотнете, так как ты это делал на С++ не стоит, ничего хорошего из этого не выдет. Другая идеология, другие паттерны.


A>>Я думаю, ты имеешь в виду "на C# как на C++".


AVK>Нет, именно на дотнете.


A>>Тогда согласен. Языки очень сильно различаются.


AVK>Языки как раз отличаются не очень сильно, сильно отличается рантайм.


На C++ тоже можно для .NET программировать и при этом использовать большинство его (C++) идиом. Именно это я и делаю уже в течении некоторого времени. Кстати, этот подход (C++ для .NET) будет еще более сильно развит в следующей версии VC++.
Re[11]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.07.03 10:22
Оценка:
Здравствуйте, alexkro, Вы писали:

DG>>К тому, что C++ выбирать в качестве языка разработки не удобно(не выгодно и т.д.)

DG>>Одна из основных проблем, что C++ стал слишком тяжелым и слишком уж с тяжелым наследием прошлого.
A>Это твое личное мнение.

С++ — это профессиональный инструмент. Новичку в нем тяжело.
Нынче хороший С++ программист сродни хорошему шахматисту — и тех и других мало. Разница лишь в том, что программисты на С++ зарабатывают деньги этим самым С++, а шахматисты зарабатывают чаще всего не шахматами.

С одной стороны это хорошо — мощь потрясающая. С другой — изучать этот язык надо долго.
Новичку нельзя доверить суппорт проекта на С++ — дохлый номер.
Такие чудеса, что демонстрирует Александреску, нельзя, к сожалению, внедрять повсюду.
Re[16]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.03 15:18
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>В С++ другая парадигма. Для С++ нужен только компилятор.

PE>Для шарпа этого уже недостаточно.

Посмотри на МС++. Там есть и делегаты и рефлексия, и никаких проблем с самим С++ не возникло.

PE>Потому и нежен рефлекшн и тд. Поскольку язык сделан максимально безопастным, делегаты сделаны в нем нативными средсвами.


Рефлешон — это полноценная информация о типах. И то что ее нет в С++ всего лишь вина авторов языка.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Будущее C#
От: WolfHound  
Дата: 01.07.03 15:25
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Расскажи неучам, объясни на пальцах.

Я уже много раз говорил про книгу. Там написано очень подробно и куда длоходчевей чем я смогу расказать.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Будущее C#
От: WolfHound  
Дата: 01.07.03 15:25
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Не хами.

Простите погорячился. Просто мне надоело что вы с Владом орете на каждом шагу о примитивности С++ при этом имея весьма отдаленные представления о нем.
AVK>Я точно так же могу сказать что пока ты не напишешь проект размером больше 1М на шарпе я с тобой на тему C++ vs C# разговаривать не буду.
Не боись напишу. Следующея версия системы над которой я сейчас работаю будет под .NET. И догадайся кто настоял не переходе.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.07.03 15:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Plutonia Experiment, Вы писали:


PE>>В С++ другая парадигма. Для С++ нужен только компилятор.

PE>>Для шарпа этого уже недостаточно.

VD>Посмотри на МС++. Там есть и делегаты и рефлексия, и никаких проблем с самим С++ не возникло.


Я про нативный имею ввиду.


PE>>Потому и нежен рефлекшн и тд. Поскольку язык сделан максимально безопастным, делегаты сделаны в нем нативными средсвами.

VD>Рефлешон — это полноценная информация о типах. И то что ее нет в С++ всего лишь вина авторов языка.

Сделать то можно. Но это же громозко. Проще обойти каким другим путем.
Re[17]: Будущее C#
От: WolfHound  
Дата: 01.07.03 16:12
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

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

По человечески это на 330 страниц в книге.
PE>Там подробнее == а мой папа лучше знает и тд и тд.
PE>Это демагогия.
Есть такое понятие RTFM дак вот "Современное проектирование на С++" Андрей Александреску это мануал. Зачем пересказывать мануал? Ты часто пересказываешь MSDN?
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.07.03 16:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Есть такое понятие RTFM дак вот "Современное проектирование на С++" Андрей Александреску это мануал. Зачем пересказывать мануал? Ты часто пересказываешь MSDN?


Я часто цитирую оттуда всякую всячину и даю ссылки на конкретные примеры.

Значит у тебя аргумент — Александруску и своей головой думать не надо ?
Re[12]: Будущее C#
От: mihailik Украина  
Дата: 01.07.03 16:22
Оценка:
VD>Я честно говря вижу только проблему которую возможно помогут обойти шалоны. Это как не странно отсуствие множественного наследования (МН). Мне лично МН нужно только для подключения к классам готовых реализаций.

В принципе, решаемо с помощью Reflection.Emit.
... << RSDN@Home 1.1 beta 1 >>
Re[19]: Будущее C#
От: WolfHound  
Дата: 01.07.03 17:10
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Значит у тебя аргумент — Александруску и своей головой думать не надо ?

Хочешь знать что можно сделать на шаблонах?
Без проблем попробуй разберись
Автор: WolfHound
Дата: 22.06.03
. Хотя для меня и тех кто освоил идеи Александреску проблем не составит.
Можно почитать эти ветки По мотивам SWL
Автор: WolfHound
Дата: 27.04.03
, Виртуальные конструкторы 2
Автор: WolfHound
Дата: 09.06.03
, Быстрое сохраниние/восстановление членов класса
Автор: Keeper_andrew
Дата: 15.04.03
.
Еще вопросы?
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Будущее C#
От: ExtraLamer  
Дата: 01.07.03 22:59
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Здравствуйте, Аноним, Вы писали:


PE>Можно в КПК засунуть .Net. Не в том виде конечно, как под виндой, но все же можно.

PE>Жаву же засунули в телефоны и КПК. .Net тож можно вкинуть.
PE>Вопрос времени.

Когда вы говорите КПК — то уточняйте что это PPC, а не Palm. Лапы Microsoft и до телефонов, и до телевизоров и до унитазов доползёт. Всё верно — это вопрос времени.
Re[16]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.07.03 06:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>Не хами.

WH>Простите погорячился. Просто мне надоело что вы с Владом орете на каждом шагу о примитивности С++ при этом имея весьма отдаленные представления о нем.

Нормальные мы имеем представления, не переживай. А о применимости не зря говорим, поскольку наболело. Мы вот вчера с retalik на эту тему общались, у него мнение такое же, хотя до недавнего времени, как я понимаю, он писал на С++. Он тоже наверное весьма отдаленные представления имеет?

AVK>>Я точно так же могу сказать что пока ты не напишешь проект размером больше 1М на шарпе я с тобой на тему C++ vs C# разговаривать не буду.

WH>Не боись напишу.

Вот когда напишешь тогда и поговорим. А пока что это, извини за резкость, просто треп.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[10]: Будущее C#
От: alexkro  
Дата: 02.07.03 07:57
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>Вот о том и речь что ты пытаешься мерять дотнет плюсовым аршином. В отличие от С++ рассматривать C# отдельно от его рантайма не имеет смысла, обычный язык почти без изысков.


A>>Да, я сравниваю языки программирования. Среда исполнения мне не особенно важна.


AVK>В дотнете крайне важна. Без нее языки не имеют смысла. В дотнете по сути все сделано наоборот — шарп разрабатывался под рантайм, а не рантайм под шарп. Собственно это в той или иной степени имеет отношение ко всем языкам дотнета.


A>>Нехороший сайт попался. Нужно поискать "policy basic_string" на www.cuj.com. Первая ссылка — это она и есть.


AVK>Чего то там много, нет времени все это читать. Объясни на пальцах что это такое и какие у него бенефиты.


AVK>>>Языки как раз отличаются не очень сильно, сильно отличается рантайм.


A>>На C++ тоже можно для .NET программировать


AVK>Ну и что? Если укладываться в рамки CLR то от С++ остануться рожки да ножки.


A>>и при этом использовать большинство его (C++) идиом.


AVK>Большинство идиом в managed коде? Не получится.


A>>Кстати, этот подход (C++ для .NET) будет еще более сильно развит в следующей версии VC++.


AVK>Откуда дровишки?


А нужны ли они тебе?

PS: на остальное тоже нет желания отвечать. Только время зря терять, если честно.
Re[12]: Будущее C#
От: alexkro  
Дата: 02.07.03 08:22
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Здравствуйте, alexkro, Вы писали:


DG>>>К тому, что C++ выбирать в качестве языка разработки не удобно(не выгодно и т.д.)

DG>>>Одна из основных проблем, что C++ стал слишком тяжелым и слишком уж с тяжелым наследием прошлого.
A>>Это твое личное мнение.

PE>С++ — это профессиональный инструмент.


А нам значит нужны какие-то другие инструменты.

PE> Новичку в нем тяжело.


Как и везде.

PE>Нынче хороший С++ программист сродни хорошему шахматисту — и тех и других мало. Разница лишь в том, что программисты на С++ зарабатывают деньги этим самым С++, а шахматисты зарабатывают чаще всего не шахматами.


PE>С одной стороны это хорошо — мощь потрясающая. С другой — изучать этот язык надо долго.

PE>Новичку нельзя доверить суппорт проекта на С++ — дохлый номер.

Чистая дискриминация. Ты подразумеваешь, что остальные C++ не поймут?

PE>Такие чудеса, что демонстрирует Александреску, нельзя, к сожалению, внедрять повсюду.


Это не чудеса, а просто новая парадигма дизайна и программирования. Можно ее принять и использовать, а можно программировать как раньше. C++ все поддерживает, недаром его называют multi-paradigm.
Re[13]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.07.03 08:32
Оценка:
Здравствуйте, alexkro, Вы писали:

PE>> Новичку в нем тяжело.

A>Как и везде.

Нет. Не везде. На шарп я перепрыгнул езо всяких книг, мануалов и тд. Просто нача писать. Потом были курсы, которые я проспал. В жаве тож самое. Парень ушел от нас и пересел без проблем на жаву. В вот на С++ так не перепрыгнешь.

PE>>Нынче хороший С++ программист сродни хорошему шахматисту — и тех и других мало. Разница лишь в том, что программисты на С++ зарабатывают деньги этим самым С++, а шахматисты зарабатывают чаще всего не шахматами.

PE>>С одной стороны это хорошо — мощь потрясающая. С другой — изучать этот язык надо долго.
PE>>Новичку нельзя доверить суппорт проекта на С++ — дохлый номер.

A>Чистая дискриминация. Ты подразумеваешь, что остальные C++ не поймут?

Это не дискриминация. Больше всего рядовых игроков, рядовых программистов.
Даеко не всякий сможет подойти к помосту и выжать 300 кг. Хотя теоретически это по плечу каждому.
С шахматами и С++ тоже самое.


PE>>Такие чудеса, что демонстрирует Александреску, нельзя, к сожалению, внедрять повсюду.


A>Это не чудеса, а просто новая парадигма дизайна и программирования. Можно ее принять и использовать, а можно программировать как раньше. C++ все поддерживает, недаром его называют multi-paradigm.

В дизайне я не увидел ничего нового. Все это было, только реализовывалось более громоздко, но более наглядно.
Я называю подход Александреску — концентрированный С++
Re[21]: Будущее C#
От: alexkro  
Дата: 02.07.03 08:54
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Несколько гвоздей в гроб подхода Александруску.


PE>1. Сам факт, что книга такого масштаба появилась только сейчас говорит о том, что C++ многогранен.


Многогранен — это точно. Но что значит "только сейчас"? Книга написана в 2001-м, некоторые идеи (например, static_checker<> — так его раньше Александреску называл) были у него уже опубликованы в 1999-м. Про Typelist он тоже в 1999-м проговорился. Все это — почти сразу после принятия стандарта.

PE>2. Этот же факт говорит о том, что мало кто понимает всю мощь этого языка.


Что-ж, многие еще до сих пор не знают, что такое "using namespace std". Разве это о чем-либо говорит? Просто люди когда-то научились программировать на C++ (на самом деле на C with classes), и с тех пор им было пофиг свои знания обновить.
Re[22]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.07.03 09:00
Оценка:
Здравствуйте, alexkro, Вы писали:

PE>>1. Сам факт, что книга такого масштаба появилась только сейчас говорит о том, что C++ многогранен.


A>Многогранен — это точно. Но что значит "только сейчас"? Книга написана в 2001-м, некоторые идеи (например, static_checker<> — так его раньше Александреску называл) были у него уже опубликованы в 1999-м. Про Typelist он тоже в 1999-м проговорился. Все это — почти сразу после принятия стандарта.


Все равно поздно. Как ни крути. Уже 2003 год.


PE>>2. Этот же факт говорит о том, что мало кто понимает всю мощь этого языка.


A>Что-ж, многие еще до сих пор не знают, что такое "using namespace std". Разве это о чем-либо говорит? Просто люди когда-то научились программировать на C++ (на самом деле на C with classes), и с тех пор им было пофиг свои знания обновить.


Таких, к сожалению, большинство. Новозможно всем сразу стать профессионалами уровня Александреску.
Re[22]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.07.03 10:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>Вопрос не в том что можно, вопрос в том что нужно. хъ

WH>Былабы возможность,а применение найдется. Нука изобрази на C#

Мне чего, заняться нечем разбираться в коде, да потом еще и реализовывать на шарпе. Нужно будет, реализую.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[21]: Будущее C#
От: WolfHound  
Дата: 02.07.03 10:17
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>3. Это же означает, что не только новичек, но и середнячек не потянет все рулезы концентрированного С++.

Если человек хочет его можно дотяуть до этого уровня очень быстро.

PE>Такая техника сродни уровню гросстмейстера мирового класса в шахматах — их очень мало.

Лесть тебя не спасет.

PE>4. Я не вижу отражения существующих тенденций — компонентное программирование и тд.

PE>__declspec(__dllexport) — это далеко не то, что надо сейчас.
Согласен. Но во первых и на этом можно очень много, во вторых есть много задачь где это не актуально.

PE>В тех примерах, что ты привел, много интересного. Но все те же вещи можно сделать настолько просто, что любой новичек сразу подхватит проект.

Ты бы лучше смотрел интерфейс, а не реализацию. Например тотже boost может легко использовать любой новичек однако понять как именно он работает довольно не просто.

PE>В примере про виртуальные конструкторы ты(или не ты) изобрел моникеры и интерфейсы, которые есть в COM, которые есть в других средах под такими же или другими именами, например локаторы.

Это я сделал на спор. Один дельфист не верил что такое возможно.

PE>Я не вижу реальной неоходимости внедрять это. Невозможно заставить людей выучить все.

Ну сериализация очень практична, SWL это потенциально очень мощьная, гибкая и лаконичная оконная библиотека только надо комуто ее написать.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Будущее C#
От: WolfHound  
Дата: 02.07.03 10:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Мне чего, заняться нечем разбираться в коде, да потом еще и реализовывать на шарпе. Нужно будет, реализую.

А что тут разбираться это просто пример того как можно написать несколько стандартных кирпичиков, а потом из них собирать классы.
А как на C# можно из стандартных кирпичиков собирать классы?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.07.03 10:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

PE>>Таких, к сожалению, большинство. Новозможно всем сразу стать профессионалами уровня Александреску.


WH>Это проще чем кажется. Стоит только захотеть.

В том то и проблема, что далеко не все смогут захотеть.
Очень сложно собрать хотябы пять человек, у которых будет абсолютно одинаковые цели, хобби, интересы и тд.

У нас работает над проектом примерно 40 человек в 4 городах в разных странах.
У каждого свое хобби, своя семья или отсутвие оной. Свои интересы. Своя жизнь.

Где нам взять 40 профессионалов уровня Александреску ?


WH>А если не хочешь то по крайней мере не надо орать что С++ примитивин. Именно это меня раздражает.

Я такого не говорил. Я сказал, что это профессинальный инструмент, многогранный, мощный и тд.
В этом его недостаток.
Re[24]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.07.03 10:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>Мне чего, заняться нечем разбираться в коде, да потом еще и реализовывать на шарпе. Нужно будет, реализую.

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

Просто чтобы прочитать такой объем исходников нужно немалое время. Я тебе могу тоже сейчас из януса кинуть кусок исходников большого объема и попросить реализовать это на С++.

WH>А как на C# можно из стандартных кирпичиков собирать классы?


Что значит из стандартных кирпичиков? Ты имеешь ввиду подключение реализаций? Пример того как это реализовать я приводил в форуме по дотнету.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[24]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.07.03 10:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, AndrewVK, Вы писали:


AVK>>Мне чего, заняться нечем разбираться в коде, да потом еще и реализовывать на шарпе. Нужно будет, реализую.

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


И ты столько кода нагнал, чтобы показать всю прелесть множественного наследования ?
Посмотри мои примеры на ATL — для этого не нужен Александреску.

Теперь по существу. Дизайн C# сделан специально для того, что бы такое конструирование запретить.

1. Разные компилеры далеко не 100% совместимы.
2. В компонентном программирования такие навороты не дают преимущества.
3. Сложность обнаружения и исправления ошибки. Пока не узнаешь стандарт и особенности компилера, не знаешь даже, где твоя ошибка, что это за ошибка, и твояли это ошика.
4. Сложность внесения изменений.
5. Ненаглядный дизайн.

Конструирование необходимо для быстрого решения прикладной проблемы.
В Шарпе это делается несколько другими средствами.


class ATL_NO_VTABLE CLayer : 
    public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CLayer, &CLSID_Layer>,
    public ISupportErrorInfo,
    public IDispatchImpl<IObjectImpl<ILayer>, &IID_ILayer, &LIBID_VPISCRIPTINGLib>,
    public IProvideClassInfo2Impl<&CLSID_Layer, &IID_ILayer, &LIBID_VPISCRIPTINGLib>,
    public CLeakHelper



class ATL_NO_VTABLE CNpNode : 
    public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CNpNode, &CLSID_NpNode>,
    public ISupportErrorInfo,
    public IConnectionPointContainerImpl<CNpNode>,
    public IConnectionPointImpl<CNpNode, &IID_IAdviseSink>,
    public IConnectionPointImpl<CNpNode, &IID_IVPIAdviseSink>,
    public IConnectionPointImpl<CNpNode, &IID_IVPIObjectAdviseSink>,
    public IPropertyNotifySinkCP<CNpNode>,
    public IDispatchImpl<INpNode, &IID_INpNode, &LIBID_NPDATALib>,
    public CNpDataBinder<CNpNode, t_nod>,
    public INpDataObject,
    public IPerPropertyBrowsing
Re[25]: Будущее C#
От: WolfHound  
Дата: 02.07.03 14:38
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Просто чтобы прочитать такой объем исходников нужно немалое время. Я тебе могу тоже сейчас из януса кинуть кусок исходников большого объема и попросить реализовать это на С++.

Если бы ты потратил хотябы минуту то понял бы что там все повторяется и разобрался бы за следующие 2 мнуты.

AVK>Что значит из стандартных кирпичиков? Ты имеешь ввиду подключение реализаций? Пример того как это реализовать я приводил в форуме по дотнету.

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

A>Здравствуйте, VladD2, Вы писали:


VD>>Да конечно появление шаблонов откроет пути к совершенству.


A>Спорный вопрос. C# generics ничего общего с шаблонами не имеют.


Да? Ты хоть гуру CLI-gyro (проект МС-ресерча добавляющий generics к SSCLI)? Один к одному шаблоны. Только слегка упрощенные, ну, и идея шаблонов развита так что шаблонными можно делать даже интерфейсы.

A> Пока что я для них одно применение вижу — типизированные контейнеры.


Почему только контейнеры? Любые алгоритмы толерантные к типам можно будет выражать с их помощью. Хотя бесспорно, что коллекции — это самое важное место где можно применять шаблоны.

A> Никакой новой парадигмы программирования они не откроют.


А новой парадигмы и не нужно. Нужно расширение дотнета позволяющее писать более эффективные и безопастные приложения. Парадигмы же достаточно и той что есть.

A> Даже такая простая вещь как policy-based programming не станет возможна в C#.


Что ты под этим понимаешь?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 15:07
Оценка:
Здравствуйте, alexkro, Вы писали:

A>Да, я сравниваю языки программирования. Среда исполнения мне не особенно важна. И потом под одну и туже среду на разных языках писать можно.


Это примерно так же как сравнивать скоростные характиристики автомобилей плюя на двигатели. Бло быстрее Волга или мерседес? Тут так же...

Для С++ рантай действительно не так важен. Он был изобретен до популяризации компонентного подхода и практически не имеет рантайма. В его терминах рантай практически равен билблиотеке. В дотнете же все совсе не так. Отсюда многие возможности языка — это возможности рантайтам. Та же компонентность — это заслуга рантайма, а не языка. Ведь даже С++ будучи портирован под дотнет становится прекрасным компонентноориентированным языком.

A>Нехороший сайт попался. Нужно поискать "policy basic_string" на www.cuj.com. Первая ссылка — это она и есть.


Ну, ты бы привел сслыку заведомо качественно описывающую то что хочешь именно ты. А то мы тут зароемся.

A>На C++ тоже можно для .NET программировать и при этом использовать большинство его (C++) идиом. Именно это я и делаю уже в течении некоторого времени. Кстати, этот подход (C++ для .NET) будет еще более сильно развит в следующей версии VC++.


Тогда должен понимать чем МС++ отличается от обычного С++. Именно эти отличия АВК и имел в виду.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 15:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

A>>и при этом использовать большинство его (C++) идиом.

AVK>Большинство идиом в managed коде? Не получится.

Все до одной. Другой вопрос что этот менеджед-код не будет совместим с CLS.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 15:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>А как его должны дооценивать?

WH>Короче пока вы с Владом не прочитаете Александреску я с вами на тему C++ vs C# разговаривать не буду ибо ваши знания о С++ очень поверхтносны.

Я бы на твоем мнении не стал делать заявлений о чужишь знаниях если ты не можешь их адекватно оценить.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Будущее C#
От: mihailik Украина  
Дата: 02.07.03 15:09
Оценка:
A>>Кстати, этот подход (C++ для .NET) будет еще более сильно развит в следующей версии VC++.

AVK>Откуда дровишки?


+1
... << RSDN@Home 1.1 beta 1 >>
Re[16]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 15:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

IT>>Неужели один прочитанный учебник может сделать из вчерашнего студента закоренелого профи?

WH>Нет но начальные знания дать может, а у них и этого нет.

Я плякаль.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Будущее C#
От: WolfHound  
Дата: 02.07.03 16:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я бы на твоем мнении не стал делать заявлений о чужишь знаниях если ты не можешь их адекватно оценить.

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

VD>Что понимается под списками? Реализация коллекций? Я вроде все более менее известные изучал по исходинкам. Не думаю, что товаришь может больше чем разработчики библиотек вроде stl, ATL, Boost...

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

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

Ну если только в дизайне программы, а где не так в этом случае?
VD>Шарп же полная противоположенность. Приятно было бы если Шарп стал ближе к С++ по возможностям. Но пусть это будет не в ущерб простотое и удобству.
К сожалению это не возможно. Либо возможности либо простота. Также я не спорю что для некоторых задачь шарп лучше подходит я сам настоял не переходе нашей конторы на шарп ибо для нашей АСУТП самое то.
Однако если нужно выжать из машины все что возможно то у шарпа против плюсов нет шансов.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Будущее C#
От: WolfHound  
Дата: 02.07.03 16:19
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что ты под этим понимаешь?

Влад очень прошу прочитай Александреску и сразу исчезнет куча вопросов.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Будущее C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.07.03 16:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Я бы на твоем мнении не стал делать заявлений о чужишь знаниях если ты не можешь их адекватно оценить.

WH>Re[12]: Будущее C#
Автор: VladD2
Дата: 02.07.03
Судя по этому посту я прав на 100%


Скорее неправ на 100%. Перечитай ссылку, что сам дал
Re[17]: Будущее C#
От: WolfHound  
Дата: 02.07.03 16:40
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Скорее неправ на 100%. Перечитай ссылку, что сам дал
Нда? Он спутал списки типов и обобщенные контейнеры что далеко не одно и тоже и предназначены для совершенно разных целей.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Будущее C#
От: mihailik Украина  
Дата: 02.07.03 16:53
Оценка:
A>>>Кстати, этот подход (C++ для .NET) будет еще более сильно развит в следующей версии VC++.

AVK>>Откуда дровишки?


A>А нужны ли они тебе?


Ты чего, ты чего? Просвети, интерестно, что там в будующем дотнетовском за тучи сгущаются
... << RSDN@Home 1.1 beta 1 >>
Re[16]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 18:10
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, AndrewVK, Вы писали:


AVK>>Не хами.

WH>Простите погорячился. Просто мне надоело что вы с Владом орете на каждом шагу о примитивности С++ при этом имея весьма отдаленные представления о нем.

А накаком основании у тебя такое самомнеие? Буду спорить, что я тебя в реальном программировании на плюсах за пояс заткну. Я на плюсах писал еще 10 лет назад. И за плечами имею несколько серьезнийших проктов. Не думаю, что одна книжка (пусть даже самая крутая) сильно поднимит мой скил в области С++. Конечно не монстр в этой области, но моиз знания об этом языке уж точно нельзя называть "отдаленными".

Короче, кончай хамить. Такие заявления здесь себе не позволяют даже самые опотные гуру. А от тебя я их точно терпеть не намерен.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 18:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Я бы на твоем мнении не стал делать заявлений о чужишь знаниях если ты не можешь их адекватно оценить.

WH>Re[12]: Будущее C#
Автор: VladD2
Дата: 02.07.03
Судя по этому посту я прав на 100%


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

WH>Нда? Он спутал списки типов и обобщенные контейнеры что далеко не одно и тоже и предназначены для совершенно разных целей.


Я спросил что ты имеешь в виду под этими словами.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 21:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Хочешь знать что можно сделать на шаблонах?

WH>Без проблем попробуй разберись
Автор: WolfHound
Дата: 22.06.03
. Хотя для меня и тех кто освоил идеи Александреску проблем не составит.

WH>Можно почитать эти ветки По мотивам SWL
Автор: WolfHound
Дата: 27.04.03
, Виртуальные конструкторы 2
Автор: WolfHound
Дата: 09.06.03
, Быстрое сохраниние/восстановление членов класса
Автор: Keeper_andrew
Дата: 15.04.03
.

WH>Еще вопросы?

Я тебя не удевлю если скажу, что все это можно сделать и на Шарпе (т.е. без шаблонов)? Причем решения будут даже более красивыми.

Так что твои примеры скорее являются доказательством высказанной мною мысли, о том что 90% использования шаблонов в С++ является затыканием дырок языка. И вызваны прощетами в языке.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 21:02
Оценка:
Здравствуйте, alexkro, Вы писали:

A>Многогранен — это точно. Но что значит "только сейчас"? Книга написана в 2001-м, некоторые идеи (например, static_checker<> — так его раньше Александреску называл) были у него уже опубликованы в 1999-м. Про Typelist он тоже в 1999-м проговорился. Все это — почти сразу после принятия стандарта.


Ты помнишь когда появился С++? Я вот 10 лет назад его изучал. А многие приколы с шаблонами только пару месяцев назад стало возможно скомпилировать на одном из самых популярных из компиляторв (VC).

A>Что-ж, многие еще до сих пор не знают, что такое "using namespace std". Разве это о чем-либо говорит? Просто люди когда-то научились программировать на C++ (на самом деле на C with classes), и с тех пор им было пофиг свои знания обновить.


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

WH>Это проще чем кажется. Стоит только захотеть.


Жаль, что мало кому хочется. Да?

WH>А если не хочешь то по крайней мере не надо орать что С++ примитивин. Именно это меня раздражает.


А кто это говорил? Тебе говорят, что он тяжел и во многом отстал от жизни. Цитату можешь привести?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 21:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

Ты вместо того чтобы доблить тонны кода просто скажи что хочешь сказать. Пойми, тут никто даже до середины твой код не дочитал.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 21:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>А как на C# можно из стандартных кирпичиков собирать классы?

Да! Ну ты крут. Тебе явно нужно отходить от плюсво. А то даже такую простую вещь как множественное наследавание ты превращаешь в страшного монстра на шаблонах.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 21:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Если бы ты потратил хотябы минуту то понял бы что там все повторяется и разобрался бы за следующие 2 мнуты.


Гы-гы.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 21:02
Оценка:
Здравствуйте, mihailik, Вы писали:

VD>>Я честно говря вижу только проблему которую возможно помогут обойти шалоны. Это как не странно отсуствие множественного наследования (МН). Мне лично МН нужно только для подключения к классам готовых реализаций.


M>В принципе, решаемо с помощью Reflection.Emit.


Мне не нужно "в принципе". Мне нужно просто, удобно и быстро. В С++ я делал примерно так:


C1<class Base>
{
  void Method1()
    {
      // Море кода...
        Base * pBase = (Base *)this;
      int i = pBase->SomeUniversalWork();
        // Еще поре кода использующее значение i...
    }
    int SomeUniversalWork(){ return 0; }
};

С2 : public C1<C2>
{
  // Методы класса C2.
    int SomeUniversalWork()
    {
      return m_x / m_y; // В общем любые вычисления...
    }
};

С3 : public C1<C2>
{
  // Методы класса C2.
    int SomeUniversalWork()
    {
      return m_x * m_y; // В общем любые другие вычисления...
    }
};


Короче, я легко создавал базовые реализации и даже взаимодействовал с классом насдедником. При этом мне даже были ненужны виртуальные методы (ведь еще на этапе компиляции 100%-но известно метод какого класса будет вызыван.

Если использовать виртуальные методы, то и шаблонов будет не нужно:

C1
{
  void Method1()
    {
      // Море кода...
      int i = SomeUniversalWork();
        // Еще поре кода использующее значение i...
    }
    virtual int SomeUniversalWork() = 0;
};

С2 : public C1
{
  // Методы класса C2.
    int SomeUniversalWork()
    {
      return m_x / m_y; // В общем любые вычисления...
    }
};

С3 : public C1
{
  // Методы класса C2.
    int SomeUniversalWork()
    {
      return m_x * m_y; // В общем любые другие вычисления...
    }
};


Короче, просто, удобно и быстро. Причем быстро, как с точки зрения написания, так и выполнения (при условии наличия хорошего оптимизирующего компилятора).
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 21:02
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Конечно, поддерживается. И поддержка логично разделена на несколько частей — в bcl сам MulticastDelegate, в vm — магия, а компилятор генерит обертку над MulticastDelegate, подставляя туда параметры метода. И вдруг появляются generics, которые именно для того вроде и нужны, чтобы подставлять в шаблоны конкретные типы, но делегаты уже сделаны без них. Неортогональный дизайн


Нормальный дизай. Шаблоны делают не тоже самое что делегаты. Более того, на С++ нужно вывернуться на изнанку, чтобы на шаблонах сэмулировать делегаты. И даже с этими вывертами они являются обманом времени компиляции и непригодны когда нужно рантайм-решение.

Если шаблоны в шарпе сделают как следует, то скорее всего можно будет определять параметры делегатов как шаблонные типы. Это несомненно усилит возможности делегатов.

_>Вызовы методов из другого домена, процесса, машины в дотнете тоже типизированные и прозрачные, но это не повод говорить, что в c++ нельзя создать полноценную замену методам.


Каким методам? Делегатам видимо... Дык можно. Вот посмотри на КОМ и КОРБУ. Прекрасные доказательства того, что это кривой путь.

_>Если не доходить до утверждений, что на c++ нет даже классов и методов, потому что нет рефлексии и сериализации, то чего из делегатов не хватает в сигналах?


Ну, про отсуствие классов и методов — это ты конечно сам придумал. А вто отсуствие полноценного рантайма конечно явно отсуствует.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.03 21:28
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

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

PE>>>Потому и нежен рефлекшн и тд. Поскольку язык сделан максимально безопастным, делегаты сделаны в нем нативными средсвами.

VD>>Рефлешон — это полноценная информация о типах. И то что ее нет в С++ всего лишь вина авторов языка.

PE>Сделать то можно. Но это же громозко. Проще обойти каким другим путем.


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

VD>>А. Ну-ну. Интересно как я погу знать о таких вещах даже не пробовав?

WH>А что ты хотел? boost _бесплатная, эксперементальная_ библиотека.
WH>Там просто мелкий недочет который можно исправить за пару часов.

И вот в чем засада. Нет ни одной библиотеки делающая тоже самое что делегаты. Разве что DCOM или CORBA использовать. Но это уже будет не языковое решение и уж точно не такое локоничное, как сигналы.

Ну, а хотеб бы я чтобы страуструп перестал впадать в старческий маразм и понял, что нужно принимать новое и расширять язык. Или придумывать средства расширения языка более действенные чем шаблоны. Правда тогда это уже будет конструктор. Нечто вроде PL1.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Будущее C#
От: Andir Россия
Дата: 03.07.03 00:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Да я вроде и без него в С++ разбирался.

WH>Я тоже так думал...

WH>Из предисловия Скотта Мейерса

WH>

WH>Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.


Вот что-что а я бы посоветовал Владу глянуть всё таки эту книжку ... Там есть над чем посмеяться, самые очевидные вещи решаются такими уродскими способами (реализация, а не задумка ) и всё это подаётся под таким соусом, как откровение ...
Правда до главы со списками я ещё не дошёл, но эта книжка прекрасный повод для критики С++ ... Язык морально устаревает и люди вроде Александреску пытаются показать, что на С++ можно делать и кое-что новое, что в том же Шарпе делается просто и лаконично ...
А самое главное, что важно для программиста это ну очень трудное чтение исходников, потому что оно неочевидное. Простые вещи скрываются под таким набором конструкций в которых в жисть эту вещь не узнаешь. В голову приходит только одна аналогия (особенно связанная с форматированием исходников — когда темплейтные определения разносят по строчкам) — ассемблер нашего века.

WH>Со стула я не свалился но долго был в шоке.

Посмотрим, посмотрим ... но подозрения, что там наворотили уже есть особенно после темплейта Type2Type.

C Уважением, Andir!
<-- using(RSDN@Home 1.1 alpha 1) {/* Работаем */} -->
Re[18]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 00:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ты путаешь причину со следствием — указатель на функцию это уже следствие. Главная обязанность делегата — обеспечить типизированный колбек. Ровно то же можно сделать используя интерфейсы, что с успехом демонстрирует тот же свинг, да и в дотнете кое где встречается. Просто интерфейсы не очень удобны, поскольку приходится описывать отдельный класс. Вот для упрощения и вводится указатель на член класса или делегат. С такой точки зрения бустовский signal выглядит несколько ущербно, не согласен?


Нет. Сигналы как раз и есть эмуляция делегатов. Своеобразная, но эмуляция. Проблема в том как это сделано! Это форменное удаление гланд через анус автогеном. И очередная демострация затыкания ущербности языка средствами использования шаблонов не по назначению. Виртуожно? Бесспорно! Бред? Несомненно! По сути делегат (если отбросить его компонентную природу в дотнете) является указателем на метод экземпляра.

По сути делегаты — это ОО-указатели на фнукции из С++. Т.е. теже средства колбэка, но объектноориентированные.

Аналога в С++ нет. Вместо него был введен уродливый и плохо применимый указатель на функцию класса. Надеюсь понятно почему данные слова выделены?

Так вот в бусте создана целая гора кода, чтобы сэмулировать такое простое решение. Если в С++ наплевать на типобезопастность, но написать такую фитюльку ничего не стоит.

Так что сигналы являются прекрасным подрверждением того, что с одной стороны С++ великий язык позвляющий творить казалось бы невозможное (с саим собой), но с другой — это устаревший и ущербный язык в котором для реализации минимальных удобств нужно молотить горы кода.

Можно взразить, но ведь на сегодня эти гору за частую написаны! Да. Но во что это выливается? На любой плевок нужно создать целый отдельный класс! Это приводить к неимоверным затратам времени на компиляцию. Один из наших проектов компилируется 25 минут на Атлон 1400! И это как раз в основном из-за шаблонов. Причем наши шаблоны бустовским не чета.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Будущее C#
От: m.a.g. Мальта http://dottedmag.net/
Дата: 03.07.03 03:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, WolfHound, Вы писали:


WH>>А тебе не кажется что если бы разговор шол о просто коллекциях то Мейерс бы не свалился со стула?


VD>А мне все равно. Короче, мой вопрос остался без ответа.


Это коллекции типов. Причем работа с ними идет во время компиляции.
... << RSDN@Home 1.1 beta 1 >>
Re[7]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 05:54
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>В них нет определенного функционала темплейтов,


VD>Можно узнать какого?


Ссылку на whitepaper с описанием изменений языка в .NET 2.0 давали неоднократно, различиям темплейтов и дженериков там посвящена отдельная глава.

AVK>>И еще, писать на дотнете, так как ты это делал на С++ не стоит, ничего хорошего из этого не выдет. Другая идеология, другие паттерны.


VD>Ну, ну. Это уже ты загнул. Писать можно так же.


Можно, вот только результатом этого как раз и являются вопли о неправильности шарпа.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[11]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 05:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Все до одной. Другой вопрос что этот менеджед-код не будет совместим с CLS.


Да? И ты берешься сделать к примеру класс с МН менеджед? Не путай пожалуйста IL-код и-managed код. Когда ты объявляешь класс gc то очень многие фичи становяться недоступны.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[21]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 06:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я тебя не удевлю если скажу, что все это можно сделать и на Шарпе (т.е. без шаблонов)? Причем решения будут даже более красивыми.


VD>Так что твои примеры скорее являются доказательством высказанной мною мысли, о том что 90% использования шаблонов в С++ является затыканием дырок языка. И вызваны прощетами в языке.


Я обычно в таких случаях предлагаю реализовать аналог конфигуратора януса . Исходники есть, даже статья есть.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 06:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>Просто чтобы прочитать такой объем исходников нужно немалое время. Я тебе могу тоже сейчас из януса кинуть кусок исходников большого объема и попросить реализовать это на С++.

WH>Если бы ты потратил хотябы минуту то понял бы что там все повторяется и разобрался бы за следующие 2 мнуты.

Ну уж нет. По сравнению с исходниками на шарпе это жутко непонятная каша.

AVK>>Что значит из стандартных кирпичиков? Ты имеешь ввиду подключение реализаций? Пример того как это реализовать я приводил в форуме по дотнету.

WH>Вобщем да. А ссылку можно?

Нету ее у меня. Поищи в поиске.

WH> Хотя у меня функциональность по больше в моем варианте один кирпичик может изменять дугой причем только с использованием полиморфизма времени компиляции те без ущерба производительности.


При желании в том подходе, пример которого приведен можно наворотить такие извратства, что плюсам и не снились, только вот нафик никому это не нужно.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[19]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 06:34
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Нет. Сигналы как раз и есть эмуляция делегатов. Своеобразная, но эмуляция.


Да начерта их эмулировать? Это самоцель что ли? Главное — обеспечить удобный простой и лаконичный типизированный оо колбек, а уж как это обеспечивать второй вопрос. Делегаты — неплохое приближение к идеалу, но совершенно точно еще не идеал. С введением к примеру анонимных методов станет все еще интереснее.

VD>Можно взразить, но ведь на сегодня эти гору за частую написаны! Да. Но во что это выливается? На любой плевок нужно создать целый отдельный класс! Это приводить к неимоверным затратам времени на компиляцию. Один из наших проектов компилируется 25 минут на Атлон 1400! И это как раз в основном из-за шаблонов. Причем наши шаблоны бустовским не чета.


Ну тут даже без шаблонов проблем достаточно. Небольшой TreeGridBase компилируется в разы дольше чем весь остальной янус, и это при том что компилер шарпа 1 версии, а плюсов 7.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[12]: Будущее C#
От: Nose Россия  
Дата: 03.07.03 06:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, VladD2, Вы писали:


VD>>Да я вроде и без него в С++ разбирался.

WH>Я тоже так думал...

WH>Из предисловия Скотта Мейерса

WH>

WH>Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.


Угу... я его сейчас читаю... смотрю на мир безумными глазами... Отхожу плохо...
Книгу нужно зарегестрить как психотропное средство...
... << RSDN@Home 1.1 beta 1 >>
Re[19]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 07:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Так вот в бусте создана целая гора кода, чтобы сэмулировать такое простое решение. Если в С++ наплевать на типобезопастность, но написать такую фитюльку ничего не стоит.


Фитюлька написана с соблюдением типобезопасности. Если хочешь показать reinterpret_cast или static_cast на потомка в реализации сигналов — дерзай, исходники доступны. Я знаю одно такое место — static_cast внутри any_cast, но он сделан для увеличения производительности (как, скажем, некоторые unsafe методы класса String) и может быть безболезненно заменен на dynamic_cast.

VD>Это форменное удаление гланд через анус автогеном. И очередная демострация затыкания ущербности языка средствами использования шаблонов не по назначению.


Да. Шаблоны задумывались для тех же целей, что и generics сейчас, но оказалось, что на них можно сделать гораздо больше. Вообще c++ — омерзительный язык, и я, если мне дадут такую возможность, вместо порта ado.net на плюсы лучше бы писал что-нибудь на c#, смирив гордыню и наплевав на шаблоны, дожидаясь generics. Но 700 строк реализации шести вложенных в System.Windows.Forms.ListView коллекций не дали мне сегодня спать до трех часов ночи...

VD>Так вот в бусте создана целая гора кода, чтобы сэмулировать такое простое решение.


Кстати, раскрою секрет: на шаблонах невозможно сделать аналог делегатов с произвольным числом параметров. Для каждого n от 0 до 10 есть шаблон делегата с n параметрами, а потом они приведены в общий вид с помощью макросов
Re[25]: Будущее C#
От: Nose Россия  
Дата: 03.07.03 08:00
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Что значит из стандартных кирпичиков? Ты имеешь ввиду подключение реализаций? Пример того как это реализовать я приводил в форуме по дотнету.


Вмешаюсь, по поводу Александреску.
Да, код кажется ужасным. Но этот код _не_ предназначен для того, чтобы его читали. Это код _не_ для повседневного использования.
Александреску в своей книге описывает библиотеку, описание которой надо прочитать, а потом, поняв основные ижеи, пользоваться, дополнять etc.

Код же использующий эту библиотеку, наоборот, очень читабелен, да и вообще, основной целью библиотеки Loki является замена громоздкого кода на лаконичный и легкочитаемый.

Пара примеров:

— подклчение реализаций:

typedef SmartPtr<Widget, NoChecking,SingleTreaded> WidgetPtr;
typedef SingletonHolder<T,CreateUsingNew,DefaultLifeTime,MultiTreaded> SingleT;

— генерация иерархий

typedef GetScatterHierarchy<TYPELIST_3(int,string,Widget),Holder> WidgetInfo;
Holder<int> Holder<string> Hoder<Widget>
| | |
----------------------------------------
|
WidgetInfo;

+линейные иерархии

— генерация фабрик на основе списка типов

typedef AbstractFactory<TYPELIST_3(Soldier,Monster,SuperMonster)> AbstractEnemyFactory;

Ну как, читаемо?
... << RSDN@Home 1.1 beta 1 >>
Re[25]: Будущее C#
От: Nose Россия  
Дата: 03.07.03 08:00
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Здравствуйте, WolfHound, Вы писали:


WH>>Здравствуйте, AndrewVK, Вы писали:


AVK>>>Мне чего, заняться нечем разбираться в коде, да потом еще и реализовывать на шарпе. Нужно будет, реализую.

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

PE>И ты столько кода нагнал, чтобы показать всю прелесть множественного наследования ?

имеется ввиду не наследование, а сборка класса на этапе компиляции
... << RSDN@Home 1.1 beta 1 >>
Re[26]: Будущее C#
От: Nose Россия  
Дата: 03.07.03 08:06
Оценка:
Здравствуйте, Nose, Вы писали:


N> typedef GetScatterHierarchy<TYPELIST_3(int,string,Widget),Holder> WidgetInfo;

N> Holder<int> Holder<string> Hoder<Widget>
N> | | |
N> ----------------------------------------
N> |
N> WidgetInfo;

Ooops! не получилось, а в редакторе все так мило выглядело
попробуем так:
Holder<int> ----------------\
Holder<string> --------------|---WidgetInfo
Holder<Widget> -------------/
... << RSDN@Home 1.1 beta 1 >>
Re[14]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 08:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, mihailik, Вы писали:


VD>C1<class Base>

VD>{
VD> void Method1()
VD> {
VD> Base * pBase = static_cast<Base*>(this); // так яснее намерения
VD> int i = pBase->SomeUniversalWork();
VD> }
VD>С2 : public C1<C2>
VD>{
VD> int SomeUniversalWork()
VD> {
VD> }
VD>};
VD>С3 : public C1<C2>
VD>{
VD> int SomeUniversalWork()
VD> {
VD> }
VD>};

Этот код нетипобезопасен — если написать C2: public C1<C3> или вызвать C1::Method1 из конструктора C1, то возникнет неопределенное поведение. С использованием generics аналогичный код будет выглядеть примерно так:

interface ISomeUniversalWork
{
  int SomeUniversalWork();
};

class C1<T> where T : ISomeUniversalWork {
  public void Method1() {
    int i = ((T)this).SomeUniversalWork();
  }
}

class C2 : C1<C2>, ISomeUniversalWork
{
  int ISomeUniversalWork.SomeUniversalWork() {
    return 0;
  }
};


При текущей реализации generics приведение (T)this будет съедать весь эффект от невиртуальности, но в принципе никто не мешает будущей версии компилятора сынлайнить все это до нужного состояния.
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 08:14
Оценка:
Здравствуйте, Nose, Вы писали:

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


Любой код должен быть предназначен для того чтобы его читали, кроме кода, время жизни которого 1-2 дня. Можешь напечатать на большом листе и повесить на стену.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[23]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 08:21
Оценка:
Здравствуйте, IT, Вы писали:

IT>public class CategoryInfo

IT>{
IT> public int CategoryID;
IT> public string CategoryName;
IT> public int Count;
IT>}

Кривыми затычками — можно.

REGISTER_CLASS("CategoryInfo", CategoryInfo)
  REGISTER_MEMBER("CategoryID", CategoryID)
  REGISTER_MEMBER("CategoryName", CategoryName)
  REGISTER_MEMBER("Count", Count)
END_REGISTER_CLASS()


И дальше получается та же одна строка.

IT>Я конечно понимаю, что поступаю не совсем честно, в C++ нет нормального RTTI и видимо никогда не будет, но я хочу сказать, что в 99.99% задач твои знания шаблонов вряд ли пригодятся. А если бы ты и попытался их где-либо применить, то работая, к примеру, в моей команде, я тебе просто элементарно запретил бы это делать.


Не надо путать написание шаблонов и их использование. Запрещать использовать vector, string, map, sort при работе на c++ — очень странное решение.

IT>Для меня эталоном программы уже давно является не виртуозное владение указателями, свитчами и шаблонами, а ясный и понятный, хорошо оформленный и откомментированный код. Впрочем, может это я просто старею...


Глядя на наши компилящиеся час на p4/1.8 полмиллиона строк, я регулярно говорю окружающим: ну их нафиг, эти шаблоны и множественное наследование, если для того, чтобы пользователи могли использовать наши классы на своем (опять кривом) прикладном языке, надо писать километры таких макросов. Не слушают.
Re[27]: Будущее C#
От: WolfHound  
Дата: 03.07.03 08:51
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Нету ее у меня. Поищи в поиске.

Не получилось. Попробуй пару ключевых слов привести.

AVK>При желании в том подходе, пример которого приведен можно наворотить такие извратства, что плюсам и не снились, только вот нафик никому это не нужно.

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

VD>Я спросил что ты имеешь в виду под этими словами.

Списки типов позволяют генерировать код.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 09:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Правда имена типов страшнее, но болие типобезопасно.


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

IT>>А теперь добавим немного рефлекшина внутрь и получим:

WH>

WH>Мда... печальное зрелище... без пузыря не разберёшся.


Действительно, непонятно нифига

WH>И что теперь говорить что рефлекшен фигня? Если в .NET будут шаблоны уровня С++


Что это за уровень такой? А шаблоны будут, вполне достаточного для дотнета уровня.

WH>и множественное наследование


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

IT>>в моём надеюсь тебе не просто будет всё понятно, а даже тривиально с первого взгляда.

WH>Первый да второй нет(вернее догадаться по контексту могу, а повторить...даже на С#... ).
WH>Таже проблема что и у тебя с моим кодом плохое знание матчасти.

Я подобный функционал сделал примерно через месяц после того как впервые увидел дотнет. И знание матчасти тут не при чем.

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


Я например весьма часто.

WH>Создание обьекта по имени класса прочитаному из какого либо конфига. Причем реализация обьекта можнет находится в либой из оформлкнных по (очень простым) правилам длл(ессно прицепленных к приложению).

WH>
WH>    Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorClassName);
WH>    ENFORCE(sensor, X_InvalidClassName)("Class Name =\"")(sensorClassName)("\"");//Исключение будет автоматом записано в лог 
WH>    sensor->Name=sensorName;//Что грузить
WH>    sensor->DataBase=dataBase;//От куда грузить
WH>    ENFORCE(sensor->Load(), X_InvalidSensorName)("Class Name =\"")(sensorClassName)("\"; Sensor name =\"")(sensorName)("\"");
WH>    //    Messge    : Class Name ="MyCoolSensorClass"; Sensor name ="MyCoolSensor"
WH>    //См ниже
WH>


Сравни
Activator.CreateInstance(Type.GetType("ClassName, assembly_name"));


WH>Так что жить можно и довольно легко.


А нужно?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 09:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>Нету ее у меня. Поищи в поиске.

WH>Не получилось. Попробуй пару ключевых слов привести.

http://www.rsdn.ru/Forum/Message.aspx?mid=53431&amp;only=1
Автор: AndrewVK
Дата: 12.05.02
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[8]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 11:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ссылку на whitepaper с описанием изменений языка в .NET 2.0 давали неоднократно, различиям темплейтов и дженериков там посвящена отдельная глава.


Там практически ничего не сказано. По крайней мере для серьезного суждения точно ничего нет. Так что ты хоть одно координальное отличие приведи. Я вот только заметил, что не будет параметризованных функций. Прискорбно конечно, но не смертельно.

AVK>Можно, вот только результатом этого как раз и являются вопли о неправильности шарпа.


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

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


VD>>Все до одной. Другой вопрос что этот менеджед-код не будет совместим с CLS.


AVK>Да? И ты берешься сделать к примеру класс с МН менеджед?


Легко. Компилируются даже шаблонные навароты ATL-я.

AVK> Не путай пожалуйста IL-код и-managed код.


Не путаю. IL == managed. То о чем говоришь ты называется "CLS-совместимый".

AVK>Когда ты объявляешь класс gc то очень многие фичи становяться недоступны.


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

A>Вот что-что а я бы посоветовал Владу глянуть всё таки эту книжку ... Там есть над чем посмеяться, самые очевидные вещи решаются такими уродскими способами (реализация, а не задумка ) и всё это подаётся под таким соусом, как откровение ...


К сожалению я все это видел воочию. Многих программистов так и тянет сделать что-нибудь через ухо. А на счет глянуть... поподет в руки обязательно гляну. Вот только точно не буду искать ее с высунутым языком. С++ для меня теперь средство решений проблем которые нужно решать на уровне битов.

A>Правда до главы со списками я ещё не дошёл, но эта книжка прекрасный повод для критики С++ ... Язык морально устаревает и люди вроде Александреску пытаются показать, что на С++ можно делать и кое-что новое, что в том же Шарпе делается просто и лаконично ...


Во-во. Это я из Александреску вижу. Причем мне нравится С++, но мне так же нарвится компонентный подход и хочется решать стоящие задачи просто и элегантно. К сожалению, С++ далек от простоты и элегнтности. Ну, а компонентность в нем отсуствует полностью.

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


Именно.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 11:27
Оценка:
Здравствуйте, m.a.g., Вы писали:

MAG>Это коллекции типов.


И это приводится в качестве аргумента в споре с Шарпом использующим самый мощьный на сегодня механизм предоставления информации о типах (рефлекшон)?

MAG>Причем работа с ними идет во время компиляции.


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

AVK>Двойка тебе за знание адонета . Чтобы создать команду нет необходимости открывать коннекшен, открывать нужно только для Execute, Prepare и BeginTransaction.


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

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


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

N> typedef AbstractFactory<TYPELIST_3(Soldier,Monster,SuperMonster)> AbstractEnemyFactory;


N> Ну как, читаемо?


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

AVK>При желании в том подходе, пример которого приведен можно наворотить такие извратства, что плюсам и не снились, только вот нафик никому это не нужно.


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

_>Этот код нетипобезопасен — если написать C2: public C1<C3> или вызвать C1::Method1 из конструктора C1, то возникнет неопределенное поведение.


Ну, C3 бесспорно. Можно правда обезопаситься делая не статик-каст, а динамик-, но это уже медленнее. А насчет вызова метода из коструктора ты ошибаешся. Тут все будет ОК.

_>С использованием generics аналогичный код будет выглядеть примерно так:


_>
_>interface ISomeUniversalWork
_>{
_>  int SomeUniversalWork();
_>};

_>class C1<T> where T : ISomeUniversalWork {
_>  public void Method1() {
_>    int i = ((T)this).SomeUniversalWork();
_>  }
_>}

_>class C2 : C1<C2>, ISomeUniversalWork
_>{
_>  int ISomeUniversalWork.SomeUniversalWork() {
_>    return 0;
_>  }
_>};
_>


Не. Не прокатит. Если отнаследовался от интерфейса, то обязан реализовать метод. Так что проще или виртуальную функцию или так же динамик-кстом. Он в шарпе работает неплохо.

_>При текущей реализации generics приведение (T)this будет съедать весь эффект от невиртуальности, но в принципе никто не мешает будущей версии компилятора сынлайнить все это до нужного состояния.


Напомнь, что реализации generics для дотнета пока вообще нет в природе. Это ты говоришь о gyro, а это совсе не то, что будет в дотнете.

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

_>Фитюлька написана с соблюдением типобезопасности.


Та на объем и уродливость кода посмотри. А ведь если в языке сделать одну поправку... вернее даже допущение, то можно было бы обойтись одной строчкой. А допущение очень простое. Соотвествие указателей на методы нужно проверять без учета типа (только на базе формального описания метода).

_> Если хочешь показать reinterpret_cast или static_cast на потомка в реализации сигналов — дерзай, исходники доступны. Я знаю одно такое место — static_cast внутри any_cast, но он сделан для увеличения производительности (как, скажем, некоторые unsafe методы класса String) и может быть безболезненно заменен на dynamic_cast.


Я не хочу показать на типобезопастность. Я хочу показать на уродливость и огромность кода для решения примитивной задачи. Еще раз повторюсь, что если наплевать на типбезопастность, тоже самое делается в 3-10 строк кода.

_>Да. Шаблоны задумывались для тех же целей, что и generics сейчас, но оказалось, что на них можно сделать гораздо больше.


Кто бы спорил. Я года три назад с удовольствием писла разные смарт-враперы. И видимо еще займусь этим на Шарпе...

_> Вообще c++ — омерзительный язык, и я, если мне дадут такую возможность, вместо порта ado.net на плюсы лучше бы писал что-нибудь на c#, смирив гордыню и наплевав на шаблоны, дожидаясь generics. Но 700 строк реализации шести вложенных в System.Windows.Forms.ListView коллекций не дали мне сегодня спать до трех часов ночи...


Что-то я не понял, какое отношение имеют строки из System.Windows.Forms.ListView к ado.net? Это ты о чем? И причем тут С++ и Шарп?

Кстати, о реализации коллекций. Я тут как-то писал парсер дотнетных метаданных (напрямую из PE-файла). Взял МС++ и с помощью... не не шаблонов, а макросов создал атоматическую герерилку кода по описаниям в стиле мапов (из MFC/ATL). Получилось красиво, элегантно, производительно и главное (!) офигительно быстро (в смысле скорость кодирования). Правда с отладкой потрахался. При этом получившийся код прекрасно работает как в менеджед режиме (под тем же Шарпом), так и в обычном анмэнеджед (под MFC). И ведь хрена с два это можно сделать на баблонах.

_>Кстати, раскрою секрет: на шаблонах невозможно сделать аналог делегатов с произвольным числом параметров. Для каждого n от 0 до 10 есть шаблон делегата с n параметрами, а потом они приведены в общий вид с помощью макросов


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

AVK>Да начерта их эмулировать? Это самоцель что ли?


Дык удобнее с ними. Ты сам попробуй на Шарпе пописать без делегатов...

AVK> Главное — обеспечить удобный простой и лаконичный типизированный оо колбек, а уж как это обеспечивать второй вопрос.


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

AVK> Делегаты — неплохое приближение к идеалу, но совершенно точно еще не идеал. С введением к примеру анонимных методов станет все еще интереснее.


Я кстати, так и не просек в чет тут кайф.

AVK>Ну тут даже без шаблонов проблем достаточно. Небольшой TreeGridBase компилируется в разы дольше чем весь остальной янус, и это при том что компилер шарпа 1 версии, а плюсов 7.


Да он по сравнению с нашими проектами компилируется моментально. К тому же шарп изначально спроектрован на компонентную сборку, а С++ на включение исходных файлов. Это надо сказать тоже неприятное наследие. В принципе, если делать чисто CLS-совместимый проект, он будет компилироваться не намного дольше Шарповского. Кстати, библиотека читающая метаданные компилируется как в менеджед-, так и в анменеджед-варианте. Так вот в анменеджед она компилируется в 1.5 раза дольше. Но это видимо из-за того, что в дотнете часть компиляции переносится в рантайм.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 11:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я не хочу показать на типобезопастность. Я хочу показать на уродливость и огромность кода для решения примитивной задачи. Еще раз повторюсь, что если наплевать на типбезопастность, тоже самое делается в 3-10 строк кода.


Не выйдет. Если делегат вызван с несколькими параметрами, то их надо передать в каждй вызов лежащих в нем колбеков, для чего надо знать их типы. Ассемблерная вставка тоже не пройдет — хочется передавать параметры и с нетривиальным конструктором копирования.

_>> Вообще c++ — омерзительный язык, и я, если мне дадут такую возможность, вместо порта ado.net на плюсы лучше бы писал что-нибудь на c#, смирив гордыню и наплевав на шаблоны, дожидаясь generics. Но 700 строк реализации шести вложенных в System.Windows.Forms.ListView коллекций не дали мне сегодня спать до трех часов ночи...

VD>Что-то я не понял, какое отношение имеют строки из System.Windows.Forms.ListView к ado.net? Это ты о чем? И причем тут С++ и Шарп?

На работе я порчу ado.net на плюсы, а дома дизассемблирую windows forms. Шесть наследников IList по 100 строк, у которых отличается максимум треть кода, — это ужасно.

_>>Кстати, раскрою секрет: на шаблонах невозможно сделать аналог делегатов с произвольным числом параметров. Для каждого n от 0 до 10 есть шаблон делегата с n параметрами, а потом они приведены в общий вид с помощью макросов

VD>Это можно решить передавая массив.

То есть сведя к ситуации с одним параметром. Я тоже не возьму буст, а буду делать в своем плюсовом проекте делегаты только с двумя параметрами — sender и eventargs.
Re[9]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 11:54
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Можно, вот только результатом этого как раз и являются вопли о неправильности шарпа.


VD>Не надо песен. Шарп и в правду не совершенен.


А про совершенство никто и не говорил. Но вопли то вроде того что шарп полная туфта по сравнению с С++.

VD>И большинство воплей по делу, если конечно это не простое фанатство.


Что то последнее время больше не по делу.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[25]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 12:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А какая разница когда его открывать?


В принципе критичной разницы нет, но увеличивается время использования коннекшена, что не есть гуд.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[21]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 12:04
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Да начерта их эмулировать? Это самоцель что ли?


VD>Дык удобнее с ними.


Но это не значит что аналогичный по назначению , но реализованный иначе механизм существовать не может.

VD> Ты сам попробуй на Шарпе пописать без делегатов...


А там им замены нет.

AVK>> Делегаты — неплохое приближение к идеалу, но совершенно точно еще не идеал. С введением к примеру анонимных методов станет все еще интереснее.


VD>Я кстати, так и не просек в чет тут кайф.


Меньше кода, код легче читать.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[16]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 12:05
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>Этот код нетипобезопасен — если написать C2: public C1<C3> или вызвать C1::Method1 из конструктора C1, то возникнет неопределенное поведение.

VD>Ну, C3 бесспорно. Можно правда обезопаситься делая не статик-каст, а динамик-, но это уже медленнее. А насчет вызова метода из коструктора ты ошибаешся. Тут все будет ОК.

Твой десятилетний опыт работы с плюсами должен был подсказать тебе, где ошибка

Вот пример, вызывающий access violation. Убери вызов Method1 из конструктора C1 — access violation пропадет.

#include <iostream>
#include <string>
using namespace std;

template<class Base>
class C1
{
public:
    C1()
    {
        Method1(); // !
    }
    void Method1()
    {
        Base * pBase = static_cast<Base*>(this);
        pBase->SomeUniversalWork();
    }
};

class C2: public C1<C2>
{
public:
    string s;
    void SomeUniversalWork()
    {
        cout << s << endl;
    }
};

int main()
{
    C2 c2;
    c2.Method1();
}


_>>class C2 : C1<C2>, ISomeUniversalWork

_>>{
_>> int ISomeUniversalWork.SomeUniversalWork() {
_>> return 0;
_>> }

VD>Не. Не прокатит. Если отнаследовался от интерфейса, то обязан реализовать метод.


А int ISomeUniversalWork.SomeUniversalWork() — это что?

VD>На счет тормозов. Да такое приведение будет динамик-кастом и скорость будет ниже. Но ведь можно делать приведение один раз и запоминать указатель в скрытом поле. При этом будет производиться или thiscall, или инлайнинг.


Внутри C1 мы можем сохранить указатель только на ISomeUniversalWork, и при вызове по нему инлайнинга точно не будет. В моем примере в принципе может быть, но для этого джит должен:

1) раскрыть инлайном C1::Method1;
2) понять, что после раскрытия this на самом деле является C2, потому что Method1 вызван для объекта типа C2;
3) в связи с этим убрать приведение this к C2 как лишнее;
4) понять, что метод C2::ISomeUniversalWork.SomeUniversalWork невиртуальный и его можно инлайнить;

Пункт 2 наименее вероятен, но без него ничего не выйдет.
Re[9]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 12:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я вот только заметил, что не будет параметризованных функций. Прискорбно конечно, но не смертельно.


Как это не будет? Все тот же gyro/docs/generics/csharp.html:

class C<V>

{
public virtual bool f6<U>(C<V> x, C<U> y) // Ok

     { ...  }
}

Вот явной полной или частичной специализации действительно не будет.
Re[16]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 12:27
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>class C1<T> where T : ISomeUniversalWork {

_>> public void Method1() {
_>> int i = ((T)this).SomeUniversalWork();
_>> }
_>>}

VD>Но ведь можно делать приведение один раз и запоминать указатель в скрытом поле.


А, действительно и в поле типа T можем. Получается почти как в ATL, но там они еще экономили место под указатель. Совсем как в ATL может быть только с приведением прямо в месте вызова, но компилятор должен быть слишком умным, как я описал.
Re[26]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 12:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, VladD2, Вы писали:


VD>>А кто это говорил? Тебе говорят, что он тяжел и во многом отстал от жизни. Цитату можешь привести?

WH>Re[9]: Будущее C#
Автор: VladD2
Дата: 27.06.03


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

AVK>В принципе критичной разницы нет, но увеличивается время использования коннекшена, что не есть гуд.


А. Экономия микросикунд...

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

_>А, действительно и в поле типа T можем. Получается почти как в ATL, но там они еще экономили место под указатель. Совсем как в ATL может быть только с приведением прямо в месте вызова, но компилятор должен быть слишком умным, как я описал.


Кстати, нет физических причин чтобы не сделать такой же оптимизации. Ведь уже на стадии компиляции известно, что текущий this можно привести к T. Просто это уже не хилая оптимизация, которая вряд ли появится в ближайшее время.

Одна надежда на Сан. Если они сделают хорошую (быструю) реализацию балонов в Яве, то МС будет вынуждена заняться оптимизацией и мы еще при жизни увидим такое чуда, как безопасное программирование на Шарпе в стиле ATL.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 13:35
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Твой десятилетний опыт работы с плюсами должен был подсказать тебе, где ошибка


Так не испоьзуй в таких методах члены-классы и все будет ОК. Сам по себе вызов проблемы не вызовет. По крайней мере по сравнению с виртуальным проблем туочно будет меньше.

Обычно такие приколы в конструкторе нужны только для изменения поведения. Это опасно, но не смертельно. Полностью соотвествует политике С++.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 13:37
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

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


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


_>Если ошибочный дизайн приводит к более простому и ясному коду, чем правильный, то пора пересмотреть методы оценки дизайна.


Угу, и заодно объявить вечный двигатель легкодостижимым и общедоступным средством. Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода. Если у тебя на C++ распыляется switch(type_id) по нескольким файлам, то аналогичную ситуацию ты получишь и в любом другом аналогичном языке.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 13:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Одна надежда на Сан. Если они сделают хорошую (быструю) реализацию балонов в Яве, то МС будет вынуждена заняться оптимизацией и мы еще при жизни увидим такое чуда, как безопасное программирование на Шарпе в стиле ATL.


У них все еще хуже — они даже не позволяют value-типу быть параметром шаблона. Виртуальная машина не меняется, и шаблоны остаются чисто синтаксической конструкцией. Они не могут поднять производительность, а могут только избавить от явного приведения типов и сделать код коллекций более безопасным.
Re[20]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 03.07.03 13:43
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

_>>Если ошибочный дизайн приводит к более простому и ясному коду, чем правильный, то пора пересмотреть методы оценки дизайна.


ГВ>Угу, и заодно объявить вечный двигатель легкодостижимым и общедоступным средством. Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода. Если у тебя на C++ распыляется switch(type_id) по нескольким файлам, то аналогичную ситуацию ты получишь и в любом другом аналогичном языке.


Чем плох вот такой дизайн?

class A
{
void Save(IStream stream)
{
  foreach (Property prop in A.Properties)
    stream.Save(prop);
}
  ...
}
Re[21]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 13:47
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Угу, и заодно объявить вечный двигатель легкодостижимым и общедоступным средством. Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода. Если у тебя на C++ распыляется switch(type_id) по нескольким файлам, то аналогичную ситуацию ты получишь и в любом другом аналогичном языке.


DG>Чем плох вот такой дизайн?


DG>
DG>class A
DG>{
DG>void Save(IStream stream)
DG>{
DG>  foreach (Property prop in A.Properties)
DG>    stream.Save(prop);
DG>}
DG>  ...
DG>}
DG>


Где гарантия наличия реализации Save (или адекватности его генерации) для всех членов A.Properties? Или скажем так, чем гарантируется, что при введении 501-го типа Property система не начнёт слетать в одном случае из сотни?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 13:48
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>У них все еще хуже — они даже не позволяют value-типу быть параметром шаблона. Виртуальная машина не меняется, и шаблоны остаются чисто синтаксической конструкцией. Они не могут поднять производительность,


Ну ты все таки поменьше верь рекламным лозунгам МС. Они не поднимут производительность при работе с value-типами путем отбрасывания боксинга просто потому что там боксинга нет. Все остальные аспекты повышения производительности, применимые к шаблонам С++ точно так же применимы и к дженерикам джавы.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[19]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 13:53
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


AVK>Ну расскажи тогда как правильно реализовать, к примеру, сериализацию классов.


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

ГВ>Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода.


Есть задачи, явно требующие динамического определения типа, скажем, клиентский курсор. Его внешний интерфейс содержит операции "взять значение" и "положить значение", а также уведомление об изменении значения с возможностью уведомляемого подменить его. От запроса курсор получает типы данных всех столбцов и организует для каждого столбца хранилище, оптимизированное под его тип. Как должен выглядеть интерфейс клиента без rtti или аналогов? По одному методу для каждого типа? А внутренние передачи данных — тоже? Реализация курсора состоит из десятков классов, время от времени обменивающихся значениями полей. Сколько методов придется размножить для каждого типа? Что делать, если захочется поддержать новый тип данных?
Re[22]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 03.07.03 14:03
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Где гарантия наличия реализации Save (или адекватности его генерации) для всех членов A.Properties?

ГВ> Или скажем так, чем гарантируется, что при введении 501-го типа Property система не начнёт слетать в одном случае из сотни?

Я тебя понял, т.е. ты за максимум проверки корректности на этапе компиляции? Я прав?

Но согласись, что даже в этом случае нужен механизм самоанализа (пусть доступный только на этапе компиляции), чтобы можно было написать ту же самую конструкцию.

class A
{
void Save (IStream stream)
{
  template_foreach(Property prop in A.Properties)
     stream.Save(prop.Name);
}
}

где template_foreach — конструкция, которая разбирается компилятором на этапе компиляции, и приводит к следующему внутреннему коду:

void Save (IStream stream)
{
  stream.Save(a);
  stream.Save(b);
}


А этот код уже проверяется компилятором.

Сейчас этого нет, что и приводит к ужасным констркуциям Begin_Map/MapElement/End_Map.
Re[21]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 14:05
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

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


ГВ>>Недостатки Rtti-based подхода абсолютно никуда не деваются от повышения понятности и ясности кода.


_>Есть задачи, явно требующие динамического определения типа, скажем, клиентский курсор. Его внешний интерфейс содержит операции "взять значение" и "положить значение", а также уведомление об изменении значения с возможностью уведомляемого подменить его. От запроса курсор получает типы данных всех столбцов и организует для каждого столбца хранилище, оптимизированное под его тип. Как должен выглядеть интерфейс клиента без rtti или аналогов? По одному методу для каждого типа? А внутренние передачи данных — тоже? Реализация курсора состоит из десятков классов, время от времени обменивающихся значениями полей. Сколько методов придется размножить для каждого типа? Что делать, если захочется поддержать новый тип данных?


Так... значит, когда ты создаёшь курсор, ты не знаешь, для какого типа данных он создаётся? Т.е., если исходно у тебя что-то вроде:


create table XTable ( ... attr1 int, attr2 varchar(100), ...)


а потом:

select attr1, attr2 from XTable


То ты просто совершенно не знаешь, типы первой и второй колонки? Позволю себе с тобой не согласиться.

С другой стороны, типы данных SQL-колонок — это внешние по отношению к клиенту данные и их символы находятся вне пространства определения типов C++. А потому распознавание и анализ типов SQL-данных это не rtti, а скорее ближе к распознаванию образов или к банальной проверке входных данных на допустимость. И то и то можно решить без rtti.

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

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


ГВ>[...]


VD>>Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.


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


На самом деле, RTTI нужен не столько программистам, пишущим на C++ (хотя есть некоторые задачи, где RTTI ну оччень бы пригодился), сколько самому компилятору С++. Если бы в объектные файлы помещалась информация о типах, то компилятору при компиляции каждого cpp-файла не приходилось бы обрабатывать сотни килобайт исходного кода, которые вставляются через #include.
Именно поэтому скорость компиляции программ на Delphi и Java на много порядков быстрее, чем на C++. Про скорость компиляции С# не скажу — не пришлось еще с ним плотно познакомится, но подозреваю, что тоже намного быстрее, чем С++.
Re[22]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 14:12
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Не выйдет. Если делегат вызван с несколькими параметрами, то их надо передать в каждй вызов лежащих в нем колбеков, для чего надо знать их типы. Ассемблерная вставка тоже не пройдет — хочется передавать параметры и с нетривиальным конструктором копирования.


Да не нужны мне мультикасты. Я их за пять минут напишу если будет не мульткаст реализован. А реализации таких приколов можно найти в форуме по С++. Мы где-то год или 1.5 назад обсуждали это дело и там были несколько решений. Мое було как раз на ассемблере, но потом кто-то показал аналог на чистом С++.

Самое смешное, что мой с ассемблером читался даже проще, чем тот второй.

_>На работе я порчу ado.net на плюсы, а дома дизассемблирую windows forms. Шесть наследников IList по 100 строк, у которых отличается максимум треть кода, — это ужасно.


Соласен. Только кто тебе сказал, что они не сгенерированы по шаблону? К тоу-же есть CollectionBase. Наследуйя от него и 90% коллекций будут писаться за пару минут. Типизированную обвязку можно сделать генератором. Хотя конечно бесспорно, что именно для этого шаблоны подходят как нельзя кстати. Тут никто и не сприт. Даже народ не использовавший ранее шаблоны не спорит (ну, за исключением упертых фанатов переписавших на дельфи или Яве). Ну, что же?... будем ждать. А пока и так более менее можно жить.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 14:12
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>То ты просто совершенно не знаешь, типы первой и второй колонки? Позволю себе с тобой не согласиться.


Часто даже представления не имею. Грид тоже кто-то должен писать, по волшебству он не появится. О конкретном типе данных в гриде надо вспоминать разве что при форматировании и парсинге.
Re[22]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 14:12
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Но это не значит что аналогичный по назначению , но реализованный иначе механизм существовать не может.


К сожалению, твой вариант был более медленныи и совсем неудобным.

AVK>Меньше кода, код легче читать.


А счего меньше кода? Куда эти чуда-методы пихать?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 14:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Соласен. Только кто тебе сказал, что они не сгенерированы по шаблону?


У CheckedListViewItemCollection сначала идет Count, а потом ItemArray, а у SelectedListViewItemCollection — наоборот, сначала SelectedItemArray, а потом Count

VD>К тоу-же есть CollectionBase. Наследуйя от него и 90% коллекций будут писаться за пару минут.


Это те самые остальные 10%. *ListViewItemCollection пользуются *IndexCollection для получения номеров, чтобы потом вытащить сами элементы из ListViewItemCollection.

VD>Типизированную обвязку можно сделать генератором.


Кстати, к msvc 1.0 такой был
Re[20]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 14:22
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хорошо, расскажу (оформлю как код, хотя здесь уже где-то пробегали реализации), но вот при чём тут rtti?..


Потому что все реализации без rtti выглядят как уроды.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[21]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 14:22
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Integer — это и есть забоксенный int.


Боксить тока надо ручками. Что же касается перфоманса, то в отличие от С++ и джава и дотнет должны производить кастинг в рантайме даже для совместимых типов, поскольку неясно что тебе в итоге могут подсунуть, поэтому шаблоны избавляют от определенной части этого кастинга и тем самым увеличивают эффективность полиморфных алгоритмов.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[23]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 14:26
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


ГВ>>Где гарантия наличия реализации Save (или адекватности его генерации) для всех членов A.Properties?

ГВ>> Или скажем так, чем гарантируется, что при введении 501-го типа Property система не начнёт слетать в одном случае из сотни?

DG>Я тебя понял, т.е. ты за максимум проверки корректности на этапе компиляции? Я прав?


Да, ты прав.

DG>Но согласись, что даже в этом случае нужен механизм самоанализа (пусть доступный только на этапе компиляции), чтобы можно было написать ту же самую конструкцию.


DG>
DG>class A
DG>{
DG>void Save (IStream stream)
DG>{
DG>  template_foreach(Property prop in A.Properties)
DG>     stream.Save(prop.Name);
DG>}
DG>}
DG>

DG>где template_foreach — конструкция, которая разбирается компилятором на этапе компиляции, и приводит к следующему внутреннему коду:

DG>
DG>void Save (IStream stream)
DG>{
DG>  stream.Save(a);
DG>  stream.Save(b);
DG>}
DG>


DG>А этот код уже проверяется компилятором.


DG>Сейчас этого нет, что и приводит к ужасным констркуциям Begin_Map/MapElement/End_Map.


В принципе — да, но я бы не стал обобщать, что Begin_Map/... — единственный возможный способ реализации списка полей для класса. И не стал бы утверждать, что сериализация должна всегда выполняться для всех полей экземпляра.

Я клоню к тому, что A.Properties на самом деле должен быть неким Ax.Properties, где Ax.Properties есть подмножество A.Properties. Выделить это подмножество можно атрибутами свойств или заведением дополнительных классов-"фильтров" (здравствуй, Begin_Map, на правда ли?). Так что, при ближайшем рассмотрении твой пример становится не очень убедительным.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 14:28
Оценка:
Здравствуйте, AndrewVK, Вы писали:

_>>Integer — это и есть забоксенный int.

AVK>Боксить тока надо ручками.

В 1.5 уже не надо будет.

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


Если только чуть-чуть. В отсутствие множественного наследования для проверки возможности кастинга, если кастят не к интерфейсу (а это бывает часто), достаточно пробежаться по цепочке предков испытуемого объекта и попытаться найти нужный тип. А нормальные коллекции value-типов, поднимающие производительность гораздо сильнее, джаве не светят.
Re[21]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 14:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


ГВ>>Хорошо, расскажу (оформлю как код, хотя здесь уже где-то пробегали реализации), но вот при чём тут rtti?..


AVK>Потому что все реализации без rtti выглядят как уроды.


Ай-яй-яй Определи-ка мне термин "уродство", не сочти за труд. А то не дискуссия, а базарная склока получится. Да, и ещё обоснуй употребление предиката "все". А то у меня появляются основания обвинить тебя в неправомерном обобщении.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[24]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 14:31
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я клоню к тому, что A.Properties на самом деле должен быть неким Ax.Properties, где Ax.Properties есть подмножество A.Properties. Выделить это подмножество можно атрибутами свойств или заведением дополнительных классов-"фильтров" (здравствуй, Begin_Map, на правда ли?).


Или здравствуй, .NET

Чтобы проверить, есть ли у свойства нужный атрибут, надо перебрать все атрибуты и попытаться найти среди них атрибут нужного типа. Опять rtti
Re[10]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 14:35
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Как это не будет? Все тот же gyro/docs/generics/csharp.html:


Ну, тем лучше.

_>Вот явной полной или частичной специализации действительно не будет.


А вот это не факт. Все из МС в один голос заявляют, что МС-Ресерч и МС две большие разницы. И что реализация дженириков на шарпе не не будет копией gyro.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 14:35
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А про совершенство никто и не говорил. Но вопли то вроде того что шарп полная туфта по сравнению с С++.


Кто бы спорил. Просто нужно осознавать недостатки обоих языков. Ну, и помнить, что С++ в дотнете никто не запрещал.

AVK>Что то последнее время больше не по делу.


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

VD>>Легко. Компилируются даже шаблонные навароты ATL-я.

AVK>Нет, gc-классы не могут использовать МН.

А причем тут gc-классы? Классы это не код. Классы это данные. Да данные могут быть менеджед только если помечены как __gc или __value. Но код все равно будет менеджед.

VD>>Не путаю. IL == managed.

AVK>Ничего подобного. Цитата из MSDN
AVK>

AVK>Compilers and tools expose the runtime's functionality and enable you to write code that benefits from this managed execution environment. Code that you develop with a language compiler that targets the runtime is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.


И где здесь написано обратное? А вот тебе другая цитата:

What is managed code and managed data?
Managed code is code that is written to target the services of the common language runtime (see What is the Common Language Runtime?). In order to target these services, the code must provide a minimum level of information (metadata) to the runtime. All C#, Visual Basic .NET, and JScript .NET code is managed by default. Visual Studio .NET C++ code is not managed by default, but the compiler can produce managed code by specifying a command-line switch (/CLR).


Короче, это спор о терминах. Анменеджед его точно назвать нельзя. Так как он компилируется в МСИЛ, требует CLR для исполнения и пердоставляет методанные.

AVK>Слабо сделать класс с МН, чтобы его можно было использовать из C# или VB.NET?


Еще раз. Есть менеджед-код, а есть менеджед-данные. Сделать класс методы котороко компилируютсяв в менеджед код и который поддерживает множественное наследование ничего не стоит.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 14:36
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

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


ГВ>>То ты просто совершенно не знаешь, типы первой и второй колонки? Позволю себе с тобой не согласиться.


_>Часто даже представления не имею. Грид тоже кто-то должен писать, по волшебству он не появится. О конкретном типе данных в гриде надо вспоминать разве что при форматировании и парсинге.


Ну и причём тут rtti? В гриде (если речь идёт о чём-то вроде контрола) данные представляются строковым типом. Следовательно, тебе нужен комплект конвертеров <SQL-тип> -> <строка>. Заметь — даже однонаправленных конвертеров будет вполне достаточно.

Предполагаю, что ты возразишь, что из грида на самом деле потом извлекаются данные для дальнейшей обработки. Я прав?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[24]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 14:44
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

_>>Часто даже представления не имею. Грид тоже кто-то должен писать, по волшебству он не появится. О конкретном типе данных в гриде надо вспоминать разве что при форматировании и парсинге.

ГВ>Ну и причём тут rtti? В гриде (если речь идёт о чём-то вроде контрола) данные представляются строковым типом. Следовательно, тебе нужен комплект конвертеров <SQL-тип> -> <строка>. Заметь — даже однонаправленных конвертеров будет вполне достаточно.

Все же двунаправленных — данные редактируются. А как будет выглядеть прототип метода конвертера? Шаблонный? А как я вызову из грида нужный конвертер? Сделать столбцы грида шаблонными? А как я создам нужные столбцы, если структура таблицы заранее неизвестна?

ГВ>Предполагаю, что ты возразишь, что из грида на самом деле потом извлекаются данные для дальнейшей обработки. Я прав?


К счастью, нет. Но в клиентском курсоре обработка действительно нужна, например, индексирование, поиск и вычисляемые столбцы с парсером выражений, содержащих столбцы любого типа.
Re[24]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 03.07.03 14:45
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


DG>>Сейчас этого нет, что и приводит к ужасным констркуциям Begin_Map/MapElement/End_Map.


ГВ>В принципе — да, но я бы не стал обобщать, что Begin_Map/... — единственный возможный способ реализации списка полей для класса. И не стал бы утверждать, что сериализация должна всегда выполняться для всех полей экземпляра.


ГВ>Я клоню к тому, что A.Properties на самом деле должен быть неким Ax.Properties, где Ax.Properties есть подмножество A.Properties. Выделить это подмножество можно атрибутами свойств или заведением дополнительных классов-"фильтров" (здравствуй, Begin_Map, на правда ли?). Так что, при ближайшем рассмотрении твой пример становится не очень убедительным.



Пусть будет так:
class A
{
  [Не сохранять]
  int A;  
  [Сохранить]
  string B;
  void Save (IStream stream)
  {
    template_foreach (prop in Select * From A.Properties where Сохранить is presence)
      stream.Save(prop.Name);
  }
}


Я против Map-ов, потому что нарушается "атомарность" действий добавления/удаления свойст в классе, т.е.
при добавление/удалении свойств, надо постоянно помнить (а также еще их найти, что может быть сложно в случаи того же наследования), что необходимо сделать синхронное изменение в Map-ах

зы
Но ведь так сейчас тоже нельзя сделать:
class A
{
  int A;
  string B;
  double C;
  Properties <PropsForSave>()
  {
    return <list>{A.A, A.C};
  }
  void Save(IStream stream)
  {
     <foreach> (Property <prop> in <PropsForSave)
       stream.Save(<prop>.Name);
  }
}

Угловые скобки указывают, что конструкция в угловых скобках есть только на этапе компиляции.

Ухищрения в стиле Александреску позволяют как-то к этому приблизится, но как же это не удобно, сложно, и не все можно сделать.
Не понятно, почему этого нет в самом компиляторе — ему то, это уж точно проще поддержать.
Re[27]: Будущее C#
От: Nose Россия  
Дата: 03.07.03 14:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Nose, Вы писали:


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


VD> Я плякаль...


я имел ввиду, что читать этот код придется не настолько часто, чтобы его сложность представляла собой реальную проблему.
Не так уж часто приходится читать исходники библиотек, да? Это не костяк программы, это инструментарий.
... << RSDN@Home 1.1 beta 1 >>
Re[19]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 15:01
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

VD>>>Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.


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


K_O>На самом деле, RTTI нужен не столько программистам, пишущим на C++ (хотя есть некоторые задачи, где RTTI ну оччень бы пригодился), сколько самому компилятору С++. Если бы в объектные файлы помещалась информация о типах, то компилятору при компиляции каждого cpp-файла не приходилось бы обрабатывать сотни килобайт исходного кода, которые вставляются через #include.


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

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


ГВ>>Я клоню к тому, что A.Properties на самом деле должен быть неким Ax.Properties, где Ax.Properties есть подмножество A.Properties. Выделить это подмножество можно атрибутами свойств или заведением дополнительных классов-"фильтров" (здравствуй, Begin_Map, на правда ли?).


_>Или здравствуй, .NET


Ну, это в примитивном обобщении.

_>Чтобы проверить, есть ли у свойства нужный атрибут, надо перебрать все атрибуты и попытаться найти среди них атрибут нужного типа. Опять rtti


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

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




AVK> Можешь напечатать на большом листе и повесить на стену.

Уж увольте. Склерозом не страдаю, а посему записки самому себе не пишу.

Я ответил, что я имел ввиду в соседнем сообщении.
... << RSDN@Home 1.1 beta 1 >>
Re[20]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 03.07.03 15:05
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

K_O>>На самом деле, RTTI нужен не столько программистам, пишущим на C++ (хотя есть некоторые задачи, где RTTI ну оччень бы пригодился), сколько самому компилятору С++. Если бы в объектные файлы помещалась информация о типах, то компилятору при компиляции каждого cpp-файла не приходилось бы обрабатывать сотни килобайт исходного кода, которые вставляются через #include.


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


А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.
Единственная проблема в том, что надо как-то стандартизовать, менять и т.д. формат информации в obj-е, но тут мог помочь xml.
Re[26]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 15:11
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

_>>Чтобы проверить, есть ли у свойства нужный атрибут, надо перебрать все атрибуты и попытаться найти среди них атрибут нужного типа. Опять rtti

ГВ>Нет, больше похоже на подмену понятий. Достаточно найти атрибут с нужной сигнатурой, или содержащий нужный символ.

У атрибутов в .net еще и поля со значениями бывают. Например, пишем [PermissionSet(SecurityAction.LinkDemand, File="Unrestricted.xml")], и этот файл зачитывается во время компиляции и помещается в код как параметр конструктора класса PermissionSetAttribute. Компилятор, кстати, об этом не знает — он знает, что надо вызвать конструктор PermissionSetAttribute(SecurityAction.LinkDemand), присвоить его свойству File указанное значение, а потом сериализовать получившийся объект прямо в результирующий код, где на рантайме он оживет, когда попросят.

А буковки еще хуже, чем rtti — с классами атрибутов компилятор контролирует, какой класс создается, а сигнатуру можно любую написать. И от проверок и свитчей сигнатуры все равно не избавят.
Re[11]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:12
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Что то последнее время больше не по делу.


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


Соглашусь
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[15]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А причем тут gc-классы? Классы это не код. Классы это данные.


+ код

VD>Короче, это спор о терминах.


Хорошо, пускай о терминах, но это ты его начал.
Тем не менее, возвращаясь к исходному спору, если мы хотим чтобы компоненты, писанные на МС++ использовались в других языках дотнета, то вынужденны лишиться возможности использовать некоторый набор фич.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[20]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:12
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Лучше один шаблон, чем куча классов, построенных на его основе.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[22]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:12
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ай-яй-яй Определи-ка мне термин "уродство", не сочти за труд.


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

ГВ>А то не дискуссия, а базарная склока получится. Да, и ещё обоснуй употребление предиката "все". А то у меня появляются основания обвинить тебя в неправомерном обобщении.


Все что я видел
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[25]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 15:12
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

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


_>>>Часто даже представления не имею. Грид тоже кто-то должен писать, по волшебству он не появится. О конкретном типе данных в гриде надо вспоминать разве что при форматировании и парсинге.

ГВ>>Ну и причём тут rtti? В гриде (если речь идёт о чём-то вроде контрола) данные представляются строковым типом. Следовательно, тебе нужен комплект конвертеров <SQL-тип> -> <строка>. Заметь — даже однонаправленных конвертеров будет вполне достаточно.

_>Все же двунаправленных — данные редактируются. А как будет выглядеть прототип метода конвертера? Шаблонный? А как я вызову из грида нужный конвертер? Сделать столбцы грида шаблонными? А как я создам нужные столбцы, если структура таблицы заранее неизвестна?


Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа), унаследованных от общего интерфейса с виртуальными функциями и конфигурируешь их набор в зависимости от поступившего набора колонок. Но это не имеет ничего общего с rtti! Это — распознавание входных данных.

ГВ>>Предполагаю, что ты возразишь, что из грида на самом деле потом извлекаются данные для дальнейшей обработки. Я прав?


_>К счастью, нет.


Это приятно слышать.

_>Но в клиентском курсоре обработка действительно нужна, например, индексирование, поиск и вычисляемые столбцы с парсером выражений, содержащих столбцы любого типа.


Снова то же самое, что и выше, только в профиль. Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами. Да, с большой вероятностью возникает необходимость преобразований типа string-float, float-date и т.п. Прекрасно решается матрицей конвертеров, поскольку базовый набор типов ограничен набором SQL-типов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 15:14
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.


У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:22
Оценка:
Здравствуйте, Nose, Вы писали:

N>я имел ввиду, что читать этот код придется не настолько часто, чтобы его сложность представляла собой реальную проблему.


Плохая читаемость кода всегда представляет собой реальную проблему

N>Не так уж часто приходится читать исходники библиотек, да?


Кому как. Написателям библиотек например очень часто приходиться

N>Это не костяк программы, это инструментарий.


Инструментарий тоже надо писать и развивать
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[23]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:22
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Но это не значит что аналогичный по назначению , но реализованный иначе механизм существовать не может.


VD>К сожалению, твой вариант был более медленныи и совсем неудобным.


Мой вариант делегатов? Ты о чем?

AVK>>Меньше кода, код легче читать.


VD>А счего меньше кода? Куда эти чуда-методы пихать?


В делегаты
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[22]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 03.07.03 15:22
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, DarkGray, Вы писали:


DG>>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.


_>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.


Это связанно с тем, что каждый отдельный obj хранит всю информацию, которая встречалась в данном cpp-ишнике и всех H-ников, которые в него include-ились, что сейчас как раз приводит к раздуванию obj-ей. если бы вместо h-ников были бы obj-и, то тогда можно было просто хранить ссылку на исходный obj, а не компилировать то же самое заново.
Re[22]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 03.07.03 15:24
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, DarkGray, Вы писали:


DG>>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.


_>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.



В продолжение, к предыдущему письму.
И на данный момент, конечно, единица трансляции в один cpp-файл, конечно, очень маловато будет.Особенно учитывая, что обычно один класс — один cpp.
Re[26]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 03.07.03 15:24
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа), унаследованных от общего интерфейса с виртуальными функциями и конфигурируешь их набор в зависимости от поступившего набора колонок. Но это не имеет ничего общего с rtti! Это — распознавание входных данных.


И формирование выходных данных тоже — после редактирования надо разобрать введенную строку в значение нужного типа и записать его в курсор. В результате свитч все равно остается, но называется все это не rtti, а каким-то другим умным словом. Вместо проверки typeid мы будем проверять какой-то заведенный нами enum. Сейчас у нас в проекте так и сделано. И чем это лучше передачи типа object/variant в функцию форматирования, где внутри стоит свитч по типу?

ГВ>Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами.


Да-да. Со свитчами.
Re[23]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 15:24
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


ГВ>>Ай-яй-яй Определи-ка мне термин "уродство", не сочти за труд.


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


Так бы сразу и сказал. Только объясни, плиз, что это за "ненужный" код?

ГВ>>А то не дискуссия, а базарная склока получится. Да, и ещё обоснуй употребление предиката "все". А то у меня появляются основания обвинить тебя в неправомерном обобщении.


AVK>Все что я видел


Т.е., все реализации, которые ты видел содержали как минимум, кучу ненужного кода? Не верю! (c) Станиславский.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 15:40
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа),


Написание редакторов для каждого типа по твоему правильный дизайн? Мда. А если у источника данных очень большой набор выходных типов и/или он часто меняется? Так и будем клепать редакторы по каждому чиху?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[25]: Будущее C#
От: Sergey Россия  
Дата: 03.07.03 15:47
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>Я против Map-ов, потому что нарушается "атомарность" действий добавления/удаления свойст в классе, т.е.

DG>при добавление/удалении свойств, надо постоянно помнить (а также еще их найти, что может быть сложно в случаи того же наследования), что необходимо сделать синхронное изменение в Map-ах

Я тоже.

DG>зы

DG>Но ведь так сейчас тоже нельзя сделать:
DG>
DG>class A
DG>{
DG>  int A;
DG>  string B;
DG>  double C;
DG>  Properties <PropsForSave>()
DG>  {
DG>    return <list>{A.A, A.C};
DG>  }
DG>  void Save(IStream stream)
DG>  {
DG>     <foreach> (Property <prop> in <PropsForSave)
DG>       stream.Save(<prop>.Name);
DG>  }
DG>} 
DG>

DG>Угловые скобки указывают, что конструкция в угловых скобках есть только на этапе компиляции.


DG>Ухищрения в стиле Александреску позволяют как-то к этому приблизится, но как же это не удобно, сложно, и не все можно сделать.

DG>Не понятно, почему этого нет в самом компиляторе — ему то, это уж точно проще поддержать.

Вот такой стиль устраивает?

class TestA : public ddx::controller<TestA, Loki::NullType>, public CDialog
{
    typedef ddx::controller<derived_type, base_type> parent_t;
protected:
    typedef ddx::member<CString, IDC_SERVER, Ser, &DDX_CBString> m_Server;
    typedef ddx::member<CString, IDC_PROCESS_NAME, Ser, &DDX_Text> m_ProcessName;
    typedef ddx::members<TYPELIST_2(m_Server, m_ProcessName)> members_info;
public:
    TestA(CWnd *wnd) {}
    members_info ddxMembers;
};

class TestC : public ddx::controller<TestC, TestA>
{
    typedef ddx::controller<derived_type, base_type> parent_t;
protected:
    typedef ddx::members<Loki::NullType> members_info;
public:
    TestC(CWnd *wnd) : parent_t(wnd) {}
    members_info ddxMembers;
};

class TestB : public ddx::controller<TestB, TestC>
{
    typedef ddx::controller<derived_type, base_type> parent_t;
protected:
    typedef ddx::member<BOOL, IDC_CREATEMM, Ser, &DDX_Check> m_CreateMM;
    typedef ddx::members<TYPELIST_1(m_CreateMM)> members_info;
public:
    TestB(CWnd *wnd) : parent_t(wnd) {}
    members_info ddxMembers;
};


Сделано (только сегодня доделал, кстати "в стиле Александреску" для избавления от возни с DoDataExchange. У каждого класса-наследника ddx::controller генерится функция void ddxExecute(CDataExchange* pDX), вызывающая DDX_ функции для каждого члена (и каждого члена базовых классов). Потом переделаю ее на шаблонную, чтоб только у терминальных классов инстанцировалась. Ну и сериализация появится
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[27]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 16:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


ГВ>>Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа),


AVK>Написание редакторов для каждого типа по твоему правильный дизайн? Мда.


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

AVK>А если у источника данных очень большой набор выходных типов и/или он часто меняется? Так и будем клепать редакторы по каждому чиху?


Пример такого источника можно? А то что-то не верится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.07.03 16:11
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


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

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


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

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


ГВ>>Да очень просто. Базовый алфавит тебе известен — набор элементарных типов SQL. Пишешь набор редакторов (по одному для каждого SQL-типа), унаследованных от общего интерфейса с виртуальными функциями и конфигурируешь их набор в зависимости от поступившего набора колонок. Но это не имеет ничего общего с rtti! Это — распознавание входных данных.


_>И формирование выходных данных тоже — после редактирования надо разобрать введенную строку в значение нужного типа и записать его в курсор. В результате свитч все равно остается,


Где? Цепочка конвертеров вполне избавляет от необходимости свитчей. Свитч по большому счёту нужен только для первичного распознавания SQL-типа, да и то без него можно обойтись списком конвертеров.

_>но называется все это не rtti, а каким-то другим умным словом. Вместо проверки typeid мы будем проверять какой-то заведенный нами enum. Сейчас у нас в проекте так и сделано. И чем это лучше передачи типа object/variant в функцию форматирования, где внутри стоит свитч по типу?


Чем это лучше в вашем проекте — не знаю, но рискну предположить, что enum появился не случайно. Скорее всего вы ограничили набор SQL-типов, сведя, например, char(x), varchar(x) и text в единый тип с набором ограничений.

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

Один из плюсов такого подхода — в возможности добавления новых конвертеров без влияния (т.е., — даже без потенциального редактирования!) на код, реализующий общую часть алгоритмов форматирования, например.

ГВ>>Узлы синтаксического дерева (или дерева вычисления выражения) вполне можно сделать по аналогии с редакторами.


_>Да-да. Со свитчами.


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

_>>>Чтобы проверить, есть ли у свойства нужный атрибут, надо перебрать все атрибуты и попытаться найти среди них атрибут нужного типа. Опять rtti

ГВ>>Нет, больше похоже на подмену понятий. Достаточно найти атрибут с нужной сигнатурой, или содержащий нужный символ.

_>У атрибутов в .net еще и поля со значениями бывают. Например, пишем [PermissionSet(SecurityAction.LinkDemand, File="Unrestricted.xml")], и этот файл зачитывается во время компиляции и помещается в код как параметр конструктора класса PermissionSetAttribute. Компилятор, кстати, об этом не знает — он знает, что надо вызвать конструктор PermissionSetAttribute(SecurityAction.LinkDemand), присвоить его свойству File указанное значение, а потом сериализовать получившийся объект прямо в результирующий код, где на рантайме он оживет, когда попросят.


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

_>А буковки еще хуже, чем rtti — с классами атрибутов компилятор контролирует, какой класс создается, а сигнатуру можно любую написать. И от проверок и свитчей сигнатуры все равно не избавят.


Ээээ... согласен, да. Сигнатуры — одно из возможных, но не лучшее решение, поскольку в данном случае просто подменяют rtti.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[24]: Будущее C#
От: IT Россия linq2db.com
Дата: 03.07.03 16:30
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Кривыми затычками — можно.




_>REGISTER_CLASS("CategoryInfo", CategoryInfo)
_>  REGISTER_MEMBER("CategoryID", CategoryID)
_>  REGISTER_MEMBER("CategoryName", CategoryName)
_>  REGISTER_MEMBER("Count", Count)
_>END_REGISTER_CLASS()


Макросами много чего можно. В твоём примере можно даже строковое задание имён полей убрать и сгенерировать их через #. Но что-то мне помнится Страуструп говорил о макросах и о плохом дизайне

_>И дальше получается та же одна строка.


Дальше получается что макросы мощнее шаблонов

_>Не надо путать написание шаблонов и их использование. Запрещать использовать vector, string, map, sort при работе на c++ — очень странное решение.


Ну ладано-ладно, подловил Хотя глядя на for с трёхэтажными итераторами в C++ и наглядность foreach в C# начинаешь задумываться о смысле жизни.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Будущее C#
От: WolfHound  
Дата: 03.07.03 16:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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

Вто не надо... с темже успехом можно сказать,а где рарантия что компилятор сгенерирует правильный код? Например в моей текущей практике почти половина ошибок на совести компилятора.(BCB6)
... << 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[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[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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 20:18
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>А чем плох большой размер obj-ей? Они же все равно пользователю не отдаются.

DG>Единственная проблема в том, что надо как-то стандартизовать, менять и т.д. формат информации в obj-е, но тут мог помочь xml.

Эээ. Как раз обектники при этом идут лесом. Это уде будет длл-ка. Ну, нечто вроде дотнетной сборки. И клиенту их как раз придется отдавать.

Другое дело, что хранить их можно намного компактнее чем сегодняшние объектники. Дотнет как раз это и делает.

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

DG>В продолжение, к предыдущему письму.

DG>И на данный момент, конечно, единица трансляции в один cpp-файл, конечно, очень маловато будет.Особенно учитывая, что обычно один класс — один cpp.

Короче, дотнет рулит! Сборки и никаких гвоздей.

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

_>>>У нас на 20-меговый .exe (configuration=debug) 370 мегов .obj. Даже 512 мегов маловато — линкуется несколько минут. Инкрементальный линк на 100-меговом .pdb уже не работает — линкер вываливается с ошибкой. Шестая студия, кстати, не могла делать инкрементальный линк уже с 64-меговым .pdb.

DG>>Это связанно с тем, что каждый отдельный obj хранит всю информацию, которая встречалась в данном cpp-ишнике и всех H-ников, которые в него include-ились, что сейчас как раз приводит к раздуванию obj-ей.

_>Я просто неправильно тебя понял. Я полностью с тобой согласен — система раздельной компиляции через obj напрочь устарела, и скомпилированные модули с метаданными рядом с кодом, впервые увиденные мной в турбопаскале, увеличивают скорость компиляции на порядки.


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

ГВ>Ай-яй-яй Определи-ка мне термин "уродство", не сочти за труд. А то не дискуссия, а базарная склока получится. Да, и ещё обоснуй употребление предиката "все". А то у меня появляются основания обвинить тебя в неправомерном обобщении.


Переведу его на русский.

Все реализации сериализации без наличии информации о типах (а это больше чем ртти) приводят к тому или иному объему ручного кодирования для даждого сериализуемого класса.

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

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

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

ГВ>Упс? А почему этот код — ненужный?


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

_>Если ошибочный дизайн приводит к более простому и ясному коду, чем правильный, то пора пересмотреть методы оценки дизайна.


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

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


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

PS

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

_>Да-да. Со свитчами.


Свичи — это прошлый век. Теперь рулят хэш-таблицы и делегаты.

Делаем примерно так:

Hashtable _ht = new Hashtable();

...

_ht.Add(typeof(MyType1), new SomeDelegate(SomeHandler1));
_ht.Add(typeof(MyType2), new SomeDelegate(SomeHandler2));
_ht.Add(someObject.GetType(), new SomeDelegate(SomeHandler3));

... // Где-то в дали... :)
void UniversalHandler(object obj, SomeType param1)
{
  ((SomeDelegate)_ht[obj].Value)(param1);
}


И у нас автоматом получается решение которое будет работать даже если на стадии компиляции нам небыл известен тип объекта someObject.

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

ГВ>Где гарантия наличия реализации Save (или адекватности его генерации) для всех членов A.Properties? Или скажем так, чем гарантируется, что при введении 501-го типа Property система не начнёт слетать в одном случае из сотни?


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

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


Это работает твое мировозрение. Ты привык что код сериализации должен быть захардкоден. А с использованием информации о типах сериализация делается автоматом.

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

ГВ>Ну... плохой компилятор, что тут можно сказать.

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

ГВ>Ээээ... согласен, да. Сигнатуры — одно из возможных, но не лучшее решение, поскольку в данном случае просто подменяют rtti.


Гы. А дотнете нет ртти. Там это называется рефлекшеном. И это именно он и был.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 21:09
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Если такие же, как в .Net, то да. Но они не всегда такие и нужны. А реализовать сопоставление метаинформации экземпляру можно и без rtti.


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

VD>>Я тебя не удевлю если скажу, что все это можно сделать и на Шарпе (т.е. без шаблонов)? Причем решения будут даже более красивыми.


ГВ>Затыкание дырок C#? Забавно.


Демагогия вместо аргументов? Забавно... А если серьезно, то на Шарпе для большинства задач просто не нужно затыкать дыры. Есть красивые шаттные решения не приводящие к трехэтажным наворотам.

VD>>Так что твои примеры скорее являются доказательством высказанной мною мысли, о том что 90% использования шаблонов в С++ является затыканием дырок языка. И вызваны прощетами в языке.


ГВ>Эдак любую библиотеку можно назвать затыканием дырок языка, на котором она написана.


Я про всю библиотеку в общем то и не говорю. Но вот сигналы бесспорно являются затыканием дыр. И TypeList-ы тоже.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 21:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, IT, Вы писали:


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

WH>Вот оветь на такой вопрос? Если С++ почти мертв как ты утверждаешь то почему МС вкладывает в развитие С++ компилятора кучу денег? Я не могу оценить изменения фреймворка но могу оценить изменения в С++ компиляторе и у меня такой чувство что вложения в него измеряются мегабаксами как минимум. Мало того что он понимает все что мне приходит в голову, компилирует boost лучше всех даже comeau сделал так он еще и не глючит.

Мой тебе совет. Сходи на ixnt. Найди там форум по программированию. Сделай в нем поиск на фамилию "Рыбинкин" и почитай...

Он изучал С (без плюсов). Во времена когда С был в фаворе. Он стал в нем докой... И до сих пор говори о нем те же слова, что ты о С++.

Что же касается МС. То они если ты заметил прикрутили к МС++ все свои последние навороты от дотнета. И в таком виде С++ еще долго будет жалеть всех живых.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 21:10
Оценка:
Здравствуйте, IT, Вы писали:

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


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

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

WH>По моему нормально, а как иначе?

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

Я это:
VD>
про:

— Гоги! У вас родился ребенок.
— Малчык?
— Нет.
— А кто?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Будущее C#
От: IT Россия linq2db.com
Дата: 03.07.03 21:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Вот оветь на такой вопрос? Если С++ почти мертв как ты утверждаешь то почему МС вкладывает в развитие С++ компилятора кучу денег? Я не могу оценить изменения фреймворка но могу оценить изменения в С++ компиляторе и у меня такой чувство что вложения в него измеряются мегабаксами как минимум. Мало того что он понимает все что мне приходит в голову, компилирует boost лучше всех даже comeau сделал так он еще и не глючит.


Вложение в компилятор — это фактически зарплата группе разработчиков. Пусть их 10, пусть они в среднем получают где-то по 100 кило в год, получается, да, где-то с лимон. Не такие уж большие деньги для MS

Почему вкладывают? А почему нет? C++ всё ещё жив, возможно они даже пытаются что-то сделать, чтобы продлить его существование (возмём тот же MC++), не исключено, что если комитет совсем забьёт на C++, то они самостоятельно добавят в него всё необходимое. Потом, я говорю прежде всего о массовом применении C++, там где надо будет копаться с указателями ему всегда место найдётся, но из прикладного программирования он однозначно будет вытеснен другими языками с более продвинутыми возможностями. Ведь на самом деле, по большому счёту дело не в языке. Почему на Дельфях можно клепать клиентские приложения гораздо быстрее чем на VC++? Да потому что среда на это заточена. Почему Remoting воспринимается новичками за неделю, а COM — это как минимум полгода тума в голове? Потому что Remoting родная встроенная часть .NET и её применение более чем прозрачно, объект делается удалённым или локальным внесением пары строк в конфигурационный файл приложения. Почему все прикладные разработки на Юниксе включая всякие саны делаются на Java, а не на C++? Потому что затраты на разработку несоизмеримо дешевле, а решения надёжнее. То что мы всё ещё используем Visual C++ под Windows, так это просто по старинке, но похоже этому скоро придёт конец. А большего рынка чем под Windows у C++ нет, под юниксом на нём клепают только всякие мелкие софтинки и крохотные тулзинки.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 21:34
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>
_>REGISTER_CLASS("CategoryInfo", CategoryInfo)
_>  REGISTER_MEMBER("CategoryID", CategoryID)
_>  REGISTER_MEMBER("CategoryName", CategoryName)
_>  REGISTER_MEMBER("Count", Count)
_>END_REGISTER_CLASS()
_>


_>И дальше получается та же одна строка.


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

N>я имел ввиду, что читать этот код придется не настолько часто, чтобы его сложность представляла собой реальную проблему.

N>Не так уж часто приходится читать исходники библиотек, да? Это не костяк программы, это инструментарий.

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

_>У них все еще хуже — они даже не позволяют value-типу быть параметром шаблона. Виртуальная машина не меняется, и шаблоны остаются чисто синтаксической конструкцией. Они не могут поднять производительность, а могут только избавить от явного приведения типов и сделать код коллекций более безопасным.


Ну, хоть так. Хотя конечно это криво. Кстати, где об этом почитать можно (более менее конкретную ссылку, не java.sun.com).
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 21:34
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>и к дженерикам джавы.


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

_>Good news! After this article was written, autoboxing was added to the Java 1.5 spec!


Гы. А как орали! Сакс... сакс... МС нарушают целостность и объектноориентированность языка! Глядишь через некоторое время добавят делегаты со свойствами и будет Шарп2.

А про невозможность работы шаблонов с приметивами — это они сильно дурака сваляли. Если МС не сваляет так же, то дотнет будет делать Яву по скорости из любого положения. Про удобство и говорить не приходится.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 21:34
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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

_>Если только чуть-чуть. В отсутствие множественного наследования для проверки возможности кастинга, если кастят не к интерфейсу (а это бывает часто), достаточно пробежаться по цепочке предков испытуемого объекта и попытаться найти нужный тип. А нормальные коллекции value-типов, поднимающие производительность гораздо сильнее, джаве не светят.


Если они так тупо будут делать, то тормоза будут жуткие. По крайней мере в дотнете все намного умнее. Но даже самая быстрая реализация будет медленнее чем подразумеваемый кастинг. Шаблоны позволяют (потенциально) вообще избежать up-кастинга. Ведь рельно эту проверку может сделать компилятор. Ну, а в виду отсуствия МН остальное уже времени не требует.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 21:42
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>У CheckedListViewItemCollection сначала идет Count, а потом ItemArray, а у SelectedListViewItemCollection — наоборот, сначала SelectedItemArray, а потом Count


Дык у них мудренный генератор. Они сожают 1000 китайцев и те генерят, генерят... А шаблон пищется на бумаге.

VD>>К тоу-же есть CollectionBase. Наследуйя от него и 90% коллекций будут писаться за пару минут.


_>Это те самые остальные 10%. *ListViewItemCollection пользуются *IndexCollection для получения номеров, чтобы потом вытащить сами элементы из ListViewItemCollection.


CollectionBase довольно универсален. Я к сожалению по начеле о нем не знал, а потом не просек его гибкости. Думаю та же фигня была и у них. А то и вообще сначала все написали влоб, а потом создали CollectionBase.

Кстати, там такая дико не оптимальная реализация, что если сделать на CollectionBase и не допустить таких глупостей, то было бы намного быстрее.

_>Кстати, к msvc 1.0 такой был


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

AVK>Мой вариант делегатов? Ты о чем?


Не. Твой вариант динамической подключалки реализаций.

AVK>>>Меньше кода, код легче читать.

VD>>А счего меньше кода? Куда эти чуда-методы пихать?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Будущее C#
От: Nose Россия  
Дата: 03.07.03 21:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ага. Почти никогда. И откуда взялся термин RTFS?


не доводите мои слова до абсурда.
... << RSDN@Home 1.1 beta 1 >>
Re[29]: Будущее C#
От: Nose Россия  
Дата: 03.07.03 21:52
Оценка:
Здравствуйте, AndrewVK, Вы писали:



AVK>Кому как. Написателям библиотек например очень часто приходиться

Разработчик этой библиотеки отлично прочитает такой код. Достатоно привыкнуть, он не так страшен, хотя очень не похож на классический код c++

AVK>Инструментарий тоже надо писать и развивать

Не спорю.

В общем, спорить не о чем. Посоветую: книжку Александреску стоит прочитать, даже если вы никогда не будете ипользовать идеи там изложенные, они очень интересны. Программирование процесса генерации кода — очень интересная тема.
... << RSDN@Home 1.1 beta 1 >>
Re[24]: Будущее C#
От: IT Россия linq2db.com
Дата: 03.07.03 22:00
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Двойка тебе за знание адонета . Чтобы создать команду нет необходимости открывать коннекшен, открывать нужно только для Execute, Prepare и BeginTransaction.


Ну вот так ни за что А я всегда явно указываю конекшин, вдруг потом в него придётся добавить вызов ещё одной команды.

IT>>старею...


AVK>Мужаешь


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

VD>>Ага. Почти никогда. И откуда взялся термин RTFS?


N>не доводите мои слова до абсурда.


Я к тому, что исходники библиотек читаются и очень даже бурно. И чем проще читать код, тем больше людей смогут использовать эту библиотеку. Например, к дотнету в половине случаев исходников нет (есть SSCLI, но в нем многого нет). Дык любой серьзный специалист по дотнету в качестве основных шорткатов/иконок держит сслки на Анакрину и Эксплорел (декомпайлры).
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.03 22:28
Оценка:
Здравствуйте, IT, Вы писали:

IT>Скорее всего они уже знают все плюсы и минусы. Самое печальное, что твоя позиция изначально проигрышная, ты споришь не с представителями вражеского лагеря как тебе кажется, а с теми кто уже давно прошёл твой путь, кто так же как ты сейчас когда-то восхищался возможностями языка, кто честно заработал свои шрамы в боях C++ vs Паскаль


Именно.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.07.03 23:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Это работает твое мировозрение. Ты привык что код сериализации должен быть захардкоден. А с использованием информации о типах сериализация делается автоматом.


Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?

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

ГВ>>Ну... плохой компилятор, что тут можно сказать.

VD>А у меня в основном на моей совести.

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

ГВ>>Где гарантия наличия реализации Save (или адекватности его генерации) для всех членов A.Properties? Или скажем так, чем гарантируется, что при введении 501-го типа Property система не начнёт слетать в одном случае из сотни?


VD>Гарантия в коде универсального сериализатора. Код сериализации автоматически сериализует состояние объектов на основании информации о них.


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

ГВ>>Если такие же, как в .Net, то да. Но они не всегда такие и нужны. А реализовать сопоставление метаинформации экземпляру можно и без rtti.


VD>Ага. Вот только прочитать в рантайме турдно. А иногда хотелось бы. Что плохой дизайн?


Ну нет, почему же? Если сопоставление метаинформации реализуется для его дальнейшего использования, то чтение будет удобным. По-моему, это очевидно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: Будущее C#
От: IT Россия linq2db.com
Дата: 04.07.03 00:24
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?


В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.07.03 01:12
Оценка:
Здравствуйте, VladD2, Вы писали:

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


ГВ>>Ээээ... согласен, да. Сигнатуры — одно из возможных, но не лучшее решение, поскольку в данном случае просто подменяют rtti.


VD>Гы. А дотнете нет ртти. Там это называется рефлекшеном. И это именно он и был.


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

VD>>>Я тебя не удевлю если скажу, что все это можно сделать и на Шарпе (т.е. без шаблонов)? Причем решения будут даже более красивыми.


ГВ>>Затыкание дырок C#? Забавно.


VD>Демагогия вместо аргументов? Забавно... А если серьезно, то на Шарпе для большинства задач просто не нужно затыкать дыры. Есть красивые шаттные решения не приводящие к трехэтажным наворотам.


Что-то ты странное говоришь. Что ты подразумеваешь под словом "дыра"?

VD>>>Так что твои примеры скорее являются доказательством высказанной мною мысли, о том что 90% использования шаблонов в С++ является затыканием дырок языка. И вызваны прощетами в языке.


ГВ>>Эдак любую библиотеку можно назвать затыканием дырок языка, на котором она написана.


VD>Я про всю библиотеку в общем то и не говорю. Но вот сигналы бесспорно являются затыканием дыр. И TypeList-ы тоже.


Повторя вопрос — что есть "дыра"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.07.03 01:45
Оценка:
Здравствуйте, IT, Вы писали:

ГВ>>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?


IT>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.


Хммм... похоже, ты меня совсем не понял.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[31]: Будущее C#
От: Nose Россия  
Дата: 04.07.03 05:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я к тому, что исходники библиотек читаются и очень даже бурно. И чем проще читать код, тем больше людей смогут использовать эту библиотеку. Например, к дотнету в половине случаев исходников нет (есть SSCLI, но в нем многого нет). Дык любой серьзный специалист по дотнету в качестве основных шорткатов/иконок держит сслки на Анакрину и Эксплорел (декомпайлры).


Я и не спорю. Есть такой недостаток у обобщенного кода. Но принимая во внимание его полезность (хотя для меня сейчас — она теоретическая ), это не фатальный недостаток. А читать его все-таки можно привыкнуть.
... << RSDN@Home 1.1 beta 1 >>
Re[17]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:12
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


Ну ж фиг там. Вот исходная цитата alexkro, из-за которой весь спор начался:

На C++ тоже можно для .NET программировать и при этом использовать большинство его (C++) идиом.


С чем я собственно и не согласился. Потому и написал:

A>На C++ тоже можно для .NET программировать

Ну и что? Если укладываться в рамки CLR то от С++ остануться рожки да ножки.

A>и при этом использовать большинство его (C++) идиом.

Большинство идиом в managed коде? Не получится.


И вот тут ты решил поиграться с терминами. Так что не надо перекладывать с больной головы на здоровую.

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


VD>Но это же не отменяет возможности компилировать старые приложения в MSIL и делать для них обертки в виде __gc-классов?


Не отменяет. Но называть это доступностью всех возможностей для программирования под дотнет имхо не стоит. Часть возможностей доступна, а для части нужны обертки, чтобы все это можно было использовать в нетовской инфраструктуре.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[15]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:12
Оценка:
Здравствуйте, alexkro, Вы писали:

A>Это потому, что ты уже знал язык, который обладает большими возможностями. А человек, который программировал на языке с возможностями, перекрывающими C++, перепрыгнет на него с такой же легкостью.


Шарп по идеологии весьма серьезно отличается от плюсов, максимум что можно использовать это похожий синтаксис. С шарпом я таких наблюдений не проводил, но зачастую для получения качественного кода на джаве новичков приходится учить меньше, нежели зубров, писавших на плюсах и дельфи.

A>Значит ли это, что C++ сложнее изучать? Не факт. Просто изучать нужно правильно.


Ровно так же нужно правильно изучать дотнет. И тогда не будут приходить в голову мысли, озвученные в корне топика.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:22
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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

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

ГВ>Упс? А почему этот код — ненужный?


Потому что можно обойтись без этого.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[30]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:22
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>К типам данных источника, надеюсь?


Естественно.

ГВ>Если так, то тривиально. Выбором нужного агрегата из набора имеющихся и привязкой его к позиции колонки.


Вот вот, выбор ты как будешь осуществлять и из чего?

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


Проблема в том что этот самый std::map при наличии rtti не нужен.

Ладно, продолжаем двигаться дальше. Теперь представь что на момент написания есть одна версия источника. Далее, когда ты уже свой софт написал и отдал билд клиенту у источника появился новый ип данных. Твои действия?

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


AVK>>SOAP


ГВ>Понятно, началось передёргивание. Следующим вариантом, видимо, будет TCP/IP, а что? чем не источник? SOAP — это протокол обмена.


ОК, если действительно не понимаешь или делаешь вид, то пускай это будет веб-сервис. Так понятнее?

ГВ> Если очень приспичит, то я сделаю единый для клиентского приложения набор SOAP-сообщений, к которым и сведу обмен между приложением и клиентом.


А если сервис не ты писал? А если он изменился?

ГВ>И при чём тут распознавание большого количества типов?


При том что SOAP отнюдь не ограничен стандартным набором типов.

ГВ>Или ты имеешь ввиду, например, что для гридов Order и Employee, буде они получены через SOAP нужно обязательно писать два отдельных грида?


Нет, я имею ввиду что для отображения недетерминированных заранее источников данных rtti очень полезен.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[24]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:32
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Гарантия в коде универсального сериализатора. Код сериализации автоматически сериализует состояние объектов на основании информации о них.


ГВ>Да фиг с ней, с сериализацией.


А, то есть таки сериализация красиво и лаконично без наличия rtti не выходит? Так как тогда быть с твоими заявлениям про неверный дизайн?

ГВ>Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации, а о чём-то ещё,


Не увиливай. Речь идет о сериализации.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:32
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации.


Неа. Форматтеры и XmlSerializer вполне могут быть написаны самостоятельно без использования фич clr. Точнее с использованием одной фичи, которая называется рефлекшен.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:32
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.


ГВ>Хммм... похоже, ты меня совсем не понял.


Правильно он тебя понял. Нет там никакого специального механизма для сериализации, есть только рефлекшен, который ровно так же пригоден и для той же визуализации, о которой ты поминал. Сему пример тот же PropertyGrid.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[27]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Вот такой стиль намного лучше:


Атрибут только называется Serializable
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[30]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:32
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Если такие же, как в .Net, то да. Но они не всегда такие и нужны. А реализовать сопоставление метаинформации экземпляру можно и без rtti.


Ага, при помощи монстроидальных мапов и шаблонов. Самое смешное что народ приводит громоздкий код на плюсах в доказательство того как на плюсах все просто. Вот только на шарпе все то же самое выходит в разы проще, понятнее и красивше.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:42
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну нет, почему же? Если сопоставление метаинформации реализуется для его дальнейшего использования, то чтение будет удобным. По-моему, это очевидно.


Так же совершенно очевидным является то что сопоставление этой самой информации руками не есть лучшее решение, поскольку все то же самое можно сделать автоматически.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[25]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:42
Оценка:
Здравствуйте, IT, Вы писали:

IT>Без привычки твой код нужно распечатать и сидеть с бумажками разбираться что он там делает. А лучше сразу сбегать в ларёк за пузырём


Ой IT, оторвался ты совсем от российских реалий. Пузырьки теперича в ларьках не продают, запрещено. Так что придется бежать немножко подальше, в магазин. Правда в ларьке можно купить пиво.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[23]: Будущее C#
От: Аноним  
Дата: 04.07.03 06:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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



VD>Ты знаком с тем как сериализация делается в дотнете? Там это ровно одна строчка кода. Причем от самого класса практически ничего не требуется. Нужно всего лишь пометить класс отрибутм говорящим что класс сериализуемый. Уравлять тем, что не нужно сериализовать или нужно сериализовать особым образом так же можно атрибутами.


Такая сериализация имеет недостатком скорость. Если надо сохранить словарь терминов на 100,000, что например встречается у нас постоянно, все выглядит очень удручающе. Да и объем тоже не воодушевляет.
Если же сохранять в бинарном виде (в других не знаю), то если поменять сборку, то она уже ничего не загрузит, т.к. сереализованный объект будет от другой версии.
Так что для сохранения настроек такая технология подходит очень хорошо, а для сохранения реальных данных (по крайней мере в моем случае) как то не катит
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Я плякаль... узнавая себя... и мысленно заменяя С++ на COM.


А мне вот повезло, поскольку джавой я занялся, поскольку ничего приличного на тот момент в сфере веб-приложений больше не было. Всеобще увличение поделкой под названием php меня как то не воодушевило, а jscript и прочия я не любил с детства . Ну а потом как то само собой получилось что дельфи и С++ отнюдь не всегда лучше даже не в веб-проектах. После этого дотнет воспринимался уже как родной .
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 06:52
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Вот оветь на такой вопрос? Если С++ почти мертв как ты утверждаешь то почему МС вкладывает в развитие С++ компилятора кучу денег? Я не могу оценить изменения фреймворка но могу оценить изменения в С++ компиляторе и у меня такой чувство что вложения в него измеряются мегабаксами как минимум.


А если сравнить с вложениями в дотнет?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[30]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:02
Оценка:
Здравствуйте, Nose, Вы писали:

AVK>>Кому как. Написателям библиотек например очень часто приходиться

N>Разработчик этой библиотеки отлично прочитает такой код. Достатоно привыкнуть,

Привыкнуть можно к примеру каждый день добираться до работы пешком, проходя километров десять. Однако почему то подавляющее большинство пользуется транспортом.

N>он не так страшен, хотя очень не похож на классический код c++


Страшен он, еще как страшен.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[21]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:02
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>и к дженерикам джавы.


VD>Кстати, ты уверен что в Яве их тоже дженериками назвали?


Причем раньше чем в дотнете. Речь о дженериках шла еще в 2000 году, а в 2001 уже была по моему пробная реализация.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[27]: Будущее C#
От: Sergey Россия  
Дата: 04.07.03 07:02
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Вот такой стиль устраивает?


S>>[ccode]

S>>class TestA : public ddx::controller<TestA, Loki::NullType>, public CDialog
S>>{
S>> typedef ddx::controller<derived_type, base_type> parent_t;
S>>protected:
S>> typedef ddx::member<CString, IDC_SERVER, Ser, &DDX_CBString> m_Server;
S>> typedef ddx::member<CString, IDC_PROCESS_NAME, Ser, &DDX_Text> m_ProcessName;
S>> typedef ddx::members<TYPELIST_2(m_Server, m_ProcessName)> members_info;
S>>public:
S>> TestA(CWnd *wnd) {}
S>> members_info ddxMembers;
S>>};


VD>


VD>О том и нечь что нет! Ни в коем случе не устривает. Это мазохизм.


Что именно тебя тут пугает? Угловые скобки не нравятся, предпочитаешь квадратные?

VD>Да и этот код использует ртти (как я понимаю).


Неправильно понимаешь. Вся генерация кода делается в компил-тайме.

VD>Вот такой стиль намного лучше:


VD>
VD>[Serialize]
VD>class TestA
VD>{
VD>    public TestA(CWnd wnd) {}
VD>    public string m_Server;
VD>    public string m_ProcessName;
VD>};

VD>[Serialize]
VD>class TestC : TestA
VD>{
VD>    public TestC(CWnd wnd) : bsae(wnd)
VD>};

VD>...
VD>    TestC с = new TestC(xxx);
VD>    ... // Что-то тварим с объектом...
VD>    // Это весь код необходимый для сериализации!
VD>    MemoryStream ms = new MemoryStream(1024);
VD>    BinaryFormatter bf = new BinaryFormatter();
VD>    bf.Serialize(ms, ds);
VD>


Угу, только у класса TestC есть десяток членов, которые сериализовать не надо. По этому атрибут [Serializable] придется для каждого члена указывать, во вторых — для каждого члена, вовлеченного в другие операции (у меня это — DoDataExchange), придется другие атрибуты добавлять. Получится еще страшнее, чем у меня.

VD>Собственно главное код сериализации который в самом конце. Вот это красиво. К сожелению не так быстро как хотелось бы, но красиво.


Собственно, код сериализации сидит в библиотеке — в обоих случаях.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[25]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 07:06
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>REGISTER_CLASS("CategoryInfo", CategoryInfo)

_>> REGISTER_MEMBER("CategoryID", CategoryID)
VD>А что теперь если содержимое запроса изменится?

В исходном примере та же проблема — структура данных отдельно, select отдельно, и имена дублируются. Мы в таких случаях передаем в Command вместо списка полей специальную пиндюшку, которая внутри превращается в список, но с COUNT и прочими вычисляемыми полями это, конечно, не поможет.
Re[18]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 07:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

Короче, у меня нет желания бесполезно дискутировать о значении термина менеджед-код. Думаю, то и все остальные все поняли как надо.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 07:08
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да фиг с ней, с сериализацией. Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации,


Нет, ну почему же? Это хороший пример демонстрирующий приемущества наличия полноценной информации.

ГВ> а о чём-то ещё, что так же, как и сериализация, строится по прнципу вызова специфического кода для каждого поля объекта.


Еще раз повторяю. Отойди от привычный тебе концепций. В дотнете богатство информации о типах позволяет во многих случаях писать универсальный код. В том числе и для сериализации.

ГВ> Ну, к примеру, визуализация.


Визуализация слишком абстрактный термин.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 07:08
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?


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

ГВ>Хммм... похоже, ты меня совсем не понял.


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

ГВ>Что-то ты странное говоришь. Что ты подразумеваешь под словом "дыра"?


Думаю, ты и сам понимаешь. Дыры — это отсуствие в языке/рантайме простых конструкций решающих стоящие перед тобой задачи. Например, когда стоит задача вызывать метод у абстрактного объекта... или когда стоит задача сделать что-то на сосновании описания типа.

Все примеры приведенные в том посте делаются на Шарпе элегантно и просто. При этом Шарп ведь не обладает такими мощными средствами самомодификации. Мысль ясна?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 07:08
Оценка:
Здравствуйте, Nose, Вы писали:

N>Я и не спорю. Есть такой недостаток у обобщенного кода. Но принимая во внимание его полезность (хотя для меня сейчас — она теоретическая ), это не фатальный недостаток. А читать его все-таки можно привыкнуть.


Можно. Но очень не хочется. А такие примитивы как делегаты хочется иметь на уровне языка. Все же не ясно почему я должен часами смотреть на компиляцию базовых вщей.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 07:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Шарп по идеологии весьма серьезно отличается от плюсов, максимум что можно использовать это похожий синтаксис. С шарпом я таких наблюдений не проводил, но зачастую для получения качественного кода на джаве новичков приходится учить меньше, нежели зубров, писавших на плюсах и дельфи.


Это уже снобизм и шовинизм. Мне почему-то знание С++ не мешает писать на шарпе. Я еще и С знаю. И на нем много писал. Этак мы дойдем, что все кто знают старые зыки на новые уже могзги переглючить не могут.

Принцыпы программирования одни и те же. Есть различия которые нжно осозновать и учитывать. Только и всего.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А про невозможность работы шаблонов с приметивами — это они сильно дурака сваляли. Если МС не сваляет так же, то дотнет будет делать Яву по скорости из любого положения.


У сана вобще очень странная политика, больше похожая на политику комитета по плюсам. Они с радостью стандартизируют библиотеки, причем выделяя на доведение этих библиотек своих спецов, но вот когда дело заходит об изменении языка и jvm то они упираются рогом. Если бы не МС то они наверное так бы никаких изменений в jvm и язык вносить не стали бы, хотя кое что напрашивается еще с древних версий. Возможно что виновато в этом то что сану приходится писать 3 jvm, а не одну, как МС.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[23]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:12
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Снижают ты хотел сказать. Полиморфизм и без шаблонов неплохо работал. Грамотная реализация шаблонов как раз могла бы избавить от лишних кастов и боксингов.


Ну я именно это и хотел сказать. Т.е. то что путем замены полиморфных алгоритмов шаблонами можно повысить эффективность за счет уменьшения количества кастингов.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[24]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Если они так тупо будут делать, то тормоза будут жуткие.


Им надо начинать править не с этого, а с добавления пользовательских value-типов в язык.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[25]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык у них мудренный генератор. Они сожают 1000 китайцев и те генерят, генерят... А шаблон пищется на бумаге.


Скорее индийцев, но в целом ты прав.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[25]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:12
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Мой вариант делегатов? Ты о чем?


VD>Не. Твой вариант динамической подключалки реализаций.


А при чем тут она? Разговор то о делегатах
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[24]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:12
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Так что для сохранения настроек такая технология подходит очень хорошо, а для сохранения реальных данных (по крайней мере в моем случае) как то не катит


А для сохранения реальных данных предназначена не сериализация, а СУБД.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[30]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 07:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>Если такие же, как в .Net, то да. Но они не всегда такие и нужны. А реализовать сопоставление метаинформации экземпляру можно и без rtti.

При объектном подходе информацию как-то привычнее представлять классами. Метаинформация ничем не волшебнее.
Re[25]: Будущее C#
От: Аноним  
Дата: 04.07.03 07:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, <Аноним>, Вы писали:


А>>Так что для сохранения настроек такая технология подходит очень хорошо, а для сохранения реальных данных (по крайней мере в моем случае) как то не катит


AVK>А для сохранения реальных данных предназначена не сериализация, а СУБД.


А как передавать такие объемы данных клиенту? В этой ветке где-то был разговор про SOAP, так что вот конкретный пример. А передать по низкоскоростному каналу связи лишние несколько метров как-то не хочется.

По моему в RSDN как раз была статься по ручной сереализации dataset для решения этих проблем.

PS Да, и на моей практике, если менялись типы данных или запросов, то все равно менялась логика, поэтому прелесть определения типов как то падает.
Re[28]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 07:27
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Я не понимаю главного. Сейчас интерфейс клиентского курсора, грубо говоря, выглядит так:

class DataTable {
  public DataRowCollection Rows {get;}
  public DataColumnCollection Columns {get;}
}

class DataColumnCollection {
  public int Count {get;}
  public DataColumn this[int index] {get;}
}

class DataColumn {
  public string ColumnName {get;}
  public Type DataType {get;}
}

class DataRowCollection {
  public int Count {get;}
  public DataRow this[int index] {get;}
}

class DataRow {
  public object this[DataColumn] {get; set;}
}


Как он изменится, если мы ставим целью избавиться от object и Type?
Re[25]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 07:32
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>Кстати, к msvc 1.0 такой был

VD>В смысле макросы? Или я что-то пропустил?

Какая-то примочка к компилятору, которая брала на вход не то шаблоны с убогим синтаксисом, не то что-то свое и генерила специализации. К счастью, ее я тоже пропустил.
Re[26]: Будущее C#
От: Аноним  
Дата: 04.07.03 07:35
Оценка:
Здравствуйте, Sergey, Вы писали:


S>Вот такой стиль устраивает?


S>[ccode]

S>class TestA : public ddx::controller<TestA, Loki::NullType>, public CDialog
S>{
S> typedef ddx::controller<derived_type, base_type> parent_t;
S>protected:
S> typedef ddx::member<CString, IDC_SERVER, Ser, &DDX_CBString> m_Server;
S> typedef ddx::member<CString, IDC_PROCESS_NAME, Ser, &DDX_Text> m_ProcessName;
S> typedef ddx::members<TYPELIST_2(m_Server, m_ProcessName)> members_info;
S>public:
S> TestA(CWnd *wnd) {}
S> members_info ddxMembers;
S>};

1. Как будет выглядить код, который должен работать с переменными m_Server и m_ProcessName?
2. Как будет выглядить код, если часть из этих полей надо еще за-save-ить?

зы
В идеале хочется вот такой код:
public TestA
{
  [Editable]
  string Server;
  [Editable, Serializable]
  string ProcessName;  
  typedef (select Field from TestA.Fields where Serializable in Field.Attributes) SerializablePropertiesMap;
  typedef (select Field from TestA.Fields where Editable in Field.Attributes) EditablePropertiesMap;
}

Вот к такому код из C++ даже со всеми ухищрениями Александреску не получится приблизится.
.Net позволяет приблизится к такому коду, но к сожалению в Runtime, а не при компиляции

Почему данный код лучше, чем явное задание map-ов, здесь уже пробегало: это атомарность добавления/удаления
отдельного свойства, что положительно сказывается на масштабируемости классов.
Re[19]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Короче, у меня нет желания бесполезно дискутировать о значении термина менеджед-код. Думаю, то и все остальные все поняли как надо.


Ну так не надо было и начинать
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[17]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 07:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это уже снобизм и шовинизм. Мне почему-то знание С++ не мешает писать на шарпе. Я еще и С знаю. И на нем много писал. Этак мы дойдем, что все кто знают старые зыки на новые уже могзги переглючить не могут.


Это ты, поскольку ты не на одном С++ писал всю жизнь. Я о тех кто серьезно использовал в работе один язык. Да и сам ты поначалу очень сильно против дотнета возражал, достаточно почитать твои споры с мной и IT на эту тему полуторагодичной давности . А вот у новичков этого нет, они сразу воспринимают особенности шарпа как единственно верные.
В общем это давно известный эффект. Ранее много народу наступило на грабли, когда изучать структурное программирование после васика было тяжелее нежели изучать его с нуля.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[20]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 07:54
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>У них все еще хуже — они даже не позволяют value-типу быть параметром шаблона. Виртуальная машина не меняется, и шаблоны остаются чисто синтаксической конструкцией. Они не могут поднять производительность, а могут только избавить от явного приведения типов и сделать код коллекций более безопасным.

VD>Ну, хоть так. Хотя конечно это криво. Кстати, где об этом почитать можно (более менее конкретную ссылку, не java.sun.com).

http://developer.java.sun.com/developer/earlyAccess/adding_generics/

Но там регистриться надо, мне что-то лень.

Кстати, они дразнят обещаниями когда-нибудь добавить "вариантность" — аналог ковариантности массивов в .net, то есть возможность по желанию разрешить встроенное преобразование ArrayList<B> к ArrayList<A>, если B — наследник A. Непонятно, как это будет сделано, потому что в массивах типобезопасность при ковариантности обеспечивается встроенными проверками типа элемента при присваивании, а в шаблонах хотелось бы для производительности обходиться без этого.
Re[25]: Будущее C#
От: WolfHound  
Дата: 04.07.03 08:10
Оценка:
Здравствуйте, VladD2, Вы писали:

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

ГВ>>Ну... плохой компилятор, что тут можно сказать.
VD>А у меня в основном на моей совести.
Просто я научился писать так что большинство логичиских ошибок становятся ошибками компиляции те сводятся на уровень опечаток которые я за ошибки не считаю.
К стати за VC++7.1 я еще не замечал не верно сгенерированого кода. Так что на нем все мое. Правда и средства контороля выше.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 08:18
Оценка:
Здравствуйте, alexkro, Вы писали:

A> val_ = addt_.Add( val_, x ); // virtual function call!


Нет. При раскрытии шаблона джит видит, что AddableInt::Add невиртуальный — невиртуальные методы, перекрывающие методы интерфейсов, видны в мсиле как virtual final.

A>2) Generics имеют constraints. Зачем, спрашивается? А вследствие (1).


Вследствие того, что в мсил компилится код шаблона, а не его специализации. Плюсовая концепция, где + в шаблоне может раскрыться и в T::operator+(const T&), и в ::operator+(const T&, const T&), и даже в + для типов, к которым может преобразовываться T, здесь невозможна в принципе.
Re[27]: Будущее C#
От: Sergey Россия  
Дата: 04.07.03 08:21
Оценка:
Здравствуйте, Аноним, Вы писали:

А>1. Как будет выглядить код, который должен работать с переменными m_Server и m_ProcessName?


Ежели компилятор позволяет, то так:

void TestA::DoSomething()
{
   data<m_Server>() = "asdf";
}


Если нет (VC 6.0, например, как у меня), то, например, так:


#define DDX_DATA(theType) data((theType*)0)

void TestA::DoSomething()
{
   DDX_DATA(m_Server) = "asdf";
}


А>2. Как будет выглядить код, если часть из этих полей надо еще за-save-ить?


Код был приведен для случая, когда все поля сохраняются — там параметром шаблона класс Ser (typedef RegistrySerializer Ser указан. Если какое-то поле не надо сохранять, то вместо него указывается NopSerializer. То же и для DDX — там просто 0 вместо функции надо передать. Есть еще параметр для DDV, там по дефолту NOPValidator.

Кстати, typedef ddx::members<TYPELIST_2(m_Server, m_ProcessName)> members_info; там избыточен, можно было бы сразу переменную объявлять, это просто моя недоработка.

А>зы

А>В идеале хочется вот такой код:
А>
А>public TestA
А>{
А>  [Editable]
А>  string Server;
А>  [Editable, Serializable]
А>  string ProcessName;  
А>  typedef (select Field from TestA.Fields where Serializable in Field.Attributes) SerializablePropertiesMap;
А>  typedef (select Field from TestA.Fields where Editable in Field.Attributes) EditablePropertiesMap;
А>}
А>

А>Вот к такому код из C++ даже со всеми ухищрениями Александреску не получится приблизится.

Да, возможности получать в компил-тайме список членов-данных класса и пробежаться по нему в C++ сильно не хватает (лично мне, по крайней мере ). Остальное легко можно было бы сделать на шаблонах.

А>Почему данный код лучше, чем явное задание map-ов, здесь уже пробегало: это атомарность добавления/удаления

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

Ну у меня добавление/удаление свойстов тоже практически атомарны — забудешь нужный typdef или не внесешь поле в список, получишь ошибку компиляции. В принципе, можно было бы убрать и тайпдефы для полей, но тогда усложнился бы доступ к полям и потребовался бы более продвинутый компилятор.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 08:29
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Угу, только у класса TestC есть десяток членов, которые сериализовать не надо. По этому атрибут [Serializable] придется для каждого члена указывать,


Рекомендую ознакомиться с матчастью.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[28]: Будущее C#
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 04.07.03 08:31
Оценка:
Здравствуйте, Sergey, Вы писали:


А>>2. Как будет выглядить код, если часть из этих полей надо еще за-save-ить?


S>Код был приведен для случая, когда все поля сохраняются — там параметром шаблона класс Ser (typedef RegistrySerializer Ser указан. Если какое-то поле не надо сохранять, то вместо него указывается NopSerializer. То же и для DDX — там просто 0 вместо функции надо передать. Есть еще параметр для DDV, там по дефолту NOPValidator.


S>Кстати, typedef ddx::members<TYPELIST_2(m_Server, m_ProcessName)> members_info; там избыточен, можно было бы сразу переменную объявлять, это просто моя недоработка.


Неудобно. Получается, что сохранение и редактирование не ортогональны друг другу.

Если кроме задач "редактирования" и "сохранения" появится еще одна сходная задача:
например, вывод внутреннего состояния класса (например, надо сохранять все поля кроме ссылок "наверх", чтобы не было зацикливания) в log-файл, то как изменится код?
Re[29]: Будущее C#
От: Sergey Россия  
Дата: 04.07.03 08:54
Оценка:
Здравствуйте, DarkGray, Вы писали:

S>>Код был приведен для случая, когда все поля сохраняются — там параметром шаблона класс Ser (typedef RegistrySerializer Ser указан. Если какое-то поле не надо сохранять, то вместо него указывается NopSerializer. То же и для DDX — там просто 0 вместо функции надо передать. Есть еще параметр для DDV, там по дефолту NOPValidator.


S>>Кстати, typedef ddx::members<TYPELIST_2(m_Server, m_ProcessName)> members_info; там избыточен, можно было бы сразу переменную объявлять, это просто моя недоработка.


DG>Неудобно. Получается, что сохранение и редактирование не ортогональны друг другу.


Ну это смотря как смотреть на вещи Считай, что ты объявляешь переменные и задаешь для каждой список обязательных атрибутов — что использовать для сериализации, для DDX и для DDV. Атрибуты предопределенные, о них должна заранее знать библиотека. Наверное, можно при желании сделать расширяемый список атрибутов, но мне в данном конкретном случае это просто не было нужно, и я не стал на эту тему думать. Да и компилятор для этого, боюсь, более другой потребовался бы. По крайней мере, примерно с тем же кодом, но основанным на boost::mpl мой VC 6 не справился. Можно еще было бы поизвращаться на предмет занесения в список не самих переменных, а ссылок на них, но тогда пришлось бы инициализировать этот список в конструкторе класса, да и опять таки это решение выходило бы за рамки моих текущих задач.

DG>Если кроме задач "редактирования" и "сохранения" появится еще одна сходная задача:

DG>например, вывод внутреннего состояния класса (например, надо сохранять все поля кроме ссылок "наверх", чтобы не было зацикливания) в log-файл, то как изменится код?

Добавился бы еще один параметр шаблона:

typedef ddx::member<BOOL, IDC_REMOVECF, Ser, &DDX_Check, Logger> m_RemoveCF;
typedef ddx::validated_float<IDC_TIME_LIMIT, ddx::NOPSerializer, ddx::NOPLogger, 0.f, 100.f> m_TimeLimit;

ddx::members<TYPELIST_2(m_RemoveCF, m_TimeLimit)> ddxMembers;
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[8]: Будущее C#
От: alexkro  
Дата: 04.07.03 09:42
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, alexkro, Вы писали:


A>> val_ = addt_.Add( val_, x ); // virtual function call!


_>Нет. При раскрытии шаблона джит видит, что AddableInt::Add невиртуальный — невиртуальные методы, перекрывающие методы интерфейсов, видны в мсиле как virtual final.


Твое предположение о том, как generics будут работать в runtime не верно. Следовательно, и вывод о невиртуальности вызова тоже.

A>>2) Generics имеют constraints. Зачем, спрашивается? А вследствие (1).


_>Вследствие того, что в мсил компилится код шаблона, а не его специализации.


Да ну! Только что ты сказал, что jit раскрывает generic для специализации AddableInt.
Re[9]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 10:28
Оценка:
Здравствуйте, alexkro, Вы писали:

A>Твое предположение о том, как generics будут работать в runtime не верно.


Почему неверно? А как будет верно?

_>>Вследствие того, что в мсил компилится код шаблона, а не его специализации.


A>Да ну! Только что ты сказал, что jit раскрывает generic для специализации AddableInt.


И где здесь противоречие?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 10:32
Оценка:
Здравствуйте, <Аноним>, Вы писали:

AVK>>А для сохранения реальных данных предназначена не сериализация, а СУБД.


А>А как передавать такие объемы данных клиенту?


А вот то что "такие" объемы данных передаются клиенту свидетельствует о неверной архитектуре. Клиент, ака пользователь, способен воспринимать данные очень медленно, настолько медленно что даже куча служебной информации не способна сильно увеличить этот объем (мы не говорим конечно об аудио/видеопотоках). И если у тебя 100 тыс. записей отдаются клиенту это явный косяк.

А>В этой ветке где-то был разговор про SOAP, так что вот конкретный пример. А передать по низкоскоростному каналу связи лишние несколько метров как-то не хочется.

А>По моему в RSDN как раз была статься по ручной сереализации dataset для решения этих проблем.

Это уже совершенно отдельный разговор, к самой идее сериализации не имеющий отношения. Это уже проблемы конкретных особенностей xml, soap и реализации мсовских форматтеров.

А>PS Да, и на моей практике, если менялись типы данных или запросов, то все равно менялась логика, поэтому прелесть определения типов как то падает.


Опять же следствия недостаточно гибкого дизайна.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[9]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 10:33
Оценка:
Здравствуйте, alexkro, Вы писали:

A>>> val_ = addt_.Add( val_, x ); // virtual function call!

_>>Нет. При раскрытии шаблона джит видит, что AddableInt::Add невиртуальный — невиртуальные методы, перекрывающие методы интерфейсов, видны в мсиле как virtual final.
A>Твое предположение о том, как generics будут работать в runtime не верно. Следовательно, и вывод о невиртуальности вызова тоже.

Не неверно, а сомнительно. По крайней мере ничего не мешает это сделать не в этой версии, так в следующей.

A>>>2) Generics имеют constraints. Зачем, спрашивается? А вследствие (1).

_>>Вследствие того, что в мсил компилится код шаблона, а не его специализации.
A>Да ну! Только что ты сказал, что jit раскрывает generic для специализации AddableInt.

Компилятор делает msil, jit делает из него машинный код. В мсиле шаблоны лежат нераскрытыми, иначе мы не могли бы затребовать специализацию из другой сборки.
Re[31]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.07.03 12:17
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


На каком основании такие предположения? Единственное, что придётся сделать — написать mapping колонок, т.е. — что-то вроде:

... = {
col_map(0, "Attr1"),
col_map(1, "Attr1"),
col_map(2, "Attr1"),
col_map(-1, "") // Финализатор описания
}


Притом такой маппинг описывать проще, чем прыгать по десяти Property-box-ам. Так что, кто из нас будет что-то-там как папа Карло — ещё не известно.

Да и то, его (mapping, а вернее — layout) можно настроить автоматически по списку колонок рекордсета.

VD>Только и всего. Ну, и еще проблема в том, что тебе потребуется контрол с исходными кодами.


Ещё круче. Это-то зачем? Обычного SysListView32 вполне хватит.

VD>А я могу взять готовый из очень большого списка. Ну и главная проблема в том, что твой подход потребует от пользователя твоего грида (тоже программиста) на порядок больших знаний чем у меня.


My God! Да почему?!

VD>Но ведь задача то решается одна и та же. Стало быть ты вибираешь не верный метод решения задачи.


VD>PS


VD>Глупо спорить, что если задача легко решается без напряга без ртти и т.п., то и не следует его использовать. Вот только это не всегда так.


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

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

ГВ>>К типам данных источника, надеюсь?
AVK>Естественно.
ГВ>>Если так, то тривиально. Выбором нужного агрегата из набора имеющихся и привязкой его к позиции колонки.
AVK>Вот вот, выбор ты как будешь осуществлять и из чего?

"Из чего" — из набора прекомпилированных конвертеров.

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


AVK>Проблема в том что этот самый std::map при наличии rtti не нужен.


Да ну? А как же run-time analysis: "Если символ типа — X, то использовать алгоритм Z"? Или мы с тобой подразумеваем под rtti разные вещи.

AVK>ОК, если действительно не понимаешь или делаешь вид, то пускай это будет веб-сервис. Так понятнее?


Давай ещё проще — пусть это будет просто SOAP-овский вызов, который возвращает некий массив.

ГВ>> Если очень приспичит, то я сделаю единый для клиентского приложения набор SOAP-сообщений, к которым и сведу обмен между приложением и клиентом.

AVK>А если сервис не ты писал? А если он изменился?

В каком смысле изменился?

ГВ>>И при чём тут распознавание большого количества типов?

AVK>При том что SOAP отнюдь не ограничен стандартным набором типов.

То есть, ты хочешь узнать, что я буду делать, если вместо

<SomeValue>
  <Order>
    <OrderName>ABCDEF</OrderName>
  </Order>
  <Order>
    <OrderName>GHIJKL</OrderName>
  </Order>
</SomeValue>


Прибежит что-то вроде:

<SomeValue>
  <Order2>
    <OrderNm>ABCDEF</OrderNm>
  </Order2>
  <Order2>
    <OrderNm>GHIJKL</OrderNm>
  </Order2>
</SomeValue>


Я правильно предположил?

ГВ>>Или ты имеешь ввиду, например, что для гридов Order и Employee, буде они получены через SOAP нужно обязательно писать два отдельных грида?

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

Это тезис понятен.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 12:36
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Вот вот, выбор ты как будешь осуществлять и из чего?


ГВ>"Из чего" — из набора прекомпилированных конвертеров.


Мда, печальственно

AVK>>Проблема в том что этот самый std::map при наличии rtti не нужен.


ГВ>Да ну? А как же run-time analysis: "Если символ типа — X, то использовать алгоритм Z"? Или мы с тобой подразумеваем под rtti разные вещи.


А зачем там такой анализ? Там все проще будет — достать из атрибута тип конвертера, создать экземпляр, вызвать метод. И все. Никакого захардкоденного анализа, рассчитанного на определенный набор входных типов не надо. Прелесть сборок в том что они самоописательны. Т.е. для добавления новых типов достаточно просто положить в каталог сборки с дополнительными обработчиками. Базовую сборку менять или пересобирать не надо. Вариант с шаблонами требует как минимум перекомпиляции.

AVK>>ОК, если действительно не понимаешь или делаешь вид, то пускай это будет веб-сервис. Так понятнее?


ГВ>Давай ещё проще — пусть это будет просто SOAP-овский вызов, который возвращает некий массив.


Не суть важно. Главное что в SOAP набор типов не огранизен каким то узким диапазоном.

AVK>>А если сервис не ты писал? А если он изменился?


ГВ>В каком смысле изменился?


А вот в таком смысле и изменился — в возвращаемую табличку добавились типы, неизвестные на момент компиляции.

ГВ>Я правильно предположил?


Примерно.

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


ГВ>Это тезис понятен.


Тогда объясни свой тезис о неправильном дизайне при использовании rtti
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 12:38
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>На каком основании такие предположения? Единственное, что придётся сделать — написать mapping колонок, т.е. — что-то вроде:


ГВ>
ГВ>... = {
ГВ>col_map(0, "Attr1"),
ГВ>col_map(1, "Attr1"),
ГВ>col_map(2, "Attr1"),
ГВ>col_map(-1, "") // Финализатор описания
ГВ>}
ГВ>


И подождать полчасика пока проект пересоберется. Прелесть рефлекшена в том что в этом случае вобще ничего менять не надо.

ГВ>Притом такой маппинг описывать проще, чем прыгать по десяти Property-box-ам. Так что, кто из нас будет что-то-там как папа Карло — ещё не известно.


Не надо никуда низачем прыгать. Нужно просто подложить сборку с обработчиками.

VD>>А я могу взять готовый из очень большого списка. Ну и главная проблема в том, что твой подход потребует от пользователя твоего грида (тоже программиста) на порядок больших знаний чем у меня.


ГВ>My God! Да почему?!


Потому что прикладному программисту нужно обязательно помнить о необходимости предварительно вносить типы в меппер.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[27]: Будущее C#
От: Аноним  
Дата: 04.07.03 12:52
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, <Аноним>, Вы писали:


AVK>А вот то что "такие" объемы данных передаются клиенту свидетельствует о неверной архитектуре. Клиент, ака пользователь, способен воспринимать данные очень медленно, настолько медленно что даже куча служебной информации не способна сильно увеличить этот объем (мы не говорим конечно об аудио/видеопотоках). И если у тебя 100 тыс. записей отдаются клиенту это явный косяк.


Это оффлайновый клиент. Как ему еще работать?

А>>В этой ветке где-то был разговор про SOAP, так что вот конкретный пример. А передать по низкоскоростному каналу связи лишние несколько метров как-то не хочется.

А>>По моему в RSDN как раз была статься по ручной сереализации dataset для решения этих проблем.

AVK>Это уже совершенно отдельный разговор, к самой идее сериализации не имеющий отношения. Это уже проблемы конкретных особенностей xml, soap и реализации мсовских форматтеров.


Но приходим к тому, что все равно приходится писать ручками. И без всяких rtti, чтобы быстрее. Разве я не прав? Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла

Конечно, для некоторых вещей, как например настройки, rtti удобно. Но если я буду заниматься проектьом год, а настройки вместо 2 часов напишу за 2 дня, по моему это не настолько критично.

А>>PS Да, и на моей практике, если менялись типы данных или запросов, то все равно менялась логика, поэтому прелесть определения типов как то падает.


AVK>Опять же следствия недостаточно гибкого дизайна.


may be
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 13:15
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Это оффлайновый клиент. Как ему еще работать?


Вот янус чего то 100 тыс записей не таскает.

AVK>>Это уже совершенно отдельный разговор, к самой идее сериализации не имеющий отношения. Это уже проблемы конкретных особенностей xml, soap и реализации мсовских форматтеров.


А>Но приходим к тому, что все равно приходится писать ручками.


Необязательно.

А>И без всяких rtti, чтобы быстрее.


Если у тебя медленный канал то это абсолютно не те тормоза, которые существенно повлияют на скорость обмена. А если нет, то тогда с увеличением трафика проблем нет.

А>Разве я не прав? Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла


А сколько ты вобще видел реализаций с rtti?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[29]: Будущее C#
От: Аноним  
Дата: 04.07.03 13:33
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, <Аноним>, Вы писали:



AVK>Вот янус чего то 100 тыс записей не таскает.


Где возможно, такой объем пережается один раз, а потом делаем обновления. А где нельзя, приходится так

AVK>>>Это уже совершенно отдельный разговор, к самой идее сериализации не имеющий отношения. Это уже проблемы конкретных особенностей xml, soap и реализации мсовских форматтеров.


А>>Но приходим к тому, что все равно приходится писать ручками.


AVK>Необязательно.


А>>И без всяких rtti, чтобы быстрее.


AVK>Если у тебя медленный канал то это абсолютно не те тормоза, которые существенно повлияют на скорость обмена. А если нет, то тогда с увеличением трафика проблем нет.


Ну не только быстрее, но и меньший объем. Просто не переписпл из предыдущего сообщения

А>>Разве я не прав? Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла


AVK>А сколько ты вобще видел реализаций с rtti?


Мало, только .net и java. Поэтому и говорю лишь про свое мнение. Но разговор в ветке проде идет о C#.
Re[7]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 13:37
Оценка:
Здравствуйте, alexkro, Вы писали:

http://rsdn.ru/ftp/CLI/Generic/Samles/generics.html
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 13:37
Оценка:
Здравствуйте, alexkro, Вы писали:

A>Очень уж эффективным не получится. Остаются виртуальные вызовы, к которым приводит наличие constraints.


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

A>http://www.google.com/search?q=policy-based+programming&amp;hl=en&amp;lr=&amp;ie=UTF-8&amp;oe=UTF-8&amp;start=10&amp;sa=N.


Ну, это практически равносильно посланию на...
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 13:37
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Такая сериализация имеет недостатком скорость.


Скорость сериализации в дотнете и в првду плохая. Но дело тут не в универсальности, а в кривой реалзации.

А> Если надо сохранить словарь терминов на 100,000, что например встречается у нас постоянно, все выглядит очень удручающе. Да и объем тоже не воодушевляет.


Согласен. Я собственно первый об этом говорил. Но тем не менее создать универсальную, но быструю реализацию можно.

А>Так что для сохранения настроек такая технология подходит очень хорошо, а для сохранения реальных данных (по крайней мере в моем случае) как то не катит


Данные тоже разные бывают. Во многих случая хватает и такой производительности.

У меня были мысли написать свой универсльный сериализатор. Общая идея такая. На базе рефлекшона генерировать в рантайме оптимальный код сериализации. Если сборка-сериализатор уже есть и ее версия свежая, использовать ее.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 13:37
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>По моему в RSDN как раз была статься по ручной сереализации dataset для решения этих проблем.


Ламерство там было. Шыло на мыло заменялось. Держи действительно шуструю и компактную сераилизацию датасета.

http://www.rsdn.ru/forum/Message.aspx?mid=247335&amp;only=1
Автор: VladD2
Дата: 21.04.03


У меня есть версия которая может писть в бинарный поток прямо из ридера.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 13:37
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Как он изменится, если мы ставим целью избавиться от object и Type?


Ну, вообще-то было бы разумно сделать типизированные гет-еры/сет-еры. Типа AsInt, AsStr...
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 13:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>А у меня в основном на моей совести.

WH>Просто я научился писать так что большинство логичиских ошибок становятся ошибками компиляции те сводятся на уровень опечаток которые я за ошибки не считаю.

И любиш же ты про свои достижения расказывать.

WH>К стати за VC++7.1 я еще не замечал не верно сгенерированого кода. Так что на нем все мое. Правда и средства контороля выше.


Да, я к тому, что хороший программист не должен сваливать ошибки в програме на компилятор. А неверно сгенерированный код для любого компилятора можно надыбать если поискать как следует. Например, твой любимый VC7.1 прекрасно компилирует вот такой прикол:

void f()
try
{
    printf("try\n");
}
catch(...)
{
}


Я не дока в стандерте С++, но что-то мне подсказывает, что у функции обызаня быть скобки.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Будущее C#
От: Аноним  
Дата: 04.07.03 13:48
Оценка:
VD>У меня были мысли написать свой универсльный сериализатор. Общая идея такая. На базе рефлекшона генерировать в рантайме
оптимальный код сериализации. Если сборка-сериализатор уже есть и ее версия свежая, использовать ее.

Было бы интересно.
Re[30]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 13:52
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>Как он изменится, если мы ставим целью избавиться от object и Type?

VD>Ну, вообще-то было бы разумно сделать типизированные гет-еры/сет-еры. Типа AsInt, AsStr...

Если говорить про ado.net, то они есть в DataReader, который проектировался для максимальной производительности. С точки зрения надежности и статической типизации Row.AsInt(col1) ничем не лучше Row.GetValue(col1).ToInt() — и там и там при неправильном типе будет ошибка выполнения.
Re[27]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 13:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>void f()

VD>try
VD>{
VD>Я не дока в стандерте С++, но что-то мне подсказывает, что у функции обызаня быть скобки.

Учи матчасть — 15/3. В конструкторах, например, перед скобками происходит инициализация базовых классов, и иногда возникает желание поймать произошедшие там исключения.
Re[27]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Неа. Форматтеры и XmlSerializer вполне могут быть написаны самостоятельно без использования фич clr. Точнее с использованием одной фичи, которая называется рефлекшен.


Уточню. Не могут быть, а именно написаны.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:07
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Что именно тебя тут пугает? Угловые скобки не нравятся, предпочитаешь квадратные?


Попробуй отойти от компьютера... забыть на секунду про все сложности С++... подойди обратно... и ужаснись этим награмождением скобок и знаков приминания.

S>Неправильно понимаешь. Вся генерация кода делается в компил-тайме.


К сожалению я не знаю реализации ТайпЛистов... Ну, да ладно. Это тут непричем.

S>Угу, только у класса TestC есть десяток членов, которые сериализовать не надо.


Помечаешь их одним атрибутом и все.

S> По этому атрибут [Serializable] придется для каждого члена указывать,


Нет. Для отмены есть другой флаг. Да и не все равно это проще, а главное читабельнее.

S> во вторых — для каждого члена, вовлеченного в другие операции (у меня это — DoDataExchange), придется другие атрибуты добавлять. Получится еще страшнее, чем у меня.


Получается красиво и пушисто. Уж точно такой жути в коде не будет.

S>Собственно, код сериализации сидит в библиотеке — в обоих случаях.


Нет батенька. Ты вынужден засорять свой код совершенно неочивидными конструцкиями.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Атрибут только называется Serializable


Это не важно.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Им надо начинать править не с этого, а с добавления пользовательских value-типов в язык.


Ну, это по большому счету не обязательно. Один фиг вэлью-типы как они есть в дотнете из концепции вырываются.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Будущее C#
От: Аноним  
Дата: 04.07.03 14:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, <Аноним>, Вы писали:


А>>Это оффлайновый клиент. Как ему еще работать?


VD>Гы. Голлеги.




А>>Лично я не видел быстрых реализаций с rtti с минимальным объемом выходного файла


VD>Но это же не значит, что ее нельзя создать?


Может и можно. Но в .net у них явно не получилось.
Re[26]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 14:12
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Им надо начинать править не с этого, а с добавления пользовательских value-типов в язык.

VD>Ну, это по большому счету не обязательно. Один фиг вэлью-типы как они есть в дотнете из концепции вырываются.

В первую очередь из концепции вырывается тип int, потому что он ну совсем не похож на ссылочные
Re[29]: Будущее C#
От: Аноним  
Дата: 04.07.03 14:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Но это же не значит, что ее нельзя создать?


Как то больше похоже на академическую проблему. Сделать так было бы отлично, но на практике не получается.
Re[31]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:33
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Если говорить про ado.net, то они есть в DataReader, который проектировался для максимальной производительности.


Гы. Значит датасет проектировался для максимальных тормозов? Класная логика.

_> С точки зрения надежности и статической типизации Row.AsInt(col1) ничем не лучше Row.GetValue(col1).ToInt() — и там и там при неправильном типе будет ошибка выполнения.


Я как бы этим занимался по этому погу обяснить, что может дать такой подход...

Для начала Row.GetValue(col1).ToInt() небывает. Бывает (int)Row[col1].

Приведение типа работает очень просто. Если в обжекте не инт, то все идут лесом. AsInt может делать более разумное преобразование.

Ну, а главное соображение — это производительность. Дело в том, что сам датасет хранит данные очнь компактно и совершенно без боксинга. А при их возврате клиенту производится боксинг и анбоксинг. В общем дурь. Если же будут типизированные гет-еры и сет-еры, то лишних телодвижений не будет.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:34
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Учи матчасть — 15/3. В конструкторах, например, перед скобками происходит инициализация базовых классов, и иногда возникает желание поймать произошедшие там исключения.


Речь идет не о перед скобками. А о вообще без скобок.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 14:36
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>Учи матчасть — 15/3. В конструкторах, например, перед скобками происходит инициализация базовых классов, и иногда возникает желание поймать произошедшие там исключения.

VD>Речь идет не о перед скобками. А о вообще без скобок.

void f()
try
{
    printf("try\n");
}
catch(...)
{
}

Код соответствует стандарту.
Re[30]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:36
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Как то больше похоже на академическую проблему. Сделать так было бы отлично, но на практике не получается.


Почему не плучается? Я лично не вижу предпосылок к этому.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:36
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Может и можно. Но в .net у них явно не получилось.


Да уж. Ну, да ладно еали они не поправят, то мы им поможем.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:36
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>В первую очередь из концепции вырывается тип int, потому что он ну совсем не похож на ссылочные


Ну, без него никуда.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Будущее C#
От: _Kostya_  
Дата: 04.07.03 14:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, <Аноним>, Вы писали:


А>>Как то больше похоже на академическую проблему. Сделать так было бы отлично, но на практике не получается.


VD>Почему не плучается? Я лично не вижу предпосылок к этому.


Ну, у тебя идея была замечательная. Надеюсь получится.
Re[32]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 14:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Для начала Row.GetValue(col1).ToInt() небывает. Бывает (int)Row[col1].

VD>Приведение типа работает очень просто. Если в обжекте не инт, то все идут лесом. AsInt может делать более разумное преобразование.

Convert.ToInt32(Row[col1])

Типизированные вызовы с более разумным преобразованием тоже должны были бы либо делать такой же Convert, либо какой-нибудь оптимизированный switch по TypeCode. Все это при желании делается простой клиентской оберткой и к ADO.NET прямого отношения не имеет.

VD>Ну, а главное соображение — это производительность. Дело в том, что сам датасет хранит данные очнь компактно и совершенно без боксинга. А при их возврате клиенту производится боксинг и анбоксинг. В общем дурь. Если же будут типизированные гет-еры и сет-еры, то лишних телодвижений не будет.


Все равно компактное хранение делается в DataStorage и боксинг происходит уже внутри — при вызове объектом DataColumn метода DataStorage, а из DataColumn данные берет DataRow. Типизированные методы пришлось бы вставлять во все эти классы, что усложняет поддержку. К тому же DataTable не завязана на типы данных IDataReader, компактное хранение — просто оптимизация для часто употребляемых типов.
Re[28]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 14:47
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>В первую очередь из концепции вырывается тип int, потому что он ну совсем не похож на ссылочные

VD>Ну, без него никуда.

А вот комбинация из двух интов (Point, скажем) в джаве уже обязана лежать в куче. Чем она хуже простого инта?
Re[30]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 14:53
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>
_>void f()
_>try
_>{
_>    printf("try\n");
_>}
_>catch(...)
_>{
_>}
_>

_>Код соответствует стандарту.

И какова цель? Что же тогда какой нибудь if не присобачили? И эти люди говорят о не последовательности Шарпа.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.07.03 14:55
Оценка:
Здравствуйте, IT, Вы писали:

ГВ>>>>Это означает только то, что в .Net предусмотрен базовый механизм для сериализации. И что? А если речь пойдёт не о ней?


IT>>>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.


ГВ>>Хммм... похоже, ты меня совсем не понял.


IT>Возможно, скорее всего ты имел ввиду рефлекшин, а не сериализацию. Правильно?


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

IT>>>В .NET предусмотрен рефлекшин, сериализация лишь один из можества механизмов, который его использует.


ГВ>>Хммм... похоже, ты меня совсем не понял.


AVK>Правильно он тебя понял. Нет там никакого специального механизма для сериализации, есть только рефлекшен, который ровно так же пригоден и для той же визуализации, о которой ты поминал. Сему пример тот же PropertyGrid.


Не-а. Не понял. О деталях .Net я ничего говорить не собирался.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[31]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 14:56
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>void f()

_>>try
_>>{
VD>И какова цель? Что же тогда какой нибудь if не присобачили? И эти люди говорят о не последовательности Шарпа.

Цель — дать возможность обработать исключения при инициализации базовых классов. А раз уж появился такой синтаксис, почему он должен быть специфичным для конструкторов?
Re[29]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.07.03 14:59
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Хммм... похоже, ты меня совсем не понял.


VD>Нет. Это ты нас не понимашь. И по всей видимости не попробовав рефлекшон прочувтвовать всей его мощи нелья.


Кто о чём...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[33]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 15:02
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Типизированные вызовы с более разумным преобразованием тоже должны были бы либо делать такой же Convert, либо какой-нибудь оптимизированный switch по TypeCode.


Именно.

_>Все это при желании делается простой клиентской оберткой и к ADO.NET прямого отношения не имеет.


Делается, то делается, но эффективность не та. Да и проблемы могут возникнуть. Ведь может оказаться, что для ускорения процесса нажно обратиться к закрытым данным, ан нет тебе.

_>Все равно компактное хранение делается в DataStorage и боксинг происходит уже внутри — при вызове объектом DataColumn метода DataStorage, а из DataColumn данные берет DataRow. Типизированные методы пришлось бы вставлять во все эти классы, что усложняет поддержку.


Дык я говорю, что при грамотной реализации баксинга можно было избежать. Не согласен?

_>К тому же DataTable не завязана на типы данных IDataReader, компактное хранение — просто оптимизация для часто употребляемых типов.


А причем тут ридер? Я тебе объясняю что дает применение типизированных методов доуступа. А ты мне про Ерему. Дизайн кривоват у датасета...
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 15:02
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>А вот комбинация из двух интов (Point, скажем) в джаве уже обязана лежать в куче. Чем она хуже простого инта?


Да фигня это по большому счету. В Яве есть куда более серьезные косяки. А структуры как ни крути стройность модели портят. Вернее их реализация в шарпе портит. Я бы на месте МС добавли бы такие фичи как свойства возвращающие ссылку. И еще кой-чё подправил. Тогда бы структуры не портили бы картину. А так у них есть очень узкая область применения.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Будущее C#
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.07.03 15:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, а главное соображение — это производительность. Дело в том, что сам датасет хранит данные очнь компактно и совершенно без боксинга. А при их возврате клиенту производится боксинг и анбоксинг. В общем дурь. Если же будут типизированные гет-еры и сет-еры, то лишних телодвижений не будет.


DataColumn хранит указатель на абстрактный класс DataStorage с методом object Get(int recordNo). Если делать типизированные геттеры без боксинга, то пришлось бы приводить этот указатель к типу конкретного DataStorage, что по времени уже сравнимо с боксингом. Либо опять же дать базовому DataStorage кучу типизированных геттеров и сеттеров, чтобы потомки переопределили совместимые, а несовместимые оставили бы из базового класса кидающими исключения. Второе решение тоже сделало бы каждый наследник DataStorage сложнее в поддержке — там фактически была бы копия класса System.Convert. Кроме того, DataAdapter.Fill вызывает DataTable.LoadDataRow, передавая ему object[] с данными текущей строки — это тоже пришлось бы сильно усложнить.

Поэтому DataTable, при создании которого не ставилась цель достичь максимальной производительности, имеет простой интерфейс, но делает боксинг там, где написанный руками код не делал бы.
Re[33]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.07.03 15:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>На каком основании такие предположения? Единственное, что придётся сделать — написать mapping колонок, т.е. — что-то вроде:


ГВ>>
ГВ>>... = {
ГВ>>col_map(0, "Attr1"),
ГВ>>col_map(1, "Attr1"),
ГВ>>col_map(2, "Attr1"),
ГВ>>col_map(-1, "") // Финализатор описания
ГВ>>}
ГВ>>


AVK>И подождать полчасика пока проект пересоберется. Прелесть рефлекшена в том что в этом случае вобще ничего менять не надо.


А я сказал, что это (такой вот тупой маппинг) обязательно надо делать? Это просто прямая альтернатива ручному "программированию" елозеньем мышкой по Object Property-ям. Только и всего. А вообще он вполне сможет сгенериться и по структуре рекордсета.

ГВ>>Притом такой маппинг описывать проще, чем прыгать по десяти Property-box-ам. Так что, кто из нас будет что-то-там как папа Карло — ещё не известно.

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

VD>>>А я могу взять готовый из очень большого списка. Ну и главная проблема в том, что твой подход потребует от пользователя твоего грида (тоже программиста) на порядок больших знаний чем у меня.

ГВ>>My God! Да почему?!
AVK>Потому что прикладному программисту нужно обязательно помнить о необходимости предварительно вносить типы в меппер.

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

VD>Да, я к тому, что хороший программист не должен сваливать ошибки в програме на компилятор.

В компиляторе я и ищу в последнюю очередь но очень часто там они и находятся
Например
while(Ref<I_ClassFactory> factory=factoryEnum->Next())
{
    ....
}

Этот код приводил к утечкам памяти ибо забывал вызывать деструктор
так заработало
while(true)
{
    Ref<I_ClassFactory> factory=factoryEnum->Next();
    if(!factory)break;
    ....
}

Этот код приводил к вызову конструктора глобольного обьекта
(буква в букву не помню но чтото типа)
std::string str1="bla bla bla";
...
std::string str2="bla bla"+str1;//Глючило это//Причем в очень многих других местах прекрасно работает
std::string str2=std::string("bla bla")+str1;//А так заработало

Еще было конструктор ушол в бесконечную рекурсию, дуструктор вызывался дважды и многое другое.
А то что он очень многие вещи просто не может скомпилить это совсем другая история. Правда иногда доходит до .... например иногда при использовании continue он падает с ICE.

VD>А неверно сгенерированный код для любого компилятора можно надыбать если поискать как следует. Например, твой любимый VC7.1 прекрасно компилирует вот такой прикол:

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

S>>Что именно тебя тут пугает? Угловые скобки не нравятся, предпочитаешь квадратные?


VD>Попробуй отойти от компьютера... забыть на секунду про все сложности С++... подойди обратно... и ужаснись этим награмождением скобок и знаков приминания.


А как, кстати, на шарпе будет выглядеть та же функциональность, что и у меня — задание идентификатора контрола, к которому привязана переменная и указание функции, которую надо использовать для обмена данными?

S>> во вторых — для каждого члена, вовлеченного в другие операции (у меня это — DoDataExchange), придется другие атрибуты добавлять. Получится еще страшнее, чем у меня.


VD>Получается красиво и пушисто. Уж точно такой жути в коде не будет.


А это для кого как — для меня, например, шарповские конструкции ужасными выглядят. А когда и шаблоны непонятными казались, а еще раньше — структуры

S>>Собственно, код сериализации сидит в библиотеке — в обоих случаях.


VD>Нет батенька. Ты вынужден засорять свой код совершенно неочивидными конструцкиями.


Эти конструкции, тем не менее, кодом сериализации не являются. А очевидными они становятся после прочтения трех строчек комментариев в хедере библиотеки.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[30]: Будущее C#
От: IT Россия linq2db.com
Дата: 04.07.03 16:38
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Нет. Я имел ввиду подход, уповающий на то, что в результате анализа неизвестного типа (т.е. — использования rtti) гарантированно будет выбрана (сгенерирована, проэмиччена и т.п., соль и перец по вкусу) корректная реализация алгоритма, его обрабатывающего. Подход этот я назвал "RTTI-Based". Понятно?


Этот подход давно известный и придуман он не в .NET, за корректную реализацию отвечают интерфейсы. В большинстве случаев этого хватает. Когда не хватает, то здесь .NET привносит немножко своего — атрибуты. Но база для всего этого одна — рефлекшин.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Будущее C#
От: IT Россия linq2db.com
Дата: 04.07.03 16:48
Оценка:
Здравствуйте, AndrewVK, Вы писали:

IT>>Без привычки твой код нужно распечатать и сидеть с бумажками разбираться что он там делает. А лучше сразу сбегать в ларёк за пузырём


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


Ну вот, видишь сколько недостатков у шаблонов, даже ларька не хватает
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 18:30
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>>>И без всяких rtti, чтобы быстрее.


AVK>>Если у тебя медленный канал то это абсолютно не те тормоза, которые существенно повлияют на скорость обмена. А если нет, то тогда с увеличением трафика проблем нет.


А>Ну не только быстрее, но и меньший объем. Просто не переписпл из предыдущего сообщения


Ну уж использование rtti на объем не влияет никак. Только на скорость.

AVK>>А сколько ты вобще видел реализаций с rtti?


А>Мало, только .net и java.


Ну вот о том и речь. На основании этого выводов делать не стоит.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 18:34
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А я сказал, что это (такой вот тупой маппинг) обязательно надо делать? Это просто прямая альтернатива ручному "программированию" елозеньем мышкой по Object Property-ям. Только и всего. А вообще он вполне сможет сгенериться и по структуре рекордсета.


О, мы уже до кодогенераторов дошли. Типа рефлекшен это кривой дизайн, а вот кодогенераторы это уже прямой. Самому не смешно?

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


ГВ>И для этого нужна высокая квалификация?


Нет, но это однозначно кривой дизайн.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[30]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 18:54
Оценка:
Здравствуйте, Sergey, Вы писали:

S>А как, кстати, на шарпе будет выглядеть та же функциональность, что и у меня — задание идентификатора контрола, к которому привязана переменная и указание функции, которую надо использовать для обмена данными?


Ну как нибудь так, если я правильно понял что ты хочешь:
class SomeForm : Form
{
    private string _someVar;
    
    [Exchange(ControlProperty = "Text", Destination = "_someVar")]
    Control _someControl;
}

Функции никакой не надо.

VD>>Получается красиво и пушисто. Уж точно такой жути в коде не будет.


S>А это для кого как — для меня, например, шарповские конструкции ужасными выглядят.


Даже если прикинуть количество строк, не говоря уж о количестве всяких скобочек и знаков препинания, то станет ясно что ты все таки лукавишь.

S>А когда и шаблоны непонятными казались, а еще раньше — структуры


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

VD>>Нет батенька. Ты вынужден засорять свой код совершенно неочивидными конструцкиями.


S>Эти конструкции, тем не менее, кодом сериализации не являются. А очевидными они становятся после прочтения трех строчек комментариев в хедере библиотеки.


Все таки ты просто не видишь отличий. Воспользуйся советом Влада — расположи его и твой пример рядом, потом расслабься и не думай о программировании некоторое время, а потом взгляни на код. Я, как человек привыкший к синтаксису и шарпа, и дельфи, и плюсов могу тебе сказать — разница в читаемости огромная. Ваши нагромождения шаблонов превращают плюсы в птичий язык.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[29]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 18:58
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Атрибут только называется Serializable


VD>Это не важно.


Ну это типа двойка тебе за знание форматтеров
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[30]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.07.03 18:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Да фигня это по большому счету. В Яве есть куда более серьезные косяки. А структуры как ни крути стройность модели портят. Вернее их реализация в шарпе портит. Я бы на месте МС добавли бы такие фичи как свойства возвращающие ссылку. И еще кой-чё подправил. Тогда бы структуры не портили бы картину. А так у них есть очень узкая область применения.


А я бы предоставил программеру самому решать где размещать класс — в стеке или на куче.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[31]: Будущее C#
От: Аноним  
Дата: 04.07.03 21:22
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, <Аноним>, Вы писали:


А>>>>И без всяких rtti, чтобы быстрее.


AVK>>>Если у тебя медленный канал то это абсолютно не те тормоза, которые существенно повлияют на скорость обмена. А если нет, то тогда с увеличением трафика проблем нет.


А>>Ну не только быстрее, но и меньший объем. Просто не переписпл из предыдущего сообщения


AVK>Ну уж использование rtti на объем не влияет никак. Только на скорость.


AVK>>>А сколько ты вобще видел реализаций с rtti?


А>>Мало, только .net и java.


AVK>Ну вот о том и речь. На основании этого выводов делать не стоит.


Ok, наверно я немного не туда ушел. В принцепе я согласен с твоими доводами, но увиденные мной реализации немного не то. В том числе и так защищаемый тобой в этой ветке .net.
Re[33]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 21:43
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Второе решение тоже сделало бы каждый наследник DataStorage сложнее в поддержке — там фактически была бы копия класса System.Convert.


Нет они могли бы реализоывать только те варианты, что отвечают за их тип данных. И реализация была бы примитивна (простое копирование). Боле того передачу можно было бы даже делать по ссылке.

_>Кроме того, DataAdapter.Fill вызывает DataTable.LoadDataRow, передавая ему object[] с данными текущей строки — это тоже пришлось бы сильно усложнить.


Ничего. Датасет класс не простой. И нармальная типизация ему бы не повредила бы.

_>Поэтому DataTable, при создании которого не ставилась цель достичь максимальной производительности, имеет простой интерфейс, но делает боксинг там, где написанный руками код не делал бы.


DataTable работает очень шустро и если бы не боксинг, то разница со структурами была бы минимальа.

Кргоме боксинга у DataTable-а еще и сериализация через задницу наапсана. Вообще ADO.NET спроектировано криво.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 21:43
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Эти конструкции, тем не менее, кодом сериализации не являются. А очевидными они становятся после прочтения трех строчек комментариев в хедере библиотеки.


Они загромождают код и замедляют компиляцию.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.03 21:43
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Ok, наверно я немного не туда ушел. В принцепе я согласен с твоими доводами, но увиденные мной реализации немного не то. В том числе и так защищаемый тобой в этой ветке .net.


Кстати, одним из вариантов сериализации является сериализация в код. Решение не только шустрое, но и чертовски красивое.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.07.03 06:15
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Ok, наверно я немного не туда ушел. В принцепе я согласен с твоими доводами, но увиденные мной реализации немного не то.


Ну посмотри тогда на XmlSerializer, он, в отличие от форматтеров, реализован очень неплохо.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.07.03 06:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, тогда С++ рулит. Там программист имеет полный контрольк над этим впоросом.


Ага, и старый добрый Borland Pascal

Нет, я имел ввиду что не только может управлять этим, но и это управление не сводится к ручному управлению памятью в случае кучи.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[33]: Будущее C#
От: WolfHound  
Дата: 05.07.03 07:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, я имел ввиду что не только может управлять этим, но и это управление не сводится к ручному управлению памятью в случае кучи.


А смарт поинтеры на что?
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.07.03 07:59
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>Нет, я имел ввиду что не только может управлять этим, но и это управление не сводится к ручному управлению памятью в случае кучи.


WH>А смарт поинтеры на что?


А смартпоинтеры это уже заплатка, да и не решают они всех проблем.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[13]: Будущее C#
От: Аноним  
Дата: 05.07.03 08:00
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>
_>op oper2 = new op(ctl){MyOp(ctl)}; // будет компилиться
_>

Ой, я видимо что-то пропустил.
А что лямбда-функции уже ввели?
Re[31]: Будущее C#
От: Nose Россия  
Дата: 05.07.03 09:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

Для Вас и для VladD2. Мне не очень хочется с вами спорить. У меня не много опыта для этого.
Но. Если вам в руки попадется Александреску, прочитайте. Плохо сосотавлять мнение по чьим-то словам.
... << RSDN@Home 1.1 beta 1 >>
Re[35]: Будущее C#
От: WolfHound  
Дата: 05.07.03 16:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А смартпоинтеры это уже заплатка,

Да для тебя все заплатка
AVK>да и не решают они всех проблем.
Всех нет но 99% легко.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 06.07.03 00:12
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Да ну? А как же run-time analysis: "Если символ типа — X, то использовать алгоритм Z"? Или мы с тобой подразумеваем под rtti разные вещи.


VD>Ну, да. Ты под ним понимаешь того убогого урода что есть в С++ и для С++ который по своей природе тяготеет к монолитности. А АВК говорит о рефлекшоне который по сравнению с ртти, как Феррари и трехколесный велосипед.


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

ГВ>>Ну нет, почему же? Если сопоставление метаинформации реализуется для его дальнейшего использования, то чтение будет удобным. По-моему, это очевидно.


VD>Тогда попробуй предствить, что вся метаинформация делается именно для того, чтобы ее читали.


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

VD>>>Гарантия в коде универсального сериализатора. Код сериализации автоматически сериализует состояние объектов на основании информации о них.

ГВ>>Да фиг с ней, с сериализацией.
AVK>А, то есть таки сериализация красиво и лаконично без наличия rtti не выходит?

Погоди, до сериализации очередь дойдёт. Я просто возвращаю тему беседы в исходное русло.

AVK>Так как тогда быть с твоими заявлениям про неверный дизайн?


Оно никуда не делось, и я от него не отказываюсь.

ГВ>>Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации, а о чём-то ещё,

AVK>Не увиливай. Речь идет о сериализации.

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

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


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

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

ГВ>>Упс? А почему этот код — ненужный?


AVK>Потому что можно обойтись без этого.


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

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

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

ГВ>>Упс? А почему этот код — ненужный?


VD>Потому-что задача сериализации — это задача решаемая декларативным путем. Достаточно сказать, что все члены класса нужно сериализовать и пометить те что не нужно. Остальное можно сделать автоматом. Но для этого нужно иметь в рантайме информацию о типах.


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

ГВ>>А я сказал, что это (такой вот тупой маппинг) обязательно надо делать? Это просто прямая альтернатива ручному "программированию" елозеньем мышкой по Object Property-ям. Только и всего. А вообще он вполне сможет сгенериться и по структуре рекордсета.


AVK>О, мы уже до кодогенераторов дошли. Типа рефлекшен это кривой дизайн, а вот кодогенераторы это уже прямой. Самому не смешно?


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

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

ГВ>>И для этого нужна высокая квалификация?
AVK>Нет, но это однозначно кривой дизайн.

Да, если такая функциональность (внесения в мапперы или аналогичная) уже реализована в окружении и попросту дублируется.
Нет, если такой функциональнсти нет. Более того, это почти единственный способ избежать модификации логики, использующий сей маппер. См. по ключевым словам: "Liscov's Substitution Principle". Позицию Лисковой я лично, разделяю.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[33]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 06.07.03 01:01
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Вот вот, выбор ты как будешь осуществлять и из чего?


ГВ>>"Из чего" — из набора прекомпилированных конвертеров.

AVK>Мда, печальственно

Извини, так получилось, хотя набор можно расширять за счёт дополнительных библиотек без перекомпиляции основного модуля. Всё равно там получаются виртуальные вызовы.

AVK>>>Проблема в том что этот самый std::map при наличии rtti не нужен.

ГВ>>Да ну? А как же run-time analysis: "Если символ типа — X, то использовать алгоритм Z"? Или мы с тобой подразумеваем под rtti разные вещи.

AVK>А зачем там такой анализ? Там все проще будет — достать из атрибута тип конвертера, создать экземпляр, вызвать метод. И все. Никакого захардкоденного анализа, рассчитанного на определенный набор входных типов не надо. Прелесть сборок в том что они самоописательны. Т.е. для добавления новых типов достаточно просто положить в каталог сборки с дополнительными обработчиками. Базовую сборку менять или пересобирать не надо. Вариант с шаблонами требует как минимум перекомпиляции.


А что ты будешь делать, если для некоего нового типа данных ещё нет обработчика среди дополнительных сборок?

AVK>>>ОК, если действительно не понимаешь или делаешь вид, то пускай это будет веб-сервис. Так понятнее?

ГВ>>Давай ещё проще — пусть это будет просто SOAP-овский вызов, который возвращает некий массив.
AVK>Не суть важно. Главное что в SOAP набор типов не огранизен каким то узким диапазоном.

OK, я тебя понял. И то, к чему ты упомянул про дополнительные сборки в каталогах программы — тоже. И сразу хочу задать встречный вопрос. А кто напишет для моей программы нужные именно ей конвертеры? Предположим, что речь идёт не о банльной конвертации в строковое представление, а например, в хливких шорьков, метОда использования которых известна только мне. Я позволю себе задать этот вопрос, поскольку спор начинался с общих фраз.

AVK>>>А если сервис не ты писал? А если он изменился?

ГВ>>В каком смысле изменился?
AVK>А вот в таком смысле и изменился — в возвращаемую табличку добавились типы, неизвестные на момент компиляции.

1. Программа выдаст пустые строки или сообщение об ошибке в зависимости от контекста.
2. Я разберусь с тем, что происходит и сделаю Upgrade своей проги.
3. Чтобы избежать п.п. 1 и 2 заключу с разработчиком сервиса соглашение, по которому он будет предупреждать меня о предстоящих изменениях, чтобы наши с ним юзеры не поливали нас грязью.
4. Если п.3 по каким-то причинам невозможен, то постараюсь сократить временой разраыв между 1 и 2.

ГВ>>Я правильно предположил?

AVK>Примерно.

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

ГВ>>Это тезис понятен.
AVK>Тогда объясни свой тезис о неправильном дизайне при использовании rtti

Всё очень просто. Вот код:

void func(object x)
{
  x.method();
}


На момент компиляции неизветсно — есть у входного x метод "method" или нет. Гарантировать хотя бы его наличие — невозможно (тип — object) . Соответственно, такой код означает следующее:

1. Проверить наличие метода "method" с сигнатурой, совместимой с "void x.method(void)"
2. Если есть, то п.3, иначе - п.4
3. Выбросить исключение.
4. Вызывать метод x.method()
...


Это, в принципе, эквивалентно:

if (x.has_method("void (void)")) x.method(); else throw_exception;


Если сделать небольшую индукцию, то получится, что всё это очень похоже на то, что принято называть "запущенным случаем":

switch(x.get_type_code())
{
  case type_1: x.meth(); break;
  case type_2: x.method(); break;
  ...
  default: throw object_has_no_required_method();
}


Отличие первого примера только в том, что количество сравнений в цикле анализа типов стремится не к общему числу возможных типов объекта x, а всегда равно 1.

То, что написано выше я называю "RTTI-based подходом". Возможно, я не совсем прав в выборе термина.

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

В противовес этому сильная типизация исключает фазы анализа x на наличие у него этого метода. Он есть по определению. Остаётся только оверхед на вычисление адреса точки входа по VMT. Но! Само по себе наличие метода гарантируется компилятором. Это, кстати, справедливо и для C++ и для .Net.

И вот что интересно. Тот пример, который ты привёл, по сути, иллюстрирует не RTTI-based подход, а видоизменённый механизм виртуальных функций. Согласен, что .Net добавляет к этому ещё и JIT-компиляцию. Но суть та же самая.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 06.07.03 01:05
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Да фиг с ней, с сериализацией. Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации,

VD>Нет, ну почему же? Это хороший пример демонстрирующий приемущества наличия полноценной информации.

Бесспорно, но не отрицающий недостатков "типоаналитического" подхода в целом.

ГВ>> а о чём-то ещё, что так же, как и сериализация, строится по прнципу вызова специфического кода для каждого поля объекта.

VD>Еще раз повторяю. Отойди от привычный тебе концепций. В дотнете богатство информации о типах позволяет во многих случаях писать универсальный код. В том числе и для сериализации.

Согласен — во многих, что логически (да и жизненно ) верно видоизменить на "в некоторых". Для того, чтобы говорить о "многих", нужно определить "все возможные случаи".

ГВ>> Ну, к примеру, визуализация.

VD>Визуализация слишком абстрактный термин.

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

ГВ>>Ну нет, почему же? Если сопоставление метаинформации реализуется для его дальнейшего использования, то чтение будет удобным. По-моему, это очевидно.


AVK>Так же совершенно очевидным является то что сопоставление этой самой информации руками не есть лучшее решение, поскольку все то же самое можно сделать автоматически.


Это бабушка надвое сказала. Полностью автоматически вся метаинформация всё равно не появится. Тем паче, что C++ позволяет до определённой степени автоматизировать этот процесс.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[36]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 07:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>А смартпоинтеры это уже заплатка,

WH>Да для тебя все заплатка

Аргумент.

AVK>>да и не решают они всех проблем.

WH>Всех нет но 99% легко.

Циклические ссылки они не отслеживают, а это больше 1%.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 07:29
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Потому что можно обойтись без этого.


ГВ>В дотнете — да. В той системе, для которой были написаны виденные тобой реализации, скорее всего — нет.


Так как быть с неправильностью rtti?
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 07:38
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Извини, так получилось, хотя набор можно расширять за счёт дополнительных библиотек без перекомпиляции основного модуля. Всё равно там получаются виртуальные вызовы.


Извини, но все равно получается через задний проход.

AVK>>А зачем там такой анализ? Там все проще будет — достать из атрибута тип конвертера, создать экземпляр, вызвать метод. И все. Никакого захардкоденного анализа, рассчитанного на определенный набор входных типов не надо. Прелесть сборок в том что они самоописательны. Т.е. для добавления новых типов достаточно просто положить в каталог сборки с дополнительными обработчиками. Базовую сборку менять или пересобирать не надо. Вариант с шаблонами требует как минимум перекомпиляции.


ГВ>А что ты будешь делать, если для некоего нового типа данных ещё нет обработчика среди дополнительных сборок?


Напишу и скомпиляю в отдельную сборку.

ГВ>OK, я тебя понял. И то, к чему ты упомянул про дополнительные сборки в каталогах программы — тоже. И сразу хочу задать встречный вопрос. А кто напишет для моей программы нужные именно ей конвертеры? Предположим, что речь идёт не о банльной конвертации в строковое представление, а например, в хливких шорьков, метОда использования которых известна только мне. Я позволю себе задать этот вопрос, поскольку спор начинался с общих фраз.


Это уже совсем другой вопрос. Главное что при добавлении новых типов старый код менять не нужно. Это уменьшает количество работы и гарантирует от глюков, связанных с тем что ты поменял тип, но забыл поменять его мап.

AVK>>А вот в таком смысле и изменился — в возвращаемую табличку добавились типы, неизвестные на момент компиляции.


ГВ>1. Программа выдаст пустые строки или сообщение об ошибке в зависимости от контекста.

ГВ>2. Я разберусь с тем, что происходит и сделаю Upgrade своей проги.

Причем править придется старый код. А это действительно кривой дизайн.

AVK>>Тогда объясни свой тезис о неправильном дизайне при использовании rtti


ГВ>Всё очень просто. Вот код:


ГВ>То, что написано выше я называю "RTTI-based подходом". Возможно, я не совсем прав в выборе термина.


Ну уж нет, ты не про rtti-based подход говорил, ты говорил просто про использование rtti.

ГВ>Следствия такого подхода (который я называю в том числе и кривым) нужно описывать? Думаю — нет.


Это все понятно. Только вот некривой подход с использованием шаблонов идет лесом, как только оказывается что часть кода недоступна на момент компиляции. Ты привых не использовать компоненты, поэтому тебе кажется что твой подход всегда лучше, а на деле это совсем не так.

ГВ>В противовес этому сильная типизация исключает фазы анализа x на наличие у него этого метода. Он есть по определению. Остаётся только оверхед на вычисление адреса точки входа по VMT. Но! Само по себе наличие метода гарантируется компилятором. Это, кстати, справедливо и для C++ и для .Net.


Вот только компилятор не может гарантировать того чего может не знать.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[36]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 07:42
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>О, мы уже до кодогенераторов дошли. Типа рефлекшен это кривой дизайн, а вот кодогенераторы это уже прямой. Самому не смешно?


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


Нифига подобного. Не говоря уж о жутком времени компиляции плюсов — сделать этьо в рантайме вобще практически невозможно. А вот в случае рефлекшена я могу собрать кодогенератор прямо в рантайме, причем сразу в кодах, минуя стадию компиляции. Опять оказывается что столь нелюбимый тобой рефлекшен позволяет создавать более красивые решения.

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

ГВ>>>И для этого нужна высокая квалификация?
AVK>>Нет, но это однозначно кривой дизайн.

ГВ>Да, если такая функциональность (внесения в мапперы или аналогичная) уже реализована в окружении и попросту дублируется.Нет, если такой функциональнсти нет.


Все равно кривой дизайн. И дело не в окружении, дело в подходе. В нете я могу спокойно планировать очень широкое использование рефлекшена, потому что использовать его ничего в плане дизайна не стоит. На плюсах же аналогичные алгоритмы с некоторого момента весь привнесенный плюс погребут под огромным количеством служебного кода и снижением удобства модификации программы. А это означает ровно одно — кривой дизайн. И если С++ не позволяет реализовать задачу как то иначе то это проблемы именно С++.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 07:50
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Да фиг с ней, с сериализацией. Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации,

VD>>Нет, ну почему же? Это хороший пример демонстрирующий приемущества наличия полноценной информации.

ГВ>Бесспорно, но не отрицающий недостатков "типоаналитического" подхода в целом.


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

VD>>Еще раз повторяю. Отойди от привычный тебе концепций. В дотнете богатство информации о типах позволяет во многих случаях писать универсальный код. В том числе и для сериализации.


ГВ>Согласен — во многих, что логически (да и жизненно ) верно видоизменить на "в некоторых".


Тут позволь с тобой не согласиться. Все таки имея приличный опыт использования шарпа могу тебя заверить что пользу от применения рефлекшена можно получить очень частро. То что ты не видишь других способов использования рефлекшена, кроме как замены шаблонов еще не означает что их нет. Все алгоритмы, рассчитанные на работу с неизвестными на момент компиляции типами при наличии рефлекшена решаются значительно проще.

ГВ>Для того, чтобы говорить о "многих", нужно определить "все возможные случаи".


Случаи, встречающиеся мне на практике — так устроит?
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[26]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 07:50
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Так как тогда быть с твоими заявлениям про неверный дизайн?


ГВ>Оно никуда не делось, и я от него не отказываюсь.


Забавно. Правильно сказали — если рефлекшен позволяет создаватьболее красивые и лаконичные решения, так может стоит пересмотреть свои оценки дизайна?

AVK>>Не увиливай. Речь идет о сериализации.


ГВ>Не передёргивай. Речь идёт о подходе, основанном на "самоанализе" программы. Всему своё время, сериализацию ещё вспомним.


Переключение спора на другую тему является демагогией.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 07:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Так же совершенно очевидным является то что сопоставление этой самой информации руками не есть лучшее решение, поскольку все то же самое можно сделать автоматически.


ГВ>Это бабушка надвое сказала. Полностью автоматически вся метаинформация всё равно не появится.


Что значит полностью автоматически?

ГВ>Тем паче, что C++ позволяет до определённой степени автоматизировать этот процесс.


Степень только этоа не очень.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[35]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 06.07.03 13:00
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Извини, так получилось, хотя набор можно расширять за счёт дополнительных библиотек без перекомпиляции основного модуля. Всё равно там получаются виртуальные вызовы.

AVK>Извини, но все равно получается через задний проход.

"А баба Яга — против!" (c) Мультик. Извини, просто ты так эмоционально реагируешь.

AVK>>>А зачем там такой анализ? Там все проще будет — достать из атрибута тип конвертера(Комментарии ниже — ГВ.), создать экземпляр, вызвать метод. И все. Никакого захардкоденного анализа, рассчитанного на определенный набор входных типов не надо. Прелесть сборок в том что они самоописательны. Т.е. для добавления новых типов достаточно просто положить в каталог сборки с дополнительными обработчиками. Базовую сборку менять или пересобирать не надо. Вариант с шаблонами требует как минимум перекомпиляции.

ГВ>>А что ты будешь делать, если для некоего нового типа данных ещё нет обработчика среди дополнительных сборок?
AVK>Напишу и скомпиляю в отдельную сборку.

И что? Где же помощь reflection? Только в том, что ты выполнишь вместо подстановки средствами механизма виртуальных функций подстановку средствами атрибутов? Т.е., грубо говоря, слоты размещаются не в VMT, а в атрибутах.

В цитате я специально выделил то место, где ты упускаешь из внимания фазу анализа. Framework сначала ищет заданный атрибут, а потом извлекает из него тип конвертера и создаёт экземпляр. То же самое делает программа на C++, поскольку тоже сначала анализирует сигнатуру типа, соспоставленую входным данным, например, в ADO-рекордсете. И в моём и в твоём случае цикл поиска:
по сигнатуре типа найти указатель на нужный конвертер (C++) или сгенерировать по определённому программистом закону имя типа конвертера и подгрузить его (.Net). Второй вариант, действительно, попроще в реализации, чем первый, если для первого нет небольшого наработанного Framework.

Более того, ты утверждаешь, что положишь тип конвертера в атрибут некоего типа, соответствующего типу, размещённому в SOAP-ответе. Значит, предлагаешь две фазы поиска — найти соответствующий соаповскому тип и поискать среди его атрибутов нужный, либо при получении SOAP-типа сгенерить простейший конвертер, который соединит эти фазы условно в одну. Можно даже сам шлюзовый тип сгенерить на лету. Напоминаю, что мы предполагаем, что SOAP-ответ приходит от программы стороннего разработчика, который знать не знает о наших конвертациях.

Обязанность по поддержанию адекватного набора конвертеров по прежнему лежит на программисте. С той лишь разницей, что для .Net он будет делать сборки, а на C++ скорее всего, — .dll или Shared Objects.

ГВ>>OK, я тебя понял. И то, к чему ты упомянул про дополнительные сборки в каталогах программы — тоже. И сразу хочу задать встречный вопрос. А кто напишет для моей программы нужные именно ей конвертеры? Предположим, что речь идёт не о банльной конвертации в строковое представление, а например, в хливких шорьков, метОда использования которых известна только мне. Я позволю себе задать этот вопрос, поскольку спор начинался с общих фраз.


AVK>Это уже совсем другой вопрос.


Да нет, в том-то и дело, что это две стороны одно и того же вопроса.

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


При такой ситуации (необрабатываемые данные во внешнем источнике данных) — всегда возможны глюки, а вернее — runtime-ошибки.

И где я говорил, что новые конвертеры, обрабатывающие сигнатуры новых типов данных источника не могут подгружаться? В default-ветке switch-а вполне может стоять что-то вроде:

default: locate_custom_datatype_converter(...);


где и будет выполняться поиск по map, если заранее предусмотренного конвертера нет. А map будет заполняться библиотеками драйверов.

Кстати, мне немного неясно, что ты имеешь ввиду под словами "поменял тип, но забыл поменять его мап".

AVK>>>А вот в таком смысле и изменился — в возвращаемую табличку добавились типы, неизвестные на момент компиляции.

ГВ>>1. Программа выдаст пустые строки или сообщение об ошибке в зависимости от контекста.
ГВ>>2. Я разберусь с тем, что происходит и сделаю Upgrade своей проги.
AVK>Причем править придется старый код. А это действительно кривой дизайн.

Не факт. Ситуация может потребовать изменения как всей проги, так и только написания для неё дополнительного адаптера/конвертера и т.п. Для твоего случая справедливо то же самое, так что не надо преждевременно обобщать.

AVK>>>Тогда объясни свой тезис о неправильном дизайне при использовании rtti

ГВ>>Всё очень просто. Вот код:
[...]
ГВ>>То, что написано выше я называю "RTTI-based подходом". Возможно, я не совсем прав в выборе термина.
AVK>Ну уж нет, ты не про rtti-based подход говорил, ты говорил просто про использование rtti.

А, ну вот уже лучше, о терминах договариваемся. Progress, однако. А то твоя иллюстрация никак не противоречила моим тезисам. Думаю, что это естественно, поскольку "опыт — не пропьёшь". Понимаешь, ты просто привёл пример того же самого правильного LSP-дизайна, только опирающегося на подстановку, выполняемую с помощью атрибутов, а не виртуальными функциями и абстрактными интерфейсами. Так что, противоречия, на самом деле — нет. Принципы дизайна остались теми же самыми. Ну да, часть задач дотнет берёт на себя, но я это и не собирался опровергать, знаешь, было бы глупо.

ГВ>>Следствия такого подхода (который я называю в том числе и кривым) нужно описывать? Думаю — нет.

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

Причём тут моё наличие или отсутствие привычки использовать компоненты? Я привык жёстко организовывать программу, чтобы обеспечивать её надёжность (и скорость). Это отнюдь не означает, что в ней мест, где используются компоненты (библиотеки, модули — хоть груздём назови).

ГВ>>В противовес этому сильная типизация исключает фазы анализа x на наличие у него этого метода. Он есть по определению. Остаётся только оверхед на вычисление адреса точки входа по VMT. Но! Само по себе наличие метода гарантируется компилятором. Это, кстати, справедливо и для C++ и для .Net.

AVK>Вот только компилятор не может гарантировать того чего может не знать.

Естественно. И, ИМХО, "правильный" дизайн должен вести к снижению количества подобных ситуаций. Просто это повышает надёжность, быстродействие и упрощает дальнейшие модификации. И потом, как это компилятор может не знать? Если он чего-то не знает, значит это — не его компетенция. Пример, которй ты привёл как раз это и подтверждает. SOAP-ответы и есть источники входных данных, которым требуется дополнительный анализ, вроде парсинга и принятия решения об обработке. Клиентская программа может не иметь соответствующих обработчиков, да, но это — случай обработки внешних данных и у программы на C++ будут ровно те же проблемы, что и дотнетовской. Проблема-то не в обработке внешних данных, где от анализа нельзя избавиться по определению, а в применении RTTI-based дизайна внутри программы. Значение термина "RTTI-based" я объяснял предыдущим постом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 06.07.03 13:01
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Так как тогда быть с твоими заявлениям про неверный дизайн?

ГВ>>Оно никуда не делось, и я от него не отказываюсь.

AVK>Забавно. Правильно сказали — если рефлекшен позволяет создаватьболее красивые и лаконичные решения, так может стоит пересмотреть свои оценки дизайна?


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

AVK>>>Не увиливай. Речь идет о сериализации.

ГВ>>Не передёргивай. Речь идёт о подходе, основанном на "самоанализе" программы. Всему своё время, сериализацию ещё вспомним.
AVK>Переключение спора на другую тему является демагогией.

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

ГВ>>>>Да фиг с ней, с сериализацией. Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации,

VD>>>Нет, ну почему же? Это хороший пример демонстрирующий приемущества наличия полноценной информации.
ГВ>>Бесспорно, но не отрицающий недостатков "типоаналитического" подхода в целом.
AVK>Недостатки в целом? Извини, но это демагогия. Уже одно то что рефлекшен позволяет в разы упростить сериализацию дает ему право на существование. Естественно что у него, как и у любой технологии, есть свои недостатки, ровно как есть они у шаблонов или МН, но это отнюдь не означает что его применение свидетельствует о кривом дизайне.

Ещё раз. Я говорил о дизайне и описал, какой именно дизайн я имею ввиду.

VD>>>Еще раз повторяю. Отойди от привычный тебе концепций. В дотнете богатство информации о типах позволяет во многих случаях писать универсальный код. В том числе и для сериализации.

ГВ>>Согласен — во многих, что логически (да и жизненно ) верно видоизменить на "в некоторых".
AVK>Тут позволь с тобой не согласиться. Все таки имея приличный опыт использования шарпа могу тебя заверить что пользу от применения рефлекшена можно получить очень частро. То что ты не видишь других способов использования рефлекшена, кроме как замены шаблонов еще не означает что их нет. Все алгоритмы, рассчитанные на работу с неизвестными на момент компиляции типами при наличии рефлекшена решаются значительно проще.

Да не неизвестные это типы! Это типы, для которых известна, как минимум, структура.

ГВ>>Для того, чтобы говорить о "многих", нужно определить "все возможные случаи".

AVK>Случаи, встречающиеся мне на практике — так устроит?

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

AVK>>>Так же совершенно очевидным является то что сопоставление этой самой информации руками не есть лучшее решение, поскольку все то же самое можно сделать автоматически.

ГВ>>Это бабушка надвое сказала. Полностью автоматически вся метаинформация всё равно не появится.
AVK>Что значит полностью автоматически?

Custom-атрибуты автоматически добавляются? А указания об их добавлении откуда появляются?

ГВ>>Тем паче, что C++ позволяет до определённой степени автоматизировать этот процесс.

AVK>Степень только этоа не очень.

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

AVK>>>Потому что можно обойтись без этого.

ГВ>>В дотнете — да. В той системе, для которой были написаны виденные тобой реализации, скорее всего — нет.
AVK>Так как быть с неправильностью rtti?

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

AVK>>>О, мы уже до кодогенераторов дошли. Типа рефлекшен это кривой дизайн, а вот кодогенераторы это уже прямой. Самому не смешно?

ГВ>>Смешно. Поскольку под термином "прямой" я имел ввиду вовсе не оценку из системы "прямой-кривой", а аналогичность в смысле функциональности. В том смысле, что действия "мышкой тыкать и имена колонок в окошках вводить" и "в тексте набить маппинг" одинаковы по своему результату — настройке колонок грида на структуру запроса. Последнее даже проще.
AVK>Нифига подобного. Не говоря уж о жутком времени компиляции плюсов — сделать этьо в рантайме вобще практически невозможно. А вот в случае рефлекшена я могу собрать кодогенератор прямо в рантайме, причем сразу в кодах, минуя стадию компиляции.

Да, не спорю, эмиттинг это позволяет, но проблема в другом — в правилах и алгоритмах сборки кодогенератора. Они-то откуда появятся?

AVK>Опять оказывается что столь нелюбимый тобой рефлекшен позволяет создавать более красивые решения.


В ряде случаев — да. Но в ряде случаев Lisp, например, гораздо красивее C++, и что из этого следует?

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

ГВ>>>>И для этого нужна высокая квалификация?
AVK>>>Нет, но это однозначно кривой дизайн.
ГВ>>Да, если такая функциональность (внесения в мапперы или аналогичная) уже реализована в окружении и попросту дублируется.Нет, если такой функциональнсти нет.
AVK>Все равно кривой дизайн. И дело не в окружении, дело в подходе. В нете я могу спокойно планировать очень широкое использование рефлекшена, потому что использовать его ничего в плане дизайна не стоит.

Дизайн всегда стоит одинаково.

AVK>На плюсах же аналогичные алгоритмы с некоторого момента весь привнесенный плюс погребут под огромным количеством служебного кода и снижением удобства модификации программы.


Очень и очень спорное обобщение, что на C++ — обязательно погребут.

AVK>А это означает ровно одно — кривой дизайн.


Это-то бесспорно — если программа погребена под огромным количеством служебного кода, но эту проблему как раз и должен решать дизайн.

AVK> И если С++ не позволяет реализовать задачу как то иначе то это проблемы именно С++.


Или дизайнера, что, ИМХО — чаще.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 15:09
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ещё раз. Я говорил о дизайне и описал, какой именно дизайн я имею ввиду.


Ты говорил что применение "самоанализа" это кривой дизайн. Перечитай еще раз свой пост.

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


ГВ>Да не неизвестные это типы! Это типы, для которых известна, как минимум, структура.


Ничего подобного. Структура ровно так же может описываться в метаданных. Взгляни на досуге замечательный дотнетовский компонент — PropertyGrid, который может редактировать ЛЮБОЙ класс дотнета. При этом исходников самого PropertyGrid не нужно и изменение его версии не повлечет за собой необходимость изменения редактируемых им компонент. На момент компиляции PropertyGrid компилятор не имеет ни малейшего представление ни о интерфейсе, ни даже о структуре типов, которые он затем будет использовать.

AVK>>Случаи, встречающиеся мне на практике — так устроит?


ГВ>Они и есть — "некоторые".


Но твое то утверждение было безусловным, не ограничивающим область применения.
... << RSDN@Home 1.1 beta 1 (np: Unknown — Track 11) >>
AVK Blog
Re[28]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 15:09
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Забавно. Правильно сказали — если рефлекшен позволяет создаватьболее красивые и лаконичные решения, так может стоит пересмотреть свои оценки дизайна?


ГВ>Причём здесь оценки дизайна?


При том что твое заявление что дизайн с использованием "самоанализа" безусловно кривой неверно.

ГВ>Если рефлекшн можно использовать в рамках вполне приличного дизайна (твой пример о конвертерах неизвестных типов), то никаких противоречий нет.


То есть ты признаешь что твое первое заявление было неверным?
... << RSDN@Home 1.1 beta 1 (np: Unknown — Track 11) >>
AVK Blog
Re[36]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 15:09
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Это бабушка надвое сказала. Полностью автоматически вся метаинформация всё равно не появится.

AVK>>Что значит полностью автоматически?

ГВ>Custom-атрибуты автоматически добавляются?


А кастом атрибуты нужны только если не устраивает некий штатный вариант поведения. В большинстве случаев можно обойтись и без них, штатная информация весьма богата. И потом — принципиальное отличие атрибутов от шаблонов в том что атрибуты это сугубо декларативная сущность, они не содержат алгоритмической части, а значит вероятность ошибки крайне низка.
... << RSDN@Home 1.1 beta 1 (np: Unknown — Track 11) >>
AVK Blog
Re[38]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.07.03 15:09
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да, не спорю, эмиттинг это позволяет, но проблема в другом — в правилах и алгоритмах сборки кодогенератора. Они-то откуда появятся?


На основании информации из рефлекшена.

AVK>>Все равно кривой дизайн. И дело не в окружении, дело в подходе. В нете я могу спокойно планировать очень широкое использование рефлекшена, потому что использовать его ничего в плане дизайна не стоит.


ГВ>Дизайн всегда стоит одинаково.


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

AVK>>На плюсах же аналогичные алгоритмы с некоторого момента весь привнесенный плюс погребут под огромным количеством служебного кода и снижением удобства модификации программы.


ГВ>Очень и очень спорное обобщение, что на C++ — обязательно погребут.


Это вывод на основании практики использования.

AVK>> И если С++ не позволяет реализовать задачу как то иначе то это проблемы именно С++.


ГВ>Или дизайнера, что, ИМХО — чаще.


Бестолковый аргумент — на неумелость дизайнера можно свалить что угодно.
... << RSDN@Home 1.1 beta 1 (np: Unknown — Track 11) >>
AVK Blog
Re[28]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.03 17:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я говорил о подходе. То, что в частном случае вытряхивание информации о структуре типа полезно — никак не отрицает недостатков RTTI-bases.


Да нет никаких недостатков "RTTI-bases". Есть разумное и не разумное использование некоторых подходов в конкретных условиях. Информация о типах полезна везде, где есть необходимось добиться универсальности в рантайме. Везде где можно обойтись компайл-таймом она не нужна.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.03 17:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

Позволю себе не ввязываться в демагогию по поводу размеров понятий "некоторых" и "многих"...

ГВ>Да не неизвестные это типы! Это типы, для которых известна, как минимум, структура.


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

ГВ>Custom-атрибуты автоматически добавляются? А указания об их добавлении откуда появляются?


Слышал когда нибудь термин "декларативное программирование"? Значеш в чем его проиемущетсво над обычным?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.03 17:57
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ага, и старый добрый Borland Pascal


Не. Реализация указателей в Паскале не совместима с жинью.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.03 17:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>да и не решают они всех проблем.

WH>Всех нет но 99% легко.

С циклическими ссылками проблемки возникают.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.03 17:57
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну посмотри тогда на XmlSerializer, он, в отличие от форматтеров, реализован очень неплохо.


Я бы оценил на 3 с плюсом.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.03 18:08
Оценка:
Здравствуйте, Nose, Вы писали:

N>Здравствуйте, AndrewVK, Вы писали:


N>Для Вас и для VladD2.


Слушай, объясни мне одну вещь. Вот в области С++ на этом сайте есть два авторитета: Андрей Тарасевич и Павел Кузнецов. Я с ними не однократно спорил не тему крутости/убогости С++. Почему ни одни из них не тыкла меня носом в незнание С++, а ты с WolfHound этим занимаешся? Вам обоим не кажется, что прочтение одной книжки еще не дает права считать себя экспертом в некоторой оболасти?

Еще раз повторсь, что С++ я знаю. И уж точно я знаю его настолько, чтобы иметь право выносить свои суждения об этом зяыке.

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

N> Мне не очень хочется с вами спорить. У меня не много опыта для этого.

N>Но. Если вам в руки попадется Александреску, прочитайте. Плохо сосотавлять мнение по чьим-то словам.

Попадется — погляжу. Но искать специально точно не буду. Не верится мне, что можно открыть америку в ванной.


отредактированно модератором. _MM_
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 06.07.03 19:44
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Ещё раз. Я говорил о дизайне и описал, какой именно дизайн я имею ввиду.

AVK>Ты говорил что применение "самоанализа" это кривой дизайн. Перечитай еще раз свой пост.

Совершенно верно, я даже описал — какой именно дизайн.

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

ГВ>>Да не неизвестные это типы! Это типы, для которых известна, как минимум, структура.
AVK>Ничего подобного. Структура ровно так же может описываться в метаданных.

Ага, что и говорит об известности, но достигаемой путём обработки описания этой структуры. Дотнет ведь генерит описание структуры класса и т.п. При этом обязательно делаются предположения о способах использования тех или иных типов данных, либо типы данных содержат дополнительную информацию, касающуюся их использования в определённых ситуациях.

AVK>Взгляни на досуге замечательный дотнетовский компонент — PropertyGrid, который может редактировать ЛЮБОЙ класс дотнета. При этом исходников самого PropertyGrid не нужно и изменение его версии не повлечет за собой необходимость изменения редактируемых им компонент. На момент компиляции PropertyGrid компилятор не имеет ни малейшего представление ни о интерфейсе, ни даже о структуре типов, которые он затем будет использовать.


Зато он настроен на определённый входной язык — сиречь язык описания структуры дотнетовских классов и делает предположения об адекватных способах редактирования. Никакого противоречия тут нет. Более того, должны существовать ситуации, в которых он окажется неадекватным и потребуется его замена. Впрочем, это неважно.

AVK>>>Случаи, встречающиеся мне на практике — так устроит?

ГВ>>Они и есть — "некоторые".
AVK>Но твое то утверждение было безусловным, не ограничивающим область применения.

Я несколько некорректно его сформулировал, забыл, что термин "RTTI" успел приобрести другое значение. В частности — для тебя.

Напоминаю, с чего всё завертелось
Автор: Геннадий Васильев
Дата: 03.07.03
:

VD>Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.

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


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

ГВ>>Что-то ты странное говоришь. Что ты подразумеваешь под словом "дыра"?


VD>Думаю, ты и сам понимаешь. Дыры — это отсуствие в языке/рантайме простых конструкций решающих стоящие перед тобой задачи. Например, когда стоит задача вызывать метод у абстрактного объекта... или когда стоит задача сделать что-то на сосновании описания типа.


А зачем вызывать метод у абстрактного объекта? Метод всегда вызывают для чего-то определённого. А значит, это не абстрактный объект, а вполне конкретный.

VD>Все примеры приведенные в том посте делаются на Шарпе элегантно и просто. При этом Шарп ведь не обладает такими мощными средствами самомодификации. Мысль ясна?


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

ГВ>>>>Это бабушка надвое сказала. Полностью автоматически вся метаинформация всё равно не появится.

AVK>>>Что значит полностью автоматически?
ГВ>>Custom-атрибуты автоматически добавляются?
AVK>А кастом атрибуты нужны только если не устраивает некий штатный вариант поведения.

Так о том-то и речь, что пока библиотеки хватает, — всё вокруг ништяк. А шаг влево, шаг вправо...

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


Согласен, что низка вероятность ошибки в реализации самого по себе атрибута. Но атрибуты-то несут информацию о дополнительной семантике. Вот тут ты с лёгкостью представил такой случай:

А зачем там такой анализ? Там все проще будет — достать из атрибута тип конвертера, создать экземпляр, вызвать метод.


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

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


AVK>>>Забавно. Правильно сказали — если рефлекшен позволяет создаватьболее красивые и лаконичные решения, так может стоит пересмотреть свои оценки дизайна?

ГВ>>Причём здесь оценки дизайна?
AVK>При том что твое заявление что дизайн с использованием "самоанализа" безусловно кривой неверно.

Так, ну поехали ещё раз. Анализ всегда преполагает разбор чего-либо на составляющие, выделение известных анализатору символов. Соответственно, он a'priori преполагает, что этих симовлов может не быть.

С точки зрения оценки системы — наличие в ней самоаналитических сегментов обязательно сказывается на быстродействии и надёжности. Почему первое — понятно, а второе — потому что работа по гарантированию целостности системы перекладывается на цикл тестирования, который и должен гарантировать, что система — цельная. Тестированием управляют прежде всего люди, а сложность системы растёт и потому это — ненадёжно.

ГВ>>Если рефлекшн можно использовать в рамках вполне приличного дизайна (твой пример о конвертерах неизвестных типов), то никаких противоречий нет.

AVK>То есть ты признаешь что твое первое заявление было неверным?

Нет, поскольку:

а) Рефлекшн и RTTI — разные, хотя и похожие вещи. Reflection (буквальный перевод — "отражение") — он сам по себе, хотя и реализует функциональность RTTI. Соответсвенно, неправомерно было контраргументировать (и я это не сразу понял) мой тезис с помощью примера, построенного на reflection-е, тем более, что там и преимуществ-то его особо показано не было.

б) Ты приводил мне пример, в котором RTTI-based подход к проектированию выражен слабо и в сущности — оправдан, поскольку речь шла о разновидности лексического анализа входных данных, т.е. структуры символов, внешних по отношению к программе. В пределе эта задача превращается в обычный компилятор.

в) Подход к проектированию, основанный на том RTTI-анализе, который я имел ввиду (а я уже объяснял — что именно это такое) неизбежно влечёт ряд недостатков, снижение быстродействия — в первую очередь (что и составляло основную мысль моей фразы).

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

ГВ>>Да, не спорю, эмиттинг это позволяет, но проблема в другом — в правилах и алгоритмах сборки кодогенератора. Они-то откуда появятся?

AVK>На основании информации из рефлекшена.

На каком основании — это неважно в данном случае. Откуда появятся сами правила? Какая программа будет делать вывод о применимости того или иного правила?

AVK>>>Все равно кривой дизайн. И дело не в окружении, дело в подходе. В нете я могу спокойно планировать очень широкое использование рефлекшена, потому что использовать его ничего в плане дизайна не стоит.

ГВ>>Дизайн всегда стоит одинаково.
AVK>Вот как раз ничего подобного. К сожалению красивая сказка о том что дизайн не зависит от инструмента для его реализации всего лишь сказка, инструмент накладывает серьезные ограничивающие или наоборот стимулирующие факторы на возможность применения тех или иных дизайнерских решений. И не учитывать это в дизайне по меньшей мере глупо.

Да, с последней частью твоего выказывания я в принципе согласен, но например, LSP сформулированы не для конкретного C++ или CLU и их использвание не зависит от используемого средства. Да и твой пример блестяще это подтверждает. Это достаточно общий принцип, также, кстати, неоднократно подтверждённый практикой.

AVK>>>На плюсах же аналогичные алгоритмы с некоторого момента весь привнесенный плюс погребут под огромным количеством служебного кода и снижением удобства модификации программы.

ГВ>>Очень и очень спорное обобщение, что на C++ — обязательно погребут.
AVK>Это вывод на основании практики использования.

Тебе не повезло.

AVK>>> И если С++ не позволяет реализовать задачу как то иначе то это проблемы именно С++.

ГВ>>Или дизайнера, что, ИМХО — чаще.
AVK>Бестолковый аргумент — на неумелость дизайнера можно свалить что угодно.

На язык — тоже.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[33]: Будущее C#
От: Nose Россия  
Дата: 06.07.03 20:19
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Слушай, объясни мне одну вещь. Вот в области С++ на этом сайте есть два авторитета: Андрей Тарасевич и Павел Кузнецов. Я с ними не однократно спорил не тему крутости/убогости С++. Почему ни одни из них не тыкла меня носом в незнание С++, а у ты с WolfHound этим занимаешся?


Кстати, неплохо было бы узнать, что Андрей Тарасевич и Павел Кузнецов думают об Александреску
... << RSDN@Home 1.1 beta 1 >>

отредактированно модератором. _MM_
Re[23]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 06.07.03 20:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Лучший пример тут дотнет. В нем даже придумали специальное расширение метаданныж — атрибуты. Представсь себе помещаешь ты метод атрибутом:

VD>
VD>[MenuText("Открыть файл"), Shotrcut(Keys.Ctrl & Keys.O), Img("FileOpen")]
VD>void OpetFile(){ ... }
VD>


VD>И у тебя как по мановению волшебной плочкой в программе появляется менюшка, шоткат и иконка в тубларе.


Я не нахожу это решение очень уж красивым, хотя нечто такое же я неоднократно делал на C++, только выглядело по-другому, примерно так:


MenuItem file_open("Открыть файл", "FileOpen.ico", &global_file_operations::file_open);


VD>И никакого кодирования и отладки. Даже дизайнер не нужен.


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

AVK>Ну посмотри тогда на XmlSerializer, он, в отличие от форматтеров, реализован очень неплохо.


Мне не нравится следующее:

1. Пусть у нас есть xml файл с данными. И некоторые поля не факт, что будут присутствовать. Можно узнать, что их нет и заполнить их по нужными данными, а не вылететь с общим исключением?
2. Есть массив. XML cериалайзер, как я понимаю, сохраняет его очень оригинально — стоит дерево тегов, в каждом из которых значение элемента.
Re[26]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.03 00:04
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ> А зачем вызывать метод у абстрактного объекта? Метод всегда вызывают для чего-то определённого. А значит, это не абстрактный объект, а вполне конкретный.


Ресское слово абстрактный не обязательно означет " = 0;".

ГВ>Ясна, конечно, но ведь речь-то шла о подходе. А сериализация это так... мелкая частная задача, на которую я обычно даже особого внимания-то не обращаю. Впрочем, это уже оффтопик.


Сериализация — это всеголишь пример. И таких примеров много. В общем, не стоит обвинять подход только на основании того, что в твоем любимом языке его применение больше похоже на половое изврещение.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.03 00:04
Оценка:
Здравствуйте, Nose, Вы писали:

N> Я просто книжку _посоветовал_ прочитать. Или тебя так раздражают советы тех, у кого меньше опыта, чем у тебя?


Лпдно. Извени. Просто тут до тебя уже советовали эту книгу в особо извращенной форме. Да и любой совет можно нормально воспринимать только 2-3 раза.

N> (Кстати, неплохо было бы узнать, что Андрей Тарасевич и Павел Кузнецов думают об Александреску)


Это не трудно. За одно узнай читали ли они его вообще.

отредактированно модератором. _MM_
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.07.03 00:20
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Я говорил о подходе. То, что в частном случае вытряхивание информации о структуре типа полезно — никак не отрицает недостатков RTTI-bases.


VD>Да нет никаких недостатков "RTTI-bases". Есть разумное и не разумное использование некоторых подходов в конкретных условиях. Информация о типах полезна везде, где есть необходимось добиться универсальности в рантайме. Везде где можно обойтись компайл-таймом она не нужна.


Влад, о чём спорим-то? Ясное дело — есть разумное и неразумное использование. Но характерные черты-то остаются в любом случае. У VMT тоже есть недостатки. И у шаблонов есть недостатки. И у RTTI-bases они есть. Как ты его не называй, но RTTI-bases обладает своими специфическими характерными чертами — относительной универсальностью с одной стороны и... ну я уже перечислял — с другой.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.07.03 00:27
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>> А зачем вызывать метод у абстрактного объекта? Метод всегда вызывают для чего-то определённого. А значит, это не абстрактный объект, а вполне конкретный.

VD>Ресское слово абстрактный не обязательно означет " = 0;".

Именно, а компьютерный "абстрактный объект" всегда представляется чем-то конкретным. И уж точно не " = 0", если речь идёт о работающем объекте.

ГВ>>Ясна, конечно, но ведь речь-то шла о подходе. А сериализация это так... мелкая частная задача, на которую я обычно даже особого внимания-то не обращаю. Впрочем, это уже оффтопик.

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

С чего ты взял, что я критикую подход всего лишь "на основании того, что в моём любимом языке..."? Если бы всё было в этом подходе "шоколадно", то JIT-компиляция не потребовалась бы. А критиковали его ещё очень давно. С тех пор, как Lisp появился.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[35]: Будущее C#
От: Nose Россия  
Дата: 07.07.03 05:49
Оценка:
Здравствуйте, VladD2, Вы писали:

N>> (Кстати, неплохо было бы узнать, что Андрей Тарасевич и Павел Кузнецов думают об Александреску)

VD>Это не трудно. За одно узнай читали ли они его вообще.


ну... Павел Кузнецов, по-крайней мере, читал: здесь
Автор: Павел Кузнецов
Дата: 15.02.03
... << RSDN@Home 1.1 beta 1 >>
Re[40]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 06:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Да, не спорю, эмиттинг это позволяет, но проблема в другом — в правилах и алгоритмах сборки кодогенератора. Они-то откуда появятся?

AVK>>На основании информации из рефлекшена.

ГВ>На каком основании — это неважно в данном случае. Откуда появятся сами правила? Какая программа будет делать вывод о применимости того или иного правила?


А какое это имеет отношение к применимости или неприменимости рефлекшена?

AVK>>Бестолковый аргумент — на неумелость дизайнера можно свалить что угодно.


ГВ>На язык — тоже.


Язык нет, его возможности вполне объективны, в отличие от рассуждений о криворукости гипотетического дизайнера.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 06:10
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Ну посмотри тогда на XmlSerializer, он, в отличие от форматтеров, реализован очень неплохо.


VD>Я бы оценил на 3 с плюсом.


С чем сравнивал?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 06:10
Оценка:
Здравствуйте, _Kostya_, Вы писали:

_K_>1. Пусть у нас есть xml файл с данными. И некоторые поля не факт, что будут присутствовать. Можно узнать, что их нет и заполнить их по нужными данными, а не вылететь с общим исключением?


Можно

_K_>2. Есть массив. XML cериалайзер, как я понимаю, сохраняет его очень оригинально — стоит дерево тегов, в каждом из которых значение элемента.


Это смотря какой массив. Если byte[] то сохраняет в бинарном виде как base64
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[24]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 06:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ> Я не нахожу это решение очень уж красивым, хотя нечто такое же я неоднократно делал на C++, только выглядело по-другому, примерно так:


Неужели не видишь разницы между декларативным заданием и экзекутивным? Твой вариант более багоопасен и более сложен для понимания. Опять же ты лукавишь — в твоем коде отсутствует механика добавления айтема в коллекцию.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[30]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 06:20
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Ещё раз. Я говорил о дизайне и описал, какой именно дизайн я имею ввиду.

AVK>>Ты говорил что применение "самоанализа" это кривой дизайн. Перечитай еще раз свой пост.

ГВ>Совершенно верно, я даже описал — какой именно дизайн.


Вот нифига подобного, ты его описал когда тебе на пальцах доказали что ты не прав. Если бы ты описал это изначально это одно, а так, повторюсь, это уже отмазка. О том что с использованием любой технологии можно налепить кривоту никто не спорит.

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


ГВ>Ага, что и говорит об известности, но достигаемой путём обработки описания этой структуры. Дотнет ведь генерит описание структуры класса и т.п. При этом обязательно делаются предположения о способах использования тех или иных типов данных, либо типы данных содержат дополнительную информацию, касающуюся их использования в определённых ситуациях.


Это уже демагогия. Естественно что код, использующий рефлекшен знает что работать он будет таки с классами, а не бог знает с чем. Но не более того. Все остальное пустопорожний треп и попытка перевести спор на терминологию.

ГВ>Зато он настроен на определённый входной язык — сиречь язык описания структуры дотнетовских классов и делает предположения об адекватных способах редактирования.


И что? Какой из этого вывод? Точно так же можно сказать что он настроем на работу с 8-мибитными байтами. Проблема только в одном — все данные, которые присутствуют в дотнете на 100% соответствуют структуре дотнетовских классов. А знание о структуре всех данных эквивалентно тому что никаких специфических знаний, присущих конкретной предметной области нет. Этими знаниями обладает любой код в дотнете.

ГВ>Никакого противоречия тут нет. Более того, должны существовать ситуации, в которых он окажется неадекватным и потребуется его замена.


"Существуют ситуации" и "необходима всегда" все таки несколько разные случаи.

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


ГВ>Я несколько некорректно его сформулировал, забыл, что термин "RTTI" успел приобрести другое значение. В частности — для тебя.


Термин RTTI имеет ровно одно значение — RunTime Type Information, т.е. информация о типах во время ваыполнения. Повторяю — не пытайся перевести спор на термины, со стороны это выглядит как попытка выкрутиться.

ГВ>Моё утверждение о "самоанализе", естественно, не распространялось на ситуации анализа внешних данных, как не распространяется на них определение RTTI. Имелись ввиду только ситуации, в которых программа начинает анализировать свой сосбственный состав.


Во первых — твоя реплика была ответом на вот это:

Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.

Где тут про какие то особенности или термины? Совершенно очевидно что имелась ввиду информация о типах в рантайме. Без всяких ограничений. Если ты настаиваешь на том что при написании фразы ты имел ввиду какой то особый способ применения rtti то приходится признать что твоя реплика была просто не в тему и опять таки ты не прав.
Что же касается "имелись ввиду только ситуации, в которых программа начинает анализировать свой сосбственный состав" то это единственное для чего можно использовать рефлекшен. Т.е. твое утверждение опять же эквивалентно тому что использование рефлекшена означает кривой дизайн.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[35]: Будущее C#
От: _Kostya_  
Дата: 07.07.03 06:23
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


_K_>>1. Пусть у нас есть xml файл с данными. И некоторые поля не факт, что будут присутствовать. Можно узнать, что их нет и заполнить их по нужными данными, а не вылететь с общим исключением?


AVK>Можно


Наверное этот вопрос не для этого форума, а как? Смотреть код в исключении?

_K_>>2. Есть массив. XML cериалайзер, как я понимаю, сохраняет его очень оригинально — стоит дерево тегов, в каждом из которых значение элемента.


AVK>Это смотря какой массив. Если byte[] то сохраняет в бинарном виде как base64


Да нет, массив объектов. Вот для словарей вместо
<dic lang="2" n="2" up="1" value="asd1"/>
<dic lang="2" n="3" up="1" value="asd2"/>
<dic lang="2" n="4" up="1" value="asd3"/>
<dic lang="2" n="5" up="1" value="asd4"/>


Получаем 
<dic>
 <lang>2</lang>
 <n>2</n>
 <up>1</up>
 ну и так далее
</dic>
Re[30]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 06:30
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>а) Рефлекшн и RTTI — разные, хотя и похожие вещи. Reflection (буквальный перевод — "отражение") — он сам по себе, хотя и реализует функциональность RTTI.


Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[38]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 06:30
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Custom-атрибуты автоматически добавляются?

AVK>>А кастом атрибуты нужны только если не устраивает некий штатный вариант поведения.

ГВ>Так о том-то и речь, что пока библиотеки хватает, — всё вокруг ништяк. А шаг влево, шаг вправо...


Какой библиотеки? Речь не о данных библиотеки, а о данных среды исполнения. Естественно что они содержат ровно тот набор, который необходим для функционирования дотнета. Если тебе этого недостаточно то можно метаданные расширить при помощи атрибутов. Уж сколько раз твердили миру — рантайм дотнета это не набор библиотечек как в С++, это совершенно особая сущность, неотделимая от понятия программирования в дотнете и от его языков.

ГВ>Т.е., атрибут является носителем ссылки на тип (вероятно — имени класса), т.е. — на совокупность методов и данных. В определённом смысле — класс как класс. Кстати, в дальнейшем ты продемонстрировал пример вполне себе даже LSP-compliant решения. Недостаток один — атрибуа может не оказаться.


Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[36]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 06:40
Оценка:
Здравствуйте, _Kostya_, Вы писали:

_K_>>>1. Пусть у нас есть xml файл с данными. И некоторые поля не факт, что будут присутствовать. Можно узнать, что их нет и заполнить их по нужными данными, а не вылететь с общим исключением?


AVK>>Можно


_K_>Наверное этот вопрос не для этого форума, а как? Смотреть код в исключении?


Во-первых он не вылетает с исключениями если находит неизвестное поле, а просто его игнорирует. Во-вторых если не хочешь игнорировать то объявляешь специальное свойство, помечаешь его атрибутом и XmlSerializer при десериализации запихнет туда все неизвестные ему теги. В-третьих есть события UnknownXXX.


_K_>>>2. Есть массив. XML cериалайзер, как я понимаю, сохраняет его очень оригинально — стоит дерево тегов, в каждом из которых значение элемента.


AVK>>Это смотря какой массив. Если byte[] то сохраняет в бинарном виде как base64


_K_>Да нет, массив объектов. Вот для словарей вместо

_K_><dic lang="2" n="2" up="1" value="asd1"/>
_K_><dic lang="2" n="3" up="1" value="asd2"/>
_K_><dic lang="2" n="4" up="1" value="asd3"/>
_K_><dic lang="2" n="5" up="1" value="asd4"/>

_K_>[code]


_K_>Получаем

<dic>>
<lang>>2</lang>
<n>>2</n>
<up>>1</up>
_K_> ну и так далее
</dic>>

Учим матчасть. В данном конкретном случае тебе надобен XmlAtttributeAttribute.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[31]: Будущее C#
От: Sergey Россия  
Дата: 07.07.03 07:13
Оценка:
Здравствуйте, AndrewVK, Вы писали:

S>>А как, кстати, на шарпе будет выглядеть та же функциональность, что и у меня — задание идентификатора контрола, к которому привязана переменная и указание функции, которую надо использовать для обмена данными?


AVK>Ну как нибудь так, если я правильно понял что ты хочешь:

AVK>
AVK>class SomeForm : Form
AVK>{
AVK>    private string _someVar;
    
AVK>    [Exchange(ControlProperty = "Text", Destination = "_someVar")]
AVK>    Control _someControl;
AVK>}
AVK>

AVK>Функции никакой не надо.

Функция нужна, если требуется задавать преобразование. А то ведь и я могу функцию из параметров шаблона выкинуть.

VD>>>Получается красиво и пушисто. Уж точно такой жути в коде не будет.


S>>А это для кого как — для меня, например, шарповские конструкции ужасными выглядят.


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


Ok, смотрим:

class SomeForm : Form
{
    [Serializable]
    private string _someVar;

    [Exchange(ControlProperty = "Text", Destination = "_someVar")]
    Control _someControl;
}


struct TestA : ddx::controller_root<TestA, CDialog>
{
protected:
    typedef ddx::member<CString, IDC_SERVER, Ser> m_Server;
    typedef ddx::members<TYPELIST_1(m_Server)> members_info;
public:
    members_info ddxMembers;
};


Что-то я кардинальной разницы не наблюдаю. А если б у меня был приличный компилятор, а не VC 6, то мой код стал бы еще чуточку короче:

struct TestA : ddx::controller_root<TestA, CDialog>
{
protected:
    typedef ddx::member<CString, IDC_SERVER, Ser> m_Server;
public:
    ddx::members<m_Server> ddxMembers;
};


Впрочем, тогда библиотека стала бы несколько сложнее.

AVK>Все таки ты просто не видишь отличий.


Не вижу.

AVK>Воспользуйся советом Влада — расположи его и твой пример рядом, потом расслабься и не думай о программировании некоторое время, а потом взгляни на код.


Даже после выходных большой разницы не вижу

AVK>Я, как человек привыкший к синтаксису и шарпа, и дельфи, и плюсов могу тебе сказать — разница в читаемости огромная. Ваши нагромождения шаблонов превращают плюсы в птичий язык.


Значит, к синтаксису C++ ты таки не привык
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 07:33
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Функция нужна, если требуется задавать преобразование. А то ведь и я могу функцию из параметров шаблона выкинуть.


Даже если нужно преобразование функиця не нужна. Достаточно вместо переменной использовать свойство.

AVK>>Я, как человек привыкший к синтаксису и шарпа, и дельфи, и плюсов могу тебе сказать — разница в читаемости огромная. Ваши нагромождения шаблонов превращают плюсы в птичий язык.


S>Значит, к синтаксису C++ ты таки не привык


Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[33]: Будущее C#
От: Sergey Россия  
Дата: 07.07.03 07:51
Оценка:
Здравствуйте, AndrewVK, Вы писали:

S>>Функция нужна, если требуется задавать преобразование. А то ведь и я могу функцию из параметров шаблона выкинуть.


AVK>Даже если нужно преобразование функиця не нужна. Достаточно вместо переменной использовать свойство.


Его сначала сделать придется, это свойство . То же самое и C++ возможно, просто с функцией в данном конкретном случае меньше писанины.

AVK>>>Я, как человек привыкший к синтаксису и шарпа, и дельфи, и плюсов могу тебе сказать — разница в читаемости огромная. Ваши нагромождения шаблонов превращают плюсы в птичий язык.


S>>Значит, к синтаксису C++ ты таки не привык


AVK>Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.


Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны?
Я ж не утверждаю, что к синтаксису дельфи привык, хотя около года пришлось с этой бякой поработать.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[37]: Будущее C#
От: _Kostya_  
Дата: 07.07.03 08:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

Ok, спасибо.
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 08:37
Оценка:
Здравствуйте, Sergey, Вы писали:

AVK>>Даже если нужно преобразование функиця не нужна. Достаточно вместо переменной использовать свойство.


S>Его сначала сделать придется, это свойство . То же самое и C++ возможно, просто с функцией в данном конкретном случае меньше писанины.


Ну да, функцию отдельную сочинять это конечно куда проще и понятнее чем объявить вместо переменной свойство

AVK>>Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.


S>Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны?


Ты когда последний раз на C# что0либо писал? И как долго? И насколько интенсивно использовал рефлекшен?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[31]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.07.03 08:54
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>>>Ещё раз. Я говорил о дизайне и описал, какой именно дизайн я имею ввиду.

AVK>>>Ты говорил что применение "самоанализа" это кривой дизайн. Перечитай еще раз свой пост.
ГВ>>Совершенно верно, я даже описал — какой именно дизайн.
AVK>Вот нифига подобного, ты его описал когда тебе на пальцах доказали что ты не прав. Если бы ты описал это изначально это одно, а так, повторюсь, это уже отмазка.

Не отмазка, а объяснение. Если я высказался неясно, то нет ничего удивительного в том, что мне пришлось уточнить свою формулировку. Это совершенно нормально. И если тебе кажется, что это отмазка, то извини, но это только твои собственные проблемы.

AVK>О том что с использованием любой технологии можно налепить кривоту никто не спорит.


Это бесспорно.

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

ГВ>>Ага, что и говорит об известности, но достигаемой путём обработки описания этой структуры. Дотнет ведь генерит описание структуры класса и т.п. При этом обязательно делаются предположения о способах использования тех или иных типов данных, либо типы данных содержат дополнительную информацию, касающуюся их использования в определённых ситуациях.
AVK>Это уже демагогия. Естественно что код, использующий рефлекшен знает что работать он будет таки с классами, а не бог знает с чем. Но не более того. Все остальное пустопорожний треп и попытка перевести спор на терминологию.

Что-что? Ты вроде бы говорил о "неизвестных" типах данных, и я указал тебе на ошибку, поскольку дотнетовские типы для дотнетовских же программ известны. Продолжая рассуждения, замечу, что известны только как структура, что на мой взгляд, который я не склонен абсолютизировать, лучше всего годится только для технологических задач, вроде сериализации или несложного persistence. Если же заводить разговор о том, что описание структуры данных может содержать информационные структуры более высоких порядков, то здесь, ИМХО, возникают спорные моменты об адекватности такого дизайна.

ГВ>>Зато он настроен на определённый входной язык — сиречь язык описания структуры дотнетовских классов и делает предположения об адекватных способах редактирования.

AVK>И что? Какой из этого вывод? Точно так же можно сказать что он настроем на работу с 8-мибитными байтами. Проблема только в одном — все данные, которые присутствуют в дотнете на 100% соответствуют структуре дотнетовских классов. А знание о структуре всех данных эквивалентно тому что никаких специфических знаний, присущих конкретной предметной области нет. Этими знаниями обладает любой код в дотнете.

А вот последнее уже, извини, чушь. Располагать информацией о структуре данных и уметь её интерпретировать в контексте той или иной прикладной области — это две большие-большие разницы.

ГВ>>Никакого противоречия тут нет. Более того, должны существовать ситуации, в которых он окажется неадекватным и потребуется его замена.

AVK>"Существуют ситуации" и "необходима всегда" все таки несколько разные случаи.

Это означает, что "универсальное" решение построенное на анализе структуры типов данных a'priori ограниченно с точки зрения его прикладной применимости. Кстати, знаешь, это ещё одно интересное дополнение к моим тезисам о недостатках RTTI-bases.

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

ГВ>>Я несколько некорректно его сформулировал, забыл, что термин "RTTI" успел приобрести другое значение. В частности — для тебя.
AVK>Термин RTTI имеет ровно одно значение — RunTime Type Information, т.е. информация о типах во время ваыполнения. Повторяю — не пытайся перевести спор на термины, со стороны это выглядит как попытка выкрутиться.

Вот чтобы не выглядело как попытка выкрутиться, я и объясняю то значение термина и те специфические аспекты, на которые я опираюсь в рассуждениях. В противном случае спор выглядел бы как: "- Да ты, дубина, незнаешь! — Да ты сам нифига не знаешь!" И если определение вступает в конфликт с твоим предположением о нём, то извини — так получилось.

Кроме того, RTTI-based по-любому сохраняет свои недост..., тьфу, чёрт, характерные черты.

ГВ>>Моё утверждение о "самоанализе", естественно, не распространялось на ситуации анализа внешних данных, как не распространяется на них определение RTTI. Имелись ввиду только ситуации, в которых программа начинает анализировать свой сосбственный состав.

AVK>Во первых — твоя реплика была ответом на вот это:
AVK>

AVK>Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.

AVK>Где тут про какие то особенности или термины?

А речь в сообщении шла не о C++? Хм. Очень интересно. Поскольку я всё-таки склонен считать, что речь Влада шла о C++, то я и вспомнил об RTTI, преимущественно в контексте его использования в C++, имея ввиду также более общие принципы, известные как LSP. При дальнейшем обсуждении выяснилось, что особенности эти так или иначе сохраняются и в дотнете.

AVK>Совершенно очевидно что имелась ввиду информация о типах в рантайме. Без всяких ограничений. Если ты настаиваешь на том что при написании фразы ты имел ввиду какой то особый способ применения rtti то приходится признать что твоя реплика была просто не в тему и опять таки ты не прав.


Да нету у него никакого особого способа использования. Стандартный вполне:

if ( OBJECT.TYPE.SOME_CHARASTERISTIC is PRESENT) then { ... } else { ... }


Даже если в блоке then стоит обращение к некоему объекту, if-то всё равно есть.

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


Так или иначе, но все недостатки (sic! — характерные черты) присущие подходу с анализом типов — остаются на месте. Что, if-ы пропадают? Так нет ведь. Онипросто могут быть скрыты, как например в COM.

Я не буду утверждать, что использование рефлекшена — однозначно кривой дизайн. Есть задачи (например, — технологические, упомянутые выше), для которых он вполне адекватен.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[35]: Будущее C#
От: Sergey Россия  
Дата: 07.07.03 08:56
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Даже если нужно преобразование функиця не нужна. Достаточно вместо переменной использовать свойство.


S>>Его сначала сделать придется, это свойство . То же самое и C++ возможно, просто с функцией в данном конкретном случае меньше писанины.


AVK>Ну да, функцию отдельную сочинять это конечно куда проще и понятнее чем объявить вместо переменной свойство


В моем случае — именно так. Потому что переменную, у которой это свойство (функция-член) будет, я обычно вообще не завожу. Раз уж ты привык к синтаксису С++, то должен был это в том коде, что я кидал, с первого взгляда заметить

AVK>>>Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.


S>>Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны?


AVK>Ты когда последний раз на C# что0либо писал? И как долго? И насколько интенсивно использовал рефлекшен?


Я, в отличие от тебя, не утверждаю, что к синтаксису шарпа привык.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[31]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.07.03 09:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


ГВ>>а) Рефлекшн и RTTI — разные, хотя и похожие вещи. Reflection (буквальный перевод — "отражение") — он сам по себе, хотя и реализует функциональность RTTI.


AVK>Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?


Возможность взаимодействовать с экземпляром за счёт атрибутов. RTTI-сугубо информационная сущность. Поскольку RTTI — это runtime type information, а не например — objects, то рефлекшн хоть и включает в себя rtti, но в рамках оценки rtti-based-подхода использовать особенности рефлекшена, ИМХО, неверно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 09:47
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не отмазка, а объяснение. Если я высказался неясно, то нет ничего удивительного в том, что мне пришлось уточнить свою формулировку. Это совершенно нормально.


Ты не уточнил сразу, ты не уточнил даже после того как народ начал тебе объяснять что ты не прав. Ты уточнил только тогда когда у тебя не осталось разумных аргументов. В этом то и проблема

AVK>>Это уже демагогия. Естественно что код, использующий рефлекшен знает что работать он будет таки с классами, а не бог знает с чем. Но не более того. Все остальное пустопорожний треп и попытка перевести спор на терминологию.


ГВ>Что-что? Ты вроде бы говорил о "неизвестных" типах данных, и я указал тебе на ошибку, поскольку дотнетовские типы для дотнетовских же программ известны.


Хорошо, уточню формулировку — неизвестных типов дотнета.

ГВ>Вот чтобы не выглядело как попытка выкрутиться, я и объясняю то значение термина и те специфические аспекты, на которые я опираюсь в рассуждениях.


Значит ты влез не в тему, потому что в начальном топике имелся ввиду именно рефлекшен в целом. Не веришь — можешь у Влада уточнить. Я тебе гарантирую что твое понятие rtti он точно не имел ввиду.

ГВ>Кроме того, RTTI-based по-любому сохраняет свои недост..., тьфу, чёрт, характерные черты.


Спорить о вкусах устриц можно только с теми кто их ел, я все больше убеждаюсь в этом.

AVK>>

AVK>>Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.

AVK>>Где тут про какие то особенности или термины?

ГВ>А речь в сообщении шла не о C++? Хм. Очень интересно. Поскольку я всё-таки склонен считать, что речь Влада шла о C++, то я и вспомнил об RTTI,


Речь шла, смотри название топика, о C# и его особенностях по сравнению с С++. И Влад указал на то что фатальным недостатком плюсов является отсутствие аналога рефлекшена. Опять же — можешь у него переспросить что именно он имел ввиду, если мне не веришь.

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


ГВ>Так или иначе, но все недостатки (sic! — характерные черты) присущие подходу с анализом типов — остаются на месте. Что, if-ы пропадают? Так нет ведь. Онипросто могут быть скрыты, как например в COM.


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

ГВ>Я не буду утверждать, что использование рефлекшена — однозначно кривой дизайн. Есть задачи (например, — технологические, упомянутые выше), для которых он вполне адекватен.


То есть, памятуя о контексте твоего высказывания, ты все таки не прав.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 09:47
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?


ГВ>Возможность взаимодействовать с экземпляром за счёт атрибутов.


Это тоже информация о типах.

ГВ>RTTI-сугубо информационная сущность.


Рефлекшен (если не поминать эмит) тоже.

ГВ> Поскольку RTTI — это runtime type information, а не например — objects, то рефлекшн хоть и включает в себя rtti, но в рамках оценки rtti-based-подхода использовать особенности рефлекшена, ИМХО, неверно.


Атрибуты это такая же информация о типах, просто она не встроена в язык, а доступна для изменения пользователем. Никакой разницы с точки зрения рефлекшена между кастом-атрибутами и скажем модификаторами доступа нет.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[36]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 10:14
Оценка:
Здравствуйте, Sergey, Вы писали:

AVK>>>>Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.


S>>>Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны?


AVK>>Ты когда последний раз на C# что0либо писал? И как долго? И насколько интенсивно использовал рефлекшен?


S>Я, в отличие от тебя, не утверждаю, что к синтаксису шарпа привык.


А я где то утверждал что привык к синтаксису С++?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[30]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.07.03 10:59
Оценка:
Здравствуйте, VladD2, Вы писали:

А я бы на их месте ввел спецификатор const как для ссылок так и для методов. Весьма не хватает этой вещи в Java и .NET!

Проблема в том, что отдавая мз метода ссылку на внутренний объект мы не можем быть уверены, что получивший ее не примется сразу по ней модифицировать наше содержимое. Все, пинцет. Через метод GetBirthday() мы можем передвинуть дату рождения.
Единственный способ борьбы с этим — возврат копии объекта. Но у него два принципиальных недостатка:
1. Клонирование дорого, и в таких случаях нафиг не надо. Паранойя съедает производительность.
2. Код, получивший ссылку и изменивший состояние копии, не будет пойман за руку компилятором — там все честно. Но результат может оказаться неожиданным.

На первый взгляд, можно преодолеть этот косяк, введя для каждого объектного типа пару интерфейсов:
IMyClassConst {}
IMyClass: IMyClassConst

и дооборудовать второй неконстантными методами. Увы, это обман. Как только мы попытаемся унаследоваться от нашего класса, мы встрянем. Ибо наследование интерфейсов у нас только одиночное, и требуемой совместимости ссылок обеспечить не удастся.

Помимо всего прочего, лично мне при проектировании ODBMS очень бы пригодились метаданные о константности методов.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.07.03 11:46
Оценка:
Здравствуйте, VladD2, Вы писали:

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


ГВ>>Custom-атрибуты автоматически добавляются? А указания об их добавлении откуда появляются?


VD>Слышал когда нибудь термин "декларативное программирование"? Значеш в чем его проиемущетсво над обычным?


Что ты подразумеваешь под "обычным"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[39]: Будущее C#
От: Vladimir Khatzkevich Россия  
Дата: 07.07.03 12:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

[skip]
AVK>Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.

В фразе "Грамотный дизайн априори сч..." есть противоречие. Т.е. грамотный дизайн предполагает отсутствие атрибутов, но с другой стороны они там есть. Нелогично как-то

ИМХО, в грамотном дизайне не должно быть нестандартного(частного) поведения. С другой стороны, из моего опыта многие дизайны грешили подобными частностями, т.е. не были грамотными.

Из всего выше сказанного можно сделать предположение, что атрибуты упрощают создание подобных частностей. Верно?
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[31]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 12:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Проблема в том, что отдавая мз метода ссылку на внутренний объект мы не можем быть уверены, что получивший ее не примется сразу по ней модифицировать наше содержимое. Все, пинцет. Через метод GetBirthday() мы можем передвинуть дату рождения.


Ерунда это все. Если ты не хочешь чтобы модифицировали то закрывай методы, которые модифицируют содержимое, делай их internal. Так значительно понятнее для чтения и контроль проще.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[40]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 13:27
Оценка:
Здравствуйте, Vladimir Khatzkevich, Вы писали:

VK>В фразе "Грамотный дизайн априори сч..." есть противоречие. Т.е. грамотный дизайн предполагает отсутствие атрибутов, но с другой стороны они там есть. Нелогично как-то


Грамотный дизайн предполагает использование атрибутов только если не устраивает штатное поведение алгоритма.

VK>ИМХО, в грамотном дизайне не должно быть нестандартного(частного) поведения. С другой стороны, из моего опыта многие дизайны грешили подобными частностями, т.е. не были грамотными.


Дело не в частностях, дело в сокрытии особенностей. Т.е. тут есть противоречие — с одной стороны способ применения необходим крайне простой чтобы не было необходимости изучать кучу информации для того чтобы начать работу. С другой стороны хотелось бы максимальной конфигурируемости и кучи настроек чтобы охватить максимальный спектр возможных применений. Одним из вариантов решения подобного противоречия является такой дизайн, что атрибуты применяются только при необходимости, а не безусловно. Поясню на примере:
"неправильный" дизайн
public class DbClass
{
    [DbField("Field1")]
    public string Field1 {...}
    
    [DbField("Field2")]
    public string Field2 {...}
    
    [DbField("Field3")]
    public string SomeField {...}
}


"правильный" дизайн
public class DbClass
{
    public string Field1 {...}
    
    public string Field2 {...}
    
    [DbField("Field3")]
    public string SomeField {...}
}
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[37]: Будущее C#
От: WolfHound  
Дата: 07.07.03 13:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>С циклическими ссылками проблемки возникают.

По этому я и написал 99%
А в большинстве случаев можно разрулить при помощи слабых ссылок.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.07.03 14:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>По этому я и написал 99%

WH>А в большинстве случаев можно разрулить при помощи слабых ссылок.

Ага, только такое разруливание оказывается тормознее и неудобнее GC.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[35]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.03 15:12
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Я бы оценил на 3 с плюсом.


AVK>С чем сравнивал?


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

VD>>Слышал когда нибудь термин "декларативное программирование"? Значеш в чем его проиемущетсво над обычным?


ГВ>Что ты подразумеваешь под "обычным"?


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

ГВ>Именно, а компьютерный "абстрактный объект" всегда представляется чем-то конкретным. И уж точно не " = 0", если речь идёт о работающем объекте.


Не прикидывайся. Речь идет о любом (некотором) объекте.

ГВ>С чего ты взял, что я критикую подход всего лишь "на основании того, что в моём любимом языке..."? Если бы всё было в этом подходе "шоколадно", то JIT-компиляция не потребовалась бы. А критиковали его ещё очень давно. С тех пор, как Lisp появился.


С того, что о дотнете ты слышал краем уха. Если бы это было не так, то как минимум ты не говорил бы о JIT-компиляции. Так как она никакого отношения к рефлекшону не имеет. Если не веришь, сделай поиск по msdn на слово ngeg. Это утилита которая позволяет прекомпилировать msil, но рефлекшон при этом полностью доступен. Это так же как в TLB в COM, только формат храниния стандартизирован.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.03 15:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Чем тебе паскалевские указатели не угодили? Ровно такие же как и в С++, кроме наличия в последнем адресной арифметики.


Гы-гы.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.03 15:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Термин RTTI имеет ровно одно значение — RunTime Type Information, т.е. информация о типах во время ваыполнения.


Вот ксатати, именно по этому мне этот термин не нравится. Дотнетный рефлекшон доступен еще на дизайн-тайме. А в С++-ном rtti даже понятия такого как дизайнтайм нет.

AVK>Повторяю — не пытайся перевести спор на термины, со стороны это выглядит как попытка выкрутиться.


Что значит выглядит? Это она и есть. Собственно по этому мне этот спор уже больше не интрересен.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.03 15:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?


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

ГВ>Возможность взаимодействовать с экземпляром за счёт атрибутов. RTTI-сугубо информационная сущность. Поскольку RTTI — это runtime type information, а не например — objects,


Нда. Атрибуты — это средства расширения метаинформации. И атрибуты всегда ассоциируются с метаданными классов/методов. К объектам же они отношения не имеют. Так что рефлекшон и есть информация о типах. Правда от rtti он отличается... тем, что информация доступна не таолько на рантайме, но и во время разработки и даже компиляции.

ГВ>то рефлекшн хоть и включает в себя rtti, но в рамках оценки rtti-based-подхода использовать особенности рефлекшена, ИМХО, неверно.


Ты снова судишь с позиции С++. А АВК говорит с позиции чистого термина. То что rtti в С++ — это убогий уродец с тобой никто не спорит. Но сама концепция равитая в дургих средах/языках от этого хуже не становится.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.03 15:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Значит ты влез не в тему, потому что в начальном топике имелся ввиду именно рефлекшен в целом. Не веришь — можешь у Влада уточнить. Я тебе гарантирую что твое понятие rtti он точно не имел ввиду.


Да я как бы вообще не употреблял термин rtti. Это вы начали. Я использовал термин "информация о типах". Rtti в С++ уродливо и неполноценно. Хорошими примероми качественной информации о типах я могу назвоть: TLB в COM, и рефлекшон в дотнете и Яве.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.07.03 16:43
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Не отмазка, а объяснение. Если я высказался неясно, то нет ничего удивительного в том, что мне пришлось уточнить свою формулировку. Это совершенно нормально.

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

Просто я считаю особенности RTTI-based дизайна очевидными.

AVK>>>Это уже демагогия. Естественно что код, использующий рефлекшен знает что работать он будет таки с классами, а не бог знает с чем. Но не более того. Все остальное пустопорожний треп и попытка перевести спор на терминологию.

ГВ>>Что-что? Ты вроде бы говорил о "неизвестных" типах данных, и я указал тебе на ошибку, поскольку дотнетовские типы для дотнетовских же программ известны.
AVK>Хорошо, уточню формулировку — неизвестных типов дотнета.

OK, но откуда они там возьмутся? Либо это дотнетовские, а значит — известные типы, либо — не-дотнетовские, а значит — неизвестные типы. Другое дело, что на момент трансляции модуля могут быть неизвестны конкретные дотнетовские типы, которые окажутся на месте аргументов метода, например.

ГВ>>Вот чтобы не выглядело как попытка выкрутиться, я и объясняю то значение термина и те специфические аспекты, на которые я опираюсь в рассуждениях.

AVK>Значит ты влез не в тему, потому что в начальном топике имелся ввиду именно рефлекшен в целом. Не веришь — можешь у Влада уточнить. Я тебе гарантирую что твое понятие rtti он точно не имел ввиду.

Знаешь, я вот думаю сейчас, а не поспешно ли я признал, что reflection и rtti — разные вещи...

ГВ>>Кроме того, RTTI-based по-любому сохраняет свои недост..., тьфу, чёрт, характерные черты.

AVK>Спорить о вкусах устриц можно только с теми кто их ел, я все больше убеждаюсь в этом.

Похоже, мы спорим не о вкусе, а об усваиваемости, что можно делать и не поедая устриц. Тем более — в огромных количествах.

AVK>>>

AVK>>>Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.

AVK>>>Где тут про какие то особенности или термины?
ГВ>>А речь в сообщении шла не о C++? Хм. Очень интересно. Поскольку я всё-таки склонен считать, что речь Влада шла о C++, то я и вспомнил об RTTI,
AVK>Речь шла, смотри название топика, о C# и его особенностях по сравнению с С++. И Влад указал на то что фатальным недостатком плюсов является отсутствие аналога рефлекшена. Опять же — можешь у него переспросить что именно он имел ввиду, если мне не веришь.

Угу, дальше он упомянул о глобальном "недостатке" C++ и ввязался я, поскольку подобных утверждений не люблю.

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

ГВ>>Так или иначе, но все недостатки (sic! — характерные черты) присущие подходу с анализом типов — остаются на месте. Что, if-ы пропадают? Так нет ведь. Онипросто могут быть скрыты, как например в COM.
AVK>В общем спор с тобой начинает терять интерес, поскольку от аргументов ты скатываешься к жонглированию понятиями, переводом спора на другие темы и прочими демагогическими приемами. Вот попробуй сам описать связь между моей цитатой и твоим ответом. Я уловить не смог.

Нет проблем. Ты приписываешь мне категоричное утверждение — "использование рефлекшена = кривой дизайн". Я, в свою очередь, отказываюсь от подобной категоричности, смягчая её ("Так или иначе"), поскольку по крайней мере на данный момент с этим не согласен. Дальше, поскольку я не хочу обобщать, то просто игнорирую "наезд" и снова повторяю характерные черты RTTI-based-дизайна, поскольку они могут присутствовать при использовании информации из reflection. Т.е. я просто смягчаю категоричность, которую ты мне упорно навязываешь и пытаюсь обратить твоё внимание на очевидный, ИМХО, факт.

ГВ>>Я не буду утверждать, что использование рефлекшена — однозначно кривой дизайн. Есть задачи (например, — технологические, упомянутые выше), для которых он вполне адекватен.

AVK>То есть, памятуя о контексте твоего высказывания, ты все таки не прав.

Хех, если с использованием reflection можно добиться чистого LSP-compliant, то Reflection <> RTTI, если нельзя, то увы: Reflection=RTTI и я ошибся, сказав, что это разные вещи.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[33]: Будущее C#
От: WolfHound  
Дата: 07.07.03 16:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Вам обоим не кажется, что прочтение одной книжки еще не дает права считать себя экспертом в некоторой оболасти?

Нет не считаю. Но практика показывает что эта книга оочень сильно поднимает уровень.

VD>Еще раз повторсь, что С++ я знаю. И уж точно я знаю его настолько, чтобы иметь право выносить свои суждения об этом зяыке.

Я тоже повторюсь интересно почему движок человека с 10 летним опытом работы на С++ единогласно пошол лесом против моего? Единственное обьяснение которое приходит на ум это то что работать с моим движком почти также просто как с C#. (Я вобще предлагал на шарпе но начальство не согласилось)
Причем когда стоит вопрос Что? все лушают его, когда он превращается в Как? то меня.

VD>Попадется — погляжу. Но искать специально точно не буду. Не верится мне, что можно открыть америку в ванной.

Можно.
К стати на счет авторитетов

Если, прочитав материал, посвященный спискам типов, вы не свалились со стула, значит, вы сидели на полу.

Scott Meyers

Что нового можно сказать о языке С++, Оказывается, очень много.

John Vlissides

Современное проектирование на С++ — важная книга. По существу, "обобщенные шаблоны", или "шаблонные шаблоны", в ней представлены как новый мощный метод гибкого проектирования на языке С++ — новый способ комбинирования шаблонных классов и шаблонов поектирования, о котором мы и мечтать не могли. Если вы проектируете и программируете на языке С++, вам следует прочесть эту книгу. Очень рекомендую...

Herb Sutter

ЗЫ книга из серии C++ In-Depth
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.07.03 16:45
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>>>Custom-атрибуты автоматически добавляются?

AVK>>>А кастом атрибуты нужны только если не устраивает некий штатный вариант поведения.
ГВ>>Так о том-то и речь, что пока библиотеки хватает, — всё вокруг ништяк. А шаг влево, шаг вправо...
AVK>Какой библиотеки?

Библиотеки Framework-а.

AVK>Речь не о данных библиотеки,

Естественно. Даже не о данных, а об алгоритмах.

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


Да я и не опровергаю этого.

ГВ>>Т.е., атрибут является носителем ссылки на тип (вероятно — имени класса), т.е. — на совокупность методов и данных. В определённом смысле — класс как класс. Кстати, в дальнейшем ты продемонстрировал пример вполне себе даже LSP-compliant решения. Недостаток один — атрибуа может не оказаться.

AVK>Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.

Поздравляю. Это и есть первейший признак RTTI-based дизайна. "Если есть нечто, влияющее на алгоритм..." И это ты называешь "грамотным дизайном"? По идее алгоритм всегда работает штатно, выполняясь на адаптированных для него сущностях. Да, отдельные сегменты могут варьироваться в зависимости от сущностей, но эти сегменты предоставляются самими сущностями (см. — виртуальные функции). Но сам факт выполнения этих сегментов не зависит от характера сущности или же, в случае, если он не нужен, может оптимизироваться компилятором.

Бесспорно, почти то же самое можно сделать с помощью атрибутов, но есть два соображения, по которым и появляется это "почти".

1. Атрибуты могут быть применены, но они не могут быть обязательно применены (если не подмешивается наследование от класса, у которого определён атрибут) что всегда должно влечь за собой условность (признак RTTI-based-дизайна) в их обработке.

2. Если алгоритм предполагает поиск атрибута => условность, то это уже не LSP-дизайн, => близок к кривому...

Хммм... получается, что...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[31]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.03 17:19
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ваши нагромождения шаблонов превращают плюсы в птичий язык.


Ну, это ты зря. Если шаблонами пользоваться умело и по месту, то они очень даже хорошо читаются. Вот простой пример из шустрика:


template <class SType> 
void __fastcall QuickSort(SType *item, int left, int right)
{
  int i, j;
  SType center;
  SType x;
  i = left;
  j = right;  
  center = item[(left + right)  2];
  while(i <= j)
  {
    while (item[i] < center && i < right)
      i++;
    while (item[j] > center && j > left)
      j--;
    
    if (i<=j){
      x  = item[i];
      item[i] = item[j];
      item[j] = x;
      i++;
      j--;
    }
  } 
  if(left < j)
    QuickSort(item, left, j);
  if(right > i)
    QuickSort(item, i, right);
}


А вот аналогичный код на Шарпе:
static void QuickSortInt(int[] item, int left, int right)
{
  int i, j;
  int center;
  int x;
  i = left;
  j = right;  
  center = item[(left + right)  2];
  while(i <= j)
  {
    while (item[i] < center && i < right)
      i++;
    while (item[j] > center && j > left)
      j--;
    
    if (i<=j){
      x  = item[i];
      item[i] = item[j];
      item[j] = x;
      i++;
      j--;
    }
  } 
  if(left < j)
    QuickSort(item, left, j);
  if(right > i)
    QuickSort(item, i, right);
}


Как видишь, разницы почти нет. Так что шаблонный код может быть таким же читабельным как и обычный. За-то универсальность такого кода куда выше.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.03 17:19
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны?

S>Я ж не утверждаю, что к синтаксису дельфи привык, хотя около года пришлось с этой бякой поработать.

Я тебе скажу так. Хотя синтаксис шаблонов в С++ меня полностью устраивает. Но в общем и целом я согласен с АВК. Читать исходники на С++ намного сложнее чем на Шарпе. А эмуляций остуствущей в функциональности на шаблонах еще больше усугубляет это положение.

PS

На плюсах последий раз неделю назад. Вообще написал на них радимых кучу кода. А читать приходилось вообще ороменные листинги.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.07.03 21:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Слышал когда нибудь термин "декларативное программирование"? Значеш в чем его проиемущетсво над обычным?

ГВ>>Что ты подразумеваешь под "обычным"?
VD>То чем занимашся ты. Долбление кода для решения любой задачи.

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

ГВ>>Именно, а компьютерный "абстрактный объект" всегда представляется чем-то конкретным. И уж точно не " = 0", если речь идёт о работающем объекте.


VD>Не прикидывайся. Речь идет о любом (некотором) объекте.


Даже "любой" объект обязан что-то делать, чтобы вместо вызовов его методов не получались сплошные throw.

ГВ>>С чего ты взял, что я критикую подход всего лишь "на основании того, что в моём любимом языке..."? Если бы всё было в этом подходе "шоколадно", то JIT-компиляция не потребовалась бы. А критиковали его ещё очень давно. С тех пор, как Lisp появился.


VD>С того, что о дотнете ты слышал краем уха. Если бы это было не так, то как минимум ты не говорил бы о JIT-компиляции. Так как она никакого отношения к рефлекшону не имеет.


Да, подловил, извини, я не прав. Я имел ввиду оптимизацию исполняемого кода в зависимости от условий его исполнения. Естественно — это только составная часть .Net-JIT-а.

С другой стороны — как бы это можно было делать анализ условий выполенения, не имея рефлективной информации? Не подскажешь? Это к твоей посылке о том, что "она никакого отношения к рефлекшону не имеет".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[34]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 00:34
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да ну?


Ну, да.

ГВ>Интересно, VC-шный class browser вероятно не предоставляет информации о классах в период разработки? Странно...


Он использует отладочную БД. Можешь обвыключаться rtti, а он все равно будет работать.

ГВ>То, что информация о типах доступна в design-time говорит только о развитости среды и относительной легкодоступности этой информации. Ну это как бы и очевидно.


Ага. В общем, оно говорит о грамотной реализации и удобстве в использовании.

ГВ>Может быть и так. Но от свойственных ей недостатков (sorry — особенностей ) как оверхед (всегда)


Оверхэд есть при любой интерпретации. Все твои предложения по замене рефлекшона строились на том, что ты изобретал свою метаинформацию и анализировал ее. Это не будет быстрее чем анализ штантной метаинформации.

ГВ>+ ненадёжность (почти всегда) она от этого не избавляется.


Ну, а вот это твое глубокое заблуждение. Практика показывает обратное. Решения реализованные на метаинформации обычно надежнее лобового кодирования. Ты кстати тоже ратуя за шаблоны и виртуальные методы кланишь к некому универсальному решинию на базе метаинформации. Но ты почему-то считаешь, что такая информация не зашитая в код приводит к каким-то там проблемам. А это не так. Анализ в рантайме сам по себе ненадежным быть не может.

В общем, борость с метаинформацией и алгоритмами ее использующими так же бессмысленно как нелюбить Пушкина в нашей стране.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 00:34
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Даже "любой" объект обязан что-то делать, чтобы вместо вызовов его методов не получались сплошные throw.


Попробуй еще раз прочесть о чем идет речь...

ГВ>Да, подловил, извини, я не прав. Я имел ввиду оптимизацию исполняемого кода в зависимости от условий его исполнения. Естественно — это только составная часть .Net-JIT-а.


Эти оптимизации никак не влияют на рабту рефлекшона. Рефлекшон ссылается на слоты, а как в эти слоты попадает машинный код и какая обработка осуществляется при его создании/чтении уже десятый вопрос. Даже если вызов метода будет соптимизирован все равно вся информация о нем останется в метаданных и ею можно бдет воспользоваться. Можно будет даже вызвать этот метод динамически (хотя будет вызван не инлайн дубликат).

ГВ>С другой стороны — как бы это можно было делать анализ условий выполенения, не имея рефлективной информации? Не подскажешь? Это к твоей посылке о том, что "она никакого отношения к рефлекшону не имеет".


Спакойно. Общую идею на счет методов я тебе поведал. Метаинфомация же лежит в специальной псевдо-реляционной структуре и есть апи ее четения. Если из кода обратиться к решлекшону, то код будет содержать вызвы этого апи. При этом совершенно все равно будет ли этот код пJIT-ится или будет всят прекомпилированный код. Да даже если будет происходить интерпретация все равно ронвным счетом ничего не изменится.


ЗЫ

Вообще, я не пойму зачем бароться с алгоритмами построенными на базе анализа метаинформации. В базах данных ее нарошно придумывают и хранят в системных таблицах. Компиляторы строят ее для автоматизации процесса кодирования. Что же плохого в том, что и код может иметь самоописание?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.07.03 04:34
Оценка:
Здравствуйте, AndrewVK, Вы писали:


AVK>Ерунда это все. Если ты не хочешь чтобы модифицировали то закрывай методы, которые модифицируют содержимое, делай их internal. Так значительно понятнее для чтения и контроль проще.

Это не ерунда. Это фундаментальная проблема дизайна этих системи. Их не так много.
Еще раз: нет способа закрыть методы!
Ну вот смотри: Есть у нас класс Date. У него есть как геттеры, так и сеттеры. Если ты сделашь его сеттеры интернал, то он будет практически иммутабл. И что дальше? Где ты собрался его использовать? В каждой сборке будет свой класс Date? Хорошо, сделаем два класса Date общего назначения. Один будет immutable, другой mutable. Для того, чтобы можно было хранить внутри mutable (мы-то сами собираемся его менять!), а отдавать наружу ссылку на immutable, нам придется унаследовать Date от ConstDate. Хорошо, для дат это еще может проконать, т.к. на практике никто не собирается наследоваться от даты. А как только соберется, он сразу огребет проблемы. Потому что сразу потребуется опять два класса, при этом совместимость сссылок должна быть вот такой:
Date - >ConstDate
MyDate - >Date
MyConstDate - >ConstDate
MyDate - >MyConstDate

Если мы унаследуемся вот так:
MyDate — >MyConstDate — > Date — >ConstDate
то MyConstDate получит в подарок неконстантный интерфейс. Упс.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[36]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 06:07
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>С чем сравнивал?


VD>С собственными тестами. В прочем, ты должен был и сам догадаться.


Я догадался, потому и спрашивал. В твоих тестах не было с чем XmlSerializer сравнивать. SoapFormatter и DataSet были явно медленнее в разы, а сравнивать с бинарными сериализаторами текстовый глупо.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 06:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, AndrewVK, Вы писали:


AVK>>Термин RTTI имеет ровно одно значение — RunTime Type Information, т.е. информация о типах во время ваыполнения.


VD>Вот ксатати, именно по этому мне этот термин не нравится. Дотнетный рефлекшон доступен еще на дизайн-тайме.


На момент появления этого термина термина дизайн-тайм не существовало, имелось ввиду противопоставление рантайм-компайлтайм. С этих позиций дизайн-тайм это безусловно тоже рантайм.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 06:17
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Просто я считаю особенности RTTI-based дизайна очевидными.


Ну считай. Не надо только говорить что использование информации о типах это безусловно кривой дизайн.

AVK>>Хорошо, уточню формулировку — неизвестных типов дотнета.


ГВ>OK, но откуда они там возьмутся? Либо это дотнетовские, а значит — известные типы,


Вот когда С++ научится распознавать хотя бы свои собственные типы в рантайме из чужих модулей тогда и поговорим. А пока плюсовые шаблоны даже такого не обеспечивают.

AVK>>Значит ты влез не в тему, потому что в начальном топике имелся ввиду именно рефлекшен в целом. Не веришь — можешь у Влада уточнить. Я тебе гарантирую что твое понятие rtti он точно не имел ввиду.


ГВ>Знаешь, я вот думаю сейчас, а не поспешно ли я признал, что reflection и rtti — разные вещи...


Правильно думаешь. Рефлекшен это дальнейшее развитие rtti, по сути rtti доведенный до ума, так чтобы им можно было пользоваться.

ГВ>Нет проблем. Ты приписываешь мне категоричное утверждение — "использование рефлекшена = кривой дизайн".


Я не приписываю, оно так и есть. Или ты уже от своих слов отказываешься?

ГВ>снова повторяю характерные черты RTTI-based-дизайна,


Зачем? У тебя про твой придуманный термин никто ничего и не спрашивал. Речь шла про рефлекшен в шарпе, и отсутствие онного к С++ если ты еще не понял.

ГВ>поскольку они могут присутствовать при использовании информации из reflection. Т.е. я просто смягчаю категоричность, которую ты мне упорно навязываешь


Я тебе ничего не навязываю, я тебя цитирую. Уж извини, но никакими приемами ты не докажешь что твоя абсолютно односмысленная фраза выражала что то совсем другое.

ГВ>и пытаюсь обратить твоё внимание на очевидный, ИМХО, факт.


Нет, ты пытаешься отмазаться от своих же слов. Надо уметь признавать свою неправоту. Ничего плохого в том что ты оказался неправ нет. Все мы не идеальны.

AVK>>То есть, памятуя о контексте твоего высказывания, ты все таки не прав.


ГВ>Хех, если с использованием reflection можно добиться чистого LSP-compliant, то Reflection <> RTTI, если нельзя, то увы: Reflection=RTTI и я ошибся, сказав, что это разные вещи.


Твои приравнивания просто не правомерны. Рефлекшен — это технология, RTTI это принцип. Сравнивать их нельзя.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 06:17
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?


VD>Вообще-то он предостовляет механизм динамического вызова.


Это тот же самый RTTI.

VD> Ну, и еще в дотнете есть средства генерации метаданных, да и кода.


Про эмит я сразу оговорился что его не учитываем.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 06:27
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Нда. Атрибуты — это средства расширения метаинформации. И атрибуты всегда ассоциируются с метаданными классов/методов. К объектам же они отношения не имеют.


ГВ>Да ну?


Именно что не имеют. Объекты там возникают только в момент их чтения, как удобная оболочка для доступа к ним. До этого атрибуты совершенно необъектная сущность. Просто в дотнете их постарались максимально закрыть классами для упрощения работы с ними. Однако некоторые атрибуты вобще как правило ввиде объектов не создаются, например атрибуты Flags, DllImport.

ГВ>Интересно, VC-шный class browser вероятно не предоставляет информации о классах в период разработки? Странно...


Это сторонняя приблуда, пользующаяся своим парсером. Влад же говорит о том что ты в своих компонентах можешь использовать штатный механизм для этого.

ГВ>С другой стороны, reflection имеет ещё кучу отличий от rtti.


Рефлекшен это и есть rtti дотнета.

VD>>Ты снова судишь с позиции С++. А АВК говорит с позиции чистого термина. То что rtti в С++ — это убогий уродец с тобой никто не спорит. Но сама концепция равитая в дургих средах/языках от этого хуже не становится.


ГВ>Может быть и так. Но от свойственных ей недостатков (sorry — особенностей ) как оверхед (всегда) + ненадёжность (почти всегда) она от этого не избавляется.


Ну и что? Исходя из этого его не стоит применять?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[32]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 06:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, AndrewVK, Вы писали:


AVK>>Ваши нагромождения шаблонов превращают плюсы в птичий язык.


VD>Ну, это ты зря. Если шаблонами пользоваться умело и по месту,


Ключевая фраза. По месту. А вот если не по месту а для затычки дырок языка то куча вложенных шаблонов никаких положительных эмоций не вызывает.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[40]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 06:37
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Так о том-то и речь, что пока библиотеки хватает, — всё вокруг ништяк. А шаг влево, шаг вправо...

AVK>>Какой библиотеки?

ГВ>Библиотеки Framework-а.


Рефлекшен это свойство CLR, библиотека используется для доступа к нему.

AVK>>Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.


ГВ>Поздравляю. Это и есть первейший признак RTTI-based дизайна. "Если есть нечто, влияющее на алгоритм..." И это ты называешь "грамотным дизайном"? По идее алгоритм всегда работает штатно, выполняясь на адаптированных для него сущностях. Да, отдельные сегменты могут варьироваться в зависимости от сущностей, но эти сегменты предоставляются самими сущностями (см. — виртуальные функции). Но сам факт выполнения этих сегментов не зависит от характера сущности или же, в случае, если он не нужен, может оптимизироваться компилятором.


Смысл твоей фразы? Чего хоть сказать хотел?

ГВ>1. Атрибуты могут быть применены, но они не могут быть обязательно применены


Зависит от компилятора.

ГВ> (если не подмешивается наследование от класса, у которого определён атрибут)


А если подмешивается?

ГВ>2. Если алгоритм предполагает поиск атрибута => условность, то это уже не LSP-дизайн, => близок к кривому...


То есть все что не соответствует какому то варианту, который тебе нравится то кривое?

ГВ>Хммм... получается, что...


Получается что ты опять не хочешь признать что помимо С++ есть что то еще.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[33]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 07:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Это не ерунда. Это фундаментальная проблема дизайна этих системи. Их не так много.

S>Еще раз: нет способа закрыть методы!

Что значит "закрыть методы"?

S>Ну вот смотри: Есть у нас класс Date. У него есть как геттеры, так и сеттеры. Если ты сделашь его сеттеры интернал, то он будет практически иммутабл.


А так оно для DateTime и есть.

S> И что дальше? Где ты собрался его использовать?


Обыкновенно.

S>В каждой сборке будет свой класс Date?


Зачем? Один на всех.

[skipped]

Ты упускаешь важный момент — закрытие сеттеров отнюдь не означает отсутствие публичных конструкторов, которые устанавливают все необходимые поля.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[35]: Будущее C#
От: Sergey Россия  
Дата: 08.07.03 07:19
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Интересно, VC-шный class browser вероятно не предоставляет информации о классах в период разработки? Странно...


VD>Он использует отладочную БД. Можешь обвыключаться rtti, а он все равно будет работать.


ГВ>>То, что информация о типах доступна в design-time говорит только о развитости среды и относительной легкодоступности этой информации. Ну это как бы и очевидно.


VD>Ага. В общем, оно говорит о грамотной реализации и удобстве в использовании.


Кстати, а VisualAssist по этому критерию чем не подходит? Большая часть того, чем он занимается — это предоставляет информацию о типах в design-time

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


IMHO, в плюсах правильным (в том числе идеологически правильным ) было бы иметь полную метаинформацию о типах во время компиляции, и при необходимости вытаскивать ее в рантайм традиционным плюсовым путем — с помощью библиотек (ну и библиотека для этого нужны бы была стандартная). Я б тогда midl куда подальше закинул...

ГВ>>+ ненадёжность (почти всегда) она от этого не избавляется.


VD>Ну, а вот это твое глубокое заблуждение. Практика показывает обратное. Решения реализованные на метаинформации обычно надежнее лобового кодирования.


Вот тут ты прав на все сто.

VD>Ты кстати тоже ратуя за шаблоны и виртуальные методы кланишь к некому универсальному решинию на базе метаинформации. Но ты почему-то считаешь, что такая информация не зашитая в код приводит к каким-то там проблемам. А это не так. Анализ в рантайме сам по себе ненадежным быть не может.


А тут — уже не прав. Анализ в компил-тайме позволяет кучу проверок переложить с программиста на компилятор, при этом будет проверен весь сгенерированный код — а в рантайме вполне можешь пару-тройку процентов редко используемого кода, анализируещего метаинформацию, оставить с ошибками.

VD>В общем, борость с метаинформацией и алгоритмами ее использующими так же бессмысленно как нелюбить Пушкина в нашей стране.


Да никто с ней в плюсах не борется. Ее, наоборот, всем не хватает Посмотри, хотя бы, на boost::mpl, если уж Александреску читать не хочешь.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[33]: Будущее C#
От: IT Россия linq2db.com
Дата: 08.07.03 12:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Если мы унаследуемся вот так:

S>MyDate — >MyConstDate — > Date — >ConstDate
S>то MyConstDate получит в подарок неконстантный интерфейс. Упс.

Почемуто у меня создаётся устойчивое впечатление, что в этой ветке не доливают...
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.07.03 12:41
Оценка:
Здравствуйте, IT, Вы писали:
IT>Почемуто у меня создаётся устойчивое впечатление, что в этой ветке не доливают...
Перечитал 8 раз. Ниче не понял.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: Будущее C#
От: WolfHound  
Дата: 08.07.03 14:15
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Можно продолжить?


Не правомерное сравнение. За рекламу люди получают деньги при чем не рискуя своей профессиональной репутацией. В данном случае я сильно сомневаюсь что ктото из них получил что либо, а вот репутация после расхваливания говна может очень сильно пострадать.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 14:20
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Не правомерное сравнение. За рекламу люди получают деньги


А ты думаешь товарищи, которые разрешили публиковать свои комментарии на обложке книжки сделали это бесплатно?

WH>при чем не рискуя своей профессиональной репутацией.


Не уверен что не рискуя.

WH>В данном случае я сильно сомневаюсь что ктото из них получил что либо,


Зря сомневаешься.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[41]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.03 14:33
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.

ГВ>>Поздравляю. Это и есть первейший признак RTTI-based дизайна. "Если есть нечто, влияющее на алгоритм..." И это ты называешь "грамотным дизайном"? По идее алгоритм всегда работает штатно, выполняясь на адаптированных для него сущностях. Да, отдельные сегменты могут варьироваться в зависимости от сущностей, но эти сегменты предоставляются самими сущностями (см. — виртуальные функции). Но сам факт выполнения этих сегментов не зависит от характера сущности или же, в случае, если он не нужен, может оптимизироваться компилятором.
AVK>Смысл твоей фразы? Чего хоть сказать хотел?

А то ты не понял?

Имеем некую функцию.

"НЕграмотный дизайн":
void SomeFunc(SomeClass *pObj1, SomeOther *pObj2)
{
  SomeValue Value;
  if (typeid(*pObj) == typeid(SomeDerivedClass))
    { Value = pObj1 -> GetSomeValue2(); }
  else
    { Value = pObj1 -> GetSomeValue(); }
    
  pObj2 -> DoMethod(Value);
}


Суть в том, что дизайн здесь нужно изменить так, чтобы убрать if (typeid(*pObj) == typeid(SomeDerivedClass)), например, введя дополнительный метод в класс SomeClass, специально для использования в функции SomeFunc:

"грамотный дизайн":
void SomeFunc(SomeClass *pObj1, SomeOther *pObj2)
{
  SomeValue Value;
  Value = pObj1 -> GetSomeValueOfSomeFunc();
  pObj2 -> DoMethod(Value);
}



ГВ>>1. Атрибуты могут быть применены, но они не могут быть обязательно применены

AVK>Зависит от компилятора.

В смысле?

ГВ>> (если не подмешивается наследование от класса, у которого определён атрибут)

AVK>А если подмешивается?

Тогда мы имеем случай исправления RTTI-based дизайна средствами поддержки полиморфизма.

ГВ>>2. Если алгоритм предполагает поиск атрибута => условность, то это уже не LSP-дизайн, => близок к кривому...

AVK>То есть все что не соответствует какому то варианту, который тебе нравится то кривое?

Почему именно "мне нравится"? Не надо сводить всё к вкусовым предпочтениям. Это вполне объективная оценка определённых характеристик дизайна.

ГВ>>Хммм... получается, что...

AVK>Получается что ты опять не хочешь признать что помимо С++ есть что то еще.

Нет, я имею ввиду не это.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[42]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.07.03 14:47
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А то ты не понял?


Нет. Потому и спросил.

ГВ>Имеем некую функцию.


ГВ>"НЕграмотный дизайн":

ГВ>
ГВ>void SomeFunc(SomeClass *pObj1, SomeOther *pObj2)
ГВ>{
ГВ>  SomeValue Value;
ГВ>  if (typeid(*pObj) == typeid(SomeDerivedClass))
ГВ>    { Value = pObj1 -> GetSomeValue2(); }
ГВ>  else
ГВ>    { Value = pObj1 -> GetSomeValue(); }
    
ГВ>  pObj2 -> DoMethod(Value);
ГВ>}
ГВ>


ГВ>Суть в том, что дизайн здесь нужно изменить так, чтобы убрать if (typeid(*pObj) == typeid(SomeDerivedClass))


Опять ты забываешь что классы могут быть не тобою написанными и без исходников, их может вобще у тебя не быть на момент разработки.

ГВ>>>1. Атрибуты могут быть применены, но они не могут быть обязательно применены

AVK>>Зависит от компилятора.

ГВ>В смысле?


В смысле тот же компилятор шарпа кое какие атрибуты контроллирует при разработке.

AVK>>То есть все что не соответствует какому то варианту, который тебе нравится то кривое?


ГВ>Почему именно "мне нравится"?


Ну а как еще объяснить то что ты считаешь единственно верным только тот вариант дизайна который тебе известен? Опять твои суждения выглядят как — вот это рулез, а остальное кривота.

ГВ>Не надо сводить всё к вкусовым предпочтениям. Это вполне объективная оценка определённых характеристик дизайна.


Пока что я никаких аргументов твоих оценок не слышал.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[35]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.03 15:44
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Просто я считаю особенности RTTI-based дизайна очевидными.

AVK>Ну считай. Не надо только говорить что использование информации о типах это безусловно кривой дизайн.

Хорошо, я готов заменить определение "...в сущности является ошибкой дизайна." как двусмысленное на "...провоцирует на дизайн, который влечёт за собой неоправданную потерю быстродействия и снижение надёжности, поскольку контроль целостности перекладывается на время исполнения."

И что от этого изменилось?

AVK>>>Хорошо, уточню формулировку — неизвестных типов дотнета.

ГВ>>OK, но откуда они там возьмутся? Либо это дотнетовские, а значит — известные типы,
AVK>Вот когда С++ научится распознавать хотя бы свои собственные типы в рантайме из чужих модулей тогда и поговорим. А пока плюсовые шаблоны даже такого не обеспечивают.

Образно выражаясь, плюсовые шаблоны "направлены" не в сторону runtime-распознавания типов, а в сторону "исключения ситуации" распознаывания.

AVK>>>Значит ты влез не в тему, потому что в начальном топике имелся ввиду именно рефлекшен в целом. Не веришь — можешь у Влада уточнить. Я тебе гарантирую что твое понятие rtti он точно не имел ввиду.

ГВ>>Знаешь, я вот думаю сейчас, а не поспешно ли я признал, что reflection и rtti — разные вещи...
AVK>Правильно думаешь. Рефлекшен это дальнейшее развитие rtti, по сути rtti доведенный до ума, так чтобы им можно было пользоваться.

Хм

ГВ>>Нет проблем. Ты приписываешь мне категоричное утверждение — "использование рефлекшена = кривой дизайн".

AVK>Я не приписываю, оно так и есть. Или ты уже от своих слов отказываешься?

Не отказываюсь. Просто они не означают того, что ты думаешь.

ГВ>>снова повторяю характерные черты RTTI-based-дизайна,

AVK>Зачем? У тебя про твой придуманный термин никто ничего и не спрашивал. Речь шла про рефлекшен в шарпе, и отсутствие онного к С++ если ты еще не понял.

Угу, и ещё о том, что отсутствие рефлекшена в C++ — его чудовищный недостаток. Я тоже считаю, что у C++ есть недостатки, но отсутствие рефлекшена в дотнетовском исполнении к ним не отношу.

ГВ>>поскольку они могут присутствовать при использовании информации из reflection. Т.е. я просто смягчаю категоричность, которую ты мне упорно навязываешь

AVK>Я тебе ничего не навязываю, я тебя цитирую. Уж извини, но никакими приемами ты не докажешь что твоя абсолютно односмысленная фраза выражала что то совсем другое.

Фраза на самом деле не "абсолютно односмысленная", поскольку содержала неопределённое понятие "в сущности".

ГВ>>и пытаюсь обратить твоё внимание на очевидный, ИМХО, факт.

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

Бесспорно.

AVK>>>То есть, памятуя о контексте твоего высказывания, ты все таки не прав.

ГВ>>Хех, если с использованием reflection можно добиться чистого LSP-compliant, то Reflection <> RTTI, если нельзя, то увы: Reflection=RTTI и я ошибся, сказав, что это разные вещи.
AVK>Твои приравнивания просто не правомерны. Рефлекшен — это технология, RTTI это принцип. Сравнивать их нельзя.

Но тем не менее:

AVK>Правильно думаешь. Рефлекшен это дальнейшее развитие rtti, по сути rtti доведенный до ума, так чтобы им можно было пользоваться.


Т.е., рефлекшен реализует rtti. Да, не только C++-rtti, да, более развитую модель, но последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[36]: Будущее C#
От: WolfHound  
Дата: 08.07.03 20:26
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Зачем? У тебя про твой придуманный термин никто ничего и не спрашивал. Речь шла про рефлекшен в шарпе, и отсутствие онного к С++ если ты еще не понял.

ГВ>Угу, и ещё о том, что отсутствие рефлекшена в C++ — его чудовищный недостаток. Я тоже считаю, что у C++ есть недостатки, но отсутствие рефлекшена в дотнетовском исполнении к ним не отношу.
А я отношу. Пусть не к чудовищьнам но к серьезным точно.

ГВ>Т.е., рефлекшен реализует rtti. Да, не только C++-rtti, да, более развитую модель, но последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti.

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

AVK>Ты упускаешь важный момент — закрытие сеттеров отнюдь не означает отсутствие публичных конструкторов, которые устанавливают все необходимые поля.

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

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


AVK>>>С чем сравнивал?


VD>>С собственными тестами. В прочем, ты должен был и сам догадаться.


AVK>Я догадался, потому и спрашивал. В твоих тестах не было с чем XmlSerializer сравнивать.


Странный ты мужик. Я тебе лично показывал. Но ты теперь до смерти будешь утверждать обратное. Это я так понимаю такой же переклин как с транзакциями в эксесе.

AVK> SoapFormatter и DataSet были явно медленнее в разы, а сравнивать с бинарными сериализаторами текстовый глупо.


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

AVK>На момент появления этого термина термина дизайн-тайм не существовало, имелось ввиду противопоставление рантайм-компайлтайм.


Гы-гы. Первые визульные среды датируются серединой 80-ых. В то время ртытыем и не пахло.

AVK>С этих позиций дизайн-тайм это безусловно тоже рантайм.


Основная разница здесь не во времени выполнения, а в доступности метоинформации другому (внешнему) коду. Например, дизайнеру. В ртти С++ только сам код может обращаться к своим метаданным. Тот же VC вынжден создавать два (!) варианта метаданных для дизайнтайма (первый для комплит-ворда, второй для отладки). В COM, Яве и дотнете к метадамнным можно боращаться не запуская на выполнение код из сборок.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 22:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Вообще-то он предостовляет механизм динамического вызова.

AVK>Это тот же самый RTTI.

В RTTI — такой функиональностью и не пахло. Более того это появилось то ли в дотнете, то ли в Яве. В том же COM-е был только IDispatch.

VD>> Ну, и еще в дотнете есть средства генерации метаданных, да и кода.

AVK>Про эмит я сразу оговорился что его не учитываем.

Главное, что в дотнете работа с метаданными есть, и она полнофункциональна. А в С++ это кастрированный урод.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 22:04
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Кстати, а VisualAssist по этому критерию чем не подходит? Большая часть того, чем он занимается — это предоставляет информацию о типах в design-time


1. Он не предаставляет метаданные, т.е. решает совершенно другие задачи.
2. Безбожно врет и глючит.

Самое смешное, что в С++ комплит-ворд лучше всего работает в менеджед проектах на обычном VS-ном механизме.

S>IMHO, в плюсах правильным (в том числе идеологически правильным ) было бы иметь полную метаинформацию о типах во время компиляции, и при необходимости вытаскивать ее в рантайм традиционным плюсовым путем — с помощью библиотек (ну и библиотека для этого нужны бы была стандартная). Я б тогда midl куда подальше закинул...


Выкидывай. В дотнете МС++ прекрасно работает без него. При этом метаданные на порядок лучше. Ну, а метаданые в компайлтайме нужный не очень сильно. sizeof-а более чем достаточно. Шаблоны и макросы позволяют делать универсальный код вообще без метаданный.

S>Вот тут ты прав на все сто.


Дык на своем животе проплз.

S>А тут — уже не прав. Анализ в компил-тайме позволяет...


Никаого анализ в компайлтайме у него небыло. Он прдлагал создавать структуры орписывающие метаинформацию и анализировать уже ее. А анализировать при компиляции особо нечего.

S> кучу проверок переложить с программиста на компилятор, при этом будет проверен весь сгенерированный код — а в рантайме вполне можешь пару-тройку процентов редко используемого кода, анализируещего метаинформацию, оставить с ошибками.


Звучит здорово. Но реально в приложениях созданных на строкомпайлтаймном С++ рантайм ошибок в разы больше чем чем созданных на шапре. Причем приложение переживает такие ошибки куда болезнеей нежели созданное на Шарпе. Короече, далеко не все можно переложить на помпилятор. Никто не спорит о том, что если это можно сделать, то лучше так и поступить. Но...

S>Да никто с ней в плюсах не борется.


А ты почитай постинги Геннадия Васильева повнимательнее.

S>Ее, наоборот, всем не хватает Посмотри, хотя бы, на boost::mpl, если уж Александреску читать не хочешь.


Дык с этим я не спорю.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 22:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Ну, это ты зря. Если шаблонами пользоваться умело и по месту,


AVK>Ключевая фраза. По месту. А вот если не по месту а для затычки дырок языка то куча вложенных шаблонов никаких положительных эмоций не вызывает.


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

Хотя конечно правильно было бы ввести в шарп недостающие фичи вроде подключения релаизации и т.п.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 22:04
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Мы-то про вполне конкретный пример кода говорили, который, на мой взгляд, одинаково прост хоть на плюсах, хоть на шарпе.


Тебе просто хочется так думть. Пару сотен килобайт такого "простого" кода и ты взывешь. Если бы небыло проблемы сложности С++, но код бы на нем писался так же шустро как на Шарпе и не приводил бы к огромному количеству ошибок. Выпендружи в стиле С — очень портят этот язык. Ну, а затычки дыр языка на шаблонах портят читабельность и замедляют компиляцию.

S>А вообще, конечно, да — но это потому, что на С++ можно некоторые более сложные вещи записать меньшим объемом кода.


Только если пользоваться макросами.

S> Тут прямая аналогия с сервер-сайд скриптом,


Это не прямая, а обратная аналогия.

VD>>А эмуляций остуствущей в функциональности на шаблонах еще больше усугубляет это положение.


S>Есть такое дело. Хотя если эту функциональность прятать в библиотеку с удобным интерфейсом, получается очень даже читабельно. Взять тот же boost::bind — внутри сущий кошмар, снаружи — лепота.


Да не очень то. Все же проще было чуть-чуть изменить язык. При этом и кашмар был бы не нужен, и код был еще более читаемым универсальным.

S>А это я не тебя спрашивал. У тебя знаний С++ поболее, тебе и вопросы другие Например, когда ты впервые узнал, что на плюсах можно посчитать факториал в компил-тайме?


Факториалы мне никтогда в жизни небыли нужны. Так что я вообще не знаю как их считать. Если ты про частичную специализацию, то она один раз мне даже пригадилась. Вот только один раз. Причем я зашел в форум по С++ и попроси, чтобы мне мой алгоритм перевели в константрный... И читать такой код ну очень не удобно. Конечно приятно, что нет лишних действий в рантайме. Но боже мой, как же нужно переворачивать мозки чтобы разглядывать алгоритм в шаблонне?!

Вот попробуй без подглядывания перевести этот алгоритм в аналогичный на базе цыкла:


template<unsigned n>
struct NBits
{
  enum { value = NBits<(n >> 1)>::value + 1 };
    static int GetBitsCount()
    {
        return NBits<n - 1>::value;
    }
};

template<>
struct NBits<0>
{
  enum { value = 0 };
};

...

    void InitCodedTokenXxx()
    {
        const Tbl tables[] =
        {
            ciTblMethod,
            ciTblMemberRef,
        };
        int iMaxCnt = m_pSchema->m_cRecs[tables[0]];
        for(int i = 1; i < GetElemCount(tables); i++)
        {
            int iCnt = m_pSchema->m_cRecs[tables[i]];
            if(iCnt > iMaxCnt)
                iMaxCnt = iCnt;
        }
        int iBits = NBits<GetElemCount(tables)>::GetBitsCount();
        int iMaxVal = iMaxCnt << iBits;
        const UINT ciMask = 0xFFFF;
        bool bSize4;
        int iSize;
        if(((UINT)(iMaxVal & ciMask)) != iMaxVal)
        {
            bSize4 = true;
            iSize = 4;
        }
        else
        {
            bSize4 = false;
            iSize = 2;
        }
    }


Поэтому. Знать я об этих приколах заню давно, но вот использовать приходится очень редкао. Ну, жалко мне мою бошку.

S> И сколько раз писал рекурсивные шаблоны? Но это так, в порядке подколки


Один!

S>Книжку Александреску прочитать тебе не зря советовали.


А может зрая?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.03 22:32
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>>Зачем? У тебя про твой придуманный термин никто ничего и не спрашивал. Речь шла про рефлекшен в шарпе, и отсутствие онного к С++ если ты еще не понял.

ГВ>>Угу, и ещё о том, что отсутствие рефлекшена в C++ — его чудовищный недостаток. Я тоже считаю, что у C++ есть недостатки, но отсутствие рефлекшена в дотнетовском исполнении к ним не отношу.
WH>А я отношу. Пусть не к чудовищьнам но к серьезным точно.

Ну, это личное дело каждого. Просто моё эмоциональное отношение к rtti и спровоцировало реплику.

ГВ>>Т.е., рефлекшен реализует rtti. Да, не только C++-rtti, да, более развитую модель, но последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti.

WH>А может просветишь? В моем проекте я очень активно использую rtti и ни каких проблем не вижу.

Это... рад за тебя.

WH>Система быстро растет как функциональнось движка так и колличество длл. Причем в основном по тому что движок не знает о конкретных длл и длл не знают что есть в движке и других длл но могут легко выяснить есть то что им надо или нет.


Значит, у тебя есть определённая система метаинформации, угу...

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

ГВ>>Суть в том, что дизайн здесь нужно изменить так, чтобы убрать if (typeid(*pObj) == typeid(SomeDerivedClass))

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

Э-э-э... немного не в кассу. Какой-либо API всегда известен или о нём договариваются заранее. Сомневаюсь, что в дотнетовском приложении ты будешь дёргать методы просто обнаружив факт их существования, игнорируя документированный API.

С другой стороны я понимаю, что ты имеешь ввиду. Заменить реализацию классов для изменения дизайна действительно может оказаться невозможно. Тут не исключено, что в каких-то случаях нечто типа rtti может оказаться единственным решением.

ГВ>>>>1. Атрибуты могут быть применены, но они не могут быть обязательно применены

AVK>>>Зависит от компилятора.
ГВ>>В смысле?
AVK>В смысле тот же компилятор шарпа кое какие атрибуты контроллирует при разработке.

Я, наверное, плохо искал, но кроме наследования, другого способа гарантировать наличие custom-атрибута не нашёл.

AVK>>>То есть все что не соответствует какому то варианту, который тебе нравится то кривое?

ГВ>>Почему именно "мне нравится"?
AVK>Ну а как еще объяснить то что ты считаешь единственно верным только тот вариант дизайна который тебе известен? Опять твои суждения выглядят как — вот это рулез, а остальное кривота.

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

Во-вторых, "единственно верного" дизайна, ИМХО, не бывает. Дизайнерские решения очень сильно зависят от условий, в которых находятся дизайнеры и их способностей принимать те или иные решения. Но это не означает, опять-таки, что тот или иной дизайн не имеет своих характерных черт и последствий, иногда — возможных, иногда — обязательных. То есть... оверхед, связанный с runtime-распознаванием типов всё равно остаётся, а при распознавании всё равно предполагается возможный отрицательный результат, а распознающие части кода всё равно могут быть раскиданы в самых неожиданных местах...


Ну и в скобочках замечу, что мне кажется, что выделенное мною твоё утверждение мягко говоря, безосновательно. Особенно с учётом того, что мы знакомы-то только по форуму. Ну это так, к слову.

ГВ>>Не надо сводить всё к вкусовым предпочтениям. Это вполне объективная оценка определённых характеристик дизайна.

AVK>Пока что я никаких аргументов твоих оценок не слышал.

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

VD>                iMaxCnt = iCnt;
VD>        }
VD>        int iBits = NBits<GetElemCount(tables)>::GetBitsCount();
VD>        int iMaxVal = iMaxCnt << iBits;
VD>        const UINT ciMask = 0xFFFF;


А GetElemCount() — это что такое? Вот такой макрос, что ли:

#define GetElemCount(x) (sizeof(x)/sizeof(x[0]))
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[31]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.07.03 23:05
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Даже "любой" объект обязан что-то делать, чтобы вместо вызовов его методов не получались сплошные throw.


VD>Попробуй еще раз прочесть о чем идет речь...


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

[...]

VD>Вообще, я не пойму зачем бароться с алгоритмами построенными на базе анализа метаинформации.


Бороться с алгоритмами бесполезно. Они сами по себе никому не мешают.

VD>В базах данных ее нарошно придумывают и хранят в системных таблицах. Компиляторы строят ее для автоматизации процесса кодирования. Что же плохого в том, что и код может иметь самоописание?


В самом по себе описании ничего плохого нет, характерные особенности подхода проявляются... ну, я уже говорил об этом необнократно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[36]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 23:12
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хорошо, я готов заменить определение "...в сущности является ошибкой дизайна." как двусмысленное на "...провоцирует на дизайн, который влечёт за собой неоправданную потерю быстродействия и снижение надёжности, поскольку контроль целостности перекладывается на время исполнения."


ГВ>И что от этого изменилось?


Очень моногое. Тепешь чтобы продемострировать, что это утверждение нужно всего лишь вспомнить, что не всегда можно осуществить контроль или анализ на стадии компиляции, так как а) данных для контроля может не быть во время компиляции, б) даныые иногда могут изменяться во времени.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 23:12
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Т.е., рефлекшен реализует rtti. Да, не только C++-rtti, да, более развитую модель, но последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti.


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

Мне уже достаточно силно надовел этот бесполезный спор. Двай я тебе покажу твой любимый С++ и его "прямой" дизайн в действии, а потом мы сравним это с аналогом на шарпе...

Вот типичный компонент созданный средствами С++ (COM):

class ATL_NO_VTABLE CTest : 
    public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CTest, &CLSID_Test>,
    public ITest1,
    public ITest2
{
public:
    CTest(){}

DECLARE_REGISTRY_RESOURCEID(IDR_TEST)

BEGIN_COM_MAP(CTest)
    COM_INTERFACE_ENTRY(ITest1)
    COM_INTERFACE_ENTRY(ITest2)
END_COM_MAP()

    DECLARE_PROTECT_FINAL_CONSTRUCT()

    HRESULT FinalConstruct(){ return S_OK; }
    
    void FinalRelease() { }
public:
    // Рабочие методы, нелизация интерфейсов ITest1 и ITest2... 
};


Надо признаться, что это красивая обертка на атл-е. Без нее код бы занимал бы раз в 10 больше места.

И главный метод (QueryInterface) выглядил бы так:

HRESULT QueryInterface(REFIID iid, void ** ppvObject)
{
    if(iid == IID_ITest1 || iid == IID_ITest2)
    {
        *ppvObject = this;
        return S_OK;
    }
    return E_NOINTERFACE;
}


А вот "кривой" дизайн (C#):
class CTest : IServiceProvider, ITest1, ITest2
{
    public object GetService(Type serviceType)
    {
        if(serviceType == typeof(ITest1) || serviceType == typeof(ITest2))
            return this;
        return null;
    }
    // Рабочие методы, нелизация интерфейсов ITest1 и ITest2... 
};


Собствнно можно и совсем универсально:

class ServiceProvider : IServiceProvider
{
    public object GetService(Type serviceType)
    {
        if(serviceType.IsAssignableFrom(this.GetType())
            return this;
        return null;
    }
};

class CTest : ServiceProvider, ITest1, ITest2
{
    // Рабочие методы, нелизация интерфейсов ITest1 и ITest2... 
};


А вот примеры использования.
С++:

CCommPtr<ITest2> spITest2;
HRESULT hr = obj->QueryInterface(__uuidof(spITest2), &spITest2);
if(hr == S_OK)
{
    // Используем сервис...
}


C#:

ITest2 test = (ITest2)obj.GetService(typeof(ITest2));
if(test != null)
{
    // Используем сервис...
}


PS

И не надо рассказывать, сказки, что можно вообще избавиться от рантайм проверок. Так как иначе это не будут компоненты (их нелзя будет создавать и использовать в рантайме).
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 23:12
Оценка:
Здравствуйте, Sinclair, Вы писали:

IT>>Почемуто у меня создаётся устойчивое впечатление, что в этой ветке не доливают...

S>Перечитал 8 раз. Ниче не понял.

Угадал все буквы не смог прочеть слово. (Это я так... на ум пришло).
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 23:58
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А GetElemCount() — это что такое? Вот такой макрос, что ли:


ГВ>
ГВ>#define GetElemCount(x) (sizeof(x)/sizeof(x[0]))
ГВ>


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

ГВ>В самом по себе описании ничего плохого нет, характерные особенности подхода проявляются... ну, я уже говорил об этом необнократно.


Ну, не стесняйся... покажи "кривоту" на пратике. Где проблемы то?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 23:58
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

WH>>А может просветишь? В моем проекте я очень активно использую rtti и ни каких проблем не вижу.


ГВ>Это... рад за тебя.


А что ты радушеся? Ты столько раз заявлял о кривоте и сетовал на ненадежность, что людям оооООочень хочется увидеть их вообчую.

ГВ>А насчёт "просветишь"... Давай, если тебе интересно, посмотрим на какую-нибудь конкретную ситуацию в которой, как ты считаешь, оправданно используется rtti. Можно приватом (мыло в профайле). Ну а я — выскажусь.


Да. Вот самая простая. Есть компонент который нужно всавлять в дизайнере (все кто говорит, что нужно лепить мапы посылаются юзерами в лес ). Поведай нам реализацию этого на своей компайл-тайм технике.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.03 23:59
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Заменить реализацию классов для изменения дизайна действительно может оказаться невозможно. Тут не исключено, что в каких-то случаях нечто типа rtti может оказаться единственным решением.


То то и оно. А еще бывают ситуации когда заменить то можно, но вот объем кодирования просто не соразмерим.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 07:11
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Я догадался, потому и спрашивал. В твоих тестах не было с чем XmlSerializer сравнивать.


VD>Странный ты мужик. Я тебе лично показывал.


Что ты мне показывал? Твои тесты я видел и неоднократно тебе говорил что делать на основе их какие либо выводы об эффективности дотнетовских xml-парсеров или XmlSerializer невозможно, просто потому что сравнивать не с чем. Вот если бы у тебя был там же тест ручной сериализации в xml то совсем другое дело. Более того — я тебе присылал результаты своего теста, где как раз была сериализация XmlSerializer автоматическая, посредством реализации IXmlSerializable и полностью ручная. Первое и третье были практически одинаковыми. Отсюда я сделал вывод что эффективность XmlSerializer весьма неплохая.

VD>Но ты теперь до смерти будешь утверждать обратное.


Ты так и не привел логической цепочки каким ты образом на основании своих тестов пришел к выводу о неэффективности XmlSerializer.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 07:11
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>На момент появления этого термина термина дизайн-тайм не существовало, имелось ввиду противопоставление рантайм-компайлтайм.


VD>Гы-гы. Первые визульные среды датируются серединой 80-ых. В то время ртытыем и не пахло.


Они может и существовали, но на момент появления rtti в плюсах в тех же плюсах никакого дизайн-тайма не было.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[35]: Будущее C#
От: _vovin http://www.pragmatic-architect.com
Дата: 09.07.03 07:28
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>На момент появления этого термина термина дизайн-тайм не существовало, имелось ввиду противопоставление рантайм-компайлтайм.


VD>>Гы-гы. Первые визульные среды датируются серединой 80-ых. В то время ртытыем и не пахло.


Будьте осторожнее с такими утверждениями.
Еще в 75-ом была среда, в которой все было ран-тайм, никаким другим таймом и не пахло.

AVK>Они может и существовали, но на момент появления rtti в плюсах в тех же плюсах никакого дизайн-тайма не было.


Бросьте дурное, кончайте бесполезный спор.

--

Владимир.
Re[36]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 07:31
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хорошо, я готов заменить определение "...в сущности является ошибкой дизайна." как двусмысленное на "...провоцирует на дизайн, который влечёт за собой неоправданную потерю быстродействия и снижение надёжности, поскольку контроль целостности перекладывается на время исполнения."


ГВ>И что от этого изменилось?


Опять какой то налет необъективности. Почему провоцирует? Я ведь точно так же могу сказать что шаблоны провоцируют создание некомпонентных слабоконфигурируемых приложений.

AVK>>Вот когда С++ научится распознавать хотя бы свои собственные типы в рантайме из чужих модулей тогда и поговорим. А пока плюсовые шаблоны даже такого не обеспечивают.


ГВ>Образно выражаясь, плюсовые шаблоны "направлены" не в сторону runtime-распознавания типов, а в сторону "исключения ситуации" распознаывания.


Вот ты уперся и ничего не хочешь видеть. Еще раз повторяю — наличие или отсутствие такой ситуации никак не зависит от тебя. Если тебе нужно использовать сторонний компонент без исходников то хоть на голове стой — все равно никак rtti ты шаблонами не заменишь.

ГВ>>>Нет проблем. Ты приписываешь мне категоричное утверждение — "использование рефлекшена = кривой дизайн".

AVK>>Я не приписываю, оно так и есть. Или ты уже от своих слов отказываешься?

ГВ>Не отказываюсь. Просто они не означают того, что ты думаешь.


Это демагогия. Я тебе уже объяснял — смысл у твоей фразы один. Все кто читает этот топик именно так его и восприняли. Да и разъяснять смысл, который ты якобы имел ввиду ты стал далеко не сразу, сначала ты доказывал что именно любое использование rtti суть кривой дизайн.

ГВ>Угу, и ещё о том, что отсутствие рефлекшена в C++ — его чудовищный недостаток.


Так и есть. В его отсутствие приходиться рожать ужасных монстров вроде СОМ. Достаточно сравнить любой СОМ-класс и аналогичный ему класс дотнета и сразу все становиться понятно. Ты конечно опять будешь возражать, мол это просто СОМ такой кривой, но вот тебе пример:

[Serializable]
public class TestClass
{
    private string _someData;
    
    public TestClass(string someData)
    {
        _someData = someData;
    }
    
    public string SomeData
    {
        get { return _someData; }
    }
}


А вот теперь напиши аналогичный класс на плюсах, так чтобы он:
1) Мог использоваться отдельно в любом проекте без исходных кодов
2) Мог сериализоваться в бинарный поток и xml
3) Его экземпляр можно было бы передать по сети
4) Обеспечивался бы контроль версий класса
5) Можно было бы создать экземпляр по имени
6) Можно было бы визуально отредактировать его свойства.
Вот когда напишешь тогда и сравним. Результаты я думаю будут забавными

AVK>>Я тебе ничего не навязываю, я тебя цитирую. Уж извини, но никакими приемами ты не докажешь что твоя абсолютно односмысленная фраза выражала что то совсем другое.


ГВ>Фраза на самом деле не "абсолютно односмысленная", поскольку содержала неопределённое понятие "в сущности".


Опять ты пытаешься перевести спор на термины. В общем неубедительно.

AVK>>Твои приравнивания просто не правомерны. Рефлекшен — это технология, RTTI это принцип. Сравнивать их нельзя.


ГВ>Но тем не менее:


ГВ>Т.е., рефлекшен реализует rtti.


Да. Где здесь противоречие?
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[38]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 07:31
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А насчёт "просветишь"... Давай, если тебе интересно, посмотрим на какую-нибудь конкретную ситуацию в которой, как ты считаешь, оправданно используется rtti. Можно приватом (мыло в профайле). Ну а я — выскажусь.


Зачем же приватом, давай уж здесь.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 07:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Вообще-то он предостовляет механизм динамического вызова.

AVK>>Это тот же самый RTTI.

VD>В RTTI — такой функиональностью и не пахло.


rtti != реализация rtti в С++. В дельфи к примеру оно тоже называется rtti.

VD>Более того это появилось то ли в дотнете, то ли в Яве.


Ну уж не в дотнете точно.

VD> В том же COM-е был только IDispatch.


Ну так это оно и есть.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[34]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 07:31
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Ключевая фраза. По месту. А вот если не по месту а для затычки дырок языка то куча вложенных шаблонов никаких положительных эмоций не вызывает.


VD>Полностью соглаен. Прада согласен и с тем, что дырки есть в любых сзыках. Шарп по-мне так значительно менее дыряв чем плюсы, но тем не менее кое-чего не хватает.


Кто бы спорил.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[44]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 07:41
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Э-э-э... немного не в кассу. Какой-либо API всегда известен или о нём договариваются заранее.


Вот только этот самый API либо flat либо COM, что как понимаешь не фонтан.

ГВ>Сомневаюсь, что в дотнетовском приложении ты будешь дёргать методы просто обнаружив факт их существования, игнорируя документированный API.


Да запросто. Например для той же сериализации.

ГВ>С другой стороны я понимаю, что ты имеешь ввиду. Заменить реализацию классов для изменения дизайна действительно может оказаться невозможно. Тут не исключено, что в каких-то случаях нечто типа rtti может оказаться единственным решением.


Ну наконец то.

AVK>>В смысле тот же компилятор шарпа кое какие атрибуты контроллирует при разработке.


ГВ>Я, наверное, плохо искал, но кроме наследования, другого способа гарантировать наличие custom-атрибута не нашёл.


Ну попробуй к примеру не указать для енума атрибут Flags и потом попробовать использовать его в бинарных операциях. Посмотришь что тебе компилятор скажет. Или попробуй неуказать DllImport для extern метода.

AVK>>Ну а как еще объяснить то что ты считаешь единственно верным только тот вариант дизайна который тебе известен? Опять твои суждения выглядят как — вот это рулез, а остальное кривота.


ГВ>Во-первых, я уже скорректировал своё утверждение об "ошибке" дизайна,


И сделал новое, ничуть не лучше.

Если алгоритм предполагает поиск атрибута => условность, то это уже не LSP-дизайн, => близок к кривому...


То есть если не LSP то криво.

ГВ>Во-вторых, "единственно верного" дизайна, ИМХО, не бывает.


Во, золотые слова. Если бы ты еще сам свои же утверждения помнил. А то единственно верного не бывает, но если не LSP то близок к кривому .
Да, расшифровал бы что ли.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[37]: Будущее C#
От: Sergey Россия  
Дата: 09.07.03 08:02
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Мы-то про вполне конкретный пример кода говорили, который, на мой взгляд, одинаково прост хоть на плюсах, хоть на шарпе.


VD>Тебе просто хочется так думть. Пару сотен килобайт такого "простого" кода и ты взывешь.


Ну не взвыл пока Хотя сплошь и рядом такой код использую. Вот компилятор время от времени воет...

VD>Если бы небыло проблемы сложности С++, но код бы на нем писался так же шустро как на Шарпе и не приводил бы к огромному количеству ошибок.


Ну, лично у меня плюсовый код пишется быстрее и содержит меньше ошибок, чем код, который я пишу на шарпе. Так что давай без голословных утверждений.

VD>Выпендружи в стиле С — очень портят этот язык. Ну, а затычки дыр языка на шаблонах портят читабельность и замедляют компиляцию.


Вот компиляцию замедляют — это да. Еще и отладка сильно усложняется.
А насчет читабельности... Ну вот, например, кусок кода:

template<class F> void SetupDrawingDC(wxDC &dc, const GenericArea &area, F func)
{
    wxBrush OldBrush = dc.GetBrush();
    wxPen OldPen = dc.GetPen();
    const wxFont OldFont = dc.GetFont();
    wxColour OldTextColor = dc.GetTextForeground();
    try
    {
        wxBrush br(*wxLIGHT_GREY, wxSOLID);
        br.SetColour(area.BackColour());
        dc.SetBrush(br);

        if (area.Font().Ok())
            dc.SetFont(area.Font());
        dc.SetTextForeground(area.TextColour());
        func(dc);
    } catch (const exception& e)
    {
        const wxRect &rc_area = area.Rect();
        dc.DrawText(e.what() , rc_area.GetX(), rc_area.GetY());
    }
    dc.SetTextForeground(OldTextColor);
    dc.SetBrush(OldBrush);
    dc.SetPen(OldPen);
    dc.SetFont(OldFont);
}

void CAreaDrawer::Draw(wxDC &dc)
{ SetupDrawingDC(dc, m_area, boost::bind(&CAreaDrawer::InternalDraw, this, _1)); }

void CAreaDrawer::FlashDraw(wxDC &dc)
{ SetupDrawingDC(dc, m_area, boost::bind(&CAreaDrawer::_FlashDraw, this, _1)); }

void CAreaDrawer::DrawTip(wxDC &dc, const wxPoint &pt)
{ SetupDrawingDC(dc, m_area, boost::bind(&CAreaDrawer::_DrawTip, this, _1, pt)); }

bool CAreaDrawer::BeginDrag(wxDC &dc, const wxPoint &pt, std::vector<DragStruct> &drags)
{
    bool retval = false;
    using boost::ref;
    SetupDrawingDC(dc, m_area, boost::bind(&CAreaDrawer::_BeginDrag, this, _1, pt, ref(drags), ref(retval)));
    return retval;
}

void CAreaDrawer::_FlashDraw(wxDC &dc) { чегото рисуем }
void CAreaDrawer::_DrawTip(wxDC &dc, const wxPoint &pt) { чето рисуем }
void CAreaDrawer::_BeginDrag(wxDC &dc) { чето делаем }


Что, сильно он в читаемости от использования boost::bind и шаблонов проиграл? Или наоборот, выиграл? А в сопровождаемости?

S>>А вообще, конечно, да — но это потому, что на С++ можно некоторые более сложные вещи записать меньшим объемом кода.


VD>Только если пользоваться макросами.


Макросы тоже бывают полезны. Но значительно реже, чем шаблоны.

S>> Тут прямая аналогия с сервер-сайд скриптом,


VD>Это не прямая, а обратная аналогия.


Поясни.

VD>>>А эмуляций остуствущей в функциональности на шаблонах еще больше усугубляет это положение.


S>>Есть такое дело. Хотя если эту функциональность прятать в библиотеку с удобным интерфейсом, получается очень даже читабельно. Взять тот же boost::bind — внутри сущий кошмар, снаружи — лепота.


VD>Да не очень то. Все же проще было чуть-чуть изменить язык. При этом и кашмар был бы не нужен, и код был еще более читаемым универсальным.


А кто с этим спорит? __closure, или как она там называется, давно пора в язык. И какой-нибудь способ компил-тайм енумерации членов класса лично мне тоже очень бы пригодился. Однако возможность на ходу создать функтор с двумя аргументами вместо функции с четырьмя, предоставляемая bind'ом, пусть лучше остается в библиотеке.

VD>Факториалы мне никтогда в жизни небыли нужны.


Ну вообще можно и синус так посчитать, но компиляться дооолго будет Просто знать о такой возможности полезно.

VD>Так что я вообще не знаю как их считать. Если ты про частичную специализацию, то она один раз мне даже пригадилась.


При чем здесь частичная специализация? Для написания рекурсивных шаблонов обычно вполне хватает полной специализации. Хотя, конечно, часто код в отсутствии поддержки частичной специализации компилятором получается сложнее, чем с частичной специализацией. Но все равно — получается.

VD>Вот только один раз. Причем я зашел в форум по С++ и попроси, чтобы мне мой алгоритм перевели в константрный... И читать такой код ну очень не удобно.


Вот я говорю — не привык.

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


Это по первости только. Да и не сложнее оно, оно просто непривычное.

VD>Вот попробуй без подглядывания перевести этот алгоритм в аналогичный на базе цыкла:


VD>
VD>template<unsigned n>
VD>struct NBits
VD>{
VD>  enum { value = NBits<(n >> 1)>::value + 1 };
VD>    static int GetBitsCount()
VD>    {
VD>        return NBits<n - 1>::value;
VD>    }
VD>};
VD>template<>
VD>struct NBits<0>
VD>{
VD>  enum { value = 0 };
VD>};
VD>


Я так понял, тебя только этот кусок кода интересовал?
Ну тогда так:

int GetBitsCount(int n)
{
int nb = 0;
for (int i = n — 1; i > 0; i = i >> 1)
nb += 1;
return nb;
}

А смысл в таком преобразовании? Алгоритм что, понятней от этого стал, что ли?

VD>Поэтому. Знать я об этих приколах заню давно, но вот использовать приходится очень редкао. Ну, жалко мне мою бошку.


А некоторым жалко бошку с указателями работать Про них еще Дейкстра кажись писал.

S>> И сколько раз писал рекурсивные шаблоны? Но это так, в порядке подколки


VD>Один!


Ну хоть что-то.

S>>Книжку Александреску прочитать тебе не зря советовали.


VD>А может зрая?


Не, не зря. Там новый (ну не для всех, конечно, он новый) подход к шаблонным извращениям описан.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[36]: Будущее C#
От: WolfHound  
Дата: 09.07.03 08:47
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Варинат 1: Возвращую копию массива.

VD>Варинат 2: Возвращую этумератор (IEnumerable).
VD>Аариант 3: Возвращу обертку реализаующиую индексатор и дургие методы и свойства позволяющие только читать этот массив.

VD>Короче, тут проблем нет.

Это криво...
Это затычки....
Узнаешь себя?
А если поискать то я уверен можно еще много мест найти где на плюсах все проще.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Будущее C#
От: WolfHound  
Дата: 09.07.03 08:47
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А насчёт "просветишь"... Давай, если тебе интересно, посмотрим на какую-нибудь конкретную ситуацию в которой, как ты считаешь, оправданно используется rtti. Можно приватом (мыло в профайле). Ну а я — выскажусь.

Например в моем случае есть куча железок с логической точки зрения идентичных(один интерфейс), а вот реализация работы сильно разная. Причем у одного заказчика один набор типов железок у дугого другой у сотого сотый. Причем ни кто не застрахован что завтра не появится логически новая железка.

Было принято решение одна железка-одна длл (хотя в принципе возможно разложить по нескольким или общие части для нескольких железок вынести в другую длл) но в длл лежит не только работа с железкой но и визуализация(возможно несколько) и формы настройки и... Хардкорить функции экспорта нельзя(помним о новых логических типах). Короче ехешник это абстрактная фабрика классов создающея объекты по имени типа возвращать она может только I_Object, а к конкретному интерфейсу приводим на месте через dynamic_cast.

В .NET это можно сделать несколько проще(но не сильно).
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 09:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Это криво...

WH>Это затычки....

Это нормальный дизайн. А вот const парметры это действительно криво
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[38]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.07.03 11:22
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Это нормальный дизайн. А вот const парметры это действительно криво

Этот нормальный дизайн приводит к серьезным потерям в производительности. Вот зашибись, давайте копировать массив в пару тысяч элементов только ради того, чтобы быть спокойными, что никто его не изменит.
Вариант с енумератором вроде ничего себе. Вот только я не могу понять, как он работает. Ну взяли мы Current. Кто нам запретит вызвать на этом Current неконстантный метод? Или там тоже копирование выполняется? Ну, тогда это то же вид сбоку.
Единственный нормальный метод — это, вроде как, создание обертки. Я над ним еще подумаю. Очевидно, что без iniline
подстановок это даст свои накладные расходы, хотя и небольшие.

Единственное, что я хотел бы понять, это чем тебя не устраивает const?
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Будущее C#
От: Аноним  
Дата: 09.07.03 11:47
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>У сана вобще очень странная политика, больше похожая на политику комитета по плюсам. Они с радостью стандартизируют библиотеки, причем выделяя на доведение этих библиотек своих спецов, но вот когда дело заходит об изменении языка и jvm то они упираются рогом.


Сполне нормальная политика. Есть стандарты, которые работают многие годы. И если уж написали, то будет собираться и работать всегда и у всех. И не надо каждые полгода грузить себе громадный фреймворк.
Re[39]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 11:50
Оценка:
Здравствуйте, Sinclair, Вы писали:

AVK>>Это нормальный дизайн. А вот const парметры это действительно криво

S>Этот нормальный дизайн приводит к серьезным потерям в производительности.

А реализация const-параметров в дотнете не приведет к потере производительности?

S>Вот зашибись, давайте копировать массив в пару тысяч элементов только ради того, чтобы быть спокойными, что никто его не изменит.


Зачем копировать? Сделать readonly обертку.

S>Вариант с енумератором вроде ничего себе. Вот только я не могу понять, как он работает. Ну взяли мы Current. Кто нам запретит вызвать на этом Current неконстантный метод?


А тут тебе и const-параметры не помогут. Мало ли что в Current сидит — компилятор об этом ничего знать не может.

S>Единственное, что я хотел бы понять, это чем тебя не устраивает const?


Как то не очень оно выглядит в условиях компонентной среды. Так же как и плюсовые шаблоны, которые в чистом виде для дотнета не годятся.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[40]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.07.03 13:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>Это нормальный дизайн. А вот const парметры это действительно криво

S>>Этот нормальный дизайн приводит к серьезным потерям в производительности.

AVK>А реализация const-параметров в дотнете не приведет к потере производительности?

Не понимаю. Модификатор const — он же только в Compile-Time.
AVK>А тут тебе и const-параметры не помогут. Мало ли что в Current сидит — компилятор об этом ничего знать не может.
Это еще почему? Если у меня Current возвращает константную ссылку, то я не смогу по ней вызвать неконстантный метод.
AVK>Как то не очень оно выглядит в условиях компонентной среды. Так же как и плюсовые шаблоны, которые в чистом виде для дотнета не годятся.
Да почему? Я этого хоть убей не пойму. Ну объясните мне наконец, почему const мешает компонентной среде?
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 14:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

AVK>>А реализация const-параметров в дотнете не приведет к потере производительности?

S>Не понимаю. Модификатор const — он же только в Compile-Time.

А толку от него в compile-time? Какое то незаконченное решение выходит.

AVK>>А тут тебе и const-параметры не помогут. Мало ли что в Current сидит — компилятор об этом ничего знать не может.

S>Это еще почему? Если у меня Current возвращает константную ссылку, то я не смогу по ней вызвать неконстантный метод.

А если Current возвращает некий класс, который потом приводится к другому? А если методы через рефлекшен зовут? А если для некоего интерфейса реализация метода М в одном классе константная, а в другом неконстантная?

S>Да почему? Я этого хоть убей не пойму.


Да потому что дотнету необходимо чтобы сущность существовала в рантайме, иначе толку от этих шаблонов никакого.

S>Ну объясните мне наконец, почему const мешает компонентной среде?


Он не мешает, но его реализация окажет заметное влияние на производительность, так как проверять необходимо не компилятору а рантайму.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[42]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.07.03 14:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А если Current возвращает некий класс, который потом приводится к другому? А если методы через рефлекшен зовут? А если для некоего интерфейса реализация метода М в одном классе константная, а в другом неконстантная?

Ага, вот тут уже начинается интерестность. Ну, во-первых, приведение константной ссылки к неконстантной — запрещено. Поэтому никакого косяка не возникает.
При рефлекшне — это да. Но ведь я же не могу вызвать приватный метод через рефлекшн? Тогда и с констами проблем не будет. Ну, будет лишняя проверка того, на чем мы вызываем.
А вот про реализации — извините! const — это часть сигнатуры. Тs же не спрашиваешь "А если для некоего интерфейса реализация метода М в одном классе возвращает int, а в другом string?".
AVK>Да потому что дотнету необходимо чтобы сущность существовала в рантайме, иначе толку от этих шаблонов никакого.
Ну и прекрасно. Я, правда, не понял, при чем тут шаблоны... Никто не мешает const существовать и в рантайме.
AVK>Он не мешает, но его реализация окажет заметное влияние на производительность, так как проверять необходимо не компилятору а рантайму.
Да не будет никакого влияния на производительность! Большая часть проверок выполняется в компайл-тайме. Касты и так проверяются в рантайме, и дополнительная проверка на конст/неконст никак не изменит ситуацию.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.07.03 14:55
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Т.е., рефлекшен реализует rtti. Да, не только C++-rtti, да, более развитую модель, но последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti.


VD>Приведи, плиз, хотя бы один пример печального использования ртти.


Не повторяй моей ошибки с неоднозначно трактуемым утверждением. Я не характеризовал последствия в системе "печальный-радостный".

VD>Я уже не говорю о рефлекшоне. Хотя можешь залезьт в Хоум и нарыть пример от туда.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[43]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.07.03 15:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ага, вот тут уже начинается интерестность. Ну, во-первых, приведение константной ссылки к неконстантной — запрещено. Поэтому никакого косяка не возникает.


Одну ссылку присвоили другой, другую привели.

S>При рефлекшне — это да. Но ведь я же не могу вызвать приватный метод через рефлекшн?


Почему не можешь? Вполне.

S>А вот про реализации — извините! const — это часть сигнатуры. Тs же не спрашиваешь "А если для некоего интерфейса реализация метода М в одном классе возвращает int, а в другом string?".


Нет, ты не понял. Входной параметр это некий интерфейс и его ты объявляешь const. Или ты только про value-типы?

AVK>>Да потому что дотнету необходимо чтобы сущность существовала в рантайме, иначе толку от этих шаблонов никакого.

S>Ну и прекрасно. Я, правда, не понял, при чем тут шаблоны... Никто не мешает const существовать и в рантайме.

Не мешает, как не мешает решать проблему тем путем про который я говорил. Заодно дизайн будет более прозрачным.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[44]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.07.03 15:22
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Одну ссылку присвоили другой, другую привели.
Ниче не понимаю. Ну вот в плюсах же нет этой проблемы, так? Нельзя ни присвоить, ни привести константную ссылку неконстантной. Приведи пример того, что ты имеешь в виду.
AVK>Почему не можешь? Вполне.
Хм. Во как. А метод не того, извините, класса, я вызвать могу? Там же вроде как проверяется, что объект позволяет вызывать этот метод.
AVK>Нет, ты не понял. Входной параметр это некий интерфейс и его ты объявляешь const. Или ты только про value-типы?
Ну. Объявляю.
Вот есть у меня интерфейс
interface ISome {
  int GetProperty() const;
    void SetProperty(int v);
}

пусть теперь у кого-то будет метод

void XXX::SomeMethod(const ISome some)
{
    some.GetProperty(); // ok
    some.SetProperty(5); // нельзя. 
}

В чем проблема-то?

AVK>Не мешает, как не мешает решать проблему тем путем про который я говорил. Заодно дизайн будет более прозрачным.

Не вижу ничего прозрачного в необходимости делать так:
class ISomeConstWrapper {
private
  ISome _wrapped;
public
  ISomeConstWrapper(ISome wrapped) {}
  int GetProperty() {return _wrapped.GetProperty();}
}
void XXX::SomeMethod(ISomeConstWrapper some)
{
...
}

Потому, что код этих враппров будет до жути однообразным. Кроме того, нет никакой гарантии того, что на самом деле метод GetProperty не нарушает своего обещания не трогать объект. В плюсах ха этим следит копилятор.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[39]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.07.03 16:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Например в моем случае есть куча железок с логической точки зрения идентичных(один интерфейс), а вот реализация работы сильно разная. Причем у одного заказчика один набор типов железок у дугого другой у сотого сотый. Причем ни кто не застрахован что завтра не появится логически новая железка.


Очень неплохие вводные.

WH>Было принято решение одна железка-одна длл (хотя в принципе возможно разложить по нескольким или общие части для нескольких железок вынести в другую длл) но в длл лежит не только работа с железкой но и визуализация(возможно несколько) и формы настройки и...


Хммм, любопытно...

WH>Хардкорить функции экспорта нельзя(помним о новых логических типах).


Здесь немного не понял: экспорта чего и куда?

WH>Короче ехешник это абстрактная фабрика классов создающея объекты по имени типа возвращать она может только I_Object, а к конкретному интерфейсу приводим на месте через dynamic_cast.


Т.е., грубо говоря, примерно так:

1. Пользователь выбирает из списка некое устройство, из имеющихся в системе;
2. Имя, соответствующее этому устройству передаётся фабрике, реализованной в exe-шнике, которая создаёт объект нужного типа, возвращая I_Object*;
3. Полученный I_Object* передаётся куда-то (скорее всего — в длл, реализующую обработку, специфичную этому устройству), где из него посредством dynamic_cast<> получается какой-нибудь I_IBM_Device*.

Если я прав, то два вопроса:
— Как реализовано заполнение фабрики?
— Каким образом на шаге 3 определяется класс или функция, которая обрабатывает специфику;

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

VD>>При этом метаданные на порядок лучше. Ну, а метаданые в компайлтайме нужный не очень сильно. sizeof-а более чем достаточно.

S>Кому как. Мне так и typeof нужен, и список членов класса, и граф наследования. А дальше уж я б на них шаблоны бы натравил.
Ну еще надо auto, template typedef, ... Также былобы не плохо упразнить маразмы которые там на кождом шагу. Просто мне уже смешно смотреть на то что глюки (а глюки ли? ) VC++ позволяют писать болие простой код чем стандарт.

S>Если б С++ была возможность получить хотя бы список членов класс и перебрать предков класса (в компил-тайме, само собой), сгенерить код сериализации класса на С++ не совтавляло бы почти никакого труда.

+1
S>Пока же приходится для такого перебора изгаляться по всякому. Самое обидное, что у компилятора эта информация есть, но он ей ни за что не поделится...
+1 вот гад.

VD>>Звучит здорово. Но реально в приложениях созданных на строкомпайлтаймном С++ рантайм ошибок в разы больше чем чем созданных на шапре.

S>Ну это у кого как.
Во-во.

S>Есть живучесть, а есть надежность. Живучесть у шарпного кода может и выше, а вот с надежностью все не так однозначно.

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

ГВ>1. Пользователь выбирает из списка некое устройство, из имеющихся в системе;

Да.
ГВ>2. Имя, соответствующее этому устройству передаётся фабрике, реализованной в exe-шнике, которая создаёт объект нужного типа, возвращая I_Object*;
Да.
ГВ>3. Полученный I_Object* передаётся куда-то (скорее всего — в длл, реализующую обработку, специфичную этому устройству), где из него посредством dynamic_cast<> получается какой-нибудь I_IBM_Device*.
Нет полученый I_Object и есть указатель на конкретную реализацию и он по средствам dynamic_cast приводится к конкретному интерфейсу.
А выглядит это примерно так
if(Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorName))
{
}

CreateObject пинает ехешник и приводит к нужному нам интерфейсу.

ГВ>Если я прав, то два вопроса:

ГВ>- Как реализовано заполнение фабрики?
Грубо говоря из длл экспортируется только одна функция которая возвращает енумератор содержащихся в ней классов за одно в нее передается указатель на обьект который содержит в себе фабрику классов, механизм асинхронных вызовов и многое другое.
Для того чтобы создать фабрику и добавить ее в енумератор надо лишь прописать имя класса в карте экспорта

DLL_EXPORT_MAP_BEGIN()
    DLL_EXPORT_CLASS(C_MyCoolSensor)
    DLL_EXPORT_SINGLETON_CLASS(C_MyCoolSingleton)
DLL_EXPORT_MAP_END()
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.07.03 16:44
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>И что от этого изменилось?

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

Насчёт внешних объектов я уже говорил здесь
Автор: Геннадий Васильев
Дата: 06.07.03
. И ещё раз повторился рядом
Автор: Геннадий Васильев
Дата: 09.07.03
— в дискусси с AVK. Суть здесь — не в обработке внешних по отношению к моей программе данных, а в организации моей программы.

PS

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

ГВ>>В самом по себе описании ничего плохого нет, характерные особенности подхода проявляются... ну, я уже говорил об этом необнократно.


VD>Ну, не стесняйся... покажи "кривоту" на пратике. Где проблемы то?


А runtime-casting — не особенность? А оверхед, связанный с этим — не особенность?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[43]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.07.03 16:57
Оценка:
Здравствуйте, VladD2, Вы писали:

Извини, блее детально я прокомментриую твоё сообщение чуть позже, меня вот это свалило со стула:

VD>И не надо рассказывать, сказки, что можно вообще избавиться от рантайм проверок. Так как иначе это не будут компоненты (их нелзя будет создавать и использовать в рантайме).


Э-э-э... раскрываю страшную тайну:

class Component {...}; // Объявление интерфейса
Component *pComp = CreateNewComponent(Parameter); // О, чудо!


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

ГВ>А runtime-casting — не особенность? А оверхед, связанный с этим — не особенность?

Очень часто это оправдано, а иногда не заменимо.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.07.03 18:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>А runtime-casting — не особенность? А оверхед, связанный с этим — не особенность?

WH>Очень часто это оправдано, а иногда не заменимо.

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

ГВ>>3. Полученный I_Object* передаётся куда-то (скорее всего — в длл, реализующую обработку, специфичную этому устройству), где из него посредством dynamic_cast<> получается какой-нибудь I_IBM_Device*.

WH>Нет полученый I_Object и есть указатель на конкретную реализацию и он по средствам dynamic_cast приводится к конкретному интерфейсу.
WH>А выглядит это примерно так
WH>
WH>if(Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorName))
WH>{
WH>}
WH>

WH>CreateObject пинает ехешник и приводит к нужному нам интерфейсу.

Здесь немного поподробнее, плз. CreateObject<>() как я понял, реализован в exe-шнике. Далее он обращается к конкретному синглтону (например — C_MyCoolSingleton), который создаёт объект Sensor. Ну там понятно: карта, по которой отображается sensorName на конкретный синглтон и т.п.

А где выполняется dynamic_cast<>()? В exe-шнике? В библиотеке, реализующей связь с конкретной железкой? В других DLL? Из твоих слов пока получается, что в exe-шнике, но всё равно как-то непонятно, а это довольно-таки важно в контексте нашего обсуждения.

Мне просто нужно понять структуру зависимостей модулей. Если вызов dynamic_cast<C_MyCoolSensor> есть в исходниках exe-шника, и других библиотеках, это одно, а если только в библиотеках сенсоров, то — другое.

И ещё вопрос:
ГВ>>- Как реализовано заполнение фабрики?
WH>Грубо говоря из длл экспортируется только одна функция которая возвращает енумератор содержащихся в ней классов за одно в нее(Выделено мной, — ГВ.) передается указатель на обьект который содержит в себе фабрику классов, механизм асинхронных вызовов и многое другое.

Вот тут тоже немного не понятно: указатель на объект, содержащий фабрику классов передаётся в экспортируемую функцию? Логично было бы предположить, что указатель передаётся из неё...

WH>Для того чтобы создать фабрику и добавить ее в енумератор надо лишь прописать имя класса в карте экспорта


WH>
WH>DLL_EXPORT_MAP_BEGIN()
WH>    DLL_EXPORT_CLASS(C_MyCoolSensor)
WH>    DLL_EXPORT_SINGLETON_CLASS(C_MyCoolSingleton)
WH>DLL_EXPORT_MAP_END()
WH>


Как я понимаю, классы сенсоров содержат дополнительно методы типа C_MyCoolSensor::GetUserReadableName()?

Ещё, ты говорил, что библиотеки содержат формы настройки. Формы просто в виде модальных диалогов или в виде чего-то типа PropertyPage? В смысле — они встраиваются в какой-то оборачивающий диалог или показываются независимо?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[44]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Э-э-э... раскрываю страшную тайну:


ГВ>
ГВ>class Component {...}; // Объявление интерфейса
ГВ>Component *pComp = CreateNewComponent(Parameter); // О, чудо!
ГВ>


ГВ>)


Будь любезен. Обяви свой компонент в другой длл-ке.

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

VD>>Ну, не стесняйся... покажи "кривоту" на пратике. Где проблемы то?


ГВ>А runtime-casting — не особенность? А оверхед, связанный с этим — не особенность?


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

S>Этот нормальный дизайн приводит к серьезным потерям в производительности. Вот зашибись, давайте копировать массив в пару тысяч элементов только ради того, чтобы быть спокойными, что никто его не изменит.


А типа const неля послать к чертям?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ну, лично у меня плюсовый код пишется быстрее и содержит меньше ошибок, чем код, который я пишу на шарпе. Так что давай без голословных утверждений.


Хорошие у тебя нервы.

S>Вот компиляцию замедляют — это да. Еще и отладка сильно усложняется.

S>А насчет читабельности... Ну вот, например, кусок кода:...

Это еще не клинический случай. Бывает куд страшнее. Хтя даже этот код на шарпе был бы короче и понятнее.

S>Что, сильно он в читаемости от использования boost::bind и шаблонов проиграл? Или наоборот, выиграл? А в сопровождаемости?


Скорее выигрыл. Так как без буста тут бы было еще строк 30-40 кода. Но вот в скорости компиляции проиграл сильно. Ведь если были бы делегаты, то все тоже самое стало бы проще и быстрее.

S>Макросы тоже бывают полезны. Но значительно реже, чем шаблоны.


Шаблонами можно только универсальный код создавать. Это конечно очень часто удобнее. Макросы же позволят творить поистине чудеса, вот только какой ценой. Не даром на них многие бочку катят.

VD>>Это не прямая, а обратная аналогия.


S>Поясни.


Что? Что такое обратная аналогия?

http://www.i-u.ru/biblio/arhiv/books/chelpanov_ul/ec24.asp
Ну, и в ya.ru на слова "обратная аналогия" и демагогия.

S>А кто с этим спорит? __closure, или как она там называется, давно пора в язык.


Ты тему внимательно читал? Тут именно с этим и спорят. А еще (и это самое противное) с этим спорят разные Страуструпы и другие хранители традиций из ANSI.

S>Ну вообще можно и синус так посчитать, но компиляться дооолго будет Просто знать о такой возможности полезно.


Я знаю. Значит могу спать спокойно. Мало ли о чем можно знать. Главное нужно оно мне или нет.

S>При чем здесь частичная специализация? Для написания рекурсивных шаблонов обычно вполне хватает полной специализации. Хотя, конечно, часто код в отсутствии поддержки частичной специализации компилятором получается сложнее, чем с частичной специализацией. Но все равно — получается.


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

S>Вот я говорю — не привык.


И не хочу привыкать. Я бы с большим удовольстивием получил бы в свое распоряжение некий идентификатор типа: const_calc — заставляющий код просчитывать значиния в компайлтайме. Но этого в плюсах нет. Честно говоря я этого вообще нигде не видел.

S>Это по первости только. Да и не сложнее оно, оно просто непривычное.


Ага. Это прям цитата из Матрицы: "я поначалу тоже видел код, а теперь мен грезятся девушки..."

S>А смысл в таком преобразовании? Алгоритм что, понятней от этого стал, что ли?


А то нет? Или читать эзопов язык это щастье?

S>А некоторым жалко бошку с указателями работать Про них еще Дейкстра кажись писал.


Вот практика и показывает, что без указателей можно очено даже эффективно объодиться. А там где можно без них, то луче без них. От указателей кроме гемороя мало чего можно получить. Есть конечно обласи, где без них совсем трудно, но к щастью этих областей не так много.

S>Ну хоть что-то.




S>Не, не зря. Там новый (ну не для всех, конечно, он новый) подход к шаблонным извращениям описан.


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

VD>>Но ты теперь до смерти будешь утверждать обратное.


AVK>Ты так и не привел логической цепочки каким ты образом на основании своих тестов пришел к выводу о неэффективности XmlSerializer.


Я же говорил?!
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, _vovin, Вы писали:

_>Еще в 75-ом была среда, в которой все было ран-тайм, никаким другим таймом и не пахло.


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

VD>>Приведи, плиз, хотя бы один пример печального использования ртти.


ГВ>Не повторяй моей ошибки с неоднозначно трактуемым утверждением. Я не характеризовал последствия в системе "печальный-радостный".


Значит идешь на попятную? Что же — это радует.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>"моей программы" — имеется ввиду та программа, которую разрабатывает и контролирует конкретный дизайнер.


А компонент это тоже "твоя программа"? Или он обязан быть частью дезайрена?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>> В том же COM-е был только IDispatch.


AVK>Ну так это оно и есть.


Это не оно. Это левая ужимка. "Оно" окромя Явы и дотнета я нигде не видел.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Список членов класса — это метаданные или что?


Список есть список. "Мета" означает — описывающие себя. В даном случае о самоописании речи не идет. Так что...

S>А не нужен мне ни MC++, ни дотнет. А нужна только метаинформация в компил-тайме.


Дык похоже, что это тперь будет только в дотнете и Яве. Так что выбор не велик. Да и не ясно в чем проблема то? С++ там тот же, только с метаданными.

S>Кому как. Мне так и typeof нужен, и список членов класса, и граф наследования. А дальше уж я б на них шаблоны бы натравил.


Оно все есть. Вот только шаблны в виду их статичности, ну, никак не прикрунишь. Скорее кодогенератор.

S>Здрасте. А про то, что сериализацию в шарпе проще и надежней делать, не ты ли распинался?


А в шарпе нет шаблонов и макросов.

S> Если б С++ была возможность получить хотя бы список членов класс и перебрать предков класса (в компил-тайме, само собой),


Не батенька. В компайл тайме перебрать — это конечно концепция интересная, но пока никем не реализованная. В дотнете все обычно вуже в рантайме....

S> сгенерить код сериализации класса на С++ не совтавляло бы почти никакого труда.


Но генерить ты будешь его уже в рантайме или в отдельном тулзе. Хотя конечно при наличии полноценного TypeInfo сдалать такую утилиту было бы можно.

S> Пока же приходится для такого перебора изгаляться по всякому. Самое обидное, что у компилятора эта информация есть, но он ей ни за что не поделится...


Во-во. Тут я полностью согласен. Собственно о том и речь. Просто некоторпые товарищи такой подход считают мовитоном.

S>Естественно, потому как С++ такой информации и не предоставляет.


Ну?! О том и речь. Тот же МС++ дает полную информацию о себе. Т.е. сделать то можно. Вот только ортодоксы типа Страуструпа всю малину портят.

S>А можно было бы — просто структуры, соответсвующие входным данным. А метаинформацию, сгенеренную для них компилером, вытаскивать в рантайм и анализировать уже ее. Одним шагом меньше — ошибок тоже будет меньше.


Можно. Но это "плохой дизайн" . Чем? Это не ко мне.

VD>>А анализировать при компиляции особо нечего.


S>Это как сказать.


Думаю, то чем ты говоришь скорее напоминает время между компиляциями. Тут спору нет. Метаданные могли бы сослужить огромную службу. Но стандрат плюсов просто таки борится с этой идеей.

VD>>Звучит здорово. Но реально в приложениях созданных на строгокомпайлтаймном С++ рантайм ошибок в разы больше чем чем созданных на шапре.


S>Ну это у кого как.


Поверь, у всех. Программист пересаженный с плюсов на дотнет резко поднимает продуктивность. Это уже не слова. Это доказано практикой. Есть конечно некоторая доля задачь, которую проще далеть на плюсах, но она все время уменьшается.

S>Есть живучесть, а есть надежность. Живучесть у шарпного кода может и выше, а вот с надежностью все не так однозначно.


Очень даже однозначно. При проектировании еще Явы этот пункт ставили в приоритеты. А уж о дотнете и говорить не приходится.

S>Мы, видимо, на его постинги с разных позиций смотрим.


И тем неменее. Там есть четкий приговор метаданным.

SP

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

ГВ>Ну давай так, сторонний компонент, как ты правильно заметил, для C++, это либо plain-api (значит-исходники), либо классы (значит — тоже исходники), либо какие-то самоописывающиеся интерфейсы (к примеру — COM). Самоописывание интерфейсов нужно для генерации исходников, которые затем будут использоваться мной. Это, фактически, единственный путь использования сторонних объектов в программах на C++. rtti или нечто похожее может понадобиться для анализа данных, получаемых извне, особенно, если дизайн стороннего компонента предполагает такой способ его использования. С точки зрения дизайна моей программы в данном случае rtti будет использован для задачи обработки внешних данных и, кстати, последствия в виде... ну я уже говорил, — никуда не денутся. И моя, кстати, негативная их оценка — тоже, несмотря на то, что это может оказаться единственным выходом. Ну сам посуди: что мне, радоваться что-ли, от того, что я, например получаю какой-нибудь IBase*, для которого надо клепать dynamic_cast<IDerived*>, обрабатывать потенциальные ошибки и т.п?



Забавно ты расуждаешь. Тебе говорят, что это в некоторых случаях единственный виход, а в некоторых не еденственный но намного боле простой. А ты все криво, и криво. Этак я могу обвинить весь мир так как в нем нужно дышать воздухом и нельзя прыгать с небоскребов. Ну, право не серьезно.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>
WH>DLL_EXPORT_MAP_BEGIN()
WH>    DLL_EXPORT_CLASS(C_MyCoolSensor)
WH>    DLL_EXPORT_SINGLETON_CLASS(C_MyCoolSingleton)
WH>DLL_EXPORT_MAP_END()
WH>


Поздравляю. Ты изобрел COM.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А> Сполне нормальная политика. Есть стандарты, которые работают многие годы. И если уж написали, то будет собираться и работать всегда и у всех. И не надо каждые полгода грузить себе громадный фреймворк.


То-то, ни одни из известных компиляторов не удовлетворяет стандрту С++ на 100%.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Будущее C#
От: IT Россия linq2db.com
Дата: 09.07.03 22:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В .NET это можно сделать несколько проще(но не сильно).


В .NET это деалется как два байта:

(IMyDeviceInterface)Activator.CreateInstance(className);


className можно в виде строки положить в базу или в любой конфигурационный файл по вкусу. Всех описываемых тобой ограничений типа одна dll и пр. не существует в принципе. Хоть одна dll, хоть четыре. При желании можно использовать и стандарные типы вроде "System.String" если они конечно поддерживают твой интерфейс.

В общем, в .NET это не "несколько проще", а совсем элементарно. У меня на подобной ерунде совместно с PropertyGrid'ом весьма навороченный визуальный редактор построен. Расширяется он во все стороны элементарно описанным выше способом.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[40]: Будущее C#
От: WolfHound  
Дата: 10.07.03 04:25
Оценка:
Здравствуйте, IT, Вы писали:

IT>В .NET это деалется как два байта:

IT>
IT>(IMyDeviceInterface)Activator.CreateInstance(className);
IT>

Можно подумать у меня сложнее
CreateObject<IMyDeviceInterface>(className);


IT>className можно в виде строки положить в базу или в любой конфигурационный файл по вкусу.

У меня тоже причем этим уже давно пользуются. И это было заложено с самого начала.
IT>Всех описываемых тобой ограничений типа одна dll и пр. не существует в принципе. Хоть одна dll, хоть четыре.
Какие ограничения? Кто говорил об ограничениях? Да хот один класс-одна длл без разници. Просто классы отвечающие за одну железку лежат в одной длл. Что в этом плохого?
IT>При желании можно использовать и стандарные типы вроде "System.String" если они конечно поддерживают твой интерфейс.
Ну это мне нафик не упало.

IT>В общем, в .NET это не "несколько проще", а совсем элементарно. У меня на подобной ерунде совместно с PropertyGrid'ом весьма навороченный визуальный редактор построен. Расширяется он во все стороны элементарно описанным выше способом.

Веришь нет но мое приложение тоже расширяется во все стороны знай себе дллки пиши.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.07.03 06:41
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хорошо, пусть не "провоцирует", а "...упрощает реализацию такого дизайна, который...".


Ну и смысл в этом высказывании? Можно так же сказать что удобный редактор кода упрощает copy&paste программирование. Отсюда делаем вывод — использование хорошего текстового редактора приводит к good text editor based design, который крив.

AVK>>Вот ты уперся и ничего не хочешь видеть. Еще раз повторяю — наличие или отсутствие такой ситуации никак не зависит от тебя. Если тебе нужно использовать сторонний компонент без исходников то хоть на голове стой — все равно никак rtti ты шаблонами не заменишь.


ГВ>Ну давай так, сторонний компонент, как ты правильно заметил, для C++, это либо plain-api (значит-исходники),


Хидеры а не исходники. Это не одно и то же.

ГВ> либо классы (значит — тоже исходники)


Опять же совершенно необязательно.

ГВ>И моя, кстати, негативная их оценка — тоже, несмотря на то, что это может оказаться единственным выходом. Ну сам посуди: что мне, радоваться что-ли, от того, что я, например получаю какой-нибудь IBase*, для которого надо клепать dynamic_cast<IDerived*>, обрабатывать потенциальные ошибки и т.п?


Только вот ты путаешь проблемы С++, который не приспособлен для этого с проблемами компонентного программирования вобще.

ГВ>Если бы смысл моей фразы был один, то и спорить было бы не о чем. И извини, но: а) на каком основании ты расписываешься за всех, кто читает этот топик, и б) смысл своей фразы буду объяснять я,


Тогда с тобой спорить не интересно, потому что ты в любой момент можешь вывернуть все наизнанку.

ГВ>особенно, если собеседники меня не поняли сразу. И ещё раз, я не говорил, что rtti — это абсолютно "кривой" дизайн.


Именно это ты и сказал.

AVK>>1) Мог использоваться отдельно в любом проекте без исходных кодов


ГВ>Исходный код — необходимое условие для C++ и ты это отлично знаешь.


Почему же? Есть ведь dll, СОМ

ГВ>Выполнение этого условия невозможно.


Неприспособленность языка для компонентного программирования?

ГВ>Исключение составляет ситуация, когда исходник или информация, достаточная для его восстановления "спарены" с бинарным кодом.


Ну вот и замечательно, так и реализуй.

ГВ>Условие неправомерно.


Почему это неправомерно? Очень даже.

AVK>>2) Мог сериализоваться в бинарный поток и xml


ГВ>Реализовать схему сериализации несложно,


Ну реализуй. Потом сравним с дотнетом.

ГВ>проблема в другом — ты в данном случае требуешь невыполнимого, — реализовать сериализаци на основе описания структуры типа, как это делает дотнет.


Ага, опять С++ не подходит.

ГВ> Верно? Если так, то

ГВ>Условие неправомерно.

А по моему очень даже.

AVK>>3) Его экземпляр можно было бы передать по сети


ГВ>При наличии приёмника на другой машине — несложно.


Ну вот и покажи как. Сравним с дотнетом.

AVK>>4) Обеспечивался бы контроль версий класса


ГВ>Реализуемо соответствующей инфраструктурой.


Покажи как. Сравним с дотнетом.

AVK>>5) Можно было бы создать экземпляр по имени


ГВ>1. Где создавать?


В любом потребителе класса.

ГВ>2. По имени типа или экземпляра?


По имени типа и набору значений параметров конструктора.

AVK>>6) Можно было бы визуально отредактировать его свойства.


ГВ>Не надо путать IDE и язык.


А я и не путаю. Просто без rtti это сделать вобще невозможно практически.

ГВ>Напиши-ка мне то же самое на дотнете, но без использования визуального редактора?


PropertyGrid имеешь ввиду? Без проблем на самом деле. Собственно самый примитивный вариант без отработки вложенных объектов такой:
public void EditObject(object o, Form editForm)
{
    foreach (PropertyInfo pi in o.GetType().GetProperties())
    {
        TextBox tx = new TextBox();
        tx.Text = TypeDescriptor.GetConverter(o.GetType()).ConvertToString();
        tx.Tag = pi;
        editForm.Controls.Add(tx);
    }
    
    if (editForm.ShowDialog == DialogResult.OK)
        foreach (Control ctrl in editForm.Controls)
        {
            TextBox tx = ctrl as TextBox;
            if (tx != null)
                ((PropertyInfo)tx.Tag).SetValue(o, TypeDescriptor.ConvertFromString(tx.Text));
        }
}


Жду аналог на С++.

ГВ>Условие неправомерно.


А помоему очень даже.

ГВ>Сначала разберёмся с предметом спора, а там посмотрим.


А чего тут разбираться? Типовая задачка поставила С++ практически по всем приведенным пунктам в тупик.

ГВ>>>Фраза на самом деле не "абсолютно односмысленная", поскольку содержала неопределённое понятие "в сущности".

AVK>>Опять ты пытаешься перевести спор на термины. В общем неубедительно.

ГВ>Да, но ты, в частности, демонстрируешь или непонимание, или упорное нежелание понять. Вот я и объясняю. Я согласен, мы все не идеальны и у всех разные стереотипы, потому я, например, и склонен уточнять и разъяснять формулировки ровно столько, сколько необходимо.


Только все таки должны быть рамки этого, иначе разговор будет попросту невозможен. Я могу тебя назвать м@#$%ом, а потом сказать что я изъясняюсь на особом диалекте русского языка, на котором слово м@#$% означает уважаемый господин. Так и здесь. Я еще понимаю если бы исходная фраза была недостаточно ясной или многосмысленной. Но высказался ты вполне определенно и попытки твои теперь представить это в ином свете лично для меня абсолютно неубедительны.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[45]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.07.03 06:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ниче не понимаю. Ну вот в плюсах же нет этой проблемы, так?


А в плюсах внутрь метода не может попасть класс, неизвестный компилятору.

S>Нельзя ни присвоить, ни привести константную ссылку неконстантной. Приведи пример того, что ты имеешь в виду.

public interface ISomeObj
{
    int Y(int x);
    // Согласись - сказать меняет этот метод состояние объекта или нет заранее невозможно
}

...

private void SomeMethod(const ISomeObj someObj)
{
    int y = someObj.Y(25);
    // А вот теперь объясни мне - как компилятор может узнать - нарушает ли это выражение константный констрейн или нет?
}


AVK>>Почему не можешь? Вполне.

S>Хм. Во как. А метод не того, извините, класса, я вызвать могу?

Нет.

S>Там же вроде как проверяется, что объект позволяет вызывать этот метод.


Тем не менее приватные методы через рефлекшен зовуться. В любом случае — проверка происходит в рантайме.

S>Ну. Объявляю.

S>Вот есть у меня интерфейс
S>
S>interface ISome {
S>  int GetProperty() const;
S>    void SetProperty(int v);
S>}
S>

S>пусть теперь у кого-то будет метод

S>
S>void XXX::SomeMethod(const ISome some)
S>{
S>    some.GetProperty(); // ok
S>    some.SetProperty(5); // нельзя. 

Собственно почему нельзя? Как ты это определил? По наличию префикса Set в имени метода?

S>}
S>

S>В чем проблема-то?

Да в том и проблема что подобные фокусы можно отловить только в рантайме, в отличие от плюсов.

AVK>>Не мешает, как не мешает решать проблему тем путем про который я говорил. Заодно дизайн будет более прозрачным.

S>Не вижу ничего прозрачного в необходимости делать так:
S>
S>class ISomeConstWrapper {
S>private
S>  ISome _wrapped;
S>public
S>  ISomeConstWrapper(ISome wrapped) {}
S>  int GetProperty() {return _wrapped.GetProperty();}
S>}
S>void XXX::SomeMethod(ISomeConstWrapper some)
S>{
S>...
S>}
S>

S>Потому, что код этих враппров будет до жути однообразным.

Они нужны только для чужих объектов. Свои ты можешь сделать заранее read only с возможностью менять параметры только в конструкторе. И уж это будет точно более красиво нежели const модификаторы, поскольку вместо сущности структурного программирования — константный параметр, вводит ОО сущность — константный класс. Согласись, в ОО-дизайне это выглядит несколько получше.

S>Кроме того, нет никакой гарантии того, что на самом деле метод GetProperty не нарушает своего обещания не трогать объект.


Гарантия тому ты сам.

S> В плюсах ха этим следит копилятор.


А здесь компилятор не может этого отследить в принципе, это можно сделать только в рантайме. Кстати есть еще такой модификатор readonly
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[46]: Будущее C#
От: m.a.g. Мальта http://dottedmag.net/
Дата: 10.07.03 07:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>private void SomeMethod(const ISomeObj someObj)

AVK>{
AVK> int y = someObj.Y(25);
AVK> // А вот теперь объясни мне — как компилятор может узнать — нарушает ли это выражение константный констрейн или нет?
AVK>}
AVK>[/c#]

Да очень просто: не сказано, что не меняет состояние объекта — значит меняет
... << RSDN@Home 1.1 beta 1 >>
Re[42]: Будущее C#
От: WolfHound  
Дата: 10.07.03 08:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Поздравляю. Ты изобрел COM.

В шарпе надо обьявить класс публичным, у меня занести в карту экспорта. Работы практически одинаково.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: Будущее C#
От: WolfHound  
Дата: 10.07.03 08:17
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здесь немного поподробнее, плз. CreateObject<>() как я понял, реализован в exe-шнике. Далее он обращается к конкретному синглтону (например — C_MyCoolSingleton), который создаёт объект Sensor. Ну там понятно: карта, по которой отображается sensorName на конкретный синглтон и т.п.

Каждая длл содержит указатель на супер фабрику классов те обьект который содержит карту фабрик. Супер фабрика может возвращать только I_OBject. CreateObject реализован в длл вобще это просто удобный акцессор к супер фабрике со встроенным dynamic_cast

ГВ>Мне просто нужно понять структуру зависимостей модулей. Если вызов dynamic_cast<C_MyCoolSensor> есть в исходниках exe-шника, и других библиотеках, это одно, а если только в библиотеках сенсоров, то — другое.

Только в длл ехешник об обьектах ни чего не знает.

ГВ>Вот тут тоже немного не понятно: указатель на объект, содержащий фабрику классов передаётся в экспортируемую функцию? Логично было бы предположить, что указатель передаётся из неё...

Указатель на супер фабрику в длл, указатель на енумератор фабрик из длл. После чего фабрики из енумератора заносятся в карту супер фабрики.

ГВ>Ещё, ты говорил, что библиотеки содержат формы настройки. Формы просто в виде модальных диалогов или в виде чего-то типа PropertyPage? В смысле — они встраиваются в какой-то оборачивающий диалог или показываются независимо?

Да как угодно.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.03 11:41
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>А типа const неля послать к чертям?
В каком это смысле послать к чертям?
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[46]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.03 12:01
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А в плюсах внутрь метода не может попасть класс, неизвестный компилятору.

Может-можеет.
S>>Нельзя ни присвоить, ни привести константную ссылку неконстантной. Приведи пример того, что ты имеешь в виду.
AVK>
AVK>public interface ISomeObj
AVK>{
AVK>    int Y(int x);
AVK>    // Согласись - сказать меняет этот метод состояние объекта или нет заранее невозможно
AVK>}
Ну почему невозможно-то? Во-первых, отсутствие слова const - значит меняет. Если есть слово конст - ну все. Это означает, что внутри не должно быть вызовов методов, не помеченных const. А также присваиваний. Рекурсивное определение позволяет компилятору достаточно шустро определить, имееет ли место нарушение. Еще раз: почему-то плюсовый компилятор делает это. И не особо напрягаясь. Пока что я не услышал ни одного внятного аргумента в пользу того, почему этот интеллект может быть недоступен шарповому компилятору.
[c#]
private void SomeMethod(const ISomeObj someObj)
{
    int y = someObj.Y(25);
    // А вот теперь объясни мне - как компилятор может узнать - нарушает ли это выражение константный констрейн или нет?
    // Извини, ты не пометил Y словом const. На этом компилятор останавливается.
}


S>>Хм. Во как. А метод не того, извините, класса, я вызвать могу?

AVK>Нет.
AVK>Тем не менее приватные методы через рефлекшен зовуться. В любом случае — проверка происходит в рантайме.
Вот именно, Андрей, вот именно. Рефлекшн — это очень медленно по-любому. И доп. проверка несущественно ухудшит быстродействие и без того медленного кода.
S>>Ну. Объявляю.
S>>Вот есть у меня интерфейс
S>>
S>>interface ISome {
S>>  int GetProperty() const;
S>>    void SetProperty(int v);
S>>}
S>>

S>>пусть теперь у кого-то будет метод

S>>
S>>void XXX::SomeMethod(const ISome some)
S>>{
S>>    some.GetProperty(); // ok
S>>    some.SetProperty(5); // нельзя. 

AVK>Собственно почему нельзя? Как ты это определил? По наличию префикса Set в имени метода?
По отсутствию постфикса const! Ты бы сразу сказал, что не знаешь семантики const в плюсах. Я бы рассказал подробнее. 
S>>

S>>В чем проблема-то?

AVK>Да в том и проблема что подобные фокусы можно отловить только в рантайме, в отличие от плюсов.

Нет! Ведь не каждый же вызов метода приводит к верификации каста? Это означает, что очень много чего можно проверить статически. Есть очень ограниченное количество способов подменить сигнатуру метода. А точнее, ровно один — рефлекшн. Про него мы уже поговорили.

S>>Потому, что код этих враппров будет до жути однообразным.

AVK>Они нужны только для чужих объектов. Свои ты можешь сделать заранее read only с возможностью менять параметры только в конструкторе. И уж это будет точно более красиво нежели const модификаторы, поскольку вместо сущности структурного программирования — константный параметр, вводит ОО сущность — константный класс. Согласись, в ОО-дизайне это выглядит несколько получше.
Андрей, еще раз. Не все объекты можно сразу сделать readonly.
AVK>Гарантия тому ты сам.
Ну не смеши меня. А как насчет гарантии того, что метод не бросает исключений, кроме декларированных в сигнатуре? Тоже на программиста обязанность гарантировать возложим? Лишь бы компилер не устал... А хотя чего мелочиться — давай проверку типов параметров тоже возложим на программиста! Как это в сях было.

AVK>А здесь компилятор не может этого отследить в принципе, это можно сделать только в рантайме. Кстати есть еще такой модификатор readonly

Почему не может-то? У него все метаданные есть!
А можно чуть подробнее про модификатор?
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[43]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.07.03 12:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Поздравляю. Ты изобрел COM.

WH>В шарпе надо обьявить класс публичным, у меня занести в карту экспорта. Работы практически одинаково.

В метаданных храняться не только публичные данные, там храниться все
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[47]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.07.03 12:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

AVK>>А в плюсах внутрь метода не может попасть класс, неизвестный компилятору.

S>Может-можеет.

Как? Через какой нибудь дайнамик кост?

S>Ну почему невозможно-то? Во-первых, отсутствие слова const — значит меняет.


А, так ты предлагаешь все методы, которые не меняют значение модификатором const размечать? Нафик нафик.

AVK>>Тем не менее приватные методы через рефлекшен зовуться. В любом случае — проверка происходит в рантайме.

S>Вот именно, Андрей, вот именно. Рефлекшн — это очень медленно по-любому. И доп. проверка несущественно ухудшит быстродействие и без того медленного кода.

Проблема только в одном — в случае чужих компонент на их компилятор полагаться нельзя, а значит контроллировать придеться не только в случае рефлекшена, но и в случае обычных вызовов.

AVK>>Они нужны только для чужих объектов. Свои ты можешь сделать заранее read only с возможностью менять параметры только в конструкторе. И уж это будет точно более красиво нежели const модификаторы, поскольку вместо сущности структурного программирования — константный параметр, вводит ОО сущность — константный класс. Согласись, в ОО-дизайне это выглядит несколько получше.

S>Андрей, еще раз. Не все объекты можно сразу сделать readonly.

Что значит нельзя? Чужие объекты надо оборачивать, свои делать ридонли, планируя дизайн так чтобы одни и те же классы не использовались как для передачи неизменяемых данных потребителю, так и для изменения данных.

AVK>>Гарантия тому ты сам.

S>Ну не смеши меня. А как насчет гарантии того, что метод не бросает исключений, кроме декларированных в сигнатуре? Тоже на программиста обязанность гарантировать возложим? Лишь бы компилер не устал... А хотя чего мелочиться — давай проверку типов параметров тоже возложим на программиста! Как это в сях было.

const не сильно дело упрощает, заставляя тебя расставлять модификаторы. Причем, что самое неприятное, для этого тебе нужно расставлять эти модификаторы не только в том месте где тебе понадобились параметры, но во всех классах которые может кто то использовать как const параметр. Т.е. если я пишу публичный класс я фактически обязан расставить по его методам и свойствам модификатор const, а мне это геморой не нужен.

AVK>>А здесь компилятор не может этого отследить в принципе, это можно сделать только в рантайме. Кстати есть еще такой модификатор readonly

S>Почему не может-то? У него все метаданные есть!

Нету у него всех метаданных. Метаданные будут в рантайме, когда под полиморфный интерфейс подсунется конкретный экземпляр с конкретными метаданными из конкретной сборки.

S>А можно чуть подробнее про модификатор?


Можно конечно

When a field-declaration includes a readonly modifier, the fields introduced by the declaration are readonly fields. Direct assignments to readonly fields can only occur as part of that declaration or in an instance constructor or static constructor in the same class. (A readonly field can be assigned to multiple times in these contexts.) Specifically, direct assignments to a readonly field are permitted only in the following contexts:

In the variable-declarator that introduces the field (by including a variable-initializer in the declaration).
For an instance field, in the instance constructors of the class that contains the field declaration; for a static field, in the static constructor of the class that contains the field declaration. These are also the only contexts in which it is valid to pass a readonly field as an out or ref parameter.
Attempting to assign to a readonly field or pass it as an out or ref parameter in any other context is a compile-time error.

... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[48]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.03 13:20
Оценка:
Здравствуйте, AndrewVK, Вы писали:
Почти убедил
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: Будущее C#
От: orangy Россия
Дата: 10.07.03 14:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

IT>>className можно в виде строки положить в базу или в любой конфигурационный файл по вкусу.

WH>У меня тоже причем этим уже давно пользуются. И это было заложено с самого начала.
Не подумайте про меня плохо, но такую фичу я делал еще ...ммм... где-то в 95ом году. Это не были стандартные средства С++, это был пост-процессор, принимавший на вход OBJ-файлы (COFF, делалось для djgpp) и выдававший некий DLM (dynamic link module). Там же был специальный run-time, который прикреплялся в ввиде stub к exe-шнику. Там была именно отложенная линковка, т.е. не GetProcAddress, а именно позднее связывание. В том числе там была фича под названием Named Classes. Использование выглядело примерно так:
int main()
{
 Base *pb,*pd;
 pb=new Base(10);        // Create an instance of Base. Nothing unusual.
 pb->f();                   // Base::f()

 pd=new("Derived") Base(4); // Create an instance of Derived.
                            // Actually Derived(4) will be called.

 pd->f();                   // Derived::f()
 delete pd;                 // Destructors are virtual so Derived::~Derived
 delete pb;                 // Base::~Base
};


Интересно, что скажут местные гуру? Было ли это компонентным программированием в зачатке или фигней полной?

Если кому интересно подробнее, вот есть какой-то древний хелп к DLM. Прошу пардону за кривой english и прочие ляпы — давно это было...
[RSDN@Home 1.1 beta 1] Сейчас 21:00, слушаю тишину
"Develop with pleasure!"
Re[41]: Будущее C#
От: orangy Россия
Дата: 10.07.03 14:04
Оценка:
Здравствуйте, Sinclair, Вы писали:

VD>>А типа const неля послать к чертям?

S>В каком это смысле послать к чертям?
Думаю, Влад имеет ввиду const_cast
[RSDN@Home 1.1 beta 1] Сейчас 21:03, слушаю тишину
"Develop with pleasure!"
Re[41]: Будущее C#
От: IT Россия linq2db.com
Дата: 10.07.03 15:20
Оценка:
Здравствуйте, 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 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Будущее C#
От: IT Россия linq2db.com
Дата: 10.07.03 15:20
Оценка:
Здравствуйте, orangy, Вы писали:

O>Интересно, что скажут местные гуру? Было ли это компонентным программированием в зачатке или фигней полной?


Кашмар, какое извратство, почему бы просто не написать CreateInstance для этого.

ЗЫ. А вообще идея интересная
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Будущее C#
От: IT Россия linq2db.com
Дата: 10.07.03 15:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Поздравляю. Ты изобрел COM.

WH>В шарпе надо обьявить класс публичным, у меня занести в карту экспорта. Работы практически одинаково.

Тебе ещё надо метод в двух местах объявить: в .h и в .cpp
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.03 15:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В шарпе надо обьявить класс публичным, у меня занести в карту экспорта. Работы практически одинаково.


А! Ну-ну.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.03 18:51
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.03 20:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Разницу чуешь?


Чую, что тебе ненравится, но почему обяснить ты не в силах.

ГВ> Это может быть единственным выходом, но я оценивать его всё равно буду негативно (или, если хочешь — с грустью, тоской, щемящим сердцем, великоросской рефлексией, сквозь зелёную бутылку, с поллитрой в руках, скрипя зубами, с самурайским мечом меж зубами, — ряд синонимов можно продолжить), поскольку присущие ему черты неизбежно останутся.


Так как ты не докозал, что "присущие черты" плохи. Будет считать это утверждение основанное на небоснованных спорных предпосылках. ОК?

ГВ>Или ты считаешь, что я должен прыгать от счастья, раз мне пришлось воспользоваться этим, единственным выходом?


Я считаю, что обчиняя нужно приводить доказательства вины. Хотя бы если об этом попросили несогласные. Или не обвинять.

ГВ>Поскольку моя личная негативная оценка не может быть предметом обсуждения


А зачем ты ее высказываешь? Раз высказал, значит она уже автоматом может стать предметом...

ГВ>, в силу субъективизма и возможной неадекватной её трактовки собеседниками то я: а) отказался от такой формулировки, но б) сформулировал описание характерных черт критикуемого мной подхода более точно.


И таки так и не дал доказательств своим критическим суждениям.

ГВ>Поскольку разработчики C++ (Страуструп, во всяком случае, насколько я это знаю) придерживались схожих взглядов, я счёл возможным в декларативной форме присоединиться к ним. Декларативную же и краткую форму выбрал сознательно, поскольку сообщение написал в форум.


Тбе декларативно и заявили, что ты не прав, в месте с Страуструпом. Что ты еще хочешь?

ГВ>Ну как, понятно объяснил? Или стрелочки логических связей нарисовать?


Такую позицию не стоило и озвучивать. Она ровным чсетом никому ничего не дает.

ГВ>А относительно "в некоторых не еденственный но намного боле простой"... Так опять ты апеллируешь к тому, что разница простой-сложный настолько велика, что это фактически — единственный выход для которого либо справедливо то, что я уже сказал, либо... несправедливо вообще ничего, поскольку "простой" и "сложный" — тоже субъективные оценки.


Твои рассуждения противоречат логике. Любой дизайн тем лучше чем проще и эффективнее он решает поставленную задачу имеющимися средствами. А понятие "криво" является сугубо отнсительным. Так что если решение единственное, то кривым его называть бессмысленно.

ГВ>PS. Да и вообще — иная простота она хуже воровства.


Ну, это аргументы из той же оперы.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.03 20:14
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.03 20:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

VD>>А типа const неля послать к чертям?

S>В каком это смысле послать к чертям?

В смысле приведения типов. const — это всего лишь условность. Удобная конечно, но не эффективная когда речь идет о реальной защите.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.03 20:14
Оценка:
Здравствуйте, m.a.g., Вы писали:

MAG>Да очень просто: не сказано, что не меняет состояние объекта — значит меняет


А зачем все это? На ратайме JIT и так будет знать меняет или нет. Конст нужен исключительно для самоконтроля программиста. Тобы тот мог как бы заранее поставить галочку. Мог это я уже менять не буду.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.03 20:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Какие ограничения? Кто говорил об ограничениях? Да хот один класс-одна длл без разници. Просто классы отвечающие за одну железку лежат в одной длл. Что в этом плохого?


А как ты находишь нужную длл-ку? Я лично не вижу дургого способа как подгружать все подяд и пытаться вызвать кекую функцию отбрасывающую метаинформцию о классе. Собственно разница как раз в том, что в дотнете такая мтаинформация уже есть и она стандартна для всех CLR-языков. А ты изобрел свой ком. Причем изначально ограниченный так как полная его реализация — это море кода.

WH>Веришь нет но мое приложение тоже расширяется во все стороны знай себе дллки пиши.


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

50%? Даумаю лично у него 99% уходит на свой энжин. Шутка ли создать собственную (пусть и ограниченную) реализацию ком-а?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Будущее C#
От: IT Россия linq2db.com
Дата: 10.07.03 22:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>50%? Даумаю лично у него 99% уходит на свой энжин. Шутка ли создать собственную (пусть и ограниченную) реализацию ком-а?


Возможно. Просто я сужу по себе, когда писал комы на ATL, то 50% уходило именно на борьбу с ATL, COM и C++. Хотя когда используются накатанные решения, то этот процент гораздо меньше. Но что-бы взять тот же COM у меня ушло несколько месяцев, а в случае с Remoting'ом, например, это исчисляется несколькими днями, от силы пару недель.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 00:00
Оценка:
Здравствуйте, IT, Вы писали:

IT>Возможно. Просто я сужу по себе, когда писал комы на ATL, то 50% уходило именно на борьбу с ATL, COM и C++. Хотя когда используются накатанные решения, то этот процент гораздо меньше. Но что-бы взять тот же COM у меня ушло несколько месяцев, а в случае с Remoting'ом, например, это исчисляется несколькими днями, от силы пару недель.


Интересно сколько на это ушло бы если доэтого ты бы не занимался КОМ-ом? Да и не все, что было в КОМ реализовано в ремоутинге. Но несомненно он спроектирован более качественно чем ком. И заслуга тут именно в возможностях заложенных в дотнете.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Будущее C#
От: orangy Россия
Дата: 11.07.03 00:47
Оценка:
Здравствуйте, 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, слушаю тишину
"Develop with pleasure!"
Re[45]: Будущее C#
От: IT Россия linq2db.com
Дата: 11.07.03 01:30
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Интересно сколько на это ушло бы если доэтого ты бы не занимался КОМ-ом? Да и не все, что было в КОМ реализовано в ремоутинге. Но несомненно он спроектирован более качественно чем ком. И заслуга тут именно в возможностях заложенных в дотнете.


Я могу сказать не только за себя. Люди с которыми я работал довольно тщетно пытались использовать COM долговое время, с ремоутингом таких проблем не было.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Будущее C#
От: Sergey Россия  
Дата: 11.07.03 07:56
Оценка:
Здравствуйте, 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).

переставлять местами — так:

есть void foo(x, y);

boost::bind(&foo, _2, _1)(5, 10) вызовет foo(10, 5).

VD>Ты лучше задачу опиши.


Описал чуть выше.

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 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[42]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.07.03 08:30
Оценка:
Здравствуйте, orangy, Вы писали:

O>Здравствуйте, Sinclair, Вы писали:


VD>>>А типа const неля послать к чертям?

S>>В каком это смысле послать к чертям?
O>Думаю, Влад имеет ввиду const_cast
Ну, мы же люди взрослые. Понимаем, что в управляемой среде такие трюки запрещены. Как и reinterpret_cast вместе со static_cast.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: Будущее C#
От: Sergey Россия  
Дата: 11.07.03 08:49
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Мне несколько другая метаинформация нужна.


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


Именно. И еще мне нужна возможность писать программу, которая будет выполняться компилятором и на основе этой метаинформации подставлять в код вызовы функций, например.

VD>Собствнно я личто только за. Главное, чтобы при этом это был не еденственны способ работы с ней. Мне так нужно чтобы она была доступна и в рантайме и в дизайнтайме. Из этой мысли, кстати, вытекает мысль о том, что нужно так же узаконивать понятия дизйнтайма.


Ну а лично для меня это уже излишне.

S>>Шаблоны это и есть кодогенератор.


VD>Не серьзяно это.


Еще как серьезно.

S>> Помнишь, я пример сериализации на С++ с кучей тайпдефов кидал? Вот там именно в компил-тайме в библиотеке генерируется код, перебирающий все (заданные в шаблоне) базовые классы и ищущий нужный тип у члена ddxMembers и возвращающий его значение (простым static_cast'ом), если в пользовательском коде была использована шаблонная функция data или field, принимающая параметр нужного типа.


VD>Помнишь как по уродски смотрелся этот код?


Нормально смотрелся.

VD>И сколько лишнего кодирования он требовал?


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

VD>И помнишь какой код нужен для дотнета?


Уродски смотрелся — если добавить привязку переменных к контролам. А мне это тоже нужно.

VD>Так вот для создания оптимального решения. Нужно чтобы в языке появились реальные и удобные средства компайлтайм-кодогенерации. Чтобы можно было создать некий мета-сериализатор. Который по информации о классе (причем без дополнительной разметки, или с минимумом таковой) генерировал бы код сериализации для класса.


Именно. Часть из этого уже предоставляют шаблоны.

VD>Согласен, что в дотнете минусом является необходимость работы в рантайме (Иногда этого можно избежать).


Как?

VD>Дык пока нет. Да и использование рекурсивных шаблонов — это очередной обход убогости языка средствами шаблона. Мне именно это не нравится.


А мне — нравится.

VD>Раз появилась потребность в метапрограммировании, то лучше встроить в язык продуманные средства для этого. А компилятор (и возможно рантайм) оптимизировать под них.


Дак не успели еще. И некому пока. Это ж надо, чтоб очередному Страуструпу очередная AT&T зарплату платила, пока он над всякими изысками размышлять будет.

VD>>>В дотнете все обычно вуже в рантайме....


S>>Это то и плохо.


VD>Ничего в этом плохого.


Потери производительности — это хорошо?

VD>Рантайм просто необходим в современных условиях.


Делать в рантайме то, что без труда можно было бы делать в компил-тайме — уродство.

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


Только надежность этого кода никакая будет.

S>>Щаз. Я уже умею генерить его компилятором — но приходится дофига тайпдефов писать, и класс от шаблонного наследовать, и еще кучу ограничений соблюдать.


VD>Ты ничего не гереришь. Ты все хардкодишь. Просто тебе шаблоны позволяют резко уменьшить этот процесс. Я уже устал это повторять.


Херню потому что повторяешь Компилятор проверяет, унаследована ли переменная ddxMembers у текущего класса от нужного типа, и если нет — рекурсивно делает то же для базового класса. Пока не упрется в терминальный базовый класс. Я только задаю правила, по которым компилятор это делает. Это именно программа, выполняемая компилятором — такая же, как и та, что заставляет компилятор вычислять факториал.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[43]: Будущее C#
От: WolfHound  
Дата: 11.07.03 08:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>50%? Даумаю лично у него 99% уходит на свой энжин. Шутка ли создать собственную (пусть и ограниченную) реализацию ком-а?

У меня весь энжин строчек 200-300 при этом он умеет не только CreateObject. Сейчас 80%-90% идет именно на бизнес логику, а другие только ей и занимаются.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Будущее C#
От: Юнусов Булат Россия  
Дата: 11.07.03 09:02
Оценка:
Здравствуйте, Аноним, Вы писали:

А>C# мёртвый язык и жизни ему не будет. Прочти — http://www.cydsoft.com/vr-online/3_2003/hvsms.htm и http://www.cydsoft.com/phpBB2/viewtopic.php?t=64


Мда, читая "Delphi. Horrific против MS" местами плакал.

"Корпорацию Borland всегда ругали за то, что программы, скомпилированные на нём, получаются большого размера. Я чисто для примера создал пустой проект с помощью MFC Wizard со статической компиляцией, когда всё необходимое встраивается в один exe файл. Когда я скомпилировал проект (напоминаю, он был пустым), то на выходе получил запускной файл размером чуть более 2 метров. Это не шутка. Я чуть ли не упал со стула, когда увидел такие размеры."
Re[2]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 09:29
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>C# мёртвый язык и жизни ему не будет. Прочти — http://www.cydsoft.com/vr-online/3_2003/hvsms.htm и http://www.cydsoft.com/phpBB2/viewtopic.php?t=64


Очередная демагогия. Ну вот например

Меня поражают разработчики Microsoft. Посмотрите на Office 2000 и ХР. В них используются очень хорошие, удобные и красивые меню и панели кнопок. А теперь запустите Visual Studio .NET и посмотрите на его меню. Они также выполнены в стиле ХР. И тут возникает вполне резонный вопрос – где в Visual Studio .NET объекты, которые позволят мне создавать подобные меню? Нету? И Office и Visual Studio .NET являются разработкой одной компании, так почему же я должен самостоятельно писать объекты меню в стиле ХР или Office 2000?

Почему программисты Borland заложили в свой Delphi 7 подобные компоненты, а Microsoft не может поделиться даже этим?


Во первых — а почему они собственно обязаны выкладывать все что использовалось в создании среды, причем забесплатно? Во вторых — а где в Дельфи 7 компонент object inspector?

Даже то, что встроено в Delphi в несколько раз превышает то, что предоставляет нам Microsoft.


Сравним по охвату фреймворк и VCL? Или мы считаем по количеству рюшечек, которые мышкой можно перетянуть на форму?

Компонентная модель Delphi действительно удобна, и программер не тратит время на создание интерфейса, а занимается программированием и созданием логики приложения, а не всякой ерундовиной.


А где собственно аргументы подразумеваемому неудобству компонентной модели дотнета?

вроде бы сильно защищены (ага, так я и поверил)


Аргументы?

приложения С# будут работать только на Windows 2000/XP. А куда девать огромный парк машин с Windows 95/98/ME.


Просто ложь. Фреймворк работает и под 98 и под МЕ. Далее куча выводов, основанных на этой лжи идет в корзину.

Все остальные заявления о платформе .NET – полное фуфло. Никаких крутых сетевых возможностей, никакой простоты разработки, никакого удобства,


Ну что тут можно сказать? Абсолютно неаргументированные вопли.

На данный момент С# программисту абсолютно не нужен. В нём нет ничего такого, ради чего можно было бы программировать на этом языке.


Собственно ни одного аргумента мы так и не услышали. одни эмоции и наглая ложь.

Корпорацию Borland всегда ругали за то, что программы, скомпилированные на нём, получаются большого размера. Я чисто для примера создал пустой проект с помощью MFC Wizard со статической компиляцией, когда всё необходимое встраивается в один exe файл. Когда я скомпилировал проект (напоминаю, он был пустым), то на выходе получил запускной файл размером чуть более 2 метров. Это не шутка. Я чуть ли не упал со стула, когда увидел такие размеры


Скомпилял бы тогда уж и минимальный проект на шарпе. Наверное тоже упал бы со стула (3К, если мне не изменяет память)

У меня крутые программы занимают не более 2 мегабайт, так в них столько окон, что MS WORD покажется однооконной системой.


Детство в заднице играет, извините за выражение
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[42]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 09:35
Оценка:
Здравствуйте, IT, Вы писали:

IT>Конечно сложнее. Что там у тебя за CreateObject'ом скрывается? У меня за активатором стандартная библиотека


Боюсь что даже не библиотека, а рантайм.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[41]: Будущее C#
От: Sergey Россия  
Дата: 11.07.03 09:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Да ничего там не перебирается и не ищется. Все есть заранее. Шаблон есть шаблон. Просто универсальная параметризованная реализация.


Ты просто не представляешь себе всех возможностей шаблонов.

S>>Было бы чего перебирать. Обычная рекурсия с условиями за счет специализации с этим на раз справлятся. Книжку Александреску почитай для начала, или сразу в boost::mpl загляни (но там, блин, трудно что-то понять с наскоку).


VD>Все равно это не кодогенерация. Это некий алгоритм выполняесый компилятором.


Правильно, это алгоритм выполняесый компилятором. И генерирующий код — подставляющий вызовы нужных функций в нужные места.

VD>Да и неудобно это ужасно.


Кому как.

VD>>>В дотнете все обычно вуже в рантайме....

S>>Это то и плохо.

VD>Да ничего в этом плохого нет. Можно и код сгенирить если что.


Ха-ха. Сгенери. Быстрее будет все руками прописать, чем такой код отлаживать.

S>>Щаз. Я уже умею генерить его компилятором — но приходится дофига тайпдефов писать, и класс от шаблонного наследовать, и еще кучу ограничений соблюдать.


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


Черта с два ты макросами такое сделаешь.

S>>Они, кстати, уже есть — OpenC++, например.


VD>Ссылкой не поделишся? Чтыо за зверь?


В гугле набрать слабо? А зверь простой — продвинутый препроцессор, предоставляющий доступ к метаинформации до компиляции. К сожалению, небезглючный — потому им и не пользуюсь.

S>>Кто именно ?! Пока я только встречал возражения против автоматического вынесения такой информации в рантайм — и с ними полностью согласен. Это работа для стандартной библиотеки, а не для языка.


VD>И как ты себе видишь "такую" работу при условии, что информация тебе становится доступна только в рантайме? Ну, не твой компонент, а алогоритм для работы с ним написать нужно.


Долго расписывать, это не для флейма тема. Но выглядеть для пользователя это могло бы примерно так:

class MyPublicClass {...};

std::provide_type_info(MyPublicClass);

S>>Там что, есть иные средства генерации кода, кроме шаблонов и макросов?


VD>CodDOM и Reflection.Emit. Гибче небывает.


Мы вроде про компил-тайм разговаривали, а?

S>> Или шаблоны атрибуты в качестве параметров понимают? Если нет, то до метаинформации опять в компил-тайме не добраться — ну и нафиг мне такое щастье?


VD>В компайл-тайме вызываются сами атрибуты. Для самих атрибутов это рантайм, но все же. Правда с шаблонами их спарить невозможно (шаблоны пока вообще только для не совместимого с CLI кода доступны). Но все же.


Чума Удаляем гланды ректально

S>>Чем же тебе так Страуструп не угодил?


VD>А ты почитай, что он пишет про все нововведения. GC — можно раелизовать как библиоткеку... (Ака щаз!)


Странно, в D&E он писал, что GC должен предоставляться компилятором. Ссылку можно?

VD>Информации о типах достаточно...


Это про rtti, наверное, а не про компайл-тайм информацию о типах. Про компайл-тайм информацию о типах он, AFAIK, вообще не писал.

VD>расширять язык дальше нельзя...


Ну тут он отчасти прав Но вот если одновременно с расширением анахронизмы сишные повыкидывать, то мог бы полный рулез получиться.

VD>Ну, а про рантайм и компоннтный подход вообще молчек. Какбодто таковго не существует.


И правильно. Это дело индустрии и на универсальный язык влиять не должно. Ну нафига одинаковый рантайм для какого-нибудь DSP и для персоналки? Рантаймом должны совершенно другие люди и организации заниматься.

VD>Впрочем как и АОП и т.п.


Про АОП больше Александреску выступает. Жаль только, соответствующих папирок с конференций в сети не валяется.

VD>А иначе возникает проблема курицы и яйца. Хотя это тоже решаемо если подумть подольше. В общем, я не против если у кого-то получится вытащить метаинформацию в компайлтайм. Только метаинформцию в рантайме — это не заменит.


Я ж говорю — если б она была доступна в компил-тайме, ее не сложно было бы вытащить и в рантайм. Правда, как обычно, каждый поставщик компилятора (стандартной баблиотеки) сделает свою метаинформацию несовместимой с другими...

VD>>>Тут спору нет. Метаданные могли бы сослужить огромную службу. Но стандрат плюсов просто таки борится с этой идеей.


S>>С какой идеей? Просто идеи метапрограммирования на шаблонах слишком недавно появились — уже после принятия стандарта.


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


В плане написания алгоритмов, рекурсия и условия полноту обеспечивают. А вот отсутствие возможности определять таким образом переменные, генерировать удобочитаемые имена — действительно делает имеющийся в плюсах метаязык неполноценным.

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


Я б от компил-тайм for и while тоже не отказался .

VD>Хотя сразу возникает проблема отладки. Те же макросы для меня лично не являются стольк опасными как их расписывают разные орлы, но отладка макросов — это сущий ад.


Являются-являются. Я с макросами так обжигался...

VD> Даже при условии наличия опций препроцессинга в код.


Для шаблонов это не так актуально. Правда, когда имена становятся очень длинными, отладчик просто перестает их видеть — это полная жопа.

VD>В конце концов метапрограммирование, генерация кода, анализ метаданных в рантайме и т.п. — это редкие в повседнвеной жизни выпендрежи. Они позоляют сделать некоторую (шаблонную) работу быстрее, но и без них можно жить. Более того 90% работы как раз не требует таких решений. И тут Шарп на коне. Ну, а про рантайм и говорить нечего. По сравнению с дотнетом в С++ он просто отсуствует.


S>>Есть, конечно, некоторая доля программистов, которые на бейсике еще быстрее чем на шарпе, писать будут


VD>Нет такой доли. Эти языки по простоте использования проактически одинаковы. Поверь, человеку написавшему не мало кода на ВБ.


Я тоже на VB немало понаписал. И никакого преимущества в скорости написания кода у VB перед C++ не заметил.

VD>В последнее время ВБ использую только для написания макростов в ворде, и то исключительно из-за того, что в ворде нельзя подключить Шарп.


А я — для тестирования COM'а.

VD>В общем, попробуй и сам поймешь, что Шарп это некий гибрид С и ВБ. Можно сказать С на стеройдах.


Во-во, С, а не С++. Убого.

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


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


Проблем и при программировании на шарпе выше крыши. А на С++ лично для меня основная проблема в том, что далеко не все члены команды уделяют хоть какое-то внимание надежности.

VD>Любой кто написал большую систему на плюсах не даст соврать.


Большая — это сколько?

VD>Иначе зачем все эти баундчекеры и т.п.?


Они вроде даже для VB и жабы есть.

VD>При проектировании Шарпа очень многие аспекты вызывающие проблемы были учтены. Например, было введенв специальные ключевые слова для перекрытия методов — override и new.


Это мне, кстати, понравилось.

VD>Так же был усилен контроль типов. Так int не приводится автоматически к bool и ошибку вроде:


VD>
VD>if(ia = ib)
VD> ...
VD>


VD>допустить становится практически невозможно. Зато писть:

VD>
VD>if((ia = ib) != 0)
VD> ...
VD>

VD>По прежнему можно. И совершенно безопастно. И таких примеров море.

Это тоже правильно. В плюсах на совместимость с С тоже следовало бы забить с самого начала. Хотя в этом случае С++ я сейчас вряд ли бы использовал

VD>Огромным шагом вперед стал отказ от указателей. По этому поводу можно ерничать.


На самом деле, просто спрятали указатели внутрь смарт-пойнтеров. Чем это от плюсов отличается?

VD>Но это действительно невироятно защищает программу от сбоев.


Ну да, вместо GPF — ексепшон. Сбой-то остается, последствия просто другие. Так же, как и смартпойнтерами в плюсах.

S>>Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...


VD>Извени, но это треп. Ты попробуй.


Что именно треп? Рантайм маленький? Или он уже у каждого пользователя установлен?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[44]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 12:03
Оценка:
Здравствуйте, IT, Вы писали:

IT>Тебе ещё надо метод в двух местах объявить: в .h и в .cpp


Зачем? Кул программеры все пишут внутри хи.. нет, хеадеров
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[42]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 12:13
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ну да, вместо GPF — ексепшон. Сбой-то остается, последствия просто другие. Так же, как и смартпойнтерами в плюсах.


Дело не в GPF или эксепшене, дело в том что большинство ошибок вызовут эксепшен именно там, где ошибка в коде, а не запортят где нибудь данные, породив тем самым нестабильные и трудноуловимые глюки.

S>>>Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...


VD>>Извени, но это треп. Ты попробуй.


S>Что именно треп? Рантайм маленький?


Нет, язык примитивный.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[42]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 12:22
Оценка:
Здравствуйте, Sergey, Вы писали:

VD>>Проблема, в том, что С++ заставляет тренеровать могзги вместо выполнения основной рабты.


S>Для меня это как раз достоинство Не так скучно работать.


Ну тогда нам наверное дальше спорить не о чем
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 11.07.03 12:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:

S>>Ну да, вместо GPF — ексепшон. Сбой-то остается, последствия просто другие. Так же, как и смартпойнтерами в плюсах.


AVK>Дело не в GPF или эксепшене, дело в том что большинство ошибок вызовут эксепшен именно там, где ошибка в коде, а не запортят где нибудь данные, породив тем самым нестабильные и трудноуловимые глюки.


С чего бы это? Случаи порчи данных при применении смартпойнтеров в моей практике еще не встречались

S>>>>Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...


VD>>>Извени, но это треп. Ты попробуй.


S>>Что именно треп? Рантайм маленький?


AVK>Нет, язык примитивный.


А что еще можно сказать про язык, который не позволяет даже ввести одно имя из нэймспейса в локальную область видимости. Впрочем, ты даже разницы между языком и рантаймом не видишь...
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[2]: Будущее C#
От: IT Россия linq2db.com
Дата: 11.07.03 15:36
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>C# мёртвый язык и жизни ему не будет. Прочти — http://www.cydsoft.com/vr-online/3_2003/hvsms.htm и http://www.cydsoft.com/phpBB2/viewtopic.php?t=64


Мда, задумчивое чтиво. Какого только бреда не валяется в сети.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Будущее C#
От: IT Россия linq2db.com
Дата: 11.07.03 15:52
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Не, нужно 5 раз. Или 500. Некоторый код — до, некторый — после. В общем случае, можно сказать, что у нас есть некоторый алгоритм, который должен вызвать внутри себя заданную мной функцию и передать ей 1 аргумент. Гадость в том, что функции нужно 5 аргументов — 4 из них надо зафиксировать до передачи функции в алгоритм. Писать функтор для каждого такого вызова не хочется. Высокая производительность не требуется. Как это делается на шарпе?


Зарядить функцию с переменным числом параметров?

void f(params object[] p)
{
}
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 20:32
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ну а лично для меня это уже излишне.


Приятно, что ты не говоришь, что это вообще ошибка дизайна.

S>Еще как серьезно.


Еще как не серьезно. Вот давича у меня как раз была подобная задача. В итге насандалил карт с описаниями и на макросах с инклюдами вывернулся. Ну, еще на какой-то матери.

VD>>Помнишь как по уродски смотрелся этот код?

S>Нормально смотрелся.

Это уже печать языка. Так сказать приплюснутость. Наньше такой эффект был у ярых ассемблерщиков. Они тоже гвоорили, что МАСМ выгдядит нормально. О вкусах как говортся не спорят, но лично мне такой код очень не нравится.

S>Лишнего — три строчки на сериализуемый класс.


Нет батенька. Там каждая переменная была обернута.

VD>>И помнишь какой код нужен для дотнета?


S>Уродски смотрелся — если добавить привязку переменных к контролам. А мне это тоже нужно.


В дотнете переменные к контролам вообще не нужно привязывать. Любой контрол объект, т.е. сам по себе переменная. А уродски сотрится именно изголения на С++. Под дотнетом чистый и понятный. Для сериализации так вообще никакого дополнительного кода не надо. Если это уродство, то дальше говорить не очем.

S>Именно. Часть из этого уже предоставляют шаблоны.


Нужно только уточнить сотую или десятую.

VD>>Согласен, что в дотнете минусом является необходимость работы в рантайме (Иногда этого можно избежать).


S>Как?


Много разных способов. Где-то все уже и так есть и грамотно. Где-то можно сгенерировать код и выполнять его.

VD>>Дык пока нет. Да и использование рекурсивных шаблонов — это очередной обход убогости языка средствами шаблона. Мне именно это не нравится.


S>А мне — нравится.


Ну, что тут можно скзать. У нас разные цели. Мне нужен рабочий код с минимумом затрат, а тебе красивые извраты.

S>Дак не успели еще. И некому пока. Это ж надо, чтоб очередному Страуструпу очередная AT&T зарплату платила, пока он над всякими изысками размышлять будет.


Что значит еще? Идее метапрограммирования думаю столько же лет сколько существуют высокоуровневые языки. А в плюсах этих изменений видимо уже дождаться будет нельзя. По крайней мере Страуструб рубит все свежие веянья на корню.

S>Потери производительности — это хорошо?


Глупость говоришь. Как можно терять то чего никогда небыло. Многие вещи вообще без поддержки в рантайме не делаются. Те же компоненты, к примеру. И как ты производительность потряешь при этом? Ту же интрперетацию будешь делать руками, вместо того, чтобы использовать готовый код. Да и не везде она так уж важна. А так где важна можно и код сгенерировать. Вопрос в сложности исполнения. На плюсах она черезвычайно высока.

S>Делать в рантайме то, что без труда можно было бы делать в компил-тайме — уродство.


Короче, эта беседа снова плавно перетекает в пустобрехство. Мне это не нравится, так что я из нее выхожу. Или давай не брасаться столь пустыми и звонкими фразами.

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


S>Только надежность этого кода никакая будет.


И откуда ты это взял? Снова треп.

S>Херню потому что повторяешь Компилятор проверяет, унаследована ли переменная ddxMembers у текущего класса от нужного типа, и если нет — рекурсивно делает то же для базового класса. Пока не упрется в терминальный базовый класс. Я только задаю правила, по которым компилятор это делает. Это именно программа, выполняемая компилятором — такая же, как и та, что заставляет компилятор вычислять факториал.


Ты не правила задаешь, а извращаешся на эзоповом языке. А до генераторов кода этому подходу как до Пекина раком.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 20:32
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ты просто не представляешь себе всех возможностей шаблонов.


Ну, куда нам тупым.

S>Правильно, это алгоритм выполняесый компилятором. И генерирующий код — подставляющий вызовы нужных функций в нужные места.


Да ничего он не подставляет. А главно, это все настолько через ухо, что пользоваться этим очень сложно.

VD>>Да и неудобно это ужасно.


S>Кому как.


И как ты будешь отлаживать более менее сложный алгоритм засунутый рекурсивный шаблон? Или что будешь делать если рекурсия для решения некоторой проблемы не является удобным подходом?

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

S>Ха-ха. Сгенери. Быстрее будет все руками прописать, чем такой код отлаживать.


Завист от объемов. Но факт в том, что его можно будет отлафивать. А втой рекурсивный шаблон точно нет. Генерация кода в общем-то не сложное занятие.

S>Черта с два ты макросами такое сделаешь.


Ну, ну. В чем проблема?

S>В гугле набрать слабо?


А ссылку дать слабо? Или вопросом на вопрос интереснее?

S> А зверь простой — продвинутый препроцессор, предоставляющий доступ к метаинформации до компиляции. К сожалению, небезглючный — потому им и не пользуюсь.


Он к языку привязан? Или его можно и для того же шарпа применить?

VD>>И как ты себе видишь "такую" работу при условии, что информация тебе становится доступна только в рантайме? Ну, не твой компонент, а алогоритм для работы с ним написать нужно.


S>Долго расписывать, это не для флейма тема. Но выглядеть для пользователя это могло бы примерно так:

S>class MyPublicClass {...};
S>std::provide_type_info(MyPublicClass);

Ага. Долго расписывать то чего на свете не существует. Неужели просто тяжело признать факт? С++ не расчитан на работу в компонентной среде и для того чтобы его к ней приобщить придется изобрести свой КОМ.

S>Мы вроде про компил-тайм разговаривали, а?


Тебе шашечки или ехать? Генерация кода эмитом и есть компайлтайм. Хочешь засунь его в процесс сборки проекта, а хочешь выполняй по-требованию. Скорость будет как у С++-ного оптимизированного кода. В чем разница то?

VD>>В компайл-тайме вызываются сами атрибуты. Для самих атрибутов это рантайм, но все же. Правда с шаблонами их спарить невозможно (шаблоны пока вообще только для не совместимого с CLI кода доступны). Но все же.


S>Чума Удаляем гланды ректально


Да никто ничего не удаляет. Это тебе все хочется что-нить через анус сотворить. Атрибуты прекрасно и так работают. Это расширение метаданных. Вот в плюсах такого нет. И это их огромное достоинство.

S>Странно, в D&E он писал, что GC должен предоставляться компилятором. Ссылку можно?


Ссылку уже вряд ли но чуть ли не в своей главной поэме.

VD>>Информации о типах достаточно...


S>Это про rtti, наверное, а не про компайл-тайм информацию о типах. Про компайл-тайм информацию о типах он, AFAIK, вообще не писал.


А ему всего и всегда достаточно. Хотя информация о типах конечно в первую очередь нужна в рантайме и дизайтайме.

S>Ну тут он отчасти прав Но вот если одновременно с расширением анахронизмы сишные повыкидывать, то мог бы полный рулез получиться.


Гы-гы. Что тогда от языка останется? Шаблоны?

S>И правильно. Это дело индустрии и на универсальный язык влиять не должно. Ну нафига одинаковый рантайм для какого-нибудь DSP и для персоналки? Рантаймом должны совершенно другие люди и организации заниматься.


Почитай про дотнет и яву. Тогда поймешь.

S>Про АОП больше Александреску выступает. Жаль только, соответствующих папирок с конференций в сети не валяется.


Ага. Как всегда через шаблоны и макросы. Ну, не вставлять же в язык дополнительные кострукции? Пусть даже простые и эффектинве...

S>Я ж говорю — если б она была доступна в компил-тайме, ее не сложно было бы вытащить и в рантайм. Правда, как обычно, каждый поставщик компилятора (стандартной баблиотеки) сделает свою метаинформацию несовместимой с другими...


Зачем вытаскивать да еще и "каждтому..."? Нужно описать ее радимую в стандарте и пусть все этот стандарт реализуют. В дотнете именно так и сделано. Получилоь замечательно.

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


S>Я б от компил-тайм for и while тоже не отказался .


Вот тольк я не пойму чем метаданные в рантайме мешают?

S>Являются-являются. Я с макросами так обжигался...


Ну, тут я тебе могу сказать... опыта у тебя мало. Я так пишу без проблем. Но в отличие от тебя прикрасно понимаю, что то-что я привык обходить грабли не делает из граблей ковровую дорожку. Та же фигня с извращениями на шаблонах. Когда ты делашь универсальный алгоритм, применение шаблонов выглядит изящно и правомерно. А когда ты используя откровенные лазейки пытаешся использовать шаблоны для решения проблем для решения которых они просто не предназначены, то получается каша. Которую не то, что поддерживать, ее писать то сложно.

В общем, мое мнение таково: Для решения пролем лучше использовать специально заточенные инструменты. Почему-то использование пердметов не поназначению в других облостях человеческой деятельности всеми вопспринимается с однозначано негативно. А тоже самое в программировании расценивается как верх мастерства. Именно это и заставляет в памяти всплывать тот самый анекдот про удаление гланд.

S>Для шаблонов это не так актуально. Правда, когда имена становятся очень длинными, отладчик просто перестает их видеть — это полная жопа.


Это предсказуемое следствие сложности языка.

S>Я тоже на VB немало понаписал. И никакого преимущества в скорости написания кода у VB перед C++ не заметил.


Значит ты очень силно отдалился от реальности.

S>А я — для тестирования COM'а.


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

S>Во-во, С, а не С++. Убого.


Ты попробуй, а потом расскажещь.

VD>>Любой кто написал большую систему на плюсах не даст соврать.

S>Большая — это сколько?

Ну, Сегабайта 1.5 чистых (рукописных) исходников. Я это прошел на двух проеках. Один 1.5 мега. Второй 3.5. И никто не убедит меня, в том что С++ удобно читать.

S>Они вроде даже для VB и жабы есть.


Они там ненужны. Ни ВБ ни Ява не могут привести к таким проблемам как на С++, а на С++ без них в больших проектах никуда.

S>Это мне, кстати, понравилось.


Еще бы. Любой кто часик поискла ошибку вызванную из-за переименования виртуального метода оценит кайф. В Шарпе таких вещей уйма. Под час даже не ясно, зачем что-то делается, а потом понимашь, что именно для безопастности.

S>Это тоже правильно. В плюсах на совместимость с С тоже следовало бы забить с самого начала. Хотя в этом случае С++ я сейчас вряд ли бы использовал


Да плюсы очень сильно не совместимы с С. Одна разница в описании функций чего стоит?! Но все же дыр и в них хватает. Собственно правила безопастного программирования на С++ и заключаются в уходе от стиля С.

VD>>Огромным шагом вперед стал отказ от указателей. По этому поводу можно ерничать.


S>На самом деле, просто спрятали указатели внутрь смарт-пойнтеров. Чем это от плюсов отличается?


Нет в Шарпе никаких смарпоинтеров. Там целостная идеология. Все сделано, так чтобы можно было жить без указателей. Они даже временами палку перегибают. Так BinaryRiader (средство чтения инфомации из бинарных файлов) написали не на указателях, а на операторе >>. Давольно забавно смотрится. И что удивительно не сильно проигрывает в скорости работе с указателями. Видимо оптимизация на уровне JIT-а.

S>Ну да, вместо GPF — ексепшон. Сбой-то остается, последствия просто другие. Так же, как и смартпойнтерами в плюсах.


В 90%-ах просто нет посылок для возникновения эксцепшонов. Да и эксцепшон — это тебе не испорченая память. Проблема AV не в механизме SEH (который кстати и используется в дотнетных исключениях), а в том, что в подавлющем количестве случаев после него (изи до него) портится память. А это уже не лечится. И если какой-нибудь ворд просто грохнется, а юзер отдуши проматерится, то в сервере приложений такой прикол может обернуться нехилыми потерями денег для компании.

S>>>Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...

VD>>Извени, но это треп. Ты попробуй.

S>Что именно треп? Рантайм маленький? Или он уже у каждого пользователя установлен?


См. выше. Хотя про натайм тоже треп. Ты ведь в своей конторе хочешь применять? У вас сеть какая? 20 мег сможете прокачать?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 20:32
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Не, нужно 5 раз. Или 500.


Про for слышал? Удивительно помогает в таких случаях.

S> Некоторый код — до, некторый — после. В общем случае, можно сказать, что у нас есть некоторый алгоритм, который должен вызвать внутри себя заданную мной функцию и передать ей 1 аргумент. Гадость в том, что функции нужно 5 аргументов — 4 из них надо зафиксировать до передачи функции в алгоритм. Писать функтор для каждого такого вызова не хочется. Высокая производительность не требуется. Как это делается на шарпе?


По разному. Самый правильный выход не доводить до такого маразма. Обычно вместо такого метода делается объект у каторого устанавливаются свойства. Продумывается ОО-модель... Ну, а если вдруг придется вызвать метод... то можно и метод вызвать. Нет особых проблем передать нужные пармаетры.

Тут лучше приводить примеры описывая, что они делают на словах. А тебе будут прводить примеры того как это решается на шарпе.

S>Это я и так в курсе. Ты ж знаешь, что в С++ к этому случаю ровно тот же подход.


Не совсем. Там нет finally. И единственным не кривым выходом является создание обертки. Что многих ленивых орлов наталкивает на идею использовать goto.

S>Надо передать ее в алгоритм, который хочет void bar(int x), при этом y должен быть равен 4.5, а s — "asdf";


S>boost::bind(&foo, _2, _1)(5, 10) вызовет foo(10, 5).


Тебе не кажется, что это кривое решение? Не проще ли объявить отдельную функцию-врапер?

В Шарпе тоже хотят ввести подобную фичу. Но в отличии от С++ никто даже не думает, о реализации ее через задницу, ой извени, шаблоны . Будут инлайн-методы. Выглядеть будет примерно так:
foo(){ foo(10, 5) };


Честно говоря я за всю свою зинь как то ни разу не нуждался в подобных наворотах. Видимо не очень часто нужная вещь.

VD>>Ты лучше задачу опиши.

S>Описал чуть выше.

Ты некое решение на заплатках описал. А задачу — нет. Задача — это: вывести некий графический объект...

VD>>Кстати, тоже рисование в дотнете сделано куда изящнее. Правда это скорее заслуга грамотности проектирования обертки над GDI+. Аналогичную можно использовать и на плюсах.


S>Тормоза.


Это тормоза ГДИ+. Они к нету отношения не имеют. На С++ скорость будет той-же.

Недавно видел генератор отчетов на ГДИ+. Работал не медленнее чем аналоги нэйтивные, но насколько же он их обганял по графическим наворотам?! Да и тормоза не на всех опирациях. А если учесть, что рано или поздно ГДИ+ акселерируют...

S>Это ровно то, что надо для генерации кода сериализации класса. А как это называть — кодогенерацией или ее зачатками, мне, в общем, по барабану.


Нет. И твой пример этому доказательство. Ты вынужден был изпещрить весь код кучей ненужных оберток. Красивое решение я тебе показал... в дотнете все эти ужимки попросту ненужны. Посмотри код генерируемый VS в Шарповом или ВБ-эшном проекте. Там чистейший воды код. Без ужимок и уродвств. Причем 90% информации для сериализации берется из описания контролов создаваемого автоматом, 9.9% — это разметка атрибутами, и только 0.1 процента — это кодирование и навороты.

VD>>Ну, и опять таки проблемы отладки не хуже чем с макросами.

S>Не, с макросами отладка на порядок хуже.

Код сгенерированный макросами хотя бы можно посмотреть. В шаблонах же это в принципе невозможно.

S>А увиливание от ответа — тоже, кстати, один из приемов демагогии.


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


А как еще можно объяснить очевидные вещи. Вот обясни к примеру, что такое синий цвет. Я тебе привел, описание и примеры прямых анлогий. А так же отличия их от обратных. Так же объяснил, что доказательство на аталогиях является обманом если не содержит доказательства аналогичности.

Скрипты и шаблоны имеют значительно больше отличий чем сходст. Ты пытаешся обощить шаблоны до скриптов. Это подмена понятий.


VD>>Ты серьезно хочешь, чтобы я за тебя еще раз перечитал всю эту немаленькую тему? Про клозур конечно тут небыло, но про делегаты не однократно.


S>А я что, где то говорил, что делегаты в С++ нужны?


А что речь была про тебя?

S> Делегаты — лишняя сущность, вполне хватило бы __closure и шаблонов с переменным числом параметров. А то, блин,


Ну, так отдал бы предпочтение делегатам в том виде как они есть в дотнете. Хотя это бы потребовало создания человеческого рантайма для С++. Но на худой конец хотя бы клосюр. Хотя это по сути указатель на метод. Только не бездарный как в С++, а грамотный да еще и с неким намеком на объектно-ориентированность.

S>Ссылку можно? Прочитаю, интересно.


Я такю бредатину в фавориты не складываю. Попробуй гуглем. Или спрости у С++-гурьев. Они обычно такие ссылки имеют.

S>Это потому, что в одном куске кода смешиваются компайл-тайм и рантайм программа. (раз уж тебе аналогия с сервер/клиент сайд скриптом не нравится )


Это потму, что когджа для решения проблем применяются не предназначенные для этого инструменты, то обычно выходит криво и непонятно. Попробуй открыть консервную банку обычным нажем, а потом консервным и почуствуй разницу. Если не прочуствуещь, то попробуй тоже сделать вилкой. Та же фигня с шаблонами. Не для того их проектировали.

S>Плохой. А третьего-то подхода нету...


Я тебе уже сказал, что нормалным подходом было бы введение в язык средств метапрограммирования, а в средства разработки возможностей отладки этого дела.

S>Я такого не утверждал, кстати. Это была очередная аналогия — между шаблонами и указателями в плане понятности кода


Ты сказал, что непонятны они только тем кто с ними работать не умеет. Так вот я умею с ними работать очень неплохо. Но так как не являюсь их фанатом (да и С++-а), то понимаю, что от них слишком много проблем, и их слишком сложно читать. Я даже в С++ вместо:
(*a++) = b;

Предпочитаю:
a[i] = b;
i++;


S>Не уходи от темы — речь шла не об ошибках, а исключительно о сложности понимания кода.


Одно порождает другое. Ухудшение читабельности приводит к увеличению ошибок, а отсутвие контроля за действиями приводит, к тому, что анализу кода приходится уделять больше внимания и веремени.

Так же фигня с типобезопастностью. Хотя в С++, и в C# можно писать присвоения внутри ифов, но тем не менее читая C#, я уверен, что проблем с этим не будет. А в С++ я вынужден напрягаться, что не пропустить детские ошибки. Для обхода этих проблем многие программисты стараются ставить в if-ах в качестве первого операнда сравнения rvalue. Тагда код вроде: if(WM_XXX = a) однозначно даст ошибку компиляции. Но, во-первых, такой код тяжелее воспринимать, а во-вторых, можно нечяно упустить это из виду и получить час отладки с выпученными галзами. Так что сложность понимания обратно пропорционально безопастности языка.

S>Не о том речь. Хотя с "очень малозатратны" вполне можно поспорить


Вперед. Я это проверял на тестах и был паражен насколько эффективно делаются эти проверки.

VD>>Проблема, в том, что С++ заставляет тренеровать могзги вместо выполнения основной рабты.


S>Для меня это как раз достоинство Не так скучно работать.


Знаешь почему пилоты делятся на смелых и старых?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 21:10
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>C# мёртвый язык и жизни ему не будет. Прочти — http://www.cydsoft.com/vr-online/3_2003/hvsms.htm и http://www.cydsoft.com/phpBB2/viewtopic.php?t=64


А что же анонимом, то? У такого юмора должен быть автор!
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 21:10
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Боюсь что даже не библиотека, а рантайм.


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

AVK>Зачем? Кул программеры все пишут внутри хи.. нет, хеадеров


Так кстати, и в правду удобнее. Правда медленее компилируется и не всегда возмжно.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 21:16
Оценка:
Здравствуйте, Sergey, Вы писали:

S>С чего бы это? Случаи порчи данных при применении смартпойнтеров в моей практике еще не встречались


Будут.

S>А что еще можно сказать про язык, который не позволяет даже ввести одно имя из нэймспейса в локальную область видимости.


О! Это и есть чистой воды треп. Причем довольно неприятный.

S>Впрочем, ты даже разницы между языком и рантаймом не видишь...


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

S>Ну, мы же люди взрослые. Понимаем, что в управляемой среде такие трюки запрещены. Как и reinterpret_cast вместе со static_cast.


Ксожалени, нет. Такую проверку можно вставить только в компилятор. Остальные на нее будут чиахать, так как даже приметива такого нет.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.07.03 06:09
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Вот именно! Я и говорю — НАДО ЕГО ВНЕСТИ В .NET. Вы что думаете, я не заметил, что его там нет? Более того, я заметил, что custom attribute такой не будет иметь никакой ценности, пока за ним не следит компилятор.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[36]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.07.03 06:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>"А баба Яга — против!" (c) Мультик. Извини, просто ты так эмоционально реагируешь.


С чего ты взял?

ГВ>>>А что ты будешь делать, если для некоего нового типа данных ещё нет обработчика среди дополнительных сборок?

AVK>>Напишу и скомпиляю в отдельную сборку.

ГВ>И что? Где же помощь reflection?


Помощь рефлекшена в том что мне не надо пересобирать старый проект. Более того — если источник данных и их потребитель это отдельные продукты, то мне достаточно только обновить источник данных и предоставить необходимые конверторы, не трогая потребителя совершенно.

ГВ>Только в том, что ты выполнишь вместо подстановки средствами механизма виртуальных функций подстановку средствам атрибутов? Т.е., грубо говоря, слоты размещаются не в VMT, а в атрибутах.


Рефлекшен гибче полиморфизма и предоставляет больше возможностей меньшими усилиями. Кроме того рефлекшен не требует наследования от какого то класса, а иногда это заметно удобнее.

ГВ>Обязанность по поддержанию адекватного набора конвертеров по прежнему лежит на программисте. С той лишь разницей, что для .Net он будет делать сборки, а на C++ скорее всего, — .dll или Shared Objects.


Разница только в одном — в отсутствие рефлекшена все это ты можешь осуществить только внутри своего продукта. Как только часть цепочки оказывается ввиде бинарного модуля без исходников то сразу все становится много печальнее.

ГВ>>>OK, я тебя понял. И то, к чему ты упомянул про дополнительные сборки в каталогах программы — тоже. И сразу хочу задать встречный вопрос. А кто напишет для моей программы нужные именно ей конвертеры? Предположим, что речь идёт не о банльной конвертации в строковое представление, а например, в хливких шорьков, метОда использования которых известна только мне. Я позволю себе задать этот вопрос, поскольку спор начинался с общих фраз.


AVK>>Это уже совсем другой вопрос.


ГВ>Да нет, в том-то и дело, что это две стороны одно и того же вопроса.


Не надо перескакивать на другие темы, если нет больше аргументов так и скажи что был не прав.

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


ГВ>При такой ситуации (необрабатываемые данные во внешнем источнике данных) — всегда возможны глюки, а вернее — runtime-ошибки.


Если все поведение системы определяется в одном месте их вероятность значительно меньше. Как например ты напишешь на плюсах систему конфигурирования, так чтобы для внесения новой переменной в конфигурацию нужно было бы всего лишь добавить поле в класс, ее содержащий, так чтобы все остальное — механика сохранения/загрузки, пользовательский интерфейс и прочая адаптировались под изменения автоматически? А при помощим рефлекшена это возможно, и оно, помимо снижения объема работы срахует от ошибок, в том числе и в рантайме просто потому что их негде сделать, изменения требуют от тебя чисто декларативных действий и никакой правки алгоритмов.

ГВ>И где я говорил, что новые конвертеры, обрабатывающие сигнатуры новых типов данных источника не могут подгружаться? В default-ветке switch-а вполне может стоять что-то вроде:


ГВ>
ГВ>default: locate_custom_datatype_converter(...);
ГВ>


ГВ>где и будет выполняться поиск по map, если заранее предусмотренного конвертера нет. А map будет заполняться библиотеками драйверов.


Неужели сам не видишь насколько все получается более громоздким? В дотнете для поддержки нового типа я напишу так:
[ConvertType("SomeType")]
class SomeTypeConverter : TypeConverter
{
    public override Convert() {...}
}


Скомпилирую в отдельную сборку и положу в каталог приложения. Все. Никаких мапов, свитчей и прочей пурги не надо. И неважно что где то внутри их видимо будет похожая механика — главное что это будет происходить автоматически. Мне не надо ничего править, дописывать где то мапы, менять свитчи и прочее, мне не надо даже управляющий код пересобирать. Весь остальной код подстроится автоматом. И вот это прелести решения на шаблонах лишены, для них необходим исходный код и полная пересборка всех задействованных алгоритмов, не говоря уж о необходимости ручной регистрации типов в кеше и правки этой регистрации при каждом(!) изменении конвертеров. И это если не вспоминать о раздувании кода и жутко медленной компиляции.

ГВ>Кстати, мне немного неясно, что ты имеешь ввиду под словами "поменял тип, но забыл поменять его мап".


То и имею ввиду. Тип добавил (изменил название), а мап нет — в результате глюки.

ГВ>>>1. Программа выдаст пустые строки или сообщение об ошибке в зависимости от контекста.

ГВ>>>2. Я разберусь с тем, что происходит и сделаю Upgrade своей проги.
AVK>>Причем править придется старый код. А это действительно кривой дизайн.

ГВ>Не факт.


Факт. И очень странно что ты этого не видишь. Раньше в дисскусиях ты высказывал интересные вещи с неплохим подходом к дизайну. Но сейчас, извини за прямоту, явно видно что ты зациклился на технологиях которые хорошо знаешь и упорно не желаешь сойти с наезженной колеи. Поэтому в упор не видишь очевидных вещей — многие задачи, особенно связанные с компонентными и глубоко конфигурируемыми системами решаются на С++ значитьно более сложно и громоздко.

ГВ> Ситуация может потребовать изменения как всей проги, так и только написания для неё дополнительного адаптера/конвертера и т.п. Для твоего случая справедливо то же самое, так что не надо преждевременно обобщать.


Тем не менее, как показывает практика, чаще все таки нужно добавлять функционал, а не перекраивать старый низкоуровневый код. И в таком случае использование плюсов не лучший вариант решения проблемы.

AVK>>Ну уж нет, ты не про rtti-based подход говорил, ты говорил просто про использование rtti.


ГВ>А, ну вот уже лучше, о терминах договариваемся.


Нет уж, цитата благо осталась.

VD>Дык информация о типах нужна то обычно в рантайме, а вот тут у плюсов идеологический калапс. Его авторы просто не думали о рантайме при проектировании языка.

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


Извини, но тут явно и без обиняков сказано — применение rtti является ошибкой дизайна, поэтому рантайм в С++ сознательно такой куцый. Извини, но трактовать твою фразу как то иначе просто не возможно. И тебе на пальцах показали что как раз невозможность применения rtti как раз частенько снижает управляемость и универсальность кода, а значит является ошибкой дизайна.

ГВ>Progress, однако. А то твоя иллюстрация никак не противоречила моим тезисам. Думаю, что это естественно, поскольку "опыт — не пропьёшь". Понимаешь, ты просто привёл пример того же самого правильного LSP-дизайна, только опирающегося на подстановку, выполняемую с помощью атрибутов, а не виртуальными функциями и абстрактными интерфейсами.


Знаешь в чем я с тобой не согласен? В том что реализовать все это добро нужно руками. Это может быть интересно первый, десятый раз. В двадцатый раз это уже вызвает раздражение. И то что в итоге на шарпе я реализую тот же самый дизайн в разы(!) быстрее, более гибко и с меньшим количеством глюков нежели на плюсах низводит все остальные плюсы и минусы в разряд шашечек, и никакие умные книжки ситуацию существенно не изменят.

ГВ> Так что, противоречия, на самом деле — нет. Принципы дизайна остались теми же самыми.


А про принципы никто и не спорит. Вопрос в реализации. А многие паттерны реализуются с использованием рефлекшена в разы проще и быстрее. Та же абстрактная фабрика, где на плюсах никогда не избавится от зависимости фабрики и производимой ею продукции.

ГВ>Ну да, часть задач дотнет берёт на себя, но я это и не собирался опровергать, знаешь, было бы глупо.


А к чему тогда слова о безусловной кривости rtti?

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


ГВ>Причём тут моё наличие или отсутствие привычки использовать компоненты?


При том что ты упорно отказываешься замечать фатальный недостаток плюсовых шаблонов и решений на их основе — шаблоны существуют только в момент компиляции и только внутри проекта.

ГВ>Я привык жёстко организовывать программу,


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

ГВ> чтобы обеспечивать её надёжность (и скорость).


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

ГВ> Это отнюдь не означает, что в ней мест, где используются компоненты (библиотеки, модули — хоть груздём назови).


Они может и есть, но все твои шаблонные навороты между ними уже не действуют.

AVK>>Вот только компилятор не может гарантировать того чего может не знать.


ГВ>Естественно. И, ИМХО, "правильный" дизайн должен вести к снижению количества подобных ситуаций.


Не обязательно. Это всего лишь залатывание дыр. Существование компонентно ориентированных сред это реальность, данная нам в ощущениях и дизайн тут не при чем. Объективные факторы заставляют делать программы, собирающиеся из набора модулей, а не представляющие собой неделимый и монолитный кусок. Полтора десятка лет развития технологий компонентного программирования ясно показали — они себя оправдали, более того, альтернативы им в настоящий момент нет. И средства разработок, пытающиеся это игнорировать рискуют оказаться никому не нужными. Уже сейчас шарп по количеству вакансий догнал С++, а по количеству новых проектов пожалуй опережает его. А прошло меньше полутора лет с релиза.

ГВ>Просто это повышает надёжность,


Нте, надежности это к сожалению не повышает, более того, из-за практически полного отсуствия каких бы то ни было возможностей контроля кода в рантайме еще ее и снижает. Дотнетный код, благодаря строгому контролю со стороны рантайма значительно надежнее плюсового и это уже доказано практикой. Кошмар ловли ошибок неделями благополучно забыт, за последние полгода в моем коде не было ни одной ошибки, на локализацию которой я потратил больше 10 минут. Не было ни одной ошибки, из-за которой глюки были не в том коде, который непосредственно ошибку содержал. Так что про надежность лучше не стоит.

ГВ> быстродействие и упрощает дальнейшие модификации.


Усложняет дальнейшие модификации. Особенно забавно будет получаться когда проект состоит из нескольких процессов.

ГВ>И потом, как это компилятор может не знать?


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

ГВ>Проблема-то не в обработке внешних данных, где от анализа нельзя избавиться по определению, а в применении RTTI-based дизайна внутри программы. Значение термина "RTTI-based" я объяснял предыдущим постом.


Не пытайся перевести разговор на другое, термин rtti-based изначально не фигурировал, твоя попытка перевести все на обсуждение терминологий выглядит нелепой отмазкой.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[37]: Будущее C#
От: WolfHound  
Дата: 12.07.03 14:53
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А про принципы никто и не спорит. Вопрос в реализации.

AVK>А многие паттерны реализуются с использованием рефлекшена в разы проще и быстрее.
ну ну
AVK>Та же абстрактная фабрика, где на плюсах никогда не избавится от зависимости фабрики и производимой ею продукции.
Не стоит так категорично высказаватся про язык который плохо знаешь. Практика показывает что при помощи rtti и не сложных шаблонов на С++ можно сделать уневерсальную фабрику классов. С учень удобным и дурака-устойчевым интерфейсом. Причем реализации классов могут лежать в разных длл.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.07.03 17:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Не стоит так категорично высказаватся про язык который плохо знаешь. Практика показывает что при помощи rtti и не сложных шаблонов на С++ можно сделать уневерсальную фабрику классов. С учень удобным и дурака-устойчевым интерфейсом. Причем реализации классов могут лежать в разных длл.


Вот только такую реализацию непоймет деже другой компилятор С++. О других языках и коворить не приходится. Отсюда и рождаются разные фабрики классов на GUID-ах. Ты Эсеншал КОМ от Дона Бокса читал? Так подробно рассказано почему КОМ написан так как нкписан.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.07.03 20:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>Та же абстрактная фабрика, где на плюсах никогда не избавится от зависимости фабрики и производимой ею продукции.

WH>Не стоит так категорично высказаватся про язык который плохо знаешь. Практика показывает что при помощи rtti и не сложных шаблонов на С++ можно сделать уневерсальную фабрику классов. С учень удобным и дурака-устойчевым интерфейсом. Причем реализации классов могут лежать в разных длл.

Для качественной реализации фабрики необходима возможность поднятия экземпляра по имени класса. Все реализации на основе шаблонов все равно требуют чтобы где нибудь явно прописывали список классов, которые может производить фабрика, а это уже менее качественная реализация.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[39]: Будущее C#
От: WolfHound  
Дата: 13.07.03 08:22
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Для качественной реализации фабрики необходима возможность поднятия экземпляра по имени класса.

Есть.
AVK>Все реализации на основе шаблонов все равно требуют чтобы где нибудь явно прописывали список классов, которые может производить фабрика, а это уже менее качественная реализация.
Единого списка нет.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[43]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.03 12:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

Извини, что долго молчал.

ГВ>>Здесь немного поподробнее, плз. CreateObject<>() как я понял, реализован в exe-шнике. Далее он обращается к конкретному синглтону (например — C_MyCoolSingleton), который создаёт объект Sensor. Ну там понятно: карта, по которой отображается sensorName на конкретный синглтон и т.п.

WH>Каждая длл содержит указатель на супер фабрику классов те обьект который содержит карту фабрик. Супер фабрика может возвращать только I_OBject. CreateObject реализован в длл вобще это просто удобный акцессор к супер фабрике со встроенным dynamic_cast

dynamic_cast<> вызывается в CreateObject? Если CreateObject возвращает общий интерфейс I_Object, то зачем в нём dynamic_cast<> ?

ГВ>>Мне просто нужно понять структуру зависимостей модулей. Если вызов dynamic_cast<C_MyCoolSensor> есть в исходниках exe-шника, и других библиотеках, это одно, а если только в библиотеках сенсоров, то — другое.

WH>Только в длл ехешник об обьектах ни чего не знает.

OK, значит dynamic_cast<> нужен только для получения частного типа из общего.

ГВ>>Вот тут тоже немного не понятно: указатель на объект, содержащий фабрику классов передаётся в экспортируемую функцию? Логично было бы предположить, что указатель передаётся из неё...

WH>Указатель на супер фабрику в длл, указатель на енумератор фабрик из длл. После чего фабрики из енумератора заносятся в карту супер фабрики.

То есть суперфабрика передаётся для саморегистрации библиотеки, а саморегистрация выполняется вызовом енумератора суперфабрикой. OK, для регистрации реализован соответствующий "микроалфавит".

ГВ>>Ещё, ты говорил, что библиотеки содержат формы настройки. Формы просто в виде модальных диалогов или в виде чего-то типа PropertyPage? В смысле — они встраиваются в какой-то оборачивающий диалог или показываются независимо?

WH>Да как угодно.

OK, тогда это пока неважно.

Надеюсь, что в итоге я правильно тебя понял:

exe:

I_Object *p = global_sensorFactory.CreateSensor(className)


exe, но уже в недрах CreateSensor():

// ... поиск фабрики-синглтона по имени соотв. класса

return pFactory->Create(); // Возвращён I_Object


Теперь .exe получил в своё распоряжение обобщённый интерфейс I_Object, что-то у него спросил — и сбросил обратно в соответствующую .dll, выбор которой осуществляется примерно тем же способом, что и поиск сигнлтона-фабрики.

Интерфейс .dll, или интерфейс обобщённого синглтона, предоставляемого .dll:

int RunSomeOperation(I_Object*)


Реализация RunSomeOperation() в библиотеке, где "живёт", например TheIBMSensor:

int RunSomeOpertion(IObject *pSensor)
{
  TheIBMSensor *pIBMSensor = dynamic_cast<TheIBMSensor*>(pSensor);
  if (!pIBMSensor) return error_code_of_invalid_sensor;

  // Дальше пошли обращения к pIBMSensor
  pIBMSensor -> ...
}


ИМХО, другого обобщенного случая здесь быть не может, поскольку ты утверждаешь, что exe не меняется в зависимости от набора .dll.

---------------

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

[...]

S>>Извращения — это для тренировки мозгов. После которой простые и эффективные решения будут писаться куда проще и эффективней


VD>Проблема, в том, что С++ заставляет тренеровать могзги вместо выполнения основной рабты.


"Не умом поразить тщился, — с достоинством ответил отец Кин. — ...Умные нам ненадобны. Надобны верные." (А. и Б. Стругацкие, "Трудно быть богом").
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[39]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.03 13:07
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>"моей программы" — имеется ввиду та программа, которую разрабатывает и контролирует конкретный дизайнер.

VD>А компонент это тоже "твоя программа"? Или он обязан быть частью дезайрена?

А откуда взялось это противопоставление? Компонент обязан вписываться в дизайн, а не наоборот. Если он не подходит, то нужно вводить дополнительную функциональность или посылать нахрен данный конкретный компонент и заменять его другим, более подходящим. В противном случае архитектура ограничивается используемыми средствами, что не есть good. ИМХО, разумеется
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[43]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.03 13:07
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Мне уже достаточно силно надовел этот бесполезный спор. Двай я тебе покажу твой любимый С++ и его "прямой" дизайн в действии, а потом мы сравним это с аналогом на шарпе...


VD>Вот типичный компонент созданный средствами С++ (COM):


[skip — пример класса]

Ну и что ты демонстрируешь этим? То, как чаще всего, вероятно, пишут. ATL — неплохая библиотека, но, ИМХО, главное её достоинство — широкая распространённость. Сам посуди: реализацию QueryInterface можно спАрить с наследованием от заданного интерфейса, объявления элементов — вынести в виртуальные базовые классы и т.п. Другое дело, что ATL написана для VC6, который начинал сходить с ума от сложного наследования, где чередовались шаблоны и виртуальное наследование... так то — проблемы компилятора, альтернативы которому имеются уже достаточно давно.

VD>Надо признаться, что это красивая обертка на атл-е. Без нее код бы занимал бы раз в 10 больше места.

VD>И главный метод (QueryInterface) выглядил бы так:

VD>
VD>HRESULT QueryInterface(REFIID iid, void ** ppvObject)
VD>{
VD>    if(iid == IID_ITest1 || iid == IID_ITest2)
VD>    {
VD>        *ppvObject = this;
VD>        return S_OK;
VD>    }
VD>    return E_NOINTERFACE;
VD>}
VD>


VD>А вот "кривой" дизайн (C#):

VD>
VD>class CTest : IServiceProvider, ITest1, ITest2
VD>{
VD>    public object GetService(Type serviceType)
VD>    {
VD>        if(serviceType == typeof(ITest1) || serviceType == typeof(ITest2))
VD>            return this;
VD>        return null;
VD>    }
VD>    // Рабочие методы, нелизация интерфейсов ITest1 и ITest2... 
VD>};
VD>


VD>Собствнно можно и совсем универсально:


VD>
VD>class ServiceProvider : IServiceProvider
VD>{
VD>    public object GetService(Type serviceType)
VD>    {
VD>        if(serviceType.IsAssignableFrom(this.GetType())
VD>            return this;
VD>        return null;
VD>    }
VD>};

VD>class CTest : ServiceProvider, ITest1, ITest2
VD>{
VD>    // Рабочие методы, нелизация интерфейсов ITest1 и ITest2... 
VD>};
VD>


На C++ будет примерно то же:

class ServiceProvider : public BasicCoClassImplement<...>
{
  public:
  virtual HRESULT GetService(IID* iid, void **ppv)
  {
    return QIBase::QueryInterface(iid, ppv);
  }
}

class CTest : public ServiceProvider, Requestable<ITest1>, Requestable<ITest2>
{
  // Рабочие методы ITest1 и ITest2
}


Если заинтересует, расскажу о реализации Requestable и т.п., но суть дела не в этом. Ты демонстрируешь одну и ту же ситуацию — проверку композиции в рантайме.

VD>А вот примеры использования.

VD>С++:

VD>
VD>CCommPtr<ITest2> spITest2;
VD>HRESULT hr = obj->QueryInterface(__uuidof(spITest2), &spITest2);
VD>if(hr == S_OK)
VD>{
VD>    // Используем сервис...
VD>}
VD>


VD>C#:


VD>
VD>ITest2 test = (ITest2)obj.GetService(typeof(ITest2));
VD>if(test != null)
VD>{
VD>    // Используем сервис...
VD>}
VD>


VD>PS


VD>И не надо рассказывать, сказки, что можно вообще избавиться от рантайм проверок. Так как иначе это не будут компоненты (их нелзя будет создавать и использовать в рантайме).


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

ГВ>>Разницу чуешь?

VD>Чую, что тебе ненравится, но почему обяснить ты не в силах.

Либо плохо объясняю, либо плохие слушатели.

ГВ>> Это может быть единственным выходом, но я оценивать его всё равно буду негативно (или, если хочешь — с грустью, тоской, щемящим сердцем, великоросской рефлексией, сквозь зелёную бутылку, с поллитрой в руках, скрипя зубами, с самурайским мечом меж зубами, — ряд синонимов можно продолжить), поскольку присущие ему черты неизбежно останутся.

VD>Так как ты не докозал, что "присущие черты" плохи. Будет считать это утверждение основанное на небоснованных спорных предпосылках. ОК?

Ну на здоровье, можешь считать, что ненадёжность, обусловленная недостаточной композиционной проработкой, это — хорошо. И ещё с тем, что оверхед, связанный с необходимостью хоть какой-то компенсации этой ненадёжности — это кул. Я разве против? Но я не думаю, что эти факторы имеют преимущественно позитивную оценку у потребителей софта.

ГВ>>Или ты считаешь, что я должен прыгать от счастья, раз мне пришлось воспользоваться этим, единственным выходом?

VD>Я считаю, что обчиняя нужно приводить доказательства вины. Хотя бы если об этом попросили несогласные. Или не обвинять.

Абсолютно согласен. Вот и привожу.

ГВ>>Поскольку моя личная негативная оценка не может быть предметом обсуждения

VD>А зачем ты ее высказываешь? Раз высказал, значит она уже автоматом может стать предметом...

Личную оценку нет смысла обсуждать, поскольку спор о вкусах легко может превратиться в упражнения по базарному красноречию. А вот объективные характеристики и прочее — обсуждать очень даже интересно. И поводом для их обсуждения как раз может послужить личная оценка. Кстати, не находишь, что здесь появляются очень интересные высказывания?

ГВ>>, в силу субъективизма и возможной неадекватной её трактовки собеседниками то я: а) отказался от такой формулировки, но б) сформулировал описание характерных черт критикуемого мной подхода более точно.

VD>И таки так и не дал доказательств своим критическим суждениям.

Доказательство наличия оверхеда

Время исполнения вызова (T) при использовании rtti: Trtti = Ta + Tc, где Ta — время анализа полученного типа, Tc — время собственно вызова.

Время исполнения вызова (T) без использовании rtti, а именно — compile-time type information для статической типизации, ctti: Tctti = Tc, где Tc — время собственно вызова.

Вывод: Trtti > Tctti

Доказательство снижения надёжности композиции

Надёжность композиции — вероятность корректного сочетания типов данных во время выполнения программы.

Оценим надёжность композиции на основе оценки надёжности выполнения вызова метода некоторого интерфейса.

P — вероятность отказа выполнения вызова.

Для случая с использованием rtti

Prtti = Pa + Ps, Pa — вероятность отказа в результате анализа (получены некорректные данные), Ps — вероятность ошибки транслятора.

Учтём, что: 0 < Pa < 1; Ps << 1

Для случая выполнения анализа в compile-time
Pctti = Ps

Соотношение вероятностей безотказной работы:
D = (1-Pctti) / (1-Prtti) = (1-Ps)/(1-Pa-Ps)

С учётом того, что Ps можно пренебречь, получим:

D ~ 1/(1-Pa)

Дополнительное соображение: величина Pa отражает надёжность выполнения всех алгоритмов, работа которых прямо или косвенно участвует в выполненнии runtime-анализа.

Вывод: D > 1, т.е., использование ctti обеспечивает бОльшую надёжность композиции, чем использование rtti.

ГВ>>Поскольку разработчики C++ (Страуструп, во всяком случае, насколько я это знаю) придерживались схожих взглядов, я счёл возможным в декларативной форме присоединиться к ним. Декларативную же и краткую форму выбрал сознательно, поскольку сообщение написал в форум.

VD>Тбе декларативно и заявили, что ты не прав, в месте с Страуструпом. Что ты еще хочешь?

Вот я и доказываю свою правоту.

ГВ>>Ну как, понятно объяснил? Или стрелочки логических связей нарисовать?

VD>Такую позицию не стоило и озвучивать. Она ровным чсетом никому ничего не дает.

Не надо за всех расписываться. Дискуссия на самом деле небезынтересная получается.

ГВ>>А относительно "в некоторых не еденственный но намного боле простой"... Так опять ты апеллируешь к тому, что разница простой-сложный настолько велика, что это фактически — единственный выход для которого либо справедливо то, что я уже сказал, либо... несправедливо вообще ничего, поскольку "простой" и "сложный" — тоже субъективные оценки.

VD>Твои рассуждения противоречат логике. Любой дизайн тем лучше чем проще и эффективнее он решает поставленную задачу имеющимися средствами. А понятие "криво" является сугубо отнсительным. Так что если решение единственное, то кривым его называть бессмысленно.

Почему? Представь, например, что некто свалился в лужу дерьма. Измазался относительно слабо (во чудо-то!). Выбираться можно только вброд, но измазаться придётся ещё больше. Единственное это решение? Скорее всего — да. Будет он материться по этому поводу? Будет, я думаю.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[44]: Будущее C#
От: WolfHound  
Дата: 13.07.03 19:15
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>dynamic_cast<> вызывается в CreateObject? Если CreateObject возвращает общий интерфейс I_Object, то зачем в нём dynamic_cast<> ?

Есть application->CreateObject(className) и есть шаблон CreateObrejct<I_MyCoolInterface>(className) шаблон пинает application (вернее один из сервисов ака супер фабрика) и делает dynamic_cast на возвращенный обьект.
Сделано исключительно для того чтобы меньше писать.

ГВ>OK, значит dynamic_cast<> нужен только для получения частного типа из общего.

Считай что это QueryInterface

ГВ>Надеюсь, что в итоге я правильно тебя понял:

Все еще проще. ехе вобще ни чего не знает кроме того как работать с фабриками (вобще у него есть еще сервисы но это не важно).
Если в длл надо создать обьект то просто пинаем application (через CreateObject<>() для удобства) и он возвращает созданный объект или null.
Короче все проще некуда
if(Ref<I_Sensor> sensor=CreateObejct<I_Sensor>(sensorName))Это в нутри длл

CreateObejct<I_Sensor>(sensorName) пинает application->CreateObject
На результат применяю dynamic_cast после чего есть указатель на конкретный интерфейс или null.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.03 19:26
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>"моей программы" — имеется ввиду та программа, которую разрабатывает и контролирует конкретный дизайнер.

VD>>А компонент это тоже "твоя программа"? Или он обязан быть частью дезайрена?

ГВ>А откуда взялось это противопоставление? Компонент обязан вписываться в дизайн, а не наоборот. Если он не подходит, то нужно вводить дополнительную функциональность или посылать нахрен данный конкретный компонент и заменять его другим, более подходящим. В противном случае архитектура ограничивается используемыми средствами, что не есть good. ИМХО, разумеется


Сдается мне, что ты вообще не понимашь этого термина. Компонент (любой, можно даже сказать компонент как класс) принципиально не вяляется частью твой программы. Он — это внешняя независимая программа. Причем при компонентном подходе к проектированию, ты свой дизайн строишь на базе компонентов. Таким образом ситуация кода компонент не подходит для дизайна является ошибкой дизайна.

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

ГВ>dynamic_cast<> вызывается в CreateObject? Если CreateObject возвращает общий интерфейс I_Object, то зачем в нём dynamic_cast<> ?


За тем, что человек создает компонентную архитектуру. Он не знает, что подключает в рантайме, а dynamic_cast позволяет ему быть в большей уверенности относительно безопасности доальнейших действий.

Вообще-то это плохое решение. Но не из-за производительности, а из-за... ну, дагодались? Из-за убогости стандарта С++. Вернее из-за нежелания его авторов описмывать в нем что-либо связанное с рантаймом (акромя библиотек).

Правильное решение в КОМ-е. Оно универсально. А еще более правильное в дотнете. Оно ни только универсально, но просто и безопасно.

ГВ>
ГВ>int RunSomeOperation(I_Object*)
ГВ>


Думаю, что I_Object — это интерфейс. Так что скорее:
I_Object->RunSomeOperation()

ГВ>ИМХО, другого обобщенного случая здесь быть не может, поскольку ты утверждаешь, что exe не меняется в зависимости от набора .dll.


Скорее всего он говорит, о механизме возврата самих I_Object (ну и дальнейшей работе с ним).
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.03 19:26
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Проблема, в том, что С++ заставляет тренеровать могзги вместо выполнения основной рабты.


ГВ>"Не умом поразить тщился, — с достоинством ответил отец Кин. — ...Умные нам ненадобны. Надобны верные." (А. и Б. Стругацкие, "Трудно быть богом").


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

ГВ>Ну и что ты демонстрируешь этим?


Догадайся с трех раз.

ГВ>То, как чаще всего, вероятно, пишут. ATL — неплохая библиотека, но, ИМХО, главное её достоинство — широкая распространённость.


Ты видил более удобную? А нет, так что зря воздух сотрясать?

ГВ> Сам посуди: реализацию QueryInterface можно спАрить с наследованием от заданного интерфейса, объявления элементов — вынести в виртуальные базовые классы и т.п. Другое дело, что ATL написана для VC6, который начинал сходить с ума от сложного наследования, где чередовались шаблоны и виртуальное наследование... так то — проблемы компилятора, альтернативы которому имеются уже достаточно давно.


Во-во. Чтобы заткнуть дыру в рантайме мы готовы вылить ушат грязи на нивчем не повинный компилятор. Только зачем? Возможности писать так же просто и красиво как дотнете нет ни в одном компиляторе кроме МС++.


ГВ>На C++ будет примерно то же:


ГВ>
ГВ>class ServiceProvider : public BasicCoClassImplement<...>
ГВ>{
ГВ>  public:
ГВ>  virtual HRESULT GetService(IID* iid, void **ppv)
ГВ>  {
ГВ>    return QIBase::QueryInterface(iid, ppv);
ГВ>  }
ГВ>}

ГВ>class CTest : public ServiceProvider, Requestable<ITest1>, Requestable<ITest2>
ГВ>{
ГВ>  // Рабочие методы ITest1 и ITest2
ГВ>}
ГВ>


Не будт на С++ то же. Так как твой Requestable уже перебор, ну, а BasicCoClassImplement увеличивает отрыв. Тебе показали простоту с какой "убогий" язык без шаблонов вегко и элегантно решает проблемы, а ты в ответ "дык, мы ща по бырому десяток килобайт оберток наклепаем....".


ГВ>Если заинтересует, расскажу о реализации Requestable и т.п., но суть дела не в этом. Ты демонстрируешь одну и ту же ситуацию — проверку композиции в рантайме.


Может быть ты не заметил, что без проверки в рантайме тут необойтись? Хотя у тебя это уже в норме вещей.

Кстати, можешь на этом примере продемострировать всю кривость этого подхода.

ГВ>Не путай, пожалуйста, рантайм-проверки результатов операций управления ресурсами и рантайм-проверки типов, т.е. — верификацию композиции. Понятие "компонент", как и "модуль" вовсе не означает необходимости проверок типов.


У тебя пунктик по поводу типов. Ты так долго себя убеждал, что типы не является обычными данными, что видимо привык. Нет никакой разницы между строкой символов полученной из-вне и типм. Это ты все сам придумал.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.03 19:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

AVK>>Для качественной реализации фабрики необходима возможность поднятия экземпляра по имени класса.

WH>Есть.
AVK>>Все реализации на основе шаблонов все равно требуют чтобы где нибудь явно прописывали список классов, которые может производить фабрика, а это уже менее качественная реализация.
WH> Единого списка нет.

Можно несколько вопросов? Спасиба.

И какой рантайм тебе пришлось для этого создать?

Можно ли написать библиотеку на разных компиляторах? Ну, хотя бы С++-ых, хотя конечно желательно вообще на любых.

Можно ли в твоей системе загружать в память только требуемые длл-ки? И если да, то как ты хранишь информацию о типах?

Ну, и последний. Зачем вообще было изобретать велосипед? Ведь есть КОМ. Почему был просто не взять готовую реализацию?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Будущее C#
От: WolfHound  
Дата: 13.07.03 19:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И какой рантайм тебе пришлось для этого создать?

~300 строк (не считая других сервисов они еще примерно столько же)
VD>Можно ли написать библиотеку на разных компиляторах? Ну, хотя бы С++-ых, хотя конечно желательно вообще на любых.
Нет. Это не требовалось.
VD>Можно ли в твоей системе загружать в память только требуемые длл-ки?
Да.
VD>И если да, то как ты хранишь информацию о типах?
В карте фабрик. Ключь — имя класса
VD>Ну, и последний. Зачем вообще было изобретать велосипед? Ведь есть КОМ. Почему был просто не взять готовую реализацию?
COM это слишком тяжолая штука для моей задачи. Хотя ни что не мешает им пользоватся например для работы с ADO или отправки данных в OPC server.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.03 20:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Можно ли в твоей системе загружать в память только требуемые длл-ки?

WH>Да.
VD>>И если да, то как ты хранишь информацию о типах?
WH>В карте фабрик. Ключь — имя класса

Обрати внимание на предыдущий вопрос. Они связаны. Так как если ты читаешь карты из длл-ки, то невольно грузишь их все в память.

WH>COM это слишком тяжолая штука для моей задачи. Хотя ни что не мешает им пользоватся например для работы с ADO или отправки данных в OPC server.


Ты почти повторил его. Ком штука концептуальная. И из него можно брать столько сколько нужно.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Будущее C#
От: WolfHound  
Дата: 13.07.03 20:20
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Обрати внимание на предыдущий вопрос. Они связаны. Так как если ты читаешь карты из длл-ки, то невольно грузишь их все в память.

Я не понял ты про фабрики или дллки? Если про фабрики то в случае загрузки дллки загружаются все фабрики из нее. А что касается дллек то какие грузить, а какие нет это мое дело.

VD>Ты почти повторил его. Ком штука концептуальная. И из него можно брать столько сколько нужно.

Я знаю только без гемороя с GUID'ами и необходимости ручками прописывать новые интерфейсы в QueryInterface + куча рюшечек не доступных COM'у.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.03 00:12
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>Я знаю только без гемороя с GUID'ами и необходимости ручками прописывать новые интерфейсы в QueryInterface


Что в твой мам, что в атл-ный. Какая разница?

WH> + куча рюшечек не доступных COM'у.


Например?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Будущее C#
От: WolfHound  
Дата: 14.07.03 04:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что в твой мам, что в атл-ный. Какая разница?

Мне не нужны GUID'ы и мне не надо писать QueryInterface это делает компилятор.

WH>> + куча рюшечек не доступных COM'у.

VD>Например?
Данные в интерфейсе. Не критично но очень удобно иметь прямой доступ к проперти подобным обьектам. К стати в .NET когда надо около сотни проперти подобных полей это придеться писать сотню пропертей в каждом кучу кода к каждому еще по полю с данными, а в моем случае не одно... В принципе может помочь внешний генератор но это криво.
Я же пишу IntParam<ParamID> MyIntParam; и регистрирую в конструкторе MyIntParam(this) компилятор забыть не даст.(В принципе при не большой модификации стандарта регистрация не понадобится) ParamID служит для работы с железкой (так что от него не избавиться) и по совместительству для сериализации.
Шаблонные адапторы к виртуальным функциям. Можно налепить и к КОМу через наследование но это не удобно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 14.07.03 07:31
Оценка:
Здравствуйте, IT, Вы писали:

S>>Ну тут он отчасти прав Но вот если одновременно с расширением анахронизмы сишные повыкидывать, то мог бы полный рулез получиться.


IT>C#?


Нет, C#, на мой взгляд, совсем не в том направлении пошел.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[47]: Будущее C#
От: WolfHound  
Дата: 14.07.03 08:25
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Сотня пропертей в одном классе это надо что то в консерватории поправить

Как? Если они один к одному в железку отображаются? А иногда несколько пропертей в одну ячейку.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: Будущее C#
От: WolfHound  
Дата: 14.07.03 08:25
Оценка:
Здравствуйте, Sergey, Вы писали:

VD>>Ты сказал, что непонятны они только тем кто с ними работать не умеет. Так вот я умею с ними работать очень неплохо.

S>С шаблонами? Вряд ли.
Согласен.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[43]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.07.03 08:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Проблема, в том, что С++ заставляет тренеровать могзги вместо выполнения основной рабты.


ГВ>>"Не умом поразить тщился, — с достоинством ответил отец Кин. — ...Умные нам ненадобны. Надобны верные." (А. и Б. Стругацкие, "Трудно быть богом").


VD>Это ты к чему?


К тому, что ты хорошо отметил общие тенденции.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 14.07.03 09:14
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Правильно, это алгоритм выполняесый компилятором. И генерирующий код — подставляющий вызовы нужных функций в нужные места.

VD>Да ничего он не подставляет. А главно, это все настолько через ухо, что пользоваться этим очень сложно.

Ну, код тебе приводить бесполезно, тебе его лень смотреть, книг ты принципиально не читаешь — оставайся при своем мнении.

VD>И как ты будешь отлаживать более менее сложный алгоритм засунутый рекурсивный шаблон?

Только сообщениями об ошибках, к сожалению.

VD>Или что будешь делать если рекурсия для решения некоторой проблемы не является удобным подходом?

Буду использовать boost::mpl, когда фирма, где я работаю, соблаговолит переползти на более стандартный компилятор.

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


S>>Ха-ха. Сгенери. Быстрее будет все руками прописать, чем такой код отлаживать.

VD>Завист от объемов. Но факт в том, что его можно будет отлафивать.

Угу, только код-то получаться иногда разный будет, и все его варианты ты по определению не отладишь... И наверняка иногда он вообще с синтаксическими ошибками будет генерироваться — у меня на эти ошибки выругается компилятор еще до поступления кода к пользователю, а у тебя?

S>>Черта с два ты макросами такое сделаешь.

VD>Ну, ну. В чем проблема?

Отлаживаться плохо, например. Ну и с типобезопастностью дело никудышно у макросов обстоит. Прагму внутрь макроса не вставишь. Да полно у препроцессора недостатков.

S>>В гугле набрать слабо?

VD>А ссылку дать слабо? Или вопросом на вопрос интереснее?

Я ее не помню. Ну ладно, потрачу пару минут, найду: http://sourceforge.net/projects/opencxx/

S>> А зверь простой — продвинутый препроцессор, предоставляющий доступ к метаинформации до компиляции. К сожалению, небезглючный — потому им и не пользуюсь.


VD>Он к языку привязан?


Да.

VD>Или его можно и для того же шарпа применить?


Тебе макросы для шарпа нужны, что ли? А чем плюсовый препроцессор не устраивает?

VD>Ага. Долго расписывать то чего на свете не существует.

Естественно, дольше, чем то, что существует. Новое сначала придумать надо.

VD>Неужели просто тяжело признать факт? С++ не расчитан на работу в компонентной среде и для того чтобы его к ней приобщить придется изобрести свой КОМ.


А я с этим спорил? Не приспособлен, конечно. Но меня это как-то мало волнует, COM надо использовать там, где нужен интерыфейс со сторонним кодом, а не пихать во все дыры.

S>>Мы вроде про компил-тайм разговаривали, а?


VD>Тебе шашечки или ехать?

Мне ехать, но чтоб платить по счетчику и по пути не ограбили. С шашечками ехать, как-то спокойнее, знаешь ли.

VD> Генерация кода эмитом и есть компайлтайм. Хочешь засунь его в процесс сборки проекта, а хочешь выполняй по-требованию. Скорость будет как у С++-ного оптимизированного кода. В чем разница то?


А то ты не видишь? Компилтайм твой будет на машине клиента, и все ошибки вылезут, когда программа будет запущена, а не когда ты проект собираешь.

VD>Да никто ничего не удаляет. Это тебе все хочется что-нить через анус сотворить. Атрибуты прекрасно и так работают.

Угу, то, что можно делать в компил-тайме — выносят в рантайм. Нечего сказать, прекрасно.

VD>Это расширение метаданных. Вот в плюсах такого нет. И это их огромное достоинство.

S>>Странно, в D&E он писал, что GC должен предоставляться компилятором. Ссылку можно?
VD>Ссылку уже вряд ли но чуть ли не в своей главной поэме.
Не помню такого, честно говоря.

S>>Ну тут он отчасти прав Но вот если одновременно с расширением анахронизмы сишные повыкидывать, то мог бы полный рулез получиться.

VD>Гы-гы. Что тогда от языка останется? Шаблоны?
Да почти все. Чуть меньше возможных вариантов деклараций, нафиг присваивания из ифов, explicit для кунструктором — по умолчанию, половину преобразований типов выкинуть, никаких компилер-генерируемых конструкторов копирования, если в классе есть члены-указатели ну и еще кое-что по мелочи.

S>>И правильно. Это дело индустрии и на универсальный язык влиять не должно. Ну нафига одинаковый рантайм для какого-нибудь DSP и для персоналки? Рантаймом должны совершенно другие люди и организации заниматься.


VD>Почитай про дотнет и яву. Тогда поймешь.

Ну и много на яве под контроллеры пишут? Про приложения под девайсы мельче чем смартофон что-то не слыхать.

S>>Про АОП больше Александреску выступает. Жаль только, соответствующих папирок с конференций в сети не валяется.

VD>Ага. Как всегда через шаблоны и макросы. Ну, не вставлять же в язык дополнительные кострукции? Пусть даже простые и эффектинве...

Я думаю, многие бы хотели добавить в С++ простые и эффективные средства для работы с метаинформацией. И чтоб "бесплатные" при этом. Но пока их нет — придумывают, как обходится без них.

S>>Я ж говорю — если б она была доступна в компил-тайме, ее не сложно было бы вытащить и в рантайм. Правда, как обычно, каждый поставщик компилятора (стандартной баблиотеки) сделает свою метаинформацию несовместимой с другими...


VD>Зачем вытаскивать да еще и "каждтому..."? Нужно описать ее радимую в стандарте и пусть все этот стандарт реализуют. В дотнете именно так и сделано. Получилоь замечательно.


А мне вот нафиг не надо, чтоб каждый какер-пионер имел полную информацию о тех объектах, которые я пользователям показывать не собираюсь. Да еще и память под это расходовать...

VD>Вот тольк я не пойму чем метаданные в рантайме мешают?


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

S>>Являются-являются. Я с макросами так обжигался...


VD>Ну, тут я тебе могу сказать... опыта у тебя мало.

С макросами? Естественно, я же их очень редко использую. Ну а те еще и чужие были, а я об их существовании вообще не знал

VD>Я так пишу без проблем. Но в отличие от тебя прикрасно понимаю, что то-что я привык обходить грабли не делает из граблей ковровую дорожку. Та же фигня с извращениями на шаблонах. Когда ты делашь универсальный алгоритм, применение шаблонов выглядит изящно и правомерно. А когда ты используя откровенные лазейки пытаешся использовать шаблоны для решения проблем для решения которых они просто не предназначены, то получается каша. Которую не то, что поддерживать, ее писать то сложно.


VD>В общем, мое мнение таково: Для решения пролем лучше использовать специально заточенные инструменты.


Угу, библиотеки, например. Чувство меры терять не надо. Не, конечно культурные люди для поедания устриц один инструмент используют, для лангустов — другой, но сколько это создает геморроя там, где хватило бы вилки и ножа...

S>>Для шаблонов это не так актуально. Правда, когда имена становятся очень длинными, отладчик просто перестает их видеть — это полная жопа.

VD>Это предсказуемое следствие сложности языка.
Не сложности языка, а примитивизма средств разработки.

S>>А я — для тестирования COM'а.

VD>Я раньше тоже для этого использовал. (Кстати, странно. Ведь по-твоему никакой разницы с плюсами у ВБ нет. )

Хинт — в плюсовом коде не обязательно использовать COM. Писать надо в том стиле, который хорошо поддерживается языком, тогда и на плюсах быстрей, чем на VB писать будешь. А COM плюсами фигово поддерживается.
Ну а для тестирования разница вообще огромная — в VB не все типы из плюсов разрешены.

S>>Они вроде даже для VB и жабы есть.

VD>Они там ненужны. Ни ВБ ни Ява не могут привести к таким проблемам как на С++, а на С++ без них в больших проектах никуда.

Да ну? Мне как-то BSTR с бинарными данными потребовалось в ASCII base64 сконвертировать, на VB — так оно так забавно валилось, пока не отладил... И не говори мне, что в VB нельзя с "сырой" памятью работать — еще как можно, если припрет.

S>>Это тоже правильно. В плюсах на совместимость с С тоже следовало бы забить с самого начала. Хотя в этом случае С++ я сейчас вряд ли бы использовал


VD>Да плюсы очень сильно не совместимы с С.


Вот-вот. Совместимость все равно потеряли, а дыр ради нее оставили немеряно.

VD>>>Огромным шагом вперед стал отказ от указателей. По этому поводу можно ерничать.

S>>На самом деле, просто спрятали указатели внутрь смарт-пойнтеров. Чем это от плюсов отличается?

VD>Нет в Шарпе никаких смарпоинтеров. Там целостная идеология.


Верю, верю. Но от смарпоинтеров это мало чем отличается.

S>>Ну да, вместо GPF — ексепшон. Сбой-то остается, последствия просто другие. Так же, как и смартпойнтерами в плюсах.


VD>В 90%-ах просто нет посылок для возникновения эксцепшонов.


Угу, а в плюсах — в 99% просто нет посылок для возникновения ошибок.

VD>Да и эксцепшон — это тебе не испорченая память.


Я уж и забыл, когда мой код последний раз память портил.

VD>Проблема AV не в механизме SEH (который кстати и используется в дотнетных исключениях), а в том, что в подавлющем количестве случаев после него (изи до него) портится память. А это уже не лечится. И если какой-нибудь ворд просто грохнется, а юзер отдуши проматерится, то в сервере приложений такой прикол может обернуться нехилыми потерями денег для компании.


Все так, только порча памяти — достаточно редкое явление.

S>>Что именно треп? Рантайм маленький? Или он уже у каждого пользователя установлен?


VD>См. выше. Хотя про натайм тоже треп. Ты ведь в своей конторе хочешь применять? У вас сеть какая? 20 мег сможете прокачать?


Мы вообще-то софт через интернет в основном продаем, и дистрибутив на 50% утолщать — ну совсем не с руки. Да еще с установкой этого рантайма у клиентов париться (а они, блин, по всему свету) — это уж вообще через край.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 14.07.03 09:40
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Ну а лично для меня это уже излишне.


VD>Приятно, что ты не говоришь, что это вообще ошибка дизайна.


Это потому, что ошибки дизайна могут быть только в конкретном дизайне А мы никакой конкретный дизайн пока не обсуждаем.

VD>Еще как не серьезно. Вот давича у меня как раз была подобная задача. В итге насандалил карт с описаниями и на макросах с инклюдами вывернулся. Ну, еще на какой-то матери.


Это доказывает только то, что тебе макросы привычнее шаблонов.

VD>Это уже печать языка. Так сказать приплюснутость. Наньше такой эффект был у ярых ассемблерщиков. Они тоже гвоорили, что МАСМ выгдядит нормально.


Ну, он и выглядит нормально, если уметь на него смотреть. Мне вот часто говорят, что функционально программирование полный рулез и показывают какой-то код на OCML'е, который на мой посторонний взгляд просто ужасен Но из этого не следует, что тот код плох — просто я его с трудом понимаю.

VD>О вкусах как говортся не спорят, но лично мне такой код очень не нравится.


S>>Лишнего — три строчки на сериализуемый класс.


VD>Нет батенька. Там каждая переменная была обернута.


А это не лишнее — это то же самое, что и атрибут с параметрами для переменной выставить.

VD>В дотнете переменные к контролам вообще не нужно привязывать. Любой контрол объект, т.е. сам по себе переменная.


Хм, а если я хочу из edit'а float'овские данные забирать без написания лишнего кода? Да еще с валидацией?

VD>Много разных способов. Где-то все уже и так есть и грамотно. Где-то можно сгенерировать код и выполнять его.


Ну дык код-то генерировать придется уже в рантайме, на машине клиента.

VD>Ну, что тут можно скзать. У нас разные цели. Мне нужен рабочий код с минимумом затрат, а тебе красивые извраты.


У нас просто разные понятия о минимуме затрат

VD>Что значит еще? Идее метапрограммирования думаю столько же лет сколько существуют высокоуровневые языки.


Ссылки и цитаты, плиз.

VD>А в плюсах этих изменений видимо уже дождаться будет нельзя. По крайней мере Страуструб рубит все свежие веянья на корню.


Ты его явно демонизируешь

S>>Потери производительности — это хорошо?

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

Ну это кому как

S>>Делать в рантайме то, что без труда можно было бы делать в компил-тайме — уродство.


VD>Короче, эта беседа снова плавно перетекает в пустобрехство. Мне это не нравится, так что я из нее выхожу.


Я тоже — завтра в отпуск уматываю

VD>Или давай не брасаться столь пустыми и звонкими фразами.


Чья бы корова мычала "А до генераторов кода этому подходу как до Пекина раком." и т.д., причем абсолютно бездоказательно.

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


S>>Только надежность этого кода никакая будет.


VD>И откуда ты это взял? Снова треп.


Ну а ты головой-то подумай, что надежней будет: сгенерировать код компилятором у себя на машине, и тут же все ошибки увидеть, или генерировать его на машине клиента?

S>>Херню потому что повторяешь Компилятор проверяет, унаследована ли переменная ddxMembers у текущего класса от нужного типа, и если нет — рекурсивно делает то же для базового класса. Пока не упрется в терминальный базовый класс. Я только задаю правила, по которым компилятор это делает. Это именно программа, выполняемая компилятором — такая же, как и та, что заставляет компилятор вычислять факториал.


VD>Ты не правила задаешь, а извращаешся на эзоповом языке. А до генераторов кода этому подходу как до Пекина раком.


Бездоказательное пустозвонство Ты даже код, который это делает, не видел.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[2]: Будущее C# - вот это флейм!!!!!!!
От: IT Россия linq2db.com
Дата: 14.07.03 16:29
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Цитата из письма моего друга, активно действующего программиста, руководителя лаборатории и нескольких проектов. Заранее прошу извинения за эмоциональность монго друга, но видимо, у него сильно накипело!


Похоже что твой друг — воинствующий динозавр и убеждать его в обратном не стоит
Сори, не в обиду, но выглядит это никак не иначе.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Будущее C# - вот это флейм!!!!!!!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.07.03 18:18
Оценка:
Здравствуйте, LaptevVV, Вы писали:


LVV>Я лично ЗАПРЕТИЛ применение Борланда 5 и выше, когда исследовал
LVV>несколько объектных файлов. На х@@. Я хочу спать спокойно.


Мда... Слушайте, мож это шутка такая?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[46]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 03:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Мне не нужны GUID'ы и мне не надо писать QueryInterface это делает компилятор.


Неужели они так страшны, что из-за этого нужно изобретать заведомо менее универсальный велосипед?

WH>>> + куча рюшечек не доступных COM'у.

VD>>Например?
WH>Данные в интерфейсе.

Это скорее ошибка дизайна.

WH> Не критично но очень удобно иметь прямой доступ к проперти подобным обьектам.


Так проперти или данным?

WH> К стати в .NET когда надо около сотни проперти подобных полей это придеться писать сотню пропертей в каждом кучу кода к каждому еще по полю с данными, а в моем случае не одно... В принципе может помочь внешний генератор но это криво.


Не понял? А какие приемущетсва у С++? В дотнете классы могкут иметь публичные члены. В общем не ясно о чем ты...

WH>Шаблонные адапторы к виртуальным функциям. Можно налепить и к КОМу через наследование но это не удобно.


А какова их цель?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 03:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Как? Если они один к одному в железку отображаются? А иногда несколько пропертей в одну ячейку.


Дык надо было для этой ячейки классик создать...
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 03:39
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Это потому, что ошибки дизайна могут быть только в конкретном дизайне А мы никакой конкретный дизайн пока не обсуждаем.


Логично. Вот только тут кое-кто утверждал, что дизайн построеный на метаданных — это принципяльно кривой дизайн.

S>Это доказывает только то, что тебе макросы привычнее шаблонов.


Вовсе нет. Просто задача решалась значительно проще на макросах. Был бы приличный генератор кода подрукой выбрал бы его.

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

S>Ну, он и выглядит нормально, если уметь на него смотреть.


— Ген! Сомотри... Мой портрет!
— Чебурашка, а что это он какой-то странный?
— Чем?
— Ну, он весь как-то стнанно разлинован и вообще...
— А! Это его месник рисовал... Он так видит!



S> Мне вот часто говорят, что функционально программирование полный рулез и показывают какой-то код на OCML'е, который на мой посторонний взгляд просто ужасен Но из этого не следует, что тот код плох — просто я его с трудом понимаю.


Ничего не могу скзать по причине не знания OCML-я. Хотя в отношении Модулы у меня такое же впечатление. Но это концепции. А тут речь о банальном излишестве кода на еденицу полезного действия. Бывают кстати и обратные перегибы. Например, регэкспы.

S>А это не лишнее — это то же самое, что и атрибут с параметрами для переменной выставить.


Вот ттлько атрибуты появляются изреда, не занимают времени компилятора и не засоряют код.

S>Хм, а если я хочу из edit'а float'овские данные забирать без написания лишнего кода? Да еще с валидацией?


Тогда ты пишешь класс редактирующий float-ы и потом всю жизнь пользуешся с ним. Это же ОО. Если влом писать лезешь в Интернет за халявой или платными продуктами.

S>Ну дык код-то генерировать придется уже в рантайме, на машине клиента.


Это как ты зашочешь. Можно и в во время компиляции генерить, а можно и на глиенте. Кстати, это со временем будет все выгоднее. Клиенты то разные и генерация это может учитывать. Хотя сам msil по большему счету уже это обеспечивает.

S>У нас просто разные понятия о минимуме затрат


Да. Для меня это бестрый результат с минимум напряжения.

VD>>Что значит еще? Идее метапрограммирования думаю столько же лет сколько существуют высокоуровневые языки.


S>Ссылки и цитаты, плиз.


Я тут не специалист. Погляди в гугле на слова SML, Prolog, Lisp, Smalltalk. Все они имеют зачатки метапрограммирования которые появились очень давно. Хотя еще раз повторю в этой области я профан.

S>Ты его явно демонизируешь


Возможно. Через лет пять увидим.

S>Чья бы корова мычала "А до генераторов кода этому подходу как до Пекина раком." и т.д., причем абсолютно бездоказательно.


Ты генераторы кода видел? Мне кажется — это очевидно. Те же макросы имеют куда большие возможности ито не дотягивают до генераторов по возможностям.

S>Ну а ты головой-то подумай, что надежней будет: сгенерировать код компилятором у себя на машине, и тут же все ошибки увидеть, или генерировать его на машине клиента?


Это ты подумай. Генерит код-то машина. Если алгоритм генерации правильный, то код будет даже надежнее рукописного. Он же по алгортму сделан. А отлафивается код один фиг в конечном счете прогонами. Так что однажды отлаженный генератор будет довать очень даже надежный код.

S>Бездоказательное пустозвонство Ты даже код, который это делает, не видел.


Нуда нам серым. Вот изобрази на шаблонах хотя бы вот такой примитив, а потом поговорим:
Файл с описанием структуры таблиц (CODER_TOKEN_DEF.h):

CODER_TOKEN_DEF_BEGIN(TypeDefOrRef)
    CODER_TOKEN_DEF_TABLE(TypeDef)
    CODER_TOKEN_DEF_TABLE(TypeRef)
    CODER_TOKEN_DEF_TABLE(TypeSpec)
CODER_TOKEN_DEF_END(TypeDefOrRef)

// И еще много много таких обявлений...

CODER_TOKEN_DEF_BEGIN(ResolutionScope)
    CODER_TOKEN_DEF_TABLE(Module)
    CODER_TOKEN_DEF_TABLE(ModuleRef)
    CODER_TOKEN_DEF_TABLE(AssemblyRef)
    CODER_TOKEN_DEF_TABLE(TypeRef)
CODER_TOKEN_DEF_END(ResolutionScope)

#undef CODER_TOKEN_DEF_BEGIN
#undef CODER_TOKEN_DEF_TABLE
#undef CODER_TOKEN_DEF_END


Описание макросов для генерации методов:

#define CODER_TOKEN_DEF_BEGIN(TokenName)   \
protected:                                                                 \
void InitCodedToken##TokenName()           \
    {                                        \
        const Tbl tables[] =                   \
        {

#define CODER_TOKEN_DEF_TABLE(TableName)            ciTbl##TableName,

#define CODER_TOKEN_DEF_END(TokenName)                             \
        };                                                             \
        int iMaxCnt = m_pSchema->m_cRecs[tables[0]];                   \
        for(int i = 1; i < GetElemCount(tables); i++)                  \
        {                                                              \
            int iCnt = m_pSchema->m_cRecs[tables[i]];                    \
            if(iCnt > iMaxCnt)                                           \
                iMaxCnt = iCnt;                                            \
        }                                                              \
        int iBits = NBits<GetElemCount(tables)>::GetBitsCount();       \
        int iMaxVal = iMaxCnt << iBits;                                \
        const UINT ciMask = 0xFFFF;                                    \
        if(((UINT)(iMaxVal & ciMask)) != iMaxVal)                      \
        {                                                              \
            m_bSize4##TokenName = true;                                  \
            m_iSize##TokenName = 4;                                      \
        }                                                              \
        else                                                           \
        {                                                              \
            m_bSize4##TokenName = false;                                 \
            m_iSize##TokenName = 2;                                      \
        }                                                              \
    }

#include "CODER_TOKEN_DEF.h"


А это для декларации переменных:

#define CODER_TOKEN_DEF_BEGIN(TokenName) m_bSize4##TokenName(false), \
                                         m_iSize##TokenName(0),
#define CODER_TOKEN_DEF_TABLE(TableName)
#define CODER_TOKEN_DEF_END(TokenName)

#include "CODER_TOKEN_DEF.h"


И таких фигней через раз. В итоге создаются десятки (порфдка 40-80 классов) представяющие собой некий АПИ. Вот попробуй создать такое же на шаблонах.

PS

А ведь хороший генератор позволил бы создать более универсальные алгоритмы и отладфивать процесс генерации.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 03:39
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ну, код тебе приводить бесполезно,


От чего же? Если он чистый и хорошо читабельный, то гляну. А на навороты глядеть неохота.

S>тебе его лень смотреть, книг ты принципиально не читаешь —


Да ты лучше меня знаешь, что я принципяльно делаю и не делаю. Прям шаман.

S>оставайся при своем мнении.


Ну, хоть на этом спасибо.

VD>>И как ты будешь отлаживать более менее сложный алгоритм засунутый рекурсивный шаблон?

S>Только сообщениями об ошибках, к сожалению.

Во-во. А это при больших объемах кодогенерации оооОочень сложно. Я лично не раз с этим сталкивался. А ведь в таких подходах порой и сообщение некуда впихнуть.

VD>>Или что будешь делать если рекурсия для решения некоторой проблемы не является удобным подходом?

S>Буду использовать boost::mpl, когда фирма, где я работаю, соблаговолит переползти на более стандартный компилятор.

Во-во. Еще и не все компиляторы это дело хавают. А те что хавают начинают безбожно тормозить. Пару сотен таких использований и проект компилируется по 10 минут на P4.

S>Угу, только код-то получаться иногда разный будет, и все его варианты ты по определению не отладишь...


Код плучается по алгоритмам. И нужно отлаживать именно их, а не конечный код. Практика показывает, что чем меньше участие человека тем меньше ошибок. 99% ошибок — это человеческий фактор.

S> И наверняка иногда он вообще с синтаксическими ошибками будет генерироваться — у меня на эти ошибки выругается компилятор еще до поступления кода к пользователю, а у тебя?


Дык код то все равно компилировать. Так что тоже компилятор. Другое дело кода. Но синтаксические ошибки в компиляторе, это как раз фигня. Намного страшнее лаогические.

S>>>Черта с два ты макросами такое сделаешь.

VD>>Ну, ну. В чем проблема?

S>Отлаживаться плохо, например.


Забавные рассуждения. Тяжело == черта с два.

S> Ну и с типобезопастностью дело никудышно у макросов обстоит. Прагму внутрь макроса не вставишь. Да полно у препроцессора недостатков.


Недостатков у препроцессора хаватает. Но в итоге все зависит от рук. Если же говорить, о гибкости, то макросы куда гибче. Тебе же именно гибкость нужна? Руки то у тебя в порядке.

S>Я ее не помню. Ну ладно, потрачу пару минут, найду: http://sourceforge.net/projects/opencxx/


Сенкс. Я вот попробовал поискать и зарылся в хламе. С описанием там как-то туго. Жаль...

VD>>Он к языку привязан?

S>Да.

Жаль.

S>Тебе макросы для шарпа нужны, что ли? А чем плюсовый препроцессор не устраивает?


Дык он плюсовый. Да и желательно было бы видеть результаты его творчества. К тому, же ограничения... отсуствие цыклов, переменного количества параметров, невозможность метаанализа...

S>Естественно, дольше, чем то, что существует. Новое сначала придумать надо.


... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 03:58
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>>Ты сказал, что непонятны они только тем кто с ними работать не умеет. Так вот я умею с ними работать очень неплохо.

S>>С шаблонами? Вряд ли.
WH>Согласен.

Гы-гы.

PS

И почему чем неопытнее люди, тем чаще они считают, что уменее всех остальных?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Будущее C#
От: WolfHound  
Дата: 15.07.03 08:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык надо было для этой ячейки классик создать...

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

VD>Неужели они так страшны, что из-за этого нужно изобретать заведомо менее универсальный велосипед?

Мне не нужна уневерсальность. Мне надо как можно меньше гемороя, а GUID, IDL... это геморой.

WH>> Не критично но очень удобно иметь прямой доступ к проперти подобным обьектам.

VD>Так проперти или данным?
Данным косящим под проперти.

VD>Не понял? А какие приемущетсва у С++? В дотнете классы могкут иметь публичные члены. В общем не ясно о чем ты...

Дык перегрузка присваивания запрещена даже у value типов. Следовательно обьект под проперти косить не может. А даже если бы и было в интерфейс всеравно не засунишь. Препроцессор бы помог но и его нету. Остается внешний кодогенератор.

VD>А какова их цель?

Как и у всех остальных шаблонов.
Писать меньше и читать проще. Часто позволяют сэкономить символов 10-50 что очень не плохо.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Будущее C# - вот это флейм!!!!!!!
От: LaptevVV Россия  
Дата: 15.07.03 13:01
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>

LVV>>Я лично ЗАПРЕТИЛ применение Борланда 5 и выше, когда исследовал
LVV>>несколько объектных файлов. На х@@. Я хочу спать спокойно.
ГВ>


ГВ>Мда... Слушайте, мож это шутка такая?

Нет, не шутка. Пишут системы реального времени. Все прошивается, видимо связано с риском крупных аварий.
Поэтому, как в том анекдоте:
Работает? Работает!
Проверял? Проверял!
Вот и не трогай ничего, пусть работает!

И я своего друга прекрасно понимаю, так же как и Михаила Донского (одного из авторов Каиссы — первого чемпиона по шахматам среди компьютеров). Он, когда переходил с Лексикона на Word, тоже говорил: мне не нравится, когда меня ВЫНУЖДАЮТ платить за то, что мне не фактически НУЖНО.
Так и С# — не вижу я особых преимуществ ни перед С++, ни перед Java. У этих языков переносимость на 3 порядка выше, чем у до диеза.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Будущее C# - вот это флейм!!!!!!!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.07.03 13:29
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Цитата из письма моего друга, активно действующего программиста, руководителя лаборатории и нескольких проектов. Заранее прошу извинения за эмоциональность монго друга, но видимо, у него сильно накипело!


Ну вот, хороший пример теперешней ситуации. Любая новая технология всегда будет встречать яростный отпор и непонимание.

Что же касается данного конкретного человека то видимо его задачи мало связаны с программированием, иначе цифра в 0.05% выглядит просто дико. А поскольку такие люди уже устроились на своем месте и дальше двигаться не желают, то они по прежнему уверены в том что все новое это ересь. До тех пор пока не столкнуться с задачкой, где объем программинга (в особенности модификации уже существующего кода) превысит те самые 0.05%.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[3]: Будущее C# - вот это флейм!!!!!!!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.07.03 13:29
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Мда... Слушайте, мож это шутка такая?


Да нет, не шутка. Не зря Влад регулярно отсылает вас на форум ixbt по программированию с предложением почитать посты тов. Рыбкина. Это вполне серьезно. Впрочем, бывают даже более удивительные случаи — есть люди, которые считают и С злом и убеждены что надо всех принудительно заставлять писать на ассемблере.

Но самое смешное что твоя позиция выглядит в точности так же, только на новом витке технологий
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[50]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.07.03 13:29
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Дык надо было для этой ячейки классик создать...

WH>Вот я и завел шаблончик

Вместо того чтобы сделать нормальную объектную модель. Это я называю template-based дизайном, который крив

Это была шутка, не воспринимайте всерьез.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[44]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.07.03 13:29
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ну, он и выглядит нормально, если уметь на него смотреть. Мне вот часто говорят, что функционально программирование полный рулез и показывают какой-то код на OCML'е, который на мой посторонний взгляд просто ужасен


Но если написать аналог на С++ то получится еще ужаснее и намного больше по объему. Речь же идет об аналогичном по функциональности коде на С++ и С#.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[46]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.07.03 13:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>>Ты сказал, что непонятны они только тем кто с ними работать не умеет. Так вот я умею с ними работать очень неплохо.

S>>>С шаблонами? Вряд ли.
WH>>Согласен.

VD>Гы-гы.


VD>PS


VD>И почему чем неопытнее люди, тем чаще они считают, что уменее всех остальных?


Человек, ни разу не покидавший родного города, считает этот город всем доступным миром (по крайней мере главной его частью). Поэтому когда путешественник не очень хорошо разбирается в расположении достопримечательностей его родного города то он считает себя значительно продвинутей в вопросах географии, несмотря на то что его познания географии, хоть и хорошие, ограничены его мирком, но он, к сожалению этого не знает или не придает этому факту никакого значения.

PS: Сорри за демагогию, но бесконечные наезды лично на собеседника меня уже достали. Господам, которые при мизерном опыте считают себя вправе судить о знаниях людей с большим опытом, стоит над этим задуматься. Не стоит считать людей вокруг себя глупее себя.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[3]: Будущее C# - вот это флейм!!!!!!!
От: LaptevVV Россия  
Дата: 15.07.03 13:43
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


LVV>>Цитата из письма моего друга, активно действующего программиста, руководителя лаборатории и нескольких проектов. Заранее прошу извинения за эмоциональность монго друга, но видимо, у него сильно накипело!


AVK>Ну вот, хороший пример теперешней ситуации. Любая новая технология всегда будет встречать яростный отпор и непонимание.


AVK>Что же касается данного конкретного человека то видимо его задачи мало связаны с программированием, иначе цифра в 0.05% выглядит просто дико. А поскольку такие люди уже устроились на своем месте и дальше двигаться не желают, то они по прежнему уверены в том что все новое это ересь. До тех пор пока не столкнуться с задачкой, где объем программинга (в особенности модификации уже существующего кода) превысит те самые 0.05%.


Если Вы следите за РАЗНЫМИ областями информационных технологий, то должны знать так называемое АВТОМАТНОЕ программирование. При правильном его применении 99,95% работы ДЕЙСТВИТЕЛЬНО делается до кодирования. Более того, кодирование можно автоматизировать по автоматной модели. Почитайте ШАЛЫТО — апологета данной технологии. У мего друга в конторе так и принято. Более того, чем больше программер кодит, тем подозрительнее относятся к его квалификации. По из понятиям ХОРОШИЙ программист делает свою часть "с первого предъявления" — то есть, после автономной отладки и тестирования система в комплексе СРАЗУ начинает работать. Ошибки — это описки по невнимательности, которые быстро выявляются и исправляются.
Вот такой подход к программированию. Новые технологии сами по себе абсолютно не нужны, если они не приводят к резкому увеличению производительности труда. Поэтому старая, но НАДЕЖНО и БЫСТРО работающая технология изготовления ПО ЛУЧШЕ новой, но недоделанной.
Производство ПО — это не столько программирование, сколько производство.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Будущее C# - вот это флейм!!!!!!!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.07.03 13:57
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Если Вы следите за РАЗНЫМИ областями информационных технологий, то должны знать так называемое АВТОМАТНОЕ программирование. При правильном его применении 99,95% работы ДЕЙСТВИТЕЛЬНО делается до кодирования. Более того, кодирование можно автоматизировать по автоматной модели. Почитайте ШАЛЫТО — апологета данной технологии. У мего друга в конторе так и принято.


Все это хорошо и правильно. Проблема только в том что подобные области применения программирования составляют небольшой процент. И тот же дотнет совершенно не нацелен на эти области. Поэтому вполне понятно что он там и не нужен. Не надо только факты из конкретной узкой области обобщать на программирование в целом.

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


А они приводят, в том то вся и соль.

LVV> Поэтому старая, но НАДЕЖНО и БЫСТРО работающая технология изготовления ПО ЛУЧШЕ новой, но недоделанной.


Да кто бы спорил. Вот только когда пытаются делать обобщения то результат получается мягко говоря не очень.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[4]: Будущее C# - вот это флейм!!!!!!!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.07.03 13:57
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Нет, не шутка. Пишут системы реального времени.


Крупными буквами

ДОТНЕТ НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ В СИСТЕМАХ РЕАЛЬНОГО ВРЕМЕНИ В СВЯЗИ С НЕПРОГНОЗИРУЕМОСТЬЮ ОТКЛИКА.

Либо ты своему товарищу неправильно разъяснил суть дискуссии, либо он ничего не видит за пределами своего мирка. Но применять дотнет и С++ для реалтайма и программирования контроллеров никто и не собирался.
... << RSDN@Home 1.1 beta 1 (np: тихо) >>
AVK Blog
Re[51]: Будущее C#
От: WolfHound  
Дата: 15.07.03 17:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Вместо того чтобы сделать нормальную объектную модель.

С удовольствием, а как?
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[47]: Будущее C#
От: WolfHound  
Дата: 15.07.03 17:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Человек, ни разу не покидавший родного города, считает этот город всем доступным миром (по крайней мере главной его частью). Поэтому когда путешественник не очень хорошо разбирается в расположении достопримечательностей его родного города то он считает себя значительно продвинутей в вопросах географии, несмотря на то что его познания географии, хоть и хорошие, ограничены его мирком, но он, к сожалению этого не знает или не придает этому факту никакого значения.

В терминах данной аналогии я указал вам с Владом на то что вы похо знаете мой город.
[подколка]
Если хочешь доказать что это не так могу предложить задачку решается очень красиво boost'ом, stl'ем и шаблонами средней сложности. Я написал за час(ради развличения), а у таких великих гуру как вы с Владом должно уйти минут 15 не больше.
[/подколка]
AVK>PS: Сорри за демагогию, но бесконечные наезды лично на собеседника меня уже достали.
А меня достали вопли что С++ это ода большая затычка лдя самого себя.
AVK>Господам, которые при мизерном опыте считают себя вправе судить о знаниях людей с большим опытом, стоит над этим задуматься.
Господам которые считают что многолетний опыт дает им абсолютные знания в том числе в тех областях куда они почти не заглядывали тоже.
AVK>Не стоит считать людей вокруг себя глупее себя.
И я о томже.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[48]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 19:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Дык перегрузка присваивания запрещена даже у value типов. Следовательно обьект под проперти косить не может. А даже если бы и было в интерфейс всеравно не засунишь. Препроцессор бы помог но и его нету. Остается внешний кодогенератор.


Что я тебя не пойму. Причем тут вэльютипы и интерфейсы? Да и МС++ доступен. Всю макросовщину можно сделать на нем, а Шарп будет видеть нагенерированные классы.

VD>>А какова их цель?

WH>Как и у всех остальных шаблонов.
WH>Писать меньше и читать проще. Часто позволяют сэкономить символов 10-50 что очень не плохо.

Это не цель. Это снова реализация. Научись описывать проблему, а не решение которое ты для нее видишь. Иначе тебя тяжело понимать.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 19:25
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Вместо того чтобы сделать нормальную объектную модель. Это я называю template-based дизайном, который крив


AVK>Это была шутка, не воспринимайте всерьез.


А я вот полностью согласен. В этом случае логичнее было бы написать специализацию контрола, а не лепить шаблоны.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 19:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, AndrewVK, Вы писали:


AVK>>Вместо того чтобы сделать нормальную объектную модель.

WH>С удовольствием, а как?

Объявляешь класс... и используешь его в свойстве (общем для набора свойств).
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 19:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Господам которые считают что многолетний опыт дает им абсолютные знания в том числе в тех областях куда они почти не заглядывали тоже.


Еще раз повторяю, что не тебе оценивать то, куда я заглядывал, а куда нет. Заметь, я как-то не обсуждают твои знания, хотя имею на это куда болшее моральное право.

AVK>>Не стоит считать людей вокруг себя глупее себя.

WH>И я о томже.

Ты это демостротивно делашь.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будущее C# - вот это флейм!!!!!!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 19:37
Оценка:
Здравствуйте, LaptevVV, Вы писали:

Ну, если автоматы, то все ясно. Хотя их тоже можно было бы в ОО-форму облечь. Да и шаблоны для решания таких задач прекрасно подходят. Вот только идеология конечных автоматов подходит далеко не везде.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будущее C# - вот это флейм!!!!!!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 19:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Но самое смешное что твоя позиция выглядит в точности так же, только на новом витке технологий


Именно.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Будущее C# - вот это флейм!!!!!!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 19:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>ДОТНЕТ НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ В СИСТЕМАХ РЕАЛЬНОГО ВРЕМЕНИ В СВЯЗИ С НЕПРОГНОЗИРУЕМОСТЬЮ ОТКЛИКА.


Это все из-за GC и JIT-компиляции. По большому счету обе проблемы решаются. Блее того как раз на GC можно создать алгоритм выделения памяти с полностью линейными временными характиристиками. Ну, а JIT можно вообще исключить. Вопрос только нужно ли оно. Дотнет действительно затевался скорее для бизнеса (сервера) и десктопа.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Будущее C# - вот это флейм!!!!!!!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.07.03 23:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Да нет, не шутка. Не зря Влад регулярно отсылает вас на форум ixbt по программированию с предложением почитать посты тов. Рыбкина. Это вполне серьезно. Впрочем, бывают даже более удивительные случаи — есть люди, которые считают и С злом и убеждены что надо всех принудительно заставлять писать на ассемблере.


Мне встречалось что-то подобное, но в менее клиническом изложении.

AVK>Но самое смешное что твоя позиция выглядит в точности так же, только на новом витке технологий


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

AVK>>Но самое смешное что твоя позиция выглядит в точности так же, только на новом витке технологий

VD>Именно.

Да нет, Влад. Не так всё просто. Вот нового в смысле "хорошо забытого старого" мне бы и не хотелось как раз...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: Будущее C# - вот это флейм!!!!!!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.03 00:20
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да, я это отлично знаю. И тов. Рыбкина тоже читал. Позабавился. Проблема в другом... Не находишь, что... изготовление, ммм... кодогенератора, это... ммм... программирование на ассемблере, только чуть более переносимом, что ли...


Оно нужно раз в год по обещанию. Это вы вцепились в кодогенерацию, а мы решение предложили.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Будущее C# - вот это флейм!!!!!!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.03 00:20
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>У C# как у языка преимуществ перед C++ никаких нет,


Во-во. Вот так и тот товарищь себя уговаривал. Только было это 7 лет назад, и сзыки были не C# vs. C++, а C++ vs. C.

ГВ> но фишка в том, что C# нельзя противопоставлять C++. Это бессмысленно по определению. C# — неотъемлемая часть системы .Net, один из многих языков, которые на ней работают, а C++ — сам по себе язык.


Я бы вразился так: язык без рантайма.

ГВ>Ровно потому же не стоит заниматься противопоставлениями C++ <-> Java. Java уже достаточно давно позиционируется как платформа, а не как язык.


И тем не менее, есть MC++. И он не лучше или хуже Шарпа. Он луче С++ без рантайма.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Будущее C# - вот это флейм!!!!!!!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.07.03 05:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да, я это отлично знаю. И тов. Рыбкина тоже читал. Позабавился. Проблема в другом... Не находишь, что... изготовление, ммм... кодогенератора, это... ммм... программирование на ассемблере, только чуть более переносимом, что ли...


Ну не на ассемблере конечно, особенно если CodeDOM пользовать, но приятного конечно мало. Другое дело что есть класс задач, которые всеми остальными способами, в том числе и шаблонами, решаются намного менее приятно. Хороший пример такой задачи — автомат для разбора регексов.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[6]: Будущее C# - вот это флейм!!!!!!!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 16.07.03 10:47
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И тем не менее, есть MC++. И он не лучше или хуже Шарпа. Он луче С++ без рантайма.


Самому не смешно?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Будущее C# - вот это флейм!!!!!!!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 16.07.03 10:50
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Да, я это отлично знаю. И тов. Рыбкина тоже читал. Позабавился. Проблема в другом... Не находишь, что... изготовление, ммм... кодогенератора, это... ммм... программирование на ассемблере, только чуть более переносимом, что ли...

VD>Оно нужно раз в год по обещанию. Это вы вцепились в кодогенерацию, а мы решение предложили.

Странно, а из твоих реплик складывается впечатление, что кодогенерация, это чуть ли не универсальная панацея. И кто это "мы", которые "вцепились в кодогенерацию"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Будущее C# - вот это флейм!!!!!!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.03 19:27
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Странно, а из твоих реплик складывается впечатление, что кодогенерация, это чуть ли не универсальная панацея. И кто это "мы", которые "вцепились в кодогенерацию"?


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

VD>>И тем не менее, есть MC++. И он не лучше или хуже Шарпа. Он луче С++ без рантайма.


ГВ>Самому не смешно?


Нет. А должно?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.07.03 22:40
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Ну и что ты демонстрируешь этим?

VD>Догадайся с трех раз.
ГВ>>То, как чаще всего, вероятно, пишут. ATL — неплохая библиотека, но, ИМХО, главное её достоинство — широкая распространённость.
VD>Ты видил более удобную? А нет, так что зря воздух сотрясать?

Это не имеет никакого значения. Видел я её или не видел — какая разница. Это никак не сказывается на оценке и языка, и подхода.

ГВ>> Сам посуди: реализацию QueryInterface можно спАрить с наследованием от заданного интерфейса, объявления элементов — вынести в виртуальные базовые классы и т.п. Другое дело, что ATL написана для VC6, который начинал сходить с ума от сложного наследования, где чередовались шаблоны и виртуальное наследование... так то — проблемы компилятора, альтернативы которому имеются уже достаточно давно.

VD>Во-во. Чтобы заткнуть дыру в рантайме мы готовы вылить ушат грязи на нивчем не повинный компилятор. Только зачем? Возможности писать так же просто и красиво как дотнете нет ни в одном компиляторе кроме МС++.

"Красота" — понятие субъективное, "простота" — обоюдоострое.

VD>Не будт на С++ то же. Так как твой Requestable уже перебор, ну, а BasicCoClassImplement увеличивает отрыв. Тебе показали простоту с какой "убогий" язык без шаблонов вегко и элегантно решает проблемы, а ты в ответ "дык, мы ща по бырому десяток килобайт оберток наклепаем....".


Про сложности реализации базового фреймворка обычно быстро забываешь. Кроме того, я согласен, что нет смысла писать что-то подобное ради одного небольшого проекта. А ради нескольких... ИМХО, вполне даже стОит.

ГВ>>Если заинтересует, расскажу о реализации Requestable и т.п., но суть дела не в этом. Ты демонстрируешь одну и ту же ситуацию — проверку композиции в рантайме.

VD>Может быть ты не заметил, что без проверки в рантайме тут необойтись? Хотя у тебя это уже в норме вещей.

Заметил, не переживай. Только проверка в рантайме выполняется ради демонстрации примера. И кроме того, зачастую без того же COM просто невозможно обойтись, потому что других способов взаимодействия с чем-либо в распоряжении попросту нет.

VD>Кстати, можешь на этом примере продемострировать всю кривость этого подхода.


Бессмысленно доказывать кривость/прямость подхода, если базовая инфраструктура построена на рантайм-проверках. Это... ммм... аргумент из серии: "Вот тебе дебе две рогатки, и куда здесь засунуть твой чёртов порох?"

ГВ>>Не путай, пожалуйста, рантайм-проверки результатов операций управления ресурсами и рантайм-проверки типов, т.е. — верификацию композиции. Понятие "компонент", как и "модуль" вовсе не означает необходимости проверок типов.

VD>У тебя пунктик по поводу типов. Ты так долго себя убеждал, что типы не является обычными данными, что видимо привык. Нет никакой разницы между строкой символов полученной из-вне и типм. Это ты все сам придумал.

Ну да, наверное нет. "Никакой ложки". Строка — это тоже тип. Строковый.

Ну а кроме шуток — строка полученная "извне", коль скоро она используется программой не только как массив символов, должна быть, например, разобрана по определённым правилам (см. "лексический анализ", "синтаксический анализ", и всяческая теория трансляции), поскольку для того, чтобы что-то выполнить процессор должен получить последовательность команд, а строка этого не содержит (если, конечно, это не машинный код ). Соответственно, трансляция отнимет некоторое время, которого не будет требоваться при сильной типизации. Ну и естественно, нельзя поручиться за результат разбора.

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

ГВ>>dynamic_cast<> вызывается в CreateObject? Если CreateObject возвращает общий интерфейс I_Object, то зачем в нём dynamic_cast<> ?

VD>За тем, что человек создает компонентную архитектуру. Он не знает, что подключает в рантайме, а dynamic_cast позволяет ему быть в большей уверенности относительно безопасности доальнейших действий.

Можно просто не подключать то, что не может быть подключено.

VD>Вообще-то это плохое решение. Но не из-за производительности, а из-за... ну, дагодались? Из-за убогости стандарта С++. Вернее из-за нежелания его авторов описмывать в нем что-либо связанное с рантаймом (акромя библиотек).


Демагогия.

VD>Правильное решение в КОМ-е. Оно универсально. А еще более правильное в дотнете. Оно ни только универсально, но просто и безопасно.


И ещё одна такая же. Впрочем: "у тебя это уже в норме вещей" (c) VladD2.

ГВ>>
ГВ>>int RunSomeOperation(I_Object*)
ГВ>>


VD>Думаю, что I_Object — это интерфейс. Так что скорее:

VD>I_Object->RunSomeOperation()

Тогда не было бы речи о dynamic_cast<>.

ГВ>>ИМХО, другого обобщенного случая здесь быть не может, поскольку ты утверждаешь, что exe не меняется в зависимости от набора .dll.


VD>Скорее всего он говорит, о механизме возврата самих I_Object (ну и дальнейшей работе с ним).


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

ГВ>>dynamic_cast<> вызывается в CreateObject? Если CreateObject возвращает общий интерфейс I_Object, то зачем в нём dynamic_cast<> ?

WH>Есть application->CreateObject(className) и есть шаблон CreateObrejct<I_MyCoolInterface>(className) шаблон пинает application (вернее один из сервисов ака супер фабрика) и делает dynamic_cast на возвращенный обьект.
WH>Сделано исключительно для того чтобы меньше писать.

Понятно.

ГВ>>OK, значит dynamic_cast<> нужен только для получения частного типа из общего.

WH>Считай что это QueryInterface

Да, одно и то же по сути.

ГВ>>Надеюсь, что в итоге я правильно тебя понял:

WH>Все еще проще. ехе вобще ни чего не знает кроме того как работать с фабриками (вобще у него есть еще сервисы но это не важно).

Ага, то есть User-readable список классов выдёргивается из фабрик.

WH>Если в длл надо создать обьект то просто пинаем application (через CreateObject<>() для удобства) и он возвращает созданный объект или null.


CreateObject<I_MyCoolSensor>?

WH>Короче все проще некуда

WH>if(Ref<I_Sensor> sensor=CreateObejct<I_Sensor>(sensorName))Это в нутри длл

Хм. I_Sensor — общий интерфейс? Или это опечатка и внутри длл всё-таки:

...=CreateObject<I_MyCoolSensor>();



Всё время выпадает какое-то общее звено. Вот смотри. Нечто (exe-шник или длл) создаёт экземпляр некоторого класса, пользуясь только именем класса, а потом (по идее?) пытается преобразовать в тот тип, который нужен, чтобы вызвать некую операцию. Вопрос. Зачем тогда создавать объект неопределённого класса, если уже известно, каким он должен быть?

Может быть, приведёшь пример конкретного сценария использования? Просто с rtti всегда так — потянешь за одну ниточку и лезет всё остальное.

WH>CreateObejct<I_Sensor>(sensorName) пинает application->CreateObject

WH>На результат применяю dynamic_cast после чего есть указатель на конкретный интерфейс или null.

Нет, если можно, то более развёрнутый пример: для чего создаётся сенсор, кто, что и когда у него вызывает. Логику работы фабрики-то я понял. Ну, если можно, то примерно такие условия: exe-шник, длл1, длл2.

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

ГВ>>>>"моей программы" — имеется ввиду та программа, которую разрабатывает и контролирует конкретный дизайнер.

VD>>>А компонент это тоже "твоя программа"? Или он обязан быть частью дезайрена?
ГВ>>[...] Компонент обязан вписываться в дизайн, а не наоборот. [...] В противном случае архитектура ограничивается используемыми средствами, что не есть good. ИМХО, разумеется

VD>Сдается мне, что ты вообще не понимашь этого термина.


Ну что же, готов выслушать твоё определение. Моё вкратце сводится к тому, что компонент прежде всего поддерживается некоторой инфраструктурой. Отдельно определить этот термин невозможно, как нельзя определить "часть", не имея ввиду какого-либо "целого".

VD>Компонент (любой, можно даже сказать компонент как класс) принципиально не вяляется частью твой программы. Он — это внешняя независимая программа. Причем при компонентном подходе к проектированию, ты свой дизайн строишь на базе компонентов. Таким образом ситуация кода компонент не подходит для дизайна является ошибкой дизайна.


Нет, Влад. Это в общем случае — отсутствие дизайна или плохой дизайн, поскольку дизайн (архитектура) зависит, прежде всего, от требований к продукту и предположений об изменчивости требований пользователя.

Создавая архитектуру на базе компонентов ты: а) становишся зависимым от дополнительных факторов типа маркетинговой политики поставщика компонентов, б) косвенно усложняешь жизнь пользователю, поскольку эти факторы сказываются и на нём. И почти всегда больше нуля вероятность того, что на определённом этапе функциональные возможности компонентов, на котором построен дизайн окажутся недостаточными для удовлетворения потребностей пользователя. И весь дизайн полетит к чёрту.

Естественно, что превентивное построение архитектуры тоже не даёт абсолютной защиты от такой ситуации, но, по крайней мере, позволяет контролировать собственный продукт и более гибко аккумулировать результаты анализа требований пользователя.

Так что, не передёргивай. Если свалить в груду кирпичи, облить их цементом и назвать это небоскрёбом, то знаешь, каждый кирпич будет на своём месте: вытащишь один — получишь по башке остальными. Только это — не дом. Понимаешь разницу?

VD>В общем, если понимаешь, что такое компонент, то этот твой ответ является очередным увиливанем от ответа, с целью таки не скзать: "Да я был не прав". А если не понимаешь, то мы вообще тут воду в ступе перемалываем.


Да нет, почему же? Меня банально уговаривают признаться в своей неправоте, оперируя неподходящими аргументами. Знаешь, я не люблю аргументов вроде: "ну скажи, что ты был неправ, и покончим с этим", "ну ты знаешь, это так... ну так! ну просто вот так круто!!" или "Это уже всё устарело, сейчас новые времена!" и подобными. Первое — суть прямое давление, второе — демонстрация детской восторженности в лучшем случае, третье — одна из форм выражения снобизма. Ни то, ни другое, ни третье меня (и не только меня) убедить в правоте оппонента не может. Равно как не может убедить в этом и массовость некоторого явления. Тем более, что 2x2=4 (в десятичной системе счисления ), даже если наблюдатель полагает, что ему абсолютно неважен результат.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Будущее C# - вот это флейм!!!!!!!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.07.03 23:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>И тем не менее, есть MC++. И он не лучше или хуже Шарпа. Он луче С++ без рантайма.

ГВ>>Самому не смешно?
VD>Нет. А должно?

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

AVK>Да нет, не шутка. Не зря Влад регулярно отсылает вас на форум ixbt по программированию с предложением почитать посты тов. Рыбкина. Это вполне серьезно. Впрочем, бывают даже более удивительные случаи — есть люди, которые считают и С злом и убеждены что надо всех принудительно заставлять писать на ассемблере.


Люди, которые считают, что "надо всех принудительно заставлять <...>" мне, кстати, неприятны, независимо от того, что стоит в <...>. Если только они не заставляют развивать свои мозги. Ну это так, замечание по ходу. А на самом деле — многое зависит от конкретных условий и многое же совершенно неизменно. Как эта вот Trtti > Tctti. Ну никуда не денешься от того, что даже:

mov eax, something
jz @@somewhere
jmp @@exit

потребует больше времени, чем... чем ничто!

AVK>Но самое смешное что твоя позиция выглядит в точности так же, только на новом витке технологий


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

ГВ>>Странно, а из твоих реплик складывается впечатление, что кодогенерация, это чуть ли не универсальная панацея. И кто это "мы", которые "вцепились в кодогенерацию"?


VD>Ну, кто вы, вы должны знать и сами.


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

ГВ>Всё время выпадает какое-то общее звено. Вот смотри. Нечто (exe-шник или длл) создаёт экземпляр некоторого класса, пользуясь только именем класса, а потом (по идее?) пытается преобразовать в тот тип, который нужен, чтобы вызвать некую операцию. Вопрос. Зачем тогда создавать объект неопределённого класса, если уже известно, каким он должен быть?

ГВ>Может быть, приведёшь пример конкретного сценария использования? Просто с rtti всегда так — потянешь за одну ниточку и лезет всё остальное.

Общий заголовок
struct I_Sensor
    :I_Object
{
//...
};

struct I_MyCoolSensor
    :I_Sensor
{
//...
};

в каждой DLL
template<class T>
Ref<T> CreateObject(const std::string& name)
{
    return dynamic_cast<T>(exe->CreateObject(name));
}

DLL 1
struct C_MyCoolSensor
    :I_MyCoolSensor
{
}

DLL_EXPORT_MAP_BEGIN()
    DLL_EXPORT_CLASS(C_MyCoolSensor)
DLL_EXPORT_MAP_END()

DLL 2
void DoSome(const std::string& sensorClassName)
{
    if(Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorClassName))
    {
        //....
    }
}

DLL 3
void DoSomeElse()
{
    if(Ref<I_MyCoolSensor> sensor=CreateObject<I_MyCoolSensor>("MyCoolSensor"))
    {
        //....
    }
}

EXE
map<string, Ref<I_Factory> > factoryMap;
void OnLoad()
{
    foreach(dll in dlls)
        foreach(factory in dll.factorys)
            factoryMap.add(factory.className, factory);
}

Ref<I_Object> CreateObject(const std::string& name)
{
    FactoryMapIter iter=factoryMap.find(name);
    if(iter!=factoryMap.end())
        return (*iter)->CreateObject();
    else
        return 0;
}

Проблема не в том что мы не знаем что придет хотя это не всегда так, а в том что передача идет через универсальный интерфейс иначе сделать так чтобы ехе не знал о том что лежит в длл не возможно. В общем если не так то основное требование (не перекомпилировать весь проект при добавлении чегото нового) летит к чертям.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[47]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 24.07.03 23:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

ГВ>>Может быть, приведёшь пример конкретного сценария использования? Просто с rtti всегда так — потянешь за одну ниточку и лезет всё остальное.


[разнообразный ccode]

WH>Проблема не в том что мы не знаем что придет хотя это не всегда так, а в том что передача идет через универсальный интерфейс иначе сделать так чтобы ехе не знал о том что лежит в длл не возможно. В общем если не так то основное требование (не перекомпилировать весь проект при добавлении чегото нового) летит к чертям.


Начну с того, что в принципе ты прав (и соответственно, в принципе неправ я в своём обобщении), другие решения в твоём случае хоть и обеспечивают несколько большую надёжность, за счёт декларирования связи интерфейсов и сущностей, но runtime-изменение конфигурации есть runtime-изменение конфигурации...

Но всё-таки кое-что к чему можно "прицепиться", я таки нашёл .

Вот здесь, как я понимаю, ты иллюстрируешь использование общего для всех классов интерфейса:
WH>
WH>void DoSome(const std::string& sensorClassName)
WH>{
WH>    if(Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorClassName))
WH>    {
WH>        //....
WH>    }
WH>}
WH>


У меня возник вопрос: а почему бы не сделать так?
void DoSome(Ref<I_Sensor> sensor)


В любом случае внешний объект вызывает DoSome не просто так и, скорее всего знает о том, что будет использоваться именно Ref<I_Sensor>. Однако, здесь я могу ошибаться, поэтому предположу, что на месте I_Sensor может стоять произвольное имя. Тогда, собственно, имеем риск того, что dynamic_cast<> == 0.

А вот здесь:
WH>
WH>void DoSomeElse()
WH>{
WH>    if(Ref<I_MyCoolSensor> sensor=CreateObject<I_MyCoolSensor>("MyCoolSensor"))
WH>    {
WH>        //....
WH>    }
WH>}
WH>


пара небольших недостатков. 1) Необходимо вручную отслеживать согласование I_MyCoolSensor<->"MyCoolSensor" в каждом таком вызове и 2) опять-таки, если функция DoSomeElse вызывается для действий над интерфейсом определённого типа, то почему бы не вынести его в формальные параметры, например, так:

void DoSomeElse(Ref<I_MyCoolSensor>)


Как я понимаю, аргументом против такого решения служит то, что DoSomeElse вызывается чем-то, кто знать не знает о существовании I_MyCoolSensor. Но тогда, ИМХО, это снова не совсем хорошо, поскольку остаётся риск отказа в обработке из-за неверного выбора класса.

То есть, в принципе, я вижу в обоих частях примера один и тот же недостаток — риск того, что dynamic_cast<> вернёт 0 и предупредить это невозможно, поскольку никак не предоставлена информация для точного выбора класса.

ИМХО, защититься от этого можно, если разделить фабрики сущностей и фабрики интерфейсов, и декларировать допустимые преобразования "интерфейс-сущность-интерфейс", например, сопоставив интерфейсам и сущностям отдельные GUID-ы ( Ну да, в некотором роде reflection как раз и получается, но это не совсем runtime-анализ).

Далее, ИМХО, стоило бы сопоставить функциям типа DoSomeElse идентификаторы тех интерфейсов, которые они могут принимать и на основе уже этой информации определять классы, идентификаторы которых можно передавать в DoSomeElse. Раз уж очень хочется в runtime выбирать класс для выполнения той или иной операции, то неплохо бы иметь адекватные критерии выбора этого класса.

Соответсвенно, задача исключения неопределённости, привносимой dynamic_cast<> сводится к тому, чтобы максимально автоматизировать регистрацию информации о связях интерфейсов с сущностями с одной стороныи, с другой стороны — предоставить информацию о допустимых типах аргументов и с третьей — не потерять вкусностей C++. Ну и ещё... случайно не написать такую же махину как CLR.

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

ГВ>У меня возник вопрос: а почему бы не сделать так?

ГВ>
ГВ>void DoSome(Ref<I_Sensor> sensor)
ГВ>

Потому что объект еще не создан. Болие того не этапе компиляции не ивесно какой именно объект будет создан. Имя класса читается из конфига.

ГВ>В любом случае внешний объект вызывает DoSome не просто так и, скорее всего знает о том, что будет использоваться именно Ref<I_Sensor>. Однако, здесь я могу ошибаться, поэтому предположу, что на месте I_Sensor может стоять произвольное имя. Тогда, собственно, имеем риск того, что dynamic_cast<> == 0.

А как ты думаешь почему и написал if?
    if(Ref<I_Sensor> sensor=CreateObject<I_Sensor>(sensorClassName))
    {
        //....
    }



ГВ>пара небольших недостатков. 1) Необходимо вручную отслеживать согласование I_MyCoolSensor<->"MyCoolSensor" в каждом таком вызове и 2) опять-таки, если функция DoSomeElse вызывается для действий над интерфейсом определённого типа, то почему бы не вынести его в формальные параметры, например, так:

Тут нужен несколько другой пример:
Переберем все сенсоры и для тех которые I_MyCoolSensor чтото сделаем.
void DoSomeWithMyCoolSensors(RefEnum<I_Sensor> sensors)
{
    while(Ref<I_Sensor> sensor=sensors->Next())
        if(Ref<I_MyCoolSensor> my_sensor=ref_cast<I_MyCoolSensor>(sensor))
        {
            //....
        }
}

ref_cast принимает и возвращает мои смартпоинтеры. Внутри вызывает dynamic_cast.

ГВ>То есть, в принципе, я вижу в обоих частях примера один и тот же недостаток — риск того, что dynamic_cast<> вернёт 0 и предупредить это невозможно, поскольку никак не предоставлена информация для точного выбора класса.

А это и не нужно. Просто проверяем входные данные и все.

ГВ>ИМХО, защититься от этого можно, если разделить фабрики сущностей и фабрики интерфейсов,

Это как?
ГВ>и декларировать допустимые преобразования "интерфейс-сущность-интерфейс",
А dynamic_cast для чего сделан?
ГВ>например, сопоставив интерфейсам и сущностям отдельные GUID-ы (
Зачем городить COM ручками? Пусть работает компилятор.
ГВ>Ну да, в некотором роде reflection как раз и получается, но это не совсем runtime-анализ).
Ну ты эта того рефлкшен бы посмотрел.

ГВ>Далее, ИМХО, стоило бы сопоставить функциям типа DoSomeElse идентификаторы тех интерфейсов, которые они могут принимать и на основе уже этой информации определять классы, идентификаторы которых можно передавать в DoSomeElse. Раз уж очень хочется в runtime выбирать класс для выполнения той или иной операции, то неплохо бы иметь адекватные критерии выбора этого класса.

Ага. И перекомпилировать ВЕСЬ проект?

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


ГВ>Пример такого обхода пока ещё не готов, заброшу несколько позже. Но пока что забавно получается.

Ты бы вышел за приделы одного ехешника чтоли.
Просто если делать один ехешник то там много другие методы конторля чем ты говоришь, а если между длл то компаилтайм проверки уже работать не будут, а если и будут то при добавлении новой сущьности придется перекомпилять ВСЕ длл ну и какой тогда в них смысл?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[49]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 30.07.03 13:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>и декларировать допустимые преобразования "интерфейс-сущность-интерфейс",

WH>А dynamic_cast для чего сделан?
Я сказал — "декларировать", а не "выяснить по ходу дела".

ГВ>>например, сопоставив интерфейсам и сущностям отдельные GUID-ы (

WH>Зачем городить COM ручками? Пусть работает компилятор.
Вот и я о том же — пусть работает компилятор.

ГВ>>Ну да, в некотором роде reflection как раз и получается, но это не совсем runtime-анализ.

WH>Ну ты эта того рефлкшен бы посмотрел.
Я сказал — "в некотором роде".

ГВ>>Далее, ИМХО, стоило бы сопоставить функциям типа DoSomeElse идентификаторы тех интерфейсов, которые они могут принимать и на основе уже этой информации определять классы, идентификаторы которых можно передавать в DoSomeElse. Раз уж очень хочется в runtime выбирать класс для выполнения той или иной операции, то неплохо бы иметь адекватные критерии выбора этого класса.

WH>Ага. И перекомпилировать ВЕСЬ проект?
Отнюдь. Хотя при изменении какого-то интерфейса его пользователей по-любому перекомпилить надо.

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


ГВ>>Пример такого обхода пока ещё не готов, заброшу несколько позже. Но пока что забавно получается.

WH>Ты бы вышел за приделы одного ехешника чтоли.
Есессно.

WH>Просто если делать один ехешник то там много другие методы конторля чем ты говоришь,

Не понял?

WH>а если между длл то компаилтайм проверки уже работать не будут, а если и будут то при добавлении новой сущьности придется перекомпилять ВСЕ длл ну и какой тогда в них смысл?

Нет, ВСЕ перекомпилять не нужно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: Будущее C# - вот это флейм!!!!!!!
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.08.03 20:18
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Нет. А должно?


ГВ>Мне — смешно. Как тебе — не знаю, вот и спросил.


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