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

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

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

A>>>

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

A>Не нужно приписывать мне свои эмоции. Я себе подобного рода несдержанные постинги не позволяю.

A>На остальное отвечать не вижу смысла.

Эмоции эмоциями, а тебе дело пишут. Ответь хоть что-нить на них, а обижаться стоит в другом месте. moderator@rsdn.ru

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

WH>Судя по презентции код на C++/CLI короче чем на шарпе дык с какого ты взял целый год тормозов на C++/CLI?

Вообще-то он про то, что раньше чем через год это чудо не появится.

WH>Короче в чем C++/CLI уступает шарпу. Только не надо размытых фраз типа шарп проще. Давай конкретно.

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

Хотя о чем я?... У тебя же ошибок не бывает, а пишишь ты со скоростью пулемета. Но не все же такие гении?

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

IT>>Расширяемый компилятор, AOP во всей красе, может ещё чего.
WH>Поставлю вопрос по другому что там будет такого чего не будет в C++/CLI?

Запись добровольцев...

Автор: VladD2
Дата: 23.12.03

Метапрограммирование (к топику о новом языке)

Автор: AndrewVK
Дата: 16.12.03

А не залудить ли нам свой язык для дотнета?

Автор: VladD2
Дата: 08.12.03

В общем, через неделю другую (как разгребем дела с журналами) начту мутить. Так что присоеденяйся и С++ тебе покажется детской игрушкой.

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

A>На остальное отвечать не вижу смысла.

А зря. Что же касается не сдержанности, то твой снобизм ее и вызвал.

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

IT>Это всё мелочи реализации. Создание объекта и его привязка к прокси свободно может контролировать компилятор.
IT>Например в шарпе никто не знает и не ведает о боксинге, тем не менее он на каждом шагу.
В шарпе другая сениматика языка. Там нет адресной арифметики, а из С++ ее не убрать.
Если убрать хендлы то либо убираем адресную арифметику либо делаем явный боксинг. Ибо они пересекаются.
IT>В MC++ есть пин-указатели, которые также контролируются компилятором. Ничего страшного, все живы и здоровы.
И кто на нем (МС++) активно пишет? Проблема в том что если из пин указателя преобразовать в обычный (а именно для этого и сделаны пин указатели) обратное преобразование не возможно, а пути легаси кода не исповедимы. Да и в любом случае его придется держать пин указатель пока легаси код указатель колбасит.

IT>Ты не понял главного. Не надо new и gcnew. Надо только один new и всё.
Да все я понял. Проблема в том что есть легаси код...(чтоб он провилился) А если писать все в новои стиле то можно к черту все хендлы выкинуть... Но...

IT>Вот это меня и настораживает. Поздравляю, господа, перед вами первый в мире язык поддерживающий одновременно две модели памяти! Заводите студентов, щас мы им это быстренько на пальцах растолкуем, а потом посадим писать программы.
А две модели памяти будут в любом случае. Просто с хендлами они явно разделены, а без них ГЦ объекты будут очень сильно походить на не ГЦ объекты.

IT>Всего один? Слабак!
Я перевоспитался. Спасибо. А вот тебя похоже тоже надо немного повоспитывать.

IT>AOP проповедует (если я его правильно понимаю) вынесение всего служебного кода из собственно кода. И использование для такого кода исключительно декларативных средств языка. Под служебным кодом может пониматься всё, что так или иначе выполняется исключительно для обеспечения поддержки функциональности, но не сама функциональность. Т.е. в идеале код должен содержать чистый сироп из бизнес-логики. Все остальные вспомогательные составляющие кода должны быть отжаты и вынесены в декларативную часть.
Вау! Это же 2 в одном серебряная пуля + TProgrammer...

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

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

