Re[40]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.03 19:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

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

Можно несколько вопросов? Спасиба.

И какой рантайм тебе пришлось для этого создать?

Можно ли написать библиотеку на разных компиляторах? Ну, хотя бы С++-ых, хотя конечно желательно вообще на любых.

Можно ли в твоей системе загружать в память только требуемые длл-ки? И если да, то как ты хранишь информацию о типах?

Ну, и последний. Зачем вообще было изобретать велосипед? Ведь есть КОМ. Почему был просто не взять готовую реализацию?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Будущее C#
От: WolfHound  
Дата: 13.07.03 19:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И какой рантайм тебе пришлось для этого создать?

~300 строк (не считая других сервисов они еще примерно столько же)
VD>Можно ли написать библиотеку на разных компиляторах? Ну, хотя бы С++-ых, хотя конечно желательно вообще на любых.
Нет. Это не требовалось.
VD>Можно ли в твоей системе загружать в память только требуемые длл-ки?
Да.
VD>И если да, то как ты хранишь информацию о типах?
В карте фабрик. Ключь — имя класса
VD>Ну, и последний. Зачем вообще было изобретать велосипед? Ведь есть КОМ. Почему был просто не взять готовую реализацию?
COM это слишком тяжолая штука для моей задачи. Хотя ни что не мешает им пользоватся например для работы с ADO или отправки данных в OPC server.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.03 20:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Можно ли в твоей системе загружать в память только требуемые длл-ки?

WH>Да.
VD>>И если да, то как ты хранишь информацию о типах?
WH>В карте фабрик. Ключь — имя класса

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

WH>COM это слишком тяжолая штука для моей задачи. Хотя ни что не мешает им пользоватся например для работы с ADO или отправки данных в OPC server.


Ты почти повторил его. Ком штука концептуальная. И из него можно брать столько сколько нужно.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Будущее C#
От: WolfHound  
Дата: 13.07.03 20:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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

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

VD>Ты почти повторил его. Ком штука концептуальная. И из него можно брать столько сколько нужно.

Я знаю только без гемороя с GUID'ами и необходимости ручками прописывать новые интерфейсы в QueryInterface + куча рюшечек не доступных COM'у.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.03 00:12
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>Я знаю только без гемороя с GUID'ами и необходимости ручками прописывать новые интерфейсы в QueryInterface


Что в твой мам, что в атл-ный. Какая разница?

WH> + куча рюшечек не доступных COM'у.


Например?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Будущее C#
От: WolfHound  
Дата: 14.07.03 04:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что в твой мам, что в атл-ный. Какая разница?

Мне не нужны GUID'ы и мне не надо писать QueryInterface это делает компилятор.

WH>> + куча рюшечек не доступных COM'у.

VD>Например?
Данные в интерфейсе. Не критично но очень удобно иметь прямой доступ к проперти подобным обьектам. К стати в .NET когда надо около сотни проперти подобных полей это придеться писать сотню пропертей в каждом кучу кода к каждому еще по полю с данными, а в моем случае не одно... В принципе может помочь внешний генератор но это криво.
Я же пишу IntParam<ParamID> MyIntParam; и регистрирую в конструкторе MyIntParam(this) компилятор забыть не даст.(В принципе при не большой модификации стандарта регистрация не понадобится) ParamID служит для работы с железкой (так что от него не избавиться) и по совместительству для сериализации.
Шаблонные адапторы к виртуальным функциям. Можно налепить и к КОМу через наследование но это не удобно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.07.03 06:06
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>К стати в .NET когда надо около сотни проперти подобных полей это придеться писать сотню пропертей в каждом кучу кода к каждому еще по полю с данными, а в моем случае не одно...


Сотня пропертей в одном классе это надо что то в консерватории поправить
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 14.07.03 07:24
Оценка: +1
Здравствуйте, VladD2, Вы писали:

S>>Не, нужно 5 раз. Или 500.


VD>Про for слышал? Удивительно помогает в таких случаях.


Ты дурака-то не включай. Это в разных местах программы надо

