Re[42]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.07.03 08:30
Оценка:
Здравствуйте, orangy, Вы писали:

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


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

S>>В каком это смысле послать к чертям?
O>Думаю, Влад имеет ввиду const_cast
Ну, мы же люди взрослые. Понимаем, что в управляемой среде такие трюки запрещены. Как и reinterpret_cast вместе со static_cast.
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: Будущее C#
От: Sergey Россия  
Дата: 11.07.03 08:49
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Мне несколько другая метаинформация нужна.


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


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

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


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

S>>Шаблоны это и есть кодогенератор.


VD>Не серьзяно это.


Еще как серьезно.

S>> Помнишь, я пример сериализации на С++ с кучей тайпдефов кидал? Вот там именно в компил-тайме в библиотеке генерируется код, перебирающий все (заданные в шаблоне) базовые классы и ищущий нужный тип у члена ddxMembers и возвращающий его значение (простым static_cast'ом), если в пользовательском коде была использована шаблонная функция data или field, принимающая параметр нужного типа.


VD>Помнишь как по уродски смотрелся этот код?


Нормально смотрелся.

VD>И сколько лишнего кодирования он требовал?


Лишнего — три строчки на сериализуемый класс. Одна из них — из-за убогости используемого мной компилятора, одна — из-за отсутствия в языке средств работы с нужной мне метаинформацией. Последняя — ну, от нее я просто не вижу как в рамках С++ избавится.

VD>И помнишь какой код нужен для дотнета?


Уродски смотрелся — если добавить привязку переменных к контролам. А мне это тоже нужно.

VD>Так вот для создания оптимального решения. Нужно чтобы в языке появились реальные и удобные средства компайлтайм-кодогенерации. Чтобы можно было создать некий мета-сериализатор. Который по информации о классе (причем без дополнительной разметки, или с минимумом таковой) генерировал бы код сериализации для класса.


Именно. Часть из этого уже предоставляют шаблоны.

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


Как?

VD>Дык пока нет. Да и использование рекурсивных шаблонов — это очередной обход убогости языка средствами шаблона. Мне именно это не нравится.


А мне — нравится.

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


Дак не успели еще. И некому пока. Это ж надо, чтоб очередному Страуструпу очередная AT&T зарплату платила, пока он над всякими изысками размышлять будет.

VD>>>В дотнете все обычно вуже в рантайме....


S>>Это то и плохо.


VD>Ничего в этом плохого.


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

VD>Рантайм просто необходим в современных условиях.


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

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


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

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


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


Херню потому что повторяешь Компилятор проверяет, унаследована ли переменная ddxMembers у текущего класса от нужного типа, и если нет — рекурсивно делает то же для базового класса. Пока не упрется в терминальный базовый класс. Я только задаю правила, по которым компилятор это делает. Это именно программа, выполняемая компилятором — такая же, как и та, что заставляет компилятор вычислять факториал.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[43]: Будущее C#
От: WolfHound  
Дата: 11.07.03 08:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>50%? Даумаю лично у него 99% уходит на свой энжин. Шутка ли создать собственную (пусть и ограниченную) реализацию ком-а?

У меня весь энжин строчек 200-300 при этом он умеет не только CreateObject. Сейчас 80%-90% идет именно на бизнес логику, а другие только ей и занимаются.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Будущее C#
От: Юнусов Булат Россия  
Дата: 11.07.03 09:02
Оценка:
Здравствуйте, Аноним, Вы писали:

А>C# мёртвый язык и жизни ему не будет. Прочти — http://www.cydsoft.com/vr-online/3_2003/hvsms.htm и http://www.cydsoft.com/phpBB2/viewtopic.php?t=64


Мда, читая "Delphi. Horrific против MS" местами плакал.

"Корпорацию Borland всегда ругали за то, что программы, скомпилированные на нём, получаются большого размера. Я чисто для примера создал пустой проект с помощью MFC Wizard со статической компиляцией, когда всё необходимое встраивается в один exe файл. Когда я скомпилировал проект (напоминаю, он был пустым), то на выходе получил запускной файл размером чуть более 2 метров. Это не шутка. Я чуть ли не упал со стула, когда увидел такие размеры."
Re[2]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 09:29
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>C# мёртвый язык и жизни ему не будет. Прочти — http://www.cydsoft.com/vr-online/3_2003/hvsms.htm и http://www.cydsoft.com/phpBB2/viewtopic.php?t=64


Очередная демагогия. Ну вот например

Меня поражают разработчики Microsoft. Посмотрите на Office 2000 и ХР. В них используются очень хорошие, удобные и красивые меню и панели кнопок. А теперь запустите Visual Studio .NET и посмотрите на его меню. Они также выполнены в стиле ХР. И тут возникает вполне резонный вопрос – где в Visual Studio .NET объекты, которые позволят мне создавать подобные меню? Нету? И Office и Visual Studio .NET являются разработкой одной компании, так почему же я должен самостоятельно писать объекты меню в стиле ХР или Office 2000?

Почему программисты Borland заложили в свой Delphi 7 подобные компоненты, а Microsoft не может поделиться даже этим?


Во первых — а почему они собственно обязаны выкладывать все что использовалось в создании среды, причем забесплатно? Во вторых — а где в Дельфи 7 компонент object inspector?

Даже то, что встроено в Delphi в несколько раз превышает то, что предоставляет нам Microsoft.


Сравним по охвату фреймворк и VCL? Или мы считаем по количеству рюшечек, которые мышкой можно перетянуть на форму?

Компонентная модель Delphi действительно удобна, и программер не тратит время на создание интерфейса, а занимается программированием и созданием логики приложения, а не всякой ерундовиной.


А где собственно аргументы подразумеваемому неудобству компонентной модели дотнета?

вроде бы сильно защищены (ага, так я и поверил)


Аргументы?

приложения С# будут работать только на Windows 2000/XP. А куда девать огромный парк машин с Windows 95/98/ME.


Просто ложь. Фреймворк работает и под 98 и под МЕ. Далее куча выводов, основанных на этой лжи идет в корзину.

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


Ну что тут можно сказать? Абсолютно неаргументированные вопли.

На данный момент С# программисту абсолютно не нужен. В нём нет ничего такого, ради чего можно было бы программировать на этом языке.


Собственно ни одного аргумента мы так и не услышали. одни эмоции и наглая ложь.

Корпорацию Borland всегда ругали за то, что программы, скомпилированные на нём, получаются большого размера. Я чисто для примера создал пустой проект с помощью MFC Wizard со статической компиляцией, когда всё необходимое встраивается в один exe файл. Когда я скомпилировал проект (напоминаю, он был пустым), то на выходе получил запускной файл размером чуть более 2 метров. Это не шутка. Я чуть ли не упал со стула, когда увидел такие размеры


Скомпилял бы тогда уж и минимальный проект на шарпе. Наверное тоже упал бы со стула (3К, если мне не изменяет память)

У меня крутые программы занимают не более 2 мегабайт, так в них столько окон, что MS WORD покажется однооконной системой.


Детство в заднице играет, извините за выражение
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[42]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 09:35
Оценка:
Здравствуйте, IT, Вы писали:

IT>Конечно сложнее. Что там у тебя за CreateObject'ом скрывается? У меня за активатором стандартная библиотека


Боюсь что даже не библиотека, а рантайм.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[41]: Будущее C#
От: Sergey Россия  
Дата: 11.07.03 09:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Да ничего там не перебирается и не ищется. Все есть заранее. Шаблон есть шаблон. Просто универсальная параметризованная реализация.


Ты просто не представляешь себе всех возможностей шаблонов.

S>>Было бы чего перебирать. Обычная рекурсия с условиями за счет специализации с этим на раз справлятся. Книжку Александреску почитай для начала, или сразу в boost::mpl загляни (но там, блин, трудно что-то понять с наскоку).


VD>Все равно это не кодогенерация. Это некий алгоритм выполняесый компилятором.


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

VD>Да и неудобно это ужасно.


Кому как.

VD>>>В дотнете все обычно вуже в рантайме....

S>>Это то и плохо.

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


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

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


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


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

S>>Они, кстати, уже есть — OpenC++, например.


VD>Ссылкой не поделишся? Чтыо за зверь?


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

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


VD>И как ты себе видишь "такую" работу при условии, что информация тебе становится доступна только в рантайме? Ну, не твой компонент, а алогоритм для работы с ним написать нужно.


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

class MyPublicClass {...};

std::provide_type_info(MyPublicClass);

S>>Там что, есть иные средства генерации кода, кроме шаблонов и макросов?


VD>CodDOM и Reflection.Emit. Гибче небывает.


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

S>> Или шаблоны атрибуты в качестве параметров понимают? Если нет, то до метаинформации опять в компил-тайме не добраться — ну и нафиг мне такое щастье?


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


Чума Удаляем гланды ректально

S>>Чем же тебе так Страуструп не угодил?


VD>А ты почитай, что он пишет про все нововведения. GC — можно раелизовать как библиоткеку... (Ака щаз!)


Странно, в D&E он писал, что GC должен предоставляться компилятором. Ссылку можно?

VD>Информации о типах достаточно...


Это про rtti, наверное, а не про компайл-тайм информацию о типах. Про компайл-тайм информацию о типах он, AFAIK, вообще не писал.

VD>расширять язык дальше нельзя...


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

VD>Ну, а про рантайм и компоннтный подход вообще молчек. Какбодто таковго не существует.


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

VD>Впрочем как и АОП и т.п.


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

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


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

VD>>>Тут спору нет. Метаданные могли бы сослужить огромную службу. Но стандрат плюсов просто таки борится с этой идеей.


S>>С какой идеей? Просто идеи метапрограммирования на шаблонах слишком недавно появились — уже после принятия стандарта.


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


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

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


Я б от компил-тайм for и while тоже не отказался .

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


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

VD> Даже при условии наличия опций препроцессинга в код.


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

VD>В конце концов метапрограммирование, генерация кода, анализ метаданных в рантайме и т.п. — это редкие в повседнвеной жизни выпендрежи. Они позоляют сделать некоторую (шаблонную) работу быстрее, но и без них можно жить. Более того 90% работы как раз не требует таких решений. И тут Шарп на коне. Ну, а про рантайм и говорить нечего. По сравнению с дотнетом в С++ он просто отсуствует.


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


VD>Нет такой доли. Эти языки по простоте использования проактически одинаковы. Поверь, человеку написавшему не мало кода на ВБ.


Я тоже на VB немало понаписал. И никакого преимущества в скорости написания кода у VB перед C++ не заметил.

VD>В последнее время ВБ использую только для написания макростов в ворде, и то исключительно из-за того, что в ворде нельзя подключить Шарп.


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

VD>В общем, попробуй и сам поймешь, что Шарп это некий гибрид С и ВБ. Можно сказать С на стеройдах.


Во-во, С, а не С++. Убого.

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


VD>Да. Соблюдая некоторые правила, можно сделать программирование на С++ значительно безопаснее. Но все равно проблем выше крыше.


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

VD>Любой кто написал большую систему на плюсах не даст соврать.


Большая — это сколько?

VD>Иначе зачем все эти баундчекеры и т.п.?


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

VD>При проектировании Шарпа очень многие аспекты вызывающие проблемы были учтены. Например, было введенв специальные ключевые слова для перекрытия методов — override и new.


Это мне, кстати, понравилось.

VD>Так же был усилен контроль типов. Так int не приводится автоматически к bool и ошибку вроде:


VD>
VD>if(ia = ib)
VD> ...
VD>


VD>допустить становится практически невозможно. Зато писть:

VD>
VD>if((ia = ib) != 0)
VD> ...
VD>

VD>По прежнему можно. И совершенно безопастно. И таких примеров море.

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

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


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

VD>Но это действительно невироятно защищает программу от сбоев.


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

S>>Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...


VD>Извени, но это треп. Ты попробуй.


Что именно треп? Рантайм маленький? Или он уже у каждого пользователя установлен?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[44]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 12:03
Оценка:
Здравствуйте, IT, Вы писали:

IT>Тебе ещё надо метод в двух местах объявить: в .h и в .cpp


Зачем? Кул программеры все пишут внутри хи.. нет, хеадеров
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[42]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 12:13
Оценка:
Здравствуйте, Sergey, Вы писали:

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


Дело не в GPF или эксепшене, дело в том что большинство ошибок вызовут эксепшен именно там, где ошибка в коде, а не запортят где нибудь данные, породив тем самым нестабильные и трудноуловимые глюки.

S>>>Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...


VD>>Извени, но это треп. Ты попробуй.


S>Что именно треп? Рантайм маленький?


Нет, язык примитивный.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[42]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.07.03 12:22
Оценка:
Здравствуйте, Sergey, Вы писали:

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


S>Для меня это как раз достоинство Не так скучно работать.


Ну тогда нам наверное дальше спорить не о чем
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[43]: Будущее C#
От: Sergey Россия  
Дата: 11.07.03 12:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>Дело не в GPF или эксепшене, дело в том что большинство ошибок вызовут эксепшен именно там, где ошибка в коде, а не запортят где нибудь данные, породив тем самым нестабильные и трудноуловимые глюки.


С чего бы это? Случаи порчи данных при применении смартпойнтеров в моей практике еще не встречались

S>>>>Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...


VD>>>Извени, но это треп. Ты попробуй.


S>>Что именно треп? Рантайм маленький?


AVK>Нет, язык примитивный.


А что еще можно сказать про язык, который не позволяет даже ввести одно имя из нэймспейса в локальную область видимости. Впрочем, ты даже разницы между языком и рантаймом не видишь...
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[2]: Будущее C#
От: IT Россия linq2db.com
Дата: 11.07.03 15:36
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>C# мёртвый язык и жизни ему не будет. Прочти — http://www.cydsoft.com/vr-online/3_2003/hvsms.htm и http://www.cydsoft.com/phpBB2/viewtopic.php?t=64


Мда, задумчивое чтиво. Какого только бреда не валяется в сети.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Будущее C#
От: IT Россия linq2db.com
Дата: 11.07.03 15:42
Оценка: :)
Здравствуйте, Sergey, Вы писали:

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