IT>Например, наследование реализации:
хъ
IT>Не надо даже объявлять соответсвующие методы, компилятор всё что надо достроит сам.
А ну точно круто и какую из энного колличеста имеплементаций брать?
IT>Конечно, тоже самое можно сделать и в C++ при помощи шаблонов и наследования. Но как насчёт разнородных классов? Правильно, множественное наследование! Ты хорошо знаешь этому цену? А так?
хъ
IT>Только множественное наследование. Либо... компилятор может легко справиться и с этой задачей, сгенерировав необходимые методы, основываясь на исчерпывающей инфеормации о типах. И при этом вполне обойтись без усложнения структуры VMT.
Такого понятия как VMT если мне не изменяет скалероз в стандарте нет. Следовательно это компиляторо зависимая фича. Следовательно при описании шаблона реализации можно его пометить компилиторо-зависимым атрибутом как встраиваемый. Пример

#if   defined(__MY_COOL_COMPILER)
#define mixin __declspec(built_in) struct 
#elif defined(__HIS_COOL_COMPILER)
#define mixin __built_in struct 
#else
#define mixin struct 
#endif

#define mixin_impl()\
self_type* self()\
{\
    return static_cast<self_type*>(this);\
}\
const self_type* self()const\
{\
    return static_cast<const self_type*>(this);\
}\
//end mixin_impl

template<class self_type>
mixin IActivatableImpl
    :IActivatable
{
    mixin_impl()
};

template<class self_type>
mixin ISavableImpl
    :ISavable
{
    mixin_impl()
};

struct MyClass
    :IActivatableImpl<MyClass>
    ,ISavableImpl<MyClass>
{
};

А интерфейсы ИМХО давно пора в С++ стандарт внести.

IT>Ну а с этим уж совсем тоска:
хъ
IT>Здесь я не просто хочу от компилятора добавления соответсвующих методов интерфейса, но так же реализации свойств. Да не просто так, а что бы свойства только возвращали int и string, а внутренне были представлены классами EditableInt32 и EditabelString.
И от куда компилятор об этом узнает? Уж не из факта неследования от IEditable ли? А если бедет интерфейс ISuperEditable?

IT>А теперь я хочу, чтобы метод save открывал транзакцию и закрывал её, если не произошло никаких исключений:
Как у тебя все просто... Что за транзакция? А ели Save пишет в две базы данных, в фаил и отправляет письмо?

IT>И сохранял лог, если произошло исключение неизвестного типа:
Пред и пост условия... старо как мир вот только почемуто языки с ними не прижились. Хотя иногда может быть удобно.

IT>Ну и проверку входных параметров делал:
Круто
А атрибут на возвращаемое значение как повесть.

IT>А вообще для написания Data Access Layer мне практически достаточно состыковать сигнатуры метода класса и сохранённой процедуры. Так в чём проблема:
Опять. С какой базой? Через какого провайдера?
IT>Готово. Ах да, забыл, Name может быть null, но только при изменении:
А где сказано что в InsertCustomer должно быть не null?
IT>Может и бизнес слой также упростить. Например, даже при наличии имплементации соответсвующих методов добавить в них что-то своё. Ну например вызов метода валидации обрабатываемого класса:
Пред/пост условия. Не ново хоть и выглядит симпотично.
В следующем стандатре С++ можно будет делать так

template<class T>
struct Validator
{
    Validator(T* _this)
        :this_(_this)
    {
        save_state();
    }
    ~Validator()
    {
        if(забыл как зовут функцию сгнализирующею об исключении||!is_valid())
        {
            rollback();
        }
    }
private:
    T* this_;
    //...
};
Validator<T> Validate(T* _this)
{
    return Validator<T>(_this);//RVO Optimization
}
...
    void InsertCustomer(Customer c)
    {
        auto Validate(this);
                //...
    }

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

IT>Ко всему прочему, Александреску учил тебя правильному использованию комбинации наследования и шаблонов. В результате, некоторые на форуме (одного я точно знаю ) говорят, что ты можешь творить с этим чудеса. А теперь представь, что у тебя появилось ещё одно измерение — вся информация о типах и полный контроль над генерацией кода. Сумеешь этим распорядиться?
Он учил меня не комбинации наследования и шаблонов(хотя и этому тоже), а получению информации о типах в время компиляции и генерации на ее основе кода. Чем я давно и с толстым удовольствиет пользуюсь. И еще надеюсь что в следуещей версии С++ можно будет получить больше информации.

