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

_>А вот комбинация из двух интов (Point, скажем) в джаве уже обязана лежать в куче. Чем она хуже простого инта?

Да фигня это по большому счету. В Яве есть куда более серьезные косяки. А структуры как ни крути стройность модели портят. Вернее их реализация в шарпе портит. Я бы на месте МС добавли бы такие фичи как свойства возвращающие ссылку. И еще кой-чё подправил. Тогда бы структуры не портили бы картину. А так у них есть очень узкая область применения.

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

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

DataColumn хранит указатель на абстрактный класс DataStorage с методом object Get(int recordNo). Если делать типизированные геттеры без боксинга, то пришлось бы приводить этот указатель к типу конкретного DataStorage, что по времени уже сравнимо с боксингом. Либо опять же дать базовому DataStorage кучу типизированных геттеров и сеттеров, чтобы потомки переопределили совместимые, а несовместимые оставили бы из базового класса кидающими исключения. Второе решение тоже сделало бы каждый наследник DataStorage сложнее в поддержке — там фактически была бы копия класса System.Convert. Кроме того, DataAdapter.Fill вызывает DataTable.LoadDataRow, передавая ему object[] с данными текущей строки — это тоже пришлось бы сильно усложнить.

Поэтому DataTable, при создании которого не ставилась цель достичь максимальной производительности, имеет простой интерфейс, но делает боксинг там, где написанный руками код не делал бы.

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

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

А нафига стройность языка портить? Еще раз повторю, что тогда уж нужно было и if-ы разрешать.

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

И для этого нужна высокая квалификация?

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

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

S>>Что именно тебя тут пугает? Угловые скобки не нравятся, предпочитаешь квадратные?

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

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

S>> во вторых — для каждого члена, вовлеченного в другие операции (у меня это — DoDataExchange), придется другие атрибуты добавлять. Получится еще страшнее, чем у меня.

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

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

S>>Собственно, код сериализации сидит в библиотеке — в обоих случаях.

VD>Нет батенька. Ты вынужден засорять свой код совершенно неочивидными конструцкиями.

Эти конструкции, тем не менее, кодом сериализации не являются. А очевидными они становятся после прочтения трех строчек комментариев в хедере библиотеки.

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

ГВ>Нет. Я имел ввиду подход, уповающий на то, что в результате анализа неизвестного типа (т.е. — использования rtti) гарантированно будет выбрана (сгенерирована, проэмиччена и т.п., соль и перец по вкусу) корректная реализация алгоритма, его обрабатывающего. Подход этот я назвал "RTTI-Based". Понятно?

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

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

IT>>Без привычки твой код нужно распечатать и сидеть с бумажками разбираться что он там делает. А лучше сразу сбегать в ларёк за пузырём

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

Ну вот, видишь сколько недостатков у шаблонов, даже ларька не хватает

Здравствуйте, <Аноним>, Вы писали:

А>>>И без всяких rtti, чтобы быстрее.

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

А>Ну не только быстрее, но и меньший объем. Просто не переписпл из предыдущего сообщения

Ну уж использование rtti на объем не влияет никак. Только на скорость.

AVK>>А сколько ты вобще видел реализаций с rtti?

А>Мало, только .net и java.

Ну вот о том и речь. На основании этого выводов делать не стоит.

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

ГВ>А я сказал, что это (такой вот тупой маппинг) обязательно надо делать? Это просто прямая альтернатива ручному "программированию" елозеньем мышкой по Object Property-ям. Только и всего. А вообще он вполне сможет сгенериться и по структуре рекордсета.

О, мы уже до кодогенераторов дошли. Типа рефлекшен это кривой дизайн, а вот кодогенераторы это уже прямой. Самому не смешно?

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

ГВ>И для этого нужна высокая квалификация?

Нет, но это однозначно кривой дизайн.

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

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

Ну как нибудь так, если я правильно понял что ты хочешь:

class SomeForm : Form
{
    private string _someVar;
    
    [Exchange(ControlProperty = "Text", Destination = "_someVar")]
    Control _someControl;
}

Функции никакой не надо.

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

S>А это для кого как — для меня, например, шарповские конструкции ужасными выглядят.

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

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

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

VD>>Нет батенька. Ты вынужден засорять свой код совершенно неочивидными конструцкиями.

S>Эти конструкции, тем не менее, кодом сериализации не являются. А очевидными они становятся после прочтения трех строчек комментариев в хедере библиотеки.

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

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

AVK>>Атрибут только называется Serializable

VD>Это не важно.

Ну это типа двойка тебе за знание форматтеров

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

VD>Да фигня это по большому счету. В Яве есть куда более серьезные косяки. А структуры как ни крути стройность модели портят. Вернее их реализация в шарпе портит. Я бы на месте МС добавли бы такие фичи как свойства возвращающие ссылку. И еще кой-чё подправил. Тогда бы структуры не портили бы картину. А так у них есть очень узкая область применения.

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

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

AVK>Здравствуйте, <Аноним>, Вы писали:

А>>>>И без всяких rtti, чтобы быстрее.

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

А>>Ну не только быстрее, но и меньший объем. Просто не переписпл из предыдущего сообщения

AVK>Ну уж использование rtti на объем не влияет никак. Только на скорость.

AVK>>>А сколько ты вобще видел реализаций с rtti?

А>>Мало, только .net и java.

AVK>Ну вот о том и речь. На основании этого выводов делать не стоит.

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

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

_>Второе решение тоже сделало бы каждый наследник DataStorage сложнее в поддержке — там фактически была бы копия класса System.Convert.

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

_>Кроме того, DataAdapter.Fill вызывает DataTable.LoadDataRow, передавая ему object[] с данными текущей строки — это тоже пришлось бы сильно усложнить.

Ничего. Датасет класс не простой. И нармальная типизация ему бы не повредила бы.

_>Поэтому DataTable, при создании которого не ставилась цель достичь максимальной производительности, имеет простой интерфейс, но делает боксинг там, где написанный руками код не делал бы.

DataTable работает очень шустро и если бы не боксинг, то разница со структурами была бы минимальа.

Кргоме боксинга у DataTable-а еще и сериализация через задницу наапсана. Вообще ADO.NET спроектировано криво.

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

S>Эти конструкции, тем не менее, кодом сериализации не являются. А очевидными они становятся после прочтения трех строчек комментариев в хедере библиотеки.

Они загромождают код и замедляют компиляцию.

Здравствуйте, <Аноним>, Вы писали:

А>Ok, наверно я немного не туда ушел. В принцепе я согласен с твоими доводами, но увиденные мной реализации немного не то. В том числе и так защищаемый тобой в этой ветке .net.

Кстати, одним из вариантов сериализации является сериализация в код. Решение не только шустрое, но и чертовски красивое.

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

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

Ну, тогда С++ рулит. Там программист имеет полный контрольк над этим впоросом.

Здравствуйте, <Аноним>, Вы писали:

А>Ok, наверно я немного не туда ушел. В принцепе я согласен с твоими доводами, но увиденные мной реализации немного не то.

Ну посмотри тогда на XmlSerializer, он, в отличие от форматтеров, реализован очень неплохо.

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

VD>Ну, тогда С++ рулит. Там программист имеет полный контрольк над этим впоросом.

Ага, и старый добрый Borland Pascal

Нет, я имел ввиду что не только может управлять этим, но и это управление не сводится к ручному управлению памятью в случае кучи.