C#?
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Будущее C#
От: IT Россия linq2db.com
Дата: 11.07.03 15:52
Оценка:
Здравствуйте, Sergey, Вы писали:

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


Зарядить функцию с переменным числом параметров?

void f(params object[] p)
{
}
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 20:32
Оценка:
Здравствуйте, Sergey, Вы писали:

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


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

S>Еще как серьезно.


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

VD>>Помнишь как по уродски смотрелся этот код?

S>Нормально смотрелся.

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

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


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

VD>>И помнишь какой код нужен для дотнета?


S>Уродски смотрелся — если добавить привязку переменных к контролам. А мне это тоже нужно.


В дотнете переменные к контролам вообще не нужно привязывать. Любой контрол объект, т.е. сам по себе переменная. А уродски сотрится именно изголения на С++. Под дотнетом чистый и понятный. Для сериализации так вообще никакого дополнительного кода не надо. Если это уродство, то дальше говорить не очем.

S>Именно. Часть из этого уже предоставляют шаблоны.


Нужно только уточнить сотую или десятую.

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


S>Как?


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

VD>>Дык пока нет. Да и использование рекурсивных шаблонов — это очередной обход убогости языка средствами шаблона. Мне именно это не нравится.


S>А мне — нравится.


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

S>Дак не успели еще. И некому пока. Это ж надо, чтоб очередному Страуструпу очередная AT&T зарплату платила, пока он над всякими изысками размышлять будет.