S>> Некоторый код — до, некторый — после. В общем случае, можно сказать, что у нас есть некоторый алгоритм, который должен вызвать внутри себя заданную мной функцию и передать ей 1 аргумент. Гадость в том, что функции нужно 5 аргументов — 4 из них надо зафиксировать до передачи функции в алгоритм. Писать функтор для каждого такого вызова не хочется. Высокая производительность не требуется. Как это делается на шарпе?


VD>По разному. Самый правильный выход не доводить до такого маразма. Обычно вместо такого метода делается объект у каторого устанавливаются свойства. Продумывается ОО-модель... Ну, а если вдруг придется вызвать метод... то можно и метод вызвать. Нет особых проблем передать нужные пармаетры.


Круто. Надо еще и сортировку через объектные обертки делать — как это я сразу-то не додумался

VD>Тут лучше приводить примеры описывая, что они делают на словах. А тебе будут прводить примеры того как это решается на шарпе.


Я тебе пример уже в коде привел. И на словах описал. Чего еще не хватает?

S>>Это я и так в курсе. Ты ж знаешь, что в С++ к этому случаю ровно тот же подход.


VD>Не совсем. Там нет finally.


И нафиг не надо.

VD>И единственным не кривым выходом является создание обертки.


Именно. finally — криво.

VD>Что многих ленивых орлов наталкивает на идею использовать goto.

Ну, на то они и орлы

S>>boost::bind(&foo, _2, _1)(5, 10) вызовет foo(10, 5).

VD>Тебе не кажется, что это кривое решение? Не проще ли объявить отдельную функцию-врапер?

Я предпочитаю объявлять объект-враппер. С помощью bind'а, в той же строчке, где этот объект используется И мне не кажется, что это более кривое решение, чем замусоривание кода ненужными врапперами.

VD>В Шарпе тоже хотят ввести подобную фичу. Но в отличии от С++ никто даже не думает, о реализации ее через задницу, ой извени, шаблоны . Будут инлайн-методы. Выглядеть будет примерно так:

VD>
VD>foo(){ foo(10, 5) };
VD>


Вот это действительно будет непонятно

VD>Честно говоря я за всю свою зинь как то ни разу не нуждался в подобных наворотах.


А еще честнее говоря, ты про них и не знал, так?

VD>Видимо не очень часто нужная вещь.


Естественно, легко можно обойтись и без подобных удобств. Но это не значит, что нужно обходится без удобств...

VD>Ты некое решение на заплатках описал. А задачу — нет. Задача — это: вывести некий графический объект...

Ну, уморил... Там работы всего-то на пару месяцев было, щаз ты мне простое и элегантное решение на шарпе через пять минут после получения ТЗ сбацаешь

VD>Это тормоза ГДИ+. Они к нету отношения не имеют. На С++ скорость будет той-же.

Ну дак а че ты его сюда приплел?

VD>Недавно видел генератор отчетов на ГДИ+. Работал не медленнее чем аналоги нэйтивные, но насколько же он их обганял по графическим наворотам?! Да и тормоза не на всех опирациях. А если учесть, что рано или поздно ГДИ+ акселерируют...


Вот когда акселерируют, тогда про него и поговорим А пока мне с профайлером приходится код полировать, никакой GDI+ я использовать не буду.

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


Это были не обертки, а разметка. И делала она в 4 раза больше, чем атрибут "сериалайз".

VD>Посмотри код генерируемый VS в Шарповом или ВБ-эшном проекте.


Вот-вот, генерируемый средой. Концептуально это такие же костыли, как VC'шные класс-визарды. Мне надо все фичи на уровне языка, а не среды.

VD>Код сгенерированный макросами хотя бы можно посмотреть. В шаблонах же это в принципе невозможно.

Зато через шаблоны отладчик нормально ходит, если имена не черезчур длинные.

VD>Скрипты и шаблоны имеют значительно больше отличий чем сходст. Ты пытаешся обощить шаблоны до скриптов. Это подмена понятий.