IT>Видишь ли в чём дело. Первый персональный компьютер был сделан умельцами в гараже. VB писался на коленках двумя студентами в самолёте. Кто знает, кем и где будет написан язык программирования намбер ван начинающегося столетия
Так. Все. Завтра сажаем тебя за этот компьютер, даем в руки тот самый васик и заставляем тебя переписывать на нем RSDN.

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

WH>

WH>#if   defined(__MY_COOL_COMPILER)
WH>#define mixin __declspec(built_in) struct 
WH>#elif defined(__HIS_COOL_COMPILER)
WH>#define mixin __built_in struct 
...
WH>

Тебе самому это не страшно читать?

WH>А интерфейсы ИМХО давно пора в С++ стандарт внести.

Вот только комитет и страуструп считают иначе.

WH>И от куда компилятор об этом узнает? Уж не из факта неследования от IEditable ли? А если бедет интерфейс ISuperEditable?

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

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

IT>>И сохранял лог, если произошло исключение неизвестного типа:
WH>Пред и пост условия... старо как мир вот только почемуто языки с ними не прижились. Хотя иногда может быть удобно.

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

WH>Круто
WH>А атрибут на возвращаемое значение как повесть.

Хреново ты Шарп знаешь.

[return: NotNull]
object Test()
{
  ...
     // Здесь будет ошибка при компиляции или в рантайме если 
     // при компиляции невозможно определить что возвратит функция.
  return null;
}

WH>Опять. С какой базой? Через какого провайдера?

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

WH>В следующем стандатре С++ можно будет делать так

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

WH>Реализуйте а там видно будет.

Обязательно.

WH> Но мучают меня смутные сомненья что не все так безоблачно как ты рисуешь.

Кто бы спорил.

WH>Он учил меня не комбинации наследования и шаблонов(хотя и этому тоже), а получению информации о типах в время компиляции и генерации на ее основе кода.

Лучше бы он почитал про OpenC++. Глядишь весь этот огород и не стал бы городить.

WH> Чем я давно и с толстым удовольствиет пользуюсь. И еще надеюсь что в следуещей версии С++ можно будет получить больше информации.

Это примитив и детские игры. Серьезных вещей так не добиться. Все будет громоздко и неполноценно.

WH>Так. Все. Завтра сажаем тебя за этот компьютер, даем в руки тот самый васик и заставляем тебя переписывать на нем RSDN.

Он уже на Шарпе.

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

Не вдаваясь в полемику рекомендую почитать блог Саттера, если конечно еще не...

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

WH>>А атрибут на возвращаемое значение как повесть.

VD>Хреново ты Шарп знаешь.
VD>

VD>[return: NotNull]
VD>object Test()
VD>{
VD>  ...
VD>     // Здесь будет ошибка при компиляции или в рантайме если 
VD>     // при компиляции невозможно определить что возвратит функция.
VD>  return null;
VD>}
VD>

Ты не понял. Он на значение хотел.

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

L>Ты не понял. Он на значение хотел.

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

Ребят, да вы что обалдели?

Парень спросил про дату выхода CLI/C++. IT ему ответил, (пусть даже не точно, не так это важно). Тут WolfHound уведел парня, пишушего на C#, который что-то сказал про C++. И вместо того, чтобы поправить дату WolfHound'а понесло...

На мой взгляд весь комизм в том, что примеры С и С# оба по 6 строчек (если в C# не считать открывающих и закрывающих скобок).

Но WolfHound так ретиво ратует за краткость, что не поленился нафигарить чесяток огромных постов. Мля, где логика?

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

WH>Здравствуйте, IT, Вы писали:
кстати драфт стандарта
можно найти здесь
http://blogs.gotdotnet.com/branbray/

или прямая ссылка
http://download.microsoft.com/download/9/9/c/99c65bcd-ac66-482e-8dc1-0e14cd1670cd/C++%20CLI%20Candidate%20Base%20Draft.pdf

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

IT>>Например в шарпе никто не знает и не ведает о боксинге, тем не менее он на каждом шагу.
WH>В шарпе другая сениматика языка. Там нет адресной арифметики, а из С++ ее не убрать.

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