Что значит еще? Идее метапрограммирования думаю столько же лет сколько существуют высокоуровневые языки. А в плюсах этих изменений видимо уже дождаться будет нельзя. По крайней мере Страуструб рубит все свежие веянья на корню.

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


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

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


Короче, эта беседа снова плавно перетекает в пустобрехство. Мне это не нравится, так что я из нее выхожу. Или давай не брасаться столь пустыми и звонкими фразами.

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


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


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

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


Ты не правила задаешь, а извращаешся на эзоповом языке. А до генераторов кода этому подходу как до Пекина раком.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 20:32
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ты просто не представляешь себе всех возможностей шаблонов.


Ну, куда нам тупым.

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


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

VD>>Да и неудобно это ужасно.


S>Кому как.


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

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

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


Завист от объемов. Но факт в том, что его можно будет отлафивать. А втой рекурсивный шаблон точно нет. Генерация кода в общем-то не сложное занятие.

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


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

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


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

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


Он к языку привязан? Или его можно и для того же шарпа применить?

VD>>И как ты себе видишь "такую" работу при условии, что информация тебе становится доступна только в рантайме? Ну, не твой компонент, а алогоритм для работы с ним написать нужно.


S>Долго расписывать, это не для флейма тема. Но выглядеть для пользователя это могло бы примерно так:

S>class MyPublicClass {...};
S>std::provide_type_info(MyPublicClass);

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

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


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

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


S>Чума Удаляем гланды ректально


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

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


Ссылку уже вряд ли но чуть ли не в своей главной поэме.

VD>>Информации о типах достаточно...


S>Это про rtti, наверное, а не про компайл-тайм информацию о типах. Про компайл-тайм информацию о типах он, AFAIK, вообще не писал.


А ему всего и всегда достаточно. Хотя информация о типах конечно в первую очередь нужна в рантайме и дизайтайме.

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


Гы-гы. Что тогда от языка останется? Шаблоны?

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


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

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


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

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


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

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


S>Я б от компил-тайм for и while тоже не отказался .


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

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


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

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

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


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

S>Я тоже на VB немало понаписал. И никакого преимущества в скорости написания кода у VB перед C++ не заметил.


Значит ты очень силно отдалился от реальности.

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


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

S>Во-во, С, а не С++. Убого.


Ты попробуй, а потом расскажещь.

VD>>Любой кто написал большую систему на плюсах не даст соврать.

S>Большая — это сколько?

Ну, Сегабайта 1.5 чистых (рукописных) исходников. Я это прошел на двух проеках. Один 1.5 мега. Второй 3.5. И никто не убедит меня, в том что С++ удобно читать.

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


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