Ты просто не понял

VD>Ну, так отдал бы предпочтение делегатам в том виде как они есть в дотнете. Хотя это бы потребовало создания человеческого рантайма для С++. Но на худой конец хотя бы клосюр. Хотя это по сути указатель на метод. Только не бездарный как в С++, а грамотный да еще и с неким намеком на объектно-ориентированность.


Одни эмоции. Указатели на члены класса и "клосюр" — принципально разные вещи и друг друга не заменяют. Более того, отсутствие "клосюр" — явная дыра в языке, поскольку то, что у борландов называется __closure, согласно нынешним правилам С++, не имеет типа, однако к нему может быть применен оператор ().

S>>Ссылку можно? Прочитаю, интересно.

VD>Я такю бредатину в фавориты не складываю. Попробуй гуглем. Или спрости у С++-гурьев. Они обычно такие ссылки имеют.

Ладно, буду считать это твоей фантазией, возникшей на почве стойкой личной неприязни к Страуструпу, которого ты считаешь главным виновником несовершенства мира

S>>Это потому, что в одном куске кода смешиваются компайл-тайм и рантайм программа. (раз уж тебе аналогия с сервер/клиент сайд скриптом не нравится )


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


Обратная аналогия, не находишь?

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


VD>Ты сказал, что непонятны они только тем кто с ними работать не умеет. Так вот я умею с ними работать очень неплохо.


С шаблонами? Вряд ли.

S>>Не уходи от темы — речь шла не об ошибках, а исключительно о сложности понимания кода.

VD>Одно порождает другое. Ухудшение читабельности приводит к увеличению ошибок, а отсутвие контроля за действиями приводит, к тому, что анализу кода приходится уделять больше внимания и веремени.

Перенос проверок в рантайм приводит к тому же — хотя читабельность при этом и не страдает.

VD>Так же фигня с типобезопастностью. Хотя в С++, и в C# можно писать присвоения внутри ифов, но тем не менее читая C#, я уверен, что проблем с этим не будет. А в С++ я вынужден напрягаться, что не пропустить детские ошибки. Для обхода этих проблем многие программисты стараются ставить в if-ах в качестве первого операнда сравнения rvalue. Тагда код вроде: if(WM_XXX = a) однозначно даст ошибку компиляции. Но, во-первых, такой код тяжелее воспринимать, а во-вторых, можно нечяно упустить это из виду и получить час отладки с выпученными галзами. Так что сложность понимания обратно пропорционально безопастности языка.


Вот насчет if'ов и неявных преобразований я с тобой согласен. Раз в пару-тройку месяцев сам на такую граблю наступаю.

S>>Не о том речь. Хотя с "очень малозатратны" вполне можно поспорить


VD>Вперед. Я это проверял на тестах и был паражен насколько эффективно делаются эти проверки.

Угу, только в С++ эти проверки вообще делаются во время компиляции.

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

S>>Для меня это как раз достоинство Не так скучно работать.
VD>Знаешь почему пилоты делятся на смелых и старых?

Тебе кода-нибудь мало-мальски сложные вычислительные алгоритмы приходилось реализовывать? Так вот, шаблоны по сравнению с ними — детские игрушки. Но, однако, помогают держать мозги в форме до того момента, когда приходится писать что-нибудь действительно крутозагнутое. А то пишешь месяца два всякие диаложки-окошки, а потом бац — подавай TABU search какой-нибудь...
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 14.07.03 07:31
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>C#?


Нет, C#, на мой взгляд, совсем не в том направлении пошел.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[47]: Будущее C#
От: WolfHound  
Дата: 14.07.03 08:25
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Сотня пропертей в одном классе это надо что то в консерватории поправить

Как? Если они один к одному в железку отображаются? А иногда несколько пропертей в одну ячейку.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: Будущее C#
От: WolfHound  
Дата: 14.07.03 08:25
Оценка:
Здравствуйте, Sergey, Вы писали:

VD>>Ты сказал, что непонятны они только тем кто с ними работать не умеет. Так вот я умею с ними работать очень неплохо.

