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

S>Ага, вот тут уже начинается интерестность. Ну, во-первых, приведение константной ссылки к неконстантной — запрещено. Поэтому никакого косяка не возникает.

Одну ссылку присвоили другой, другую привели.

S>При рефлекшне — это да. Но ведь я же не могу вызвать приватный метод через рефлекшн?

Почему не можешь? Вполне.

S>А вот про реализации — извините! const — это часть сигнатуры. Тs же не спрашиваешь "А если для некоего интерфейса реализация метода М в одном классе возвращает int, а в другом string?".

Нет, ты не понял. Входной параметр это некий интерфейс и его ты объявляешь const. Или ты только про value-типы?

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

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

Здравствуйте, 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 не нарушает своего обещания не трогать объект. В плюсах ха этим следит копилятор.

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

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

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

Очень неплохие вводные.

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

Хммм, любопытно...

WH>Хардкорить функции экспорта нельзя(помним о новых логических типах).

Здесь немного не понял: экспорта чего и куда?

WH>Короче ехешник это абстрактная фабрика классов создающея объекты по имени типа возвращать она может только I_Object, а к конкретному интерфейсу приводим на месте через dynamic_cast.

Т.е., грубо говоря, примерно так:

1. Пользователь выбирает из списка некое устройство, из имеющихся в системе;
2. Имя, соответствующее этому устройству передаётся фабрике, реализованной в exe-шнике, которая создаёт объект нужного типа, возвращая I_Object*;
3. Полученный I_Object* передаётся куда-то (скорее всего — в длл, реализующую обработку, специфичную этому устройству), где из него посредством dynamic_cast<> получается какой-нибудь I_IBM_Device*.

Если я прав, то два вопроса:
— Как реализовано заполнение фабрики?
— Каким образом на шаге 3 определяется класс или функция, которая обрабатывает специфику;

Если не прав, то поправь меня, плз.

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

VD>>При этом метаданные на порядок лучше. Ну, а метаданые в компайлтайме нужный не очень сильно. sizeof-а более чем достаточно.
S>Кому как. Мне так и typeof нужен, и список членов класса, и граф наследования. А дальше уж я б на них шаблоны бы натравил.
Ну еще надо auto, template typedef, ... Также былобы не плохо упразнить маразмы которые там на кождом шагу. Просто мне уже смешно смотреть на то что глюки (а глюки ли? ) VC++ позволяют писать болие простой код чем стандарт.

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

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

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

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

ГВ>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()

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

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

Насчёт внешних объектов я уже говорил здесь

Автор: Геннадий Васильев
Дата: 06.07.03

. И ещё раз повторился рядом

Автор: Геннадий Васильев
Дата: 09.07.03

— в дискусси с AVK. Суть здесь — не в обработке внешних по отношению к моей программе данных, а в организации моей программы.

PS

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

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

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

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

А runtime-casting — не особенность? А оверхед, связанный с этим — не особенность?

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

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

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

Э-э-э... раскрываю страшную тайну:

class Component {...}; // Объявление интерфейса
Component *pComp = CreateNewComponent(Parameter); // О, чудо!

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

ГВ>А runtime-casting — не особенность? А оверхед, связанный с этим — не особенность?
Очень часто это оправдано, а иногда не заменимо.

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

ГВ>>А runtime-casting — не особенность? А оверхед, связанный с этим — не особенность?
WH>Очень часто это оправдано, а иногда не заменимо.

Всяко бывает...

Здравствуйте, 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? В смысле — они встраиваются в какой-то оборачивающий диалог или показываются независимо?

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

ГВ>Э-э-э... раскрываю страшную тайну:

ГВ>

ГВ>class Component {...}; // Объявление интерфейса
ГВ>Component *pComp = CreateNewComponent(Parameter); // О, чудо!
ГВ>

ГВ>)

Будь любезен. Обяви свой компонент в другой длл-ке.

Или типа все кто писали КОМ и Корбу были туупее тебя?

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

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

ГВ>А runtime-casting — не особенность? А оверхед, связанный с этим — не особенность?

Да что ты так смущаешся. Ты кривоту покажи. )

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

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

А типа const неля послать к чертям?

Здравствуйте, 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>Не, не зря. Там новый (ну не для всех, конечно, он новый) подход к шаблонным извращениям описан.

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

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

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

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

Я же говорил?!

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

_>Еще в 75-ом была среда, в которой все было ран-тайм, никаким другим таймом и не пахло.

А я и есть осторожный. Если был бы не осторожный, то сказал бы в семедесятых.

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

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

ГВ>Не повторяй моей ошибки с неоднозначно трактуемым утверждением. Я не характеризовал последствия в системе "печальный-радостный".

Значит идешь на попятную? Что же — это радует.

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

ГВ>"моей программы" — имеется ввиду та программа, которую разрабатывает и контролирует конкретный дизайнер.

А компонент это тоже "твоя программа"? Или он обязан быть частью дезайрена?