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

Я это:
VD>
про:

— Гоги! У вас родился ребенок.
— Малчык?
— Нет.
— А кто?

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

WH>Вот оветь на такой вопрос? Если С++ почти мертв как ты утверждаешь то почему МС вкладывает в развитие С++ компилятора кучу денег? Я не могу оценить изменения фреймворка но могу оценить изменения в С++ компиляторе и у меня такой чувство что вложения в него измеряются мегабаксами как минимум. Мало того что он понимает все что мне приходит в голову, компилирует boost лучше всех даже comeau сделал так он еще и не глючит.

Вложение в компилятор — это фактически зарплата группе разработчиков. Пусть их 10, пусть они в среднем получают где-то по 100 кило в год, получается, да, где-то с лимон. Не такие уж большие деньги для MS

Почему вкладывают? А почему нет? C++ всё ещё жив, возможно они даже пытаются что-то сделать, чтобы продлить его существование (возмём тот же MC++), не исключено, что если комитет совсем забьёт на C++, то они самостоятельно добавят в него всё необходимое. Потом, я говорю прежде всего о массовом применении C++, там где надо будет копаться с указателями ему всегда место найдётся, но из прикладного программирования он однозначно будет вытеснен другими языками с более продвинутыми возможностями. Ведь на самом деле, по большому счёту дело не в языке. Почему на Дельфях можно клепать клиентские приложения гораздо быстрее чем на VC++? Да потому что среда на это заточена. Почему Remoting воспринимается новичками за неделю, а COM — это как минимум полгода тума в голове? Потому что Remoting родная встроенная часть .NET и её применение более чем прозрачно, объект делается удалённым или локальным внесением пары строк в конфигурационный файл приложения. Почему все прикладные разработки на Юниксе включая всякие саны делаются на Java, а не на C++? Потому что затраты на разработку несоизмеримо дешевле, а решения надёжнее. То что мы всё ещё используем Visual C++ под Windows, так это просто по старинке, но похоже этому скоро придёт конец. А большего рынка чем под Windows у C++ нет, под юниксом на нём клепают только всякие мелкие софтинки и крохотные тулзинки.

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

_>

_>REGISTER_CLASS("CategoryInfo", CategoryInfo)
_>  REGISTER_MEMBER("CategoryID", CategoryID)
_>  REGISTER_MEMBER("CategoryName", CategoryName)
_>  REGISTER_MEMBER("Count", Count)
_>END_REGISTER_CLASS()
_>

_>И дальше получается та же одна строка.

А что теперь если содержимое запроса изменится?

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

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

Ага. Почти никогда. И откуда взялся термин RTFS?

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

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

Ну, хоть так. Хотя конечно это криво. Кстати, где об этом почитать можно (более менее конкретную ссылку, не java.sun.com).

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

AVK>и к дженерикам джавы.

Кстати, ты уверен что в Яве их тоже дженериками назвали?

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

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

Гы. А как орали! Сакс... сакс... МС нарушают целостность и объектноориентированность языка! Глядишь через некоторое время добавят делегаты со свойствами и будет Шарп2.

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

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

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

Снижают ты хотел сказать. Полиморфизм и без шаблонов неплохо работал. Грамотная реализация шаблонов как раз могла бы избавить от лишних кастов и боксингов.

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

_>Если только чуть-чуть. В отсутствие множественного наследования для проверки возможности кастинга, если кастят не к интерфейсу (а это бывает часто), достаточно пробежаться по цепочке предков испытуемого объекта и попытаться найти нужный тип. А нормальные коллекции value-типов, поднимающие производительность гораздо сильнее, джаве не светят.

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

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

_>У CheckedListViewItemCollection сначала идет Count, а потом ItemArray, а у SelectedListViewItemCollection — наоборот, сначала SelectedItemArray, а потом Count

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

VD>>К тоу-же есть CollectionBase. Наследуйя от него и 90% коллекций будут писаться за пару минут.

_>Это те самые остальные 10%. *ListViewItemCollection пользуются *IndexCollection для получения номеров, чтобы потом вытащить сами элементы из ListViewItemCollection.

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

Кстати, там такая дико не оптимальная реализация, что если сделать на CollectionBase и не допустить таких глупостей, то было бы намного быстрее.

_>Кстати, к msvc 1.0 такой был

В смысле макросы? Или я что-то пропустил?

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

AVK>Мой вариант делегатов? Ты о чем?

Не. Твой вариант динамической подключалки реализаций.

AVK>>>Меньше кода, код легче читать.
VD>>А счего меньше кода? Куда эти чуда-методы пихать?

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

VD>Ага. Почти никогда. И откуда взялся термин RTFS?

не доводите мои слова до абсурда.

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



AVK>Кому как. Написателям библиотек например очень часто приходиться
Разработчик этой библиотеки отлично прочитает такой код. Достатоно привыкнуть, он не так страшен, хотя очень не похож на классический код c++

AVK>Инструментарий тоже надо писать и развивать
Не спорю.

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

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

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

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

IT>>во-вторых, на макросах это даже проще,
WH>Чесно говоря не вижу куда их можно прикрутить

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

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

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

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

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

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

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

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

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

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

IT>>старею...

AVK>Мужаешь

Матерею

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

VD>>Ага. Почти никогда. И откуда взялся термин RTFS?

N>не доводите мои слова до абсурда.

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

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

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

Именно.

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

ГВ>>Я не писал о гарантии правильной реализации. Какой там! Я имел ввиду просто наличие самой по себе реализации. О ней в данном случае можно попросту случайно забыть.

VD>Это работает твое мировозрение. Ты привык что код сериализации должен быть захардкоден. А с использованием информации о типах сериализация делается автоматом.

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

WH>>>Например в моей текущей практике почти половина ошибок на совести компилятора.(BCB6)
ГВ>>Ну... плохой компилятор, что тут можно сказать.

VD>А у меня в основном на моей совести.
У меня, кстати, тоже. Впрочем, с совестью я уже давно договорился по этому поводу.

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

ГВ>>Где гарантия наличия реализации Save (или адекватности его генерации) для всех членов A.Properties? Или скажем так, чем гарантируется, что при введении 501-го типа Property система не начнёт слетать в одном случае из сотни?

VD>Гарантия в коде универсального сериализатора. Код сериализации автоматически сериализует состояние объектов на основании информации о них.

Да фиг с ней, с сериализацией. Вопрос не в сериализации самой по себе. Предположим, что речь идёт не о сериализации, а о чём-то ещё, что так же, как и сериализация, строится по прнципу вызова специфического кода для каждого поля объекта. Ну, к примеру, визуализация.

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

ГВ>>Если такие же, как в .Net, то да. Но они не всегда такие и нужны. А реализовать сопоставление метаинформации экземпляру можно и без rtti.

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

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