S>С шаблонами? Вряд ли.
Согласен.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[43]: Будущее C#
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.07.03 08:56
Оценка:
Здравствуйте, VladD2, Вы писали:

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


ГВ>>"Не умом поразить тщился, — с достоинством ответил отец Кин. — ...Умные нам ненадобны. Надобны верные." (А. и Б. Стругацкие, "Трудно быть богом").


VD>Это ты к чему?


К тому, что ты хорошо отметил общие тенденции.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 14.07.03 09:14
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Да ничего он не подставляет. А главно, это все настолько через ухо, что пользоваться этим очень сложно.

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

VD>И как ты будешь отлаживать более менее сложный алгоритм засунутый рекурсивный шаблон?

Только сообщениями об ошибках, к сожалению.

VD>Или что будешь делать если рекурсия для решения некоторой проблемы не является удобным подходом?

Буду использовать boost::mpl, когда фирма, где я работаю, соблаговолит переползти на более стандартный компилятор.

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


S>>Ха-ха. Сгенери. Быстрее будет все руками прописать, чем такой код отлаживать.

VD>Завист от объемов. Но факт в том, что его можно будет отлафивать.

Угу, только код-то получаться иногда разный будет, и все его варианты ты по определению не отладишь... И наверняка иногда он вообще с синтаксическими ошибками будет генерироваться — у меня на эти ошибки выругается компилятор еще до поступления кода к пользователю, а у тебя?

S>>Черта с два ты макросами такое сделаешь.

VD>Ну, ну. В чем проблема?

Отлаживаться плохо, например. Ну и с типобезопастностью дело никудышно у макросов обстоит. Прагму внутрь макроса не вставишь. Да полно у препроцессора недостатков.

S>>В гугле набрать слабо?

VD>А ссылку дать слабо? Или вопросом на вопрос интереснее?

Я ее не помню. Ну ладно, потрачу пару минут, найду: http://sourceforge.net/projects/opencxx/

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


VD>Он к языку привязан?


Да.

VD>Или его можно и для того же шарпа применить?


Тебе макросы для шарпа нужны, что ли? А чем плюсовый препроцессор не устраивает?

VD>Ага. Долго расписывать то чего на свете не существует.

Естественно, дольше, чем то, что существует. Новое сначала придумать надо.

VD>Неужели просто тяжело признать факт? С++ не расчитан на работу в компонентной среде и для того чтобы его к ней приобщить придется изобрести свой КОМ.


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

S>>Мы вроде про компил-тайм разговаривали, а?


VD>Тебе шашечки или ехать?

Мне ехать, но чтоб платить по счетчику и по пути не ограбили. С шашечками ехать, как-то спокойнее, знаешь ли.

VD> Генерация кода эмитом и есть компайлтайм. Хочешь засунь его в процесс сборки проекта, а хочешь выполняй по-требованию. Скорость будет как у С++-ного оптимизированного кода. В чем разница то?


А то ты не видишь? Компилтайм твой будет на машине клиента, и все ошибки вылезут, когда программа будет запущена, а не когда ты проект собираешь.

VD>Да никто ничего не удаляет. Это тебе все хочется что-нить через анус сотворить. Атрибуты прекрасно и так работают.

Угу, то, что можно делать в компил-тайме — выносят в рантайм. Нечего сказать, прекрасно.

VD>Это расширение метаданных. Вот в плюсах такого нет. И это их огромное достоинство.

S>>Странно, в D&E он писал, что GC должен предоставляться компилятором. Ссылку можно?
VD>Ссылку уже вряд ли но чуть ли не в своей главной поэме.
Не помню такого, честно говоря.

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

VD>Гы-гы. Что тогда от языка останется? Шаблоны?
Да почти все. Чуть меньше возможных вариантов деклараций, нафиг присваивания из ифов, explicit для кунструктором — по умолчанию, половину преобразований типов выкинуть, никаких компилер-генерируемых конструкторов копирования, если в классе есть члены-указатели ну и еще кое-что по мелочи.