Вообще же указатели в C++ — это дремучее наследие C, ничего больше. А этому языку уже лет сорок наверное. Ещё во времена C++ люди писали программы скальпелем на перфокартах и это было круто. А во времена молодости C нормальным было программирование регистров процессора с помощью тумблеров на панели управления вычислительного устройства. К сожалению, сейчас уже не те объёмы задач и совсем другие требования к качеству софта и срокам разработки. А как известно, свойства продукта не могут превышать больше чем на порядок свойства того средства, на котором этот продукт сделан. Т.е. хочешь C++? Получите лики. У тебя в распоряжении только CRTL? Потрать время на написание своего доморощенного фреймворка.

WH>Если убрать хендлы то либо убираем адресную арифметику либо делаем явный боксинг. Ибо они пересекаются.

Там где они явно пересекаются я согласен исользовать что-то и явно. Понимабельность кода от этого только выиграет.

IT>>В MC++ есть пин-указатели, которые также контролируются компилятором. Ничего страшного, все живы и здоровы.
WH>И кто на нем (МС++) активно пишет? Проблема в том что если из пин указателя преобразовать в обычный (а именно для этого и сделаны пин указатели) обратное преобразование не возможно, а пути легаси кода не исповедимы. Да и в любом случае его придется держать пин указатель пока легаси код указатель колбасит.

Легаси не легаси — это понятие временное. Ты либо один раз поработаешь над переносом библиотеки, либо будешь писать всё с нуля. Писать одновременно и в новом и в старом моделях ты долго не будешь, только во время переходного периода. Но тем не менее, handles прибиты гвоздями в язык и их уже оттуда не вырубишь топором. Т.е. все будущие поколения разработчиков будут с недоумением спрашивать, а зачем в языке ещё какие-то '*' и '&'? И ты будешь объяснять своим потомкам

— Ну понимаешь, внучок, была когда-то в C++ такая штука как нативные указатели...
— Какие кто?
— Ну такие поинтеры на объекты...
— Объекты знаю, а поинтеры это что?
— Ну это объекты перед которыми стоит '*'...
— А...

И т.д.

IT>>Ты не понял главного. Не надо new и gcnew. Надо только один new и всё.
WH>Да все я понял. Проблема в том что есть легаси код...(чтоб он провилился) А если писать все в новои стиле то можно к черту все хендлы выкинуть... Но...

То-то и оно. Вот тут alex говорил про кодинг фром скрач. Ну чушь это полная. Раз я пишу фром скрач, то нахрен мне одновременно '*' и '^' Переходный период в жизни каждого C++ девелопера мог бы быть не более нескольких месяцев. Но не тут то было. MS нам запланировал его до пенсии.

IT>>Вот это меня и настораживает. Поздравляю, господа, перед вами первый в мире язык поддерживающий одновременно две модели памяти! Заводите студентов, щас мы им это быстренько на пальцах растолкуем, а потом посадим писать программы.
WH>А две модели памяти будут в любом случае. Просто с хендлами они явно разделены, а без них ГЦ объекты будут очень сильно походить на не ГЦ объекты.

Да и фиг с ними. Пусть они походят на что угодно, лишь бы C++ походил на C++.

IT>>AOP проповедует (если я его правильно понимаю) вынесение всего служебного кода из собственно кода. И использование для такого кода исключительно декларативных средств языка. Под служебным кодом может пониматься всё, что так или иначе выполняется исключительно для обеспечения поддержки функциональности, но не сама функциональность. Т.е. в идеале код должен содержать чистый сироп из бизнес-логики. Все остальные вспомогательные составляющие кода должны быть отжаты и вынесены в декларативную часть.
WH>Вау! Это же 2 в одном серебряная пуля + TProgrammer...

Дык. Я уже почти живу во всём этом счастье. Объём кода заметно сокращён. Но страшно не хватает поиска ошибок во время компиляции, страдает отладка и приходится писать много абстрактных классов.

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

Какая больше подходит. Решит это компилятор, который будет натренирован тобой.

IT>>Только множественное наследование. Либо... компилятор может легко справиться и с этой задачей, сгенерировав необходимые методы, основываясь на исчерпывающей инфеормации о типах. И при этом вполне обойтись без усложнения структуры VMT.
WH>Такого понятия как VMT если мне не изменяет скалероз в стандарте нет.

