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

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

Чем тебе паскалевские указатели не угодили? Ровно такие же как и в С++, кроме наличия в последнем адресной арифметики.

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

Здравствуйте, 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++ ты таки не привык

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

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

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

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

S>Значит, к синтаксису C++ ты таки не привык

Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.

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

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

AVK>Даже если нужно преобразование функиця не нужна. Достаточно вместо переменной использовать свойство.

Его сначала сделать придется, это свойство . То же самое и C++ возможно, просто с функцией в данном конкретном случае меньше писанины.

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

S>>Значит, к синтаксису C++ ты таки не привык

AVK>Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.

Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны?
Я ж не утверждаю, что к синтаксису дельфи привык, хотя около года пришлось с этой бякой поработать.

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

Ok, спасибо.

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

AVK>>Даже если нужно преобразование функиця не нужна. Достаточно вместо переменной использовать свойство.

S>Его сначала сделать придется, это свойство . То же самое и C++ возможно, просто с функцией в данном конкретном случае меньше писанины.

Ну да, функцию отдельную сочинять это конечно куда проще и понятнее чем объявить вместо переменной свойство

AVK>>Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.

S>Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны?

Ты когда последний раз на C# что0либо писал? И как долго? И насколько интенсивно использовал рефлекшен?

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

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

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

AVK>>>Даже если нужно преобразование функиця не нужна. Достаточно вместо переменной использовать свойство.

S>>Его сначала сделать придется, это свойство . То же самое и C++ возможно, просто с функцией в данном конкретном случае меньше писанины.

AVK>Ну да, функцию отдельную сочинять это конечно куда проще и понятнее чем объявить вместо переменной свойство

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

AVK>>>Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.

S>>Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны?

AVK>Ты когда последний раз на C# что0либо писал? И как долго? И насколько интенсивно использовал рефлекшен?

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

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

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

ГВ>>а) Рефлекшн и RTTI — разные, хотя и похожие вещи. Reflection (буквальный перевод — "отражение") — он сам по себе, хотя и реализует функциональность RTTI.

AVK>Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?

Возможность взаимодействовать с экземпляром за счёт атрибутов. RTTI-сугубо информационная сущность. Поскольку RTTI — это runtime type information, а не например — objects, то рефлекшн хоть и включает в себя rtti, но в рамках оценки rtti-based-подхода использовать особенности рефлекшена, ИМХО, неверно.

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

ГВ>Не отмазка, а объяснение. Если я высказался неясно, то нет ничего удивительного в том, что мне пришлось уточнить свою формулировку. Это совершенно нормально.

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

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

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

Хорошо, уточню формулировку — неизвестных типов дотнета.

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

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

ГВ>Кроме того, RTTI-based по-любому сохраняет свои недост..., тьфу, чёрт, характерные черты.

Спорить о вкусах устриц можно только с теми кто их ел, я все больше убеждаюсь в этом.

AVK>>

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

AVK>>Где тут про какие то особенности или термины?

ГВ>А речь в сообщении шла не о C++? Хм. Очень интересно. Поскольку я всё-таки склонен считать, что речь Влада шла о C++, то я и вспомнил об RTTI,

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

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

ГВ>Так или иначе, но все недостатки (sic! — характерные черты) присущие подходу с анализом типов — остаются на месте. Что, if-ы пропадают? Так нет ведь. Онипросто могут быть скрыты, как например в COM.

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

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

То есть, памятуя о контексте твоего высказывания, ты все таки не прав.

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

AVK>>Объясни тогда пожалуйста почему рефлекшен это не RTTI? Что еще предоставляет рефлекшен окромя информации о типах?

ГВ>Возможность взаимодействовать с экземпляром за счёт атрибутов.

Это тоже информация о типах.

ГВ>RTTI-сугубо информационная сущность.

Рефлекшен (если не поминать эмит) тоже.

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

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

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

AVK>>>>Аргумент. Ты уж точно знаешь к чему я привык а к чему нет.

S>>>Ты когда в последний раз на C++ что-либо писал? И как долго? И насколько интенсивно использовал шаблоны?

AVK>>Ты когда последний раз на C# что0либо писал? И как долго? И насколько интенсивно использовал рефлекшен?

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

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

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

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

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

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

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

А я бы на их месте ввел спецификатор const как для ссылок так и для методов. Весьма не хватает этой вещи в Java и .NET!

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

На первый взгляд, можно преодолеть этот косяк, введя для каждого объектного типа пару интерфейсов:

IMyClassConst {}
IMyClass: IMyClassConst

и дооборудовать второй неконстантными методами. Увы, это обман. Как только мы попытаемся унаследоваться от нашего класса, мы встрянем. Ибо наследование интерфейсов у нас только одиночное, и требуемой совместимости ссылок обеспечить не удастся.

Помимо всего прочего, лично мне при проектировании ODBMS очень бы пригодились метаданные о константности методов.

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

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

ГВ>>Custom-атрибуты автоматически добавляются? А указания об их добавлении откуда появляются?

VD>Слышал когда нибудь термин "декларативное программирование"? Значеш в чем его проиемущетсво над обычным?

Что ты подразумеваешь под "обычным"?

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

[skip]
AVK>Ну и что? Грамотный дизайн априори считает что атрибутов нет и используются они только в тех случаях когда надо изменить стандартное поведение. Нет атрибута значит алгоритм отработает штатно.

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

ИМХО, в грамотном дизайне не должно быть нестандартного(частного) поведения. С другой стороны, из моего опыта многие дизайны грешили подобными частностями, т.е. не были грамотными.

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

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

S>Проблема в том, что отдавая мз метода ссылку на внутренний объект мы не можем быть уверены, что получивший ее не примется сразу по ней модифицировать наше содержимое. Все, пинцет. Через метод GetBirthday() мы можем передвинуть дату рождения.

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

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

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

VD>С циклическими ссылками проблемки возникают.
По этому я и написал 99%
А в большинстве случаев можно разрулить при помощи слабых ссылок.