S>>И правильно. Это дело индустрии и на универсальный язык влиять не должно. Ну нафига одинаковый рантайм для какого-нибудь DSP и для персоналки? Рантаймом должны совершенно другие люди и организации заниматься.


VD>Почитай про дотнет и яву. Тогда поймешь.

Ну и много на яве под контроллеры пишут? Про приложения под девайсы мельче чем смартофон что-то не слыхать.

S>>Про АОП больше Александреску выступает. Жаль только, соответствующих папирок с конференций в сети не валяется.

VD>Ага. Как всегда через шаблоны и макросы. Ну, не вставлять же в язык дополнительные кострукции? Пусть даже простые и эффектинве...

Я думаю, многие бы хотели добавить в С++ простые и эффективные средства для работы с метаинформацией. И чтоб "бесплатные" при этом. Но пока их нет — придумывают, как обходится без них.

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


VD>Зачем вытаскивать да еще и "каждтому..."? Нужно описать ее радимую в стандарте и пусть все этот стандарт реализуют. В дотнете именно так и сделано. Получилоь замечательно.


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

VD>Вот тольк я не пойму чем метаданные в рантайме мешают?


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

S>>Являются-являются. Я с макросами так обжигался...


VD>Ну, тут я тебе могу сказать... опыта у тебя мало.

С макросами? Естественно, я же их очень редко использую. Ну а те еще и чужие были, а я об их существовании вообще не знал

VD>Я так пишу без проблем. Но в отличие от тебя прикрасно понимаю, что то-что я привык обходить грабли не делает из граблей ковровую дорожку. Та же фигня с извращениями на шаблонах. Когда ты делашь универсальный алгоритм, применение шаблонов выглядит изящно и правомерно. А когда ты используя откровенные лазейки пытаешся использовать шаблоны для решения проблем для решения которых они просто не предназначены, то получается каша. Которую не то, что поддерживать, ее писать то сложно.


VD>В общем, мое мнение таково: Для решения пролем лучше использовать специально заточенные инструменты.


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

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

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

S>>А я — для тестирования COM'а.

VD>Я раньше тоже для этого использовал. (Кстати, странно. Ведь по-твоему никакой разницы с плюсами у ВБ нет. )

Хинт — в плюсовом коде не обязательно использовать COM. Писать надо в том стиле, который хорошо поддерживается языком, тогда и на плюсах быстрей, чем на VB писать будешь. А COM плюсами фигово поддерживается.
Ну а для тестирования разница вообще огромная — в VB не все типы из плюсов разрешены.

S>>Они вроде даже для VB и жабы есть.

VD>Они там ненужны. Ни ВБ ни Ява не могут привести к таким проблемам как на С++, а на С++ без них в больших проектах никуда.

Да ну? Мне как-то BSTR с бинарными данными потребовалось в ASCII base64 сконвертировать, на VB — так оно так забавно валилось, пока не отладил... И не говори мне, что в VB нельзя с "сырой" памятью работать — еще как можно, если припрет.

S>>Это тоже правильно. В плюсах на совместимость с С тоже следовало бы забить с самого начала. Хотя в этом случае С++ я сейчас вряд ли бы использовал


VD>Да плюсы очень сильно не совместимы с С.


Вот-вот. Совместимость все равно потеряли, а дыр ради нее оставили немеряно.

VD>>>Огромным шагом вперед стал отказ от указателей. По этому поводу можно ерничать.

S>>На самом деле, просто спрятали указатели внутрь смарт-пойнтеров. Чем это от плюсов отличается?

VD>Нет в Шарпе никаких смарпоинтеров. Там целостная идеология.


Верю, верю. Но от смарпоинтеров это мало чем отличается.

S>>Ну да, вместо GPF — ексепшон. Сбой-то остается, последствия просто другие. Так же, как и смартпойнтерами в плюсах.


VD>В 90%-ах просто нет посылок для возникновения эксцепшонов.


Угу, а в плюсах — в 99% просто нет посылок для возникновения ошибок.

