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

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

AVK>>>С чем сравнивал?

VD>>С собственными тестами. В прочем, ты должен был и сам догадаться.

AVK>Я догадался, потому и спрашивал. В твоих тестах не было с чем XmlSerializer сравнивать.

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

AVK> SoapFormatter и DataSet были явно медленнее в разы, а сравнивать с бинарными сериализаторами текстовый глупо.

Тебе виднее.

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

AVK>На момент появления этого термина термина дизайн-тайм не существовало, имелось ввиду противопоставление рантайм-компайлтайм.

Гы-гы. Первые визульные среды датируются серединой 80-ых. В то время ртытыем и не пахло.

AVK>С этих позиций дизайн-тайм это безусловно тоже рантайм.

Основная разница здесь не во времени выполнения, а в доступности метоинформации другому (внешнему) коду. Например, дизайнеру. В ртти С++ только сам код может обращаться к своим метаданным. Тот же VC вынжден создавать два (!) варианта метаданных для дизайнтайма (первый для комплит-ворда, второй для отладки). В COM, Яве и дотнете к метадамнным можно боращаться не запуская на выполнение код из сборок.

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

VD>>Вообще-то он предостовляет механизм динамического вызова.
AVK>Это тот же самый RTTI.

В RTTI — такой функиональностью и не пахло. Более того это появилось то ли в дотнете, то ли в Яве. В том же COM-е был только IDispatch.

VD>> Ну, и еще в дотнете есть средства генерации метаданных, да и кода.
AVK>Про эмит я сразу оговорился что его не учитываем.

Главное, что в дотнете работа с метаданными есть, и она полнофункциональна. А в С++ это кастрированный урод.

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

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

1. Он не предаставляет метаданные, т.е. решает совершенно другие задачи.
2. Безбожно врет и глючит.

Самое смешное, что в С++ комплит-ворд лучше всего работает в менеджед проектах на обычном VS-ном механизме.

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

Выкидывай. В дотнете МС++ прекрасно работает без него. При этом метаданные на порядок лучше. Ну, а метаданые в компайлтайме нужный не очень сильно. sizeof-а более чем достаточно. Шаблоны и макросы позволяют делать универсальный код вообще без метаданный.

S>Вот тут ты прав на все сто.

Дык на своем животе проплз.

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

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

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

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

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

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

S>Ее, наоборот, всем не хватает Посмотри, хотя бы, на boost::mpl, если уж Александреску читать не хочешь.

Дык с этим я не спорю.

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

VD>>Ну, это ты зря. Если шаблонами пользоваться умело и по месту,

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

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

Хотя конечно правильно было бы ввести в шарп недостающие фичи вроде подключения релаизации и т.п.

Здравствуйте, 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>Книжку Александреску прочитать тебе не зря советовали.

А может зрая?

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

AVK>>>Зачем? У тебя про твой придуманный термин никто ничего и не спрашивал. Речь шла про рефлекшен в шарпе, и отсутствие онного к С++ если ты еще не понял.
ГВ>>Угу, и ещё о том, что отсутствие рефлекшена в C++ — его чудовищный недостаток. Я тоже считаю, что у C++ есть недостатки, но отсутствие рефлекшена в дотнетовском исполнении к ним не отношу.
WH>А я отношу. Пусть не к чудовищьнам но к серьезным точно.

Ну, это личное дело каждого. Просто моё эмоциональное отношение к rtti и спровоцировало реплику.

ГВ>>Т.е., рефлекшен реализует rtti. Да, не только C++-rtti, да, более развитую модель, но последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti.
WH>А может просветишь? В моем проекте я очень активно использую rtti и ни каких проблем не вижу.

Это... рад за тебя.

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

Значит, у тебя есть определённая система метаинформации, угу...

А насчёт "просветишь"... Давай, если тебе интересно, посмотрим на какую-нибудь конкретную ситуацию в которой, как ты считаешь, оправданно используется rtti. Можно приватом (мыло в профайле). Ну а я — выскажусь.

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

ГВ>>Суть в том, что дизайн здесь нужно изменить так, чтобы убрать if (typeid(*pObj) == typeid(SomeDerivedClass))
AVK>Опять ты забываешь что классы могут быть не тобою написанными и без исходников, их может вобще у тебя не быть на момент разработки.

Э-э-э... немного не в кассу. Какой-либо API всегда известен или о нём договариваются заранее. Сомневаюсь, что в дотнетовском приложении ты будешь дёргать методы просто обнаружив факт их существования, игнорируя документированный API.

С другой стороны я понимаю, что ты имеешь ввиду. Заменить реализацию классов для изменения дизайна действительно может оказаться невозможно. Тут не исключено, что в каких-то случаях нечто типа rtti может оказаться единственным решением.