S>Это мне, кстати, понравилось.


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

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


Да плюсы очень сильно не совместимы с С. Одна разница в описании функций чего стоит?! Но все же дыр и в них хватает. Собственно правила безопастного программирования на С++ и заключаются в уходе от стиля С.

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


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


Нет в Шарпе никаких смарпоинтеров. Там целостная идеология. Все сделано, так чтобы можно было жить без указателей. Они даже временами палку перегибают. Так BinaryRiader (средство чтения инфомации из бинарных файлов) написали не на указателях, а на операторе >>. Давольно забавно смотрится. И что удивительно не сильно проигрывает в скорости работе с указателями. Видимо оптимизация на уровне JIT-а.

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


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

S>>>Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...

VD>>Извени, но это треп. Ты попробуй.

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


См. выше. Хотя про натайм тоже треп. Ты ведь в своей конторе хочешь применять? У вас сеть какая? 20 мег сможете прокачать?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 20:32
Оценка:
Здравствуйте, Sergey, Вы писали:

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


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

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


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

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

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


Не совсем. Там нет finally. И единственным не кривым выходом является создание обертки. Что многих ленивых орлов наталкивает на идею использовать goto.

S>Надо передать ее в алгоритм, который хочет void bar(int x), при этом y должен быть равен 4.5, а s — "asdf";


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


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

В Шарпе тоже хотят ввести подобную фичу. Но в отличии от С++ никто даже не думает, о реализации ее через задницу, ой извени, шаблоны . Будут инлайн-методы. Выглядеть будет примерно так:
foo(){ foo(10, 5) };


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

VD>>Ты лучше задачу опиши.

S>Описал чуть выше.

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

VD>>Кстати, тоже рисование в дотнете сделано куда изящнее. Правда это скорее заслуга грамотности проектирования обертки над GDI+. Аналогичную можно использовать и на плюсах.


S>Тормоза.


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

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

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


Нет. И твой пример этому доказательство. Ты вынужден был изпещрить весь код кучей ненужных оберток. Красивое решение я тебе показал... в дотнете все эти ужимки попросту ненужны. Посмотри код генерируемый VS в Шарповом или ВБ-эшном проекте. Там чистейший воды код. Без ужимок и уродвств. Причем 90% информации для сериализации берется из описания контролов создаваемого автоматом, 9.9% — это разметка атрибутами, и только 0.1 процента — это кодирование и навороты.

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