VD>Да и эксцепшон — это тебе не испорченая память.


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

VD>Проблема AV не в механизме SEH (который кстати и используется в дотнетных исключениях), а в том, что в подавлющем количестве случаев после него (изи до него) портится память. А это уже не лечится. И если какой-нибудь ворд просто грохнется, а юзер отдуши проматерится, то в сервере приложений такой прикол может обернуться нехилыми потерями денег для компании.


Все так, только порча памяти — достаточно редкое явление.

S>>Что именно треп? Рантайм маленький? Или он уже у каждого пользователя установлен?


VD>См. выше. Хотя про натайм тоже треп. Ты ведь в своей конторе хочешь применять? У вас сеть какая? 20 мег сможете прокачать?


Мы вообще-то софт через интернет в основном продаем, и дистрибутив на 50% утолщать — ну совсем не с руки. Да еще с установкой этого рантайма у клиентов париться (а они, блин, по всему свету) — это уж вообще через край.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 14.07.03 09:40
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Ну а лично для меня это уже излишне.


VD>Приятно, что ты не говоришь, что это вообще ошибка дизайна.


Это потому, что ошибки дизайна могут быть только в конкретном дизайне А мы никакой конкретный дизайн пока не обсуждаем.

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


Это доказывает только то, что тебе макросы привычнее шаблонов.

VD>Это уже печать языка. Так сказать приплюснутость. Наньше такой эффект был у ярых ассемблерщиков. Они тоже гвоорили, что МАСМ выгдядит нормально.


Ну, он и выглядит нормально, если уметь на него смотреть. Мне вот часто говорят, что функционально программирование полный рулез и показывают какой-то код на OCML'е, который на мой посторонний взгляд просто ужасен Но из этого не следует, что тот код плох — просто я его с трудом понимаю.

VD>О вкусах как говортся не спорят, но лично мне такой код очень не нравится.


S>>Лишнего — три строчки на сериализуемый класс.


VD>Нет батенька. Там каждая переменная была обернута.


А это не лишнее — это то же самое, что и атрибут с параметрами для переменной выставить.

VD>В дотнете переменные к контролам вообще не нужно привязывать. Любой контрол объект, т.е. сам по себе переменная.


Хм, а если я хочу из edit'а float'овские данные забирать без написания лишнего кода? Да еще с валидацией?

VD>Много разных способов. Где-то все уже и так есть и грамотно. Где-то можно сгенерировать код и выполнять его.


Ну дык код-то генерировать придется уже в рантайме, на машине клиента.

VD>Ну, что тут можно скзать. У нас разные цели. Мне нужен рабочий код с минимумом затрат, а тебе красивые извраты.


У нас просто разные понятия о минимуме затрат

VD>Что значит еще? Идее метапрограммирования думаю столько же лет сколько существуют высокоуровневые языки.


Ссылки и цитаты, плиз.

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


Ты его явно демонизируешь

S>>Потери производительности — это хорошо?

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

Ну это кому как

S>>Делать в рантайме то, что без труда можно было бы делать в компил-тайме — уродство.


VD>Короче, эта беседа снова плавно перетекает в пустобрехство. Мне это не нравится, так что я из нее выхожу.


Я тоже — завтра в отпуск уматываю

VD>Или давай не брасаться столь пустыми и звонкими фразами.


Чья бы корова мычала "А до генераторов кода этому подходу как до Пекина раком." и т.д., причем абсолютно бездоказательно.

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


S>>Только надежность этого кода никакая будет.


VD>И откуда ты это взял? Снова треп.


Ну а ты головой-то подумай, что надежней будет: сгенерировать код компилятором у себя на машине, и тут же все ошибки увидеть, или генерировать его на машине клиента?

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


VD>Ты не правила задаешь, а извращаешся на эзоповом языке. А до генераторов кода этому подходу как до Пекина раком.