В стандарте может и нет, а вот в жизни есть.

WH>Следовательно это компиляторо зависимая фича. Следовательно при описании шаблона реализации можно его пометить компилиторо-зависимым атрибутом как встраиваемый. Пример

Компиляторо-зависимые фичи — это ещё один бред, придуманный создателями языка. Причём скорее всего это сделано из-за элементарной нехватки времени и попытки сделать язык совместимым со всеми существующими тогда платформами. Но ведь всё равно фигово получилось. Делали язык программирования на века, а пришёл юникод и всё похерил. Оказалось что C++ под него просто не приспособлен, потому-что в своё время может опять же не хватило времени, может просто поленились, но строковый тип в язык не ввели. Вот и получите.

[скип]

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

IT>>Здесь я не просто хочу от компилятора добавления соответсвующих методов интерфейса, но так же реализации свойств. Да не просто так, а что бы свойства только возвращали int и string, а внутренне были представлены классами EditableInt32 и EditabelString.
WH>И от куда компилятор об этом узнает? Уж не из факта неследования от IEditable ли? А если бедет интерфейс ISuperEditable?

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

IT>>А теперь я хочу, чтобы метод save открывал транзакцию и закрывал её, если не произошло никаких исключений:
WH>Как у тебя все просто... Что за транзакция? А ели Save пишет в две базы данных, в фаил и отправляет письмо?

А тебе что именно надо?

IT>>И сохранял лог, если произошло исключение неизвестного типа:
WH>Пред и пост условия... старо как мир вот только почемуто языки с ними не прижились. Хотя иногда может быть удобно.

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

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

IT>>А вообще для написания Data Access Layer мне практически достаточно состыковать сигнатуры метода класса и сохранённой процедуры. Так в чём проблема:
WH>Опять. С какой базой? Через какого провайдера?

Ну сам подумай, есть тысяча способов.

IT>>Готово. Ах да, забыл, Name может быть null, но только при изменении:
WH>А где сказано что в InsertCustomer должно быть не null?

Тебе уже не к чему придраться?

WH>Реализуйте а там видно будет. Но мучают меня смутные сомненья что не все так безоблачно как ты рисуешь.

Естественно, за все удовольствия надо платить.

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

O>Не вдаваясь в полемику рекомендую почитать блог Саттера, если конечно еще не...

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

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

А>Добрый день!

А>У меня возник простой вопрос: КОГДА ВЫЙДЕТ CLI/C++,
А>то есть это будет реализовано в новой версии студии?
А>И в каком году, в каком месяце можно ждать его появления....

А>Спасибо — С новым годом

После прочтения драфта у меня сложилось впечатление, что программирование на CLI/C++ под .Net
сродни удалению гланд через .... автогеном.

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

IT>Какая больше подходит. Решит это компилятор, который будет натренирован тобой.

Выглядит полным бредом, или я недопонял

Ну-ка побудь на месте компилятора и подбери чего-нибудь подходящего на IDisposable. И как это "тренировать" я что-то совсем недорубаю.

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

IT>>Какая больше подходит. Решит это компилятор, который будет натренирован тобой.

M>Выглядит полным бредом, или я недопонял



M>Ну-ка побудь на месте компилятора и подбери чего-нибудь подходящего на IDisposable.

Вот кстати, тоже хороший пример. Всё элементарно. Смотрим, есть ли у нас мемберы нашего класса, которые имплементируют IDisposable. Если есть и программист сам не определил Dispose в классе, то строим такой метод, по всем правилам освобождая в нём мемберы с IDisposable. Вот код

Автор: IT
Дата: 15.08.02

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

M>И как это "тренировать" я что-то совсем недорубаю.

После того как компилятор распарсил код и создал дерево объектов и кода у себя в памяти, он должен вызвать моё расширение, которое сможет проанализировать и при надобности изменить это дерево. Затем возможно ещё раз синтаксический анализ и генерация исполняемого кода. Что-то подобное сделано в XC# (ссылочка где-то здесь пробегала). Основная проблема, как я понимаю, это именно взаимодействие компилятора и расширений. Если это не закладывать в компилятор с самого начала, то шансов на успех практически никаких.