S>Не, с макросами отладка на порядок хуже.

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

S>А увиливание от ответа — тоже, кстати, один из приемов демагогии.


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


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

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


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


S>А я что, где то говорил, что делегаты в С++ нужны?


А что речь была про тебя?

S> Делегаты — лишняя сущность, вполне хватило бы __closure и шаблонов с переменным числом параметров. А то, блин,


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

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


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

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


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

S>Плохой. А третьего-то подхода нету...


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

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


Ты сказал, что непонятны они только тем кто с ними работать не умеет. Так вот я умею с ними работать очень неплохо. Но так как не являюсь их фанатом (да и С++-а), то понимаю, что от них слишком много проблем, и их слишком сложно читать. Я даже в С++ вместо:
(*a++) = b;

Предпочитаю:
a[i] = b;
i++;


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


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

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

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


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

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


S>Для меня это как раз достоинство Не так скучно работать.


Знаешь почему пилоты делятся на смелых и старых?
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 21:10
Оценка: :))) :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Или мы считаем по количеству рюшечек, которые мышкой можно перетянуть на форму?


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

Кстати, какое все это отнешение к дотнету имеет я не пойму. Тот же борланд уже склепал среду для Шарпа и срубает бабки продавая в месте с ней компоненты от компонент-ван. Там менюх те что надо.

AVK>А где собственно аргументы подразумеваемому неудобству компонентной модели дотнета?


Не. Ну ты тупой! Ты ламер думешь, что компонентная модель — это некая идеология построения и взаимодействия с компонентами. А — это грамотное наклепывание и складывание по закладкам обертон над МС-ными контролами из момон-контролс.

AVK>

вроде бы сильно защищены (ага, так я и поверил)

AVK>Аргументы?

Где? Да и зачем?

AVK>Просто ложь. Фреймворк работает и под 98 и под МЕ. Далее куча выводов, основанных на этой лжи идет в корзину.


Ну, опять ты обежаешь заслуженных гуру. Что такое фрэймворк? Как его установить? Не, не. Не надо про какие-то инсталляторы на 20 мег. Фрэймвор это же VS.NET! А она не работает. Значит и приложения создать и запустить нельзя.

AVK>Ну что тут можно сказать? Абсолютно неаргументированные вопли.


Ты чё? Какие аргумнты. Это же крик души? Ну, в смысле призыв душить.

AVK>

На данный момент С# программисту абсолютно не нужен. В нём нет ничего такого, ради чего можно было бы программировать на этом языке.


AVK>Собственно ни одного аргумента мы так и не услышали. одни эмоции и наглая ложь.


Как? В Шарпе нет банальных бегинов с эндом! Как без этого жить? А это обявление переменных внутри кода! Это же форменный изврат!

AVK>

Корпорацию Borland всегда ругали за то, что программы, скомпилированные на нём, получаются большого размера. Я чисто для примера создал пустой проект с помощью MFC Wizard со статической компиляцией, когда всё необходимое встраивается в один exe файл. Когда я скомпилировал проект (напоминаю, он был пустым), то на выходе получил запускной файл размером чуть более 2 метров. Это не шутка. Я чуть ли не упал со стула, когда увидел такие размеры


AVK>Скомпилял бы тогда уж и минимальный проект на шарпе. Наверное тоже упал бы со стула (3К, если мне не изменяет память)


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

Причем я бы еще понял, бы если ты издевался над каким то ламером. Но этот парень и в правду истенный талант. Так как у меня как я не крутил так и не удалось создать (визардом) на MFC исполняемый файл размером больше 989 килобайт. Возможно моя ошибка была в том, что я компилировался в релизе, но не в этом суть... Ты замхнулся на незыблимые факты! Ты бы еще преплел, что ATL-проект можно довести до размера в 3 килобайта вообще без внешних длл-ей. Это же не честно!
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 21:10
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>C# мёртвый язык и жизни ему не будет. Прочти — http://www.cydsoft.com/vr-online/3_2003/hvsms.htm и http://www.cydsoft.com/phpBB2/viewtopic.php?t=64


А что же анонимом, то? У такого юмора должен быть автор!
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.07.03 21:10
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Боюсь что даже не библиотека, а рантайм.


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