Бездоказательное пустозвонство Ты даже код, который это делает, не видел.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re: Будущее C# - вот это флейм!!!!!!!
От: LaptevVV Россия  
Дата: 14.07.03 14:42
Оценка: 3 (1) :)))
Цитата из письма моего друга, активно действующего программиста, руководителя лаборатории и нескольких проектов. Заранее прошу извинения за эмоциональность монго друга, но видимо, у него сильно накипело!

Мы пишем все на строгом ANSI (старом) Си, и всячески пресекаем бл@@@во ++.
Потому что оно и есть бл@@@во, а не обеспечение безопасности.
Сам посуди — написать на чистом Си объектно ориентированный текст — нет
проблем.
В чем тут может дать выигрыш ++ — я не понимаю. Особенно если учесть, что
написание программы составляет 0.05 % от времени разработки.
В чем экономия? Где деньги, Зин?
Разве что для написания действующих (как бы) прототипов — ну и что?
От прототипа до продукта — ср@ть и ср@ть!!!!
Мы применяем компилятор Борланд 3.1 и 4.5, еще MS 4.1. Проверены.
Лицензий не надо.
Я лично ЗАПРЕТИЛ применение Борланда 5 и выше, когда исследовал
несколько объектных файлов. На х@@. Я хочу спать спокойно.
Про # — не знаю. Это финт сына самой популяроной женщины в мире.
И от этого финта она станет еще популярней. Зачем???????
Ты хоть можешь мне пояснить — хоть три причины — что именно я получу
при переходе на эту пое@@@нь?????
Я вижу единственный козырь у них — новые платформы будут поддержаны
только этим компилятором. Х@й в нюх! Фортран жил, жив и будет жить!
А почему? Потому, что много его, написано много. И на Си написано много.
Так что пусть не вые@@@@@@@ся. Но тема очччччень забавная! Пиши!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Будущее C# - вот это флейм!!!!!!!
От: IT Россия linq2db.com
Дата: 14.07.03 16:29
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Цитата из письма моего друга, активно действующего программиста, руководителя лаборатории и нескольких проектов. Заранее прошу извинения за эмоциональность монго друга, но видимо, у него сильно накипело!


Похоже что твой друг — воинствующий динозавр и убеждать его в обратном не стоит
Сори, не в обиду, но выглядит это никак не иначе.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Будущее C# - вот это флейм!!!!!!!
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.07.03 18:18
Оценка:
Здравствуйте, LaptevVV, Вы писали:


LVV>Я лично ЗАПРЕТИЛ применение Борланда 5 и выше, когда исследовал
LVV>несколько объектных файлов. На х@@. Я хочу спать спокойно.


Мда... Слушайте, мож это шутка такая?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Будущее C# - вот это флейм!!!!!!!
От: Воронков Василий Россия  
Дата: 14.07.03 21:50
Оценка: :))
Здравствуйте, LaptevVV, Вы писали:

Почитал я тут соседнюю ветку про XML, где все говорят — сжатие нужно, сжатие, дескать много повторяющихся данных и пр. Вот я и думаю, если из этого текста весь мат выкинуть, то ведь какое сжатие получится-то! Одни только названия стандартов да языков останутся. В общем товарищи выкинем весь мат из XML! Впрочем, я лучше спать пойду.
... << RSDN@Home 1.1 beta 1 >>
Re[46]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 03:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Мне не нужны GUID'ы и мне не надо писать QueryInterface это делает компилятор.


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

WH>>> + куча рюшечек не доступных COM'у.

VD>>Например?
WH>Данные в интерфейсе.

Это скорее ошибка дизайна.

WH> Не критично но очень удобно иметь прямой доступ к проперти подобным обьектам.


Так проперти или данным?

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


Не понял? А какие приемущетсва у С++? В дотнете классы могкут иметь публичные члены. В общем не ясно о чем ты...

WH>Шаблонные адапторы к виртуальным функциям. Можно налепить и к КОМу через наследование но это не удобно.


А какова их цель?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.03 03:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Как? Если они один к одному в железку отображаются? А иногда несколько пропертей в одну ячейку.


Дык надо было для этой ячейки классик создать...
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.