ГВ>>>>1. Атрибуты могут быть применены, но они не могут быть обязательно применены
AVK>>>Зависит от компилятора.
ГВ>>В смысле?
AVK>В смысле тот же компилятор шарпа кое какие атрибуты контроллирует при разработке.

Я, наверное, плохо искал, но кроме наследования, другого способа гарантировать наличие custom-атрибута не нашёл.

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

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

Во-вторых, "единственно верного" дизайна, ИМХО, не бывает. Дизайнерские решения очень сильно зависят от условий, в которых находятся дизайнеры и их способностей принимать те или иные решения. Но это не означает, опять-таки, что тот или иной дизайн не имеет своих характерных черт и последствий, иногда — возможных, иногда — обязательных. То есть... оверхед, связанный с runtime-распознаванием типов всё равно остаётся, а при распознавании всё равно предполагается возможный отрицательный результат, а распознающие части кода всё равно могут быть раскиданы в самых неожиданных местах...


Ну и в скобочках замечу, что мне кажется, что выделенное мною твоё утверждение мягко говоря, безосновательно. Особенно с учётом того, что мы знакомы-то только по форуму. Ну это так, к слову.

ГВ>>Не надо сводить всё к вкусовым предпочтениям. Это вполне объективная оценка определённых характеристик дизайна.
AVK>Пока что я никаких аргументов твоих оценок не слышал.

См. двумя абзацами выше.

Здравствуйте, 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]))

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

ГВ>>Даже "любой" объект обязан что-то делать, чтобы вместо вызовов его методов не получались сплошные throw.

VD>Попробуй еще раз прочесть о чем идет речь...

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

[...]

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

Бороться с алгоритмами бесполезно. Они сами по себе никому не мешают.

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

В самом по себе описании ничего плохого нет, характерные особенности подхода проявляются... ну, я уже говорил об этом необнократно.

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

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

ГВ>И что от этого изменилось?

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

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

ГВ>Т.е., рефлекшен реализует rtti. Да, не только C++-rtti, да, более развитую модель, но последствия его активного использования тем не менее остаются теми же самыми, что и при использовании C++-rtti.

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

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

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

Вот типичный компонент созданный средствами С++ (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

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

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

IT>>Почемуто у меня создаётся устойчивое впечатление, что в этой ветке не доливают...
S>Перечитал 8 раз. Ниче не понял.

Угадал все буквы не смог прочеть слово. (Это я так... на ум пришло).

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

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

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

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

Короче, тут проблем нет.

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

ГВ>А GetElemCount() — это что такое? Вот такой макрос, что ли:

ГВ>

ГВ>#define GetElemCount(x) (sizeof(x)/sizeof(x[0]))
ГВ>

Ага.

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

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

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

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

WH>>А может просветишь? В моем проекте я очень активно использую rtti и ни каких проблем не вижу.

ГВ>Это... рад за тебя.

А что ты радушеся? Ты столько раз заявлял о кривоте и сетовал на ненадежность, что людям оооООочень хочется увидеть их вообчую.

ГВ>А насчёт "просветишь"... Давай, если тебе интересно, посмотрим на какую-нибудь конкретную ситуацию в которой, как ты считаешь, оправданно используется rtti. Можно приватом (мыло в профайле). Ну а я — выскажусь.

Да. Вот самая простая. Есть компонент который нужно всавлять в дизайнере (все кто говорит, что нужно лепить мапы посылаются юзерами в лес ). Поведай нам реализацию этого на своей компайл-тайм технике.

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

ГВ>Заменить реализацию классов для изменения дизайна действительно может оказаться невозможно. Тут не исключено, что в каких-то случаях нечто типа rtti может оказаться единственным решением.

То то и оно. А еще бывают ситуации когда заменить то можно, но вот объем кодирования просто не соразмерим.

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

AVK>>Я догадался, потому и спрашивал. В твоих тестах не было с чем XmlSerializer сравнивать.

VD>Странный ты мужик. Я тебе лично показывал.

Что ты мне показывал? Твои тесты я видел и неоднократно тебе говорил что делать на основе их какие либо выводы об эффективности дотнетовских xml-парсеров или XmlSerializer невозможно, просто потому что сравнивать не с чем. Вот если бы у тебя был там же тест ручной сериализации в xml то совсем другое дело. Более того — я тебе присылал результаты своего теста, где как раз была сериализация XmlSerializer автоматическая, посредством реализации IXmlSerializable и полностью ручная. Первое и третье были практически одинаковыми. Отсюда я сделал вывод что эффективность XmlSerializer весьма неплохая.

VD>Но ты теперь до смерти будешь утверждать обратное.

Ты так и не привел логической цепочки каким ты образом на основании своих тестов пришел к выводу о неэффективности XmlSerializer.