Второй вариант — это что-то типа препроцессора. Перед тем как вызвать стандартный компилятор код отдаётся такому препроцессору, который самостоятельно осуществляет парсинг и добавляет в код недостающую реализацию. Затем изменённый код отдаётся стандартному компилятору.

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

IT>Manager C++ существует уже почти два года — Управляемый C++

Автор(ы): Игорь Ткачёв
Дата: 05.02.2002
До сих пор трудно ответить на вопрос, что такое .Net. Эта статья, являясь введением в Managed Extensions for C++ (MC++), содержит описание ряда смелых экспериментов советских ученых, наконец-то позволяющих понять, что же такое .Net вообще, и место MC++ в нем, в частности.

Попробовал скомпилировать C++ проект для .NET (MSVС++ 7.1) и заметил, что вызов виртуальной функции выполняется примерно 700 тактов.
Можно это как-нибудь ускорить?

IT>строим такой метод, по всем правилам освобождая в нём мемберы с IDisposable. Вот код

Автор: IT
Дата: 15.08.02

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

А порядок освобождения? А блокировки? А исключения? Для IDisposable такая самодеятельность не прокатит.

M>>И как это "тренировать" я что-то совсем недорубаю.

IT>После того как компилятор распарсил код и создал дерево объектов и кода у себя в памяти, он должен вызвать моё расширение, которое сможет проанализировать и при надобности изменить это дерево.

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

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

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

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

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

IT>>>Например в шарпе никто не знает и не ведает о боксинге, тем не менее он на каждом шагу.
WH>>В шарпе другая сениматика языка. Там нет адресной арифметики, а из С++ ее не убрать.

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

Современные приложения далеко не ограничиваются тем, чем вы занимаетесь.

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

Я, как настоящий истребитель индеёцев, бью по рукам всех в тиме, у кого ручонки тянуться к stl boost loki и.т.п. лабуде.

IT>Вообще же указатели в C++ — это дремучее наследие C, ничего больше.

Указатели -- один из краеугольных камней C/C++. Тот, кто не умеет ими пользоваться, просто не владеет основами языка, таким людям надо выбирать себе языки попроще, C#, например.

IT> А этому языку уже лет сорок наверное. Ещё во времена C++ люди писали программы скальпелем на перфокартах и это было круто. А во времена молодости C нормальным было программирование регистров процессора с помощью тумблеров на панели управления вычислительного устройства. К сожалению, сейчас уже не те объёмы задач и совсем другие требования к качеству софта и срокам разработки. А как известно, свойства продукта не могут превышать больше чем на порядок свойства того средства, на котором этот продукт сделан. Т.е. хочешь C++? Получите лики. У тебя в распоряжении только CRTL? Потрать время на написание своего доморощенного фреймворка.

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

Тут надо понимать одну вещь. Человеческий мозг -- гораздо более мощное орудие, чем любой компилятор. Поэтому попытка избавиться от необходимости думать, спихивая свою работу тупой машине, контрпродуктивна. Это прокатывает только для определённых классов задач, где можно ограничиться несложным комбинированием простых рецептов. Это то, что можно условно назвать Макдональдс. У Джоела об этом хорошо было написано. Но существование Макдональдсов нисколько не отменяет существование дорогих и качественных ресторанов, где работают не повара, окончившие 21-дневные курсы, а истинные мастера своего дела. Кстати, куда вы водите свою любимую женщину? Неужели в Макдональдс?

По существу дискуссии.

Насколько я понимаю, MC++ был скороделкой, его вполне можно при этом использовать. Что будет с выходом новой версии C++/CLI и как оно будет выглядеть -- ещё вилами на воде писано. Мне кажеться, лучше дождаться релиза, а тогда и обсуждать, что удачно, что нет.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

Ш>Попробуйте, в качестве упражнения, сделать хороший текстовый редактирующий элемент, такого же класса или лучше, как в студии. Если я правильно понял, Янус использует Scintillе-у? А что, свой было влом сделать?

Зачем?