Re[35]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>> В том же COM-е был только IDispatch.


AVK>Ну так это оно и есть.


Это не оно. Это левая ужимка. "Оно" окромя Явы и дотнета я нигде не видел.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Список членов класса — это метаданные или что?


Список есть список. "Мета" означает — описывающие себя. В даном случае о самоописании речи не идет. Так что...

S>А не нужен мне ни MC++, ни дотнет. А нужна только метаинформация в компил-тайме.


Дык похоже, что это тперь будет только в дотнете и Яве. Так что выбор не велик. Да и не ясно в чем проблема то? С++ там тот же, только с метаданными.

S>Кому как. Мне так и typeof нужен, и список членов класса, и граф наследования. А дальше уж я б на них шаблоны бы натравил.


Оно все есть. Вот только шаблны в виду их статичности, ну, никак не прикрунишь. Скорее кодогенератор.

S>Здрасте. А про то, что сериализацию в шарпе проще и надежней делать, не ты ли распинался?


А в шарпе нет шаблонов и макросов.

S> Если б С++ была возможность получить хотя бы список членов класс и перебрать предков класса (в компил-тайме, само собой),


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

S> сгенерить код сериализации класса на С++ не совтавляло бы почти никакого труда.


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

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


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

S>Естественно, потому как С++ такой информации и не предоставляет.


Ну?! О том и речь. Тот же МС++ дает полную информацию о себе. Т.е. сделать то можно. Вот только ортодоксы типа Страуструпа всю малину портят.

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


Можно. Но это "плохой дизайн" . Чем? Это не ко мне.

VD>>А анализировать при компиляции особо нечего.


S>Это как сказать.


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

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


S>Ну это у кого как.


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

S>Есть живучесть, а есть надежность. Живучесть у шарпного кода может и выше, а вот с надежностью все не так однозначно.


Очень даже однозначно. При проектировании еще Явы этот пункт ставили в приоритеты. А уж о дотнете и говорить не приходится.

S>Мы, видимо, на его постинги с разных позиций смотрим.


И тем неменее. Там есть четкий приговор метаданным.

SP

В общем, займись дотнетом и посмотрим на твои позиции чезе годик.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Будущее C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.03 20:55
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну давай так, сторонний компонент, как ты правильно заметил, для C++, это либо plain-api (значит-исходники), либо классы (значит — тоже исходники), либо какие-то самоописывающиеся интерфейсы (к примеру — COM). Самоописывание интерфейсов нужно для генерации исходников, которые затем будут использоваться мной. Это, фактически, единственный путь использования сторонних объектов в программах на C++. rtti или нечто похожее может понадобиться для анализа данных, получаемых извне, особенно, если дизайн стороннего компонента предполагает такой способ его использования. С точки зрения дизайна моей программы в данном случае rtti будет использован для задачи обработки внешних данных и, кстати, последствия в виде... ну я уже говорил, — никуда не денутся. И моя, кстати, негативная их оценка — тоже, несмотря на то, что это может оказаться единственным выходом. Ну сам посуди: что мне, радоваться что-ли, от того, что я, например получаю какой-нибудь IBase*, для которого надо клепать dynamic_cast<IDerived*>, обрабатывать потенциальные ошибки и т.п?



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

WH>
WH>DLL_EXPORT_MAP_BEGIN()
WH>    DLL_EXPORT_CLASS(C_MyCoolSensor)
WH>    DLL_EXPORT_SINGLETON_CLASS(C_MyCoolSingleton)
WH>DLL_EXPORT_MAP_END()
WH>


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

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


То-то, ни одни из известных компиляторов не удовлетворяет стандрту С++ на 100%.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Будущее C#
От: IT Россия linq2db.com
Дата: 09.07.03 22:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В .NET это можно сделать несколько проще(но не сильно).


В .NET это деалется как два байта:

(IMyDeviceInterface)Activator.CreateInstance(className);


className можно в виде строки положить в базу или в любой конфигурационный файл по вкусу. Всех описываемых тобой ограничений типа одна dll и пр. не существует в принципе. Хоть одна dll, хоть четыре. При желании можно использовать и стандарные типы вроде "System.String" если они конечно поддерживают твой интерфейс.

В общем, в .NET это не "несколько проще", а совсем элементарно. У меня на подобной ерунде совместно с PropertyGrid'ом весьма навороченный визуальный редактор построен. Расширяется он во все стороны элементарно описанным выше способом.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[40]: Будущее C#
От: WolfHound  
Дата: 10.07.03 04:25
Оценка:
Здравствуйте, IT, Вы писали:

IT>В .NET это деалется как два байта:

IT>
IT>(IMyDeviceInterface)Activator.CreateInstance(className);
IT>

Можно подумать у меня сложнее
CreateObject<IMyDeviceInterface>(className);


IT>className можно в виде строки положить в базу или в любой конфигурационный файл по вкусу.

У меня тоже причем этим уже давно пользуются. И это было заложено с самого начала.
IT>Всех описываемых тобой ограничений типа одна dll и пр. не существует в принципе. Хоть одна dll, хоть четыре.
Какие ограничения? Кто говорил об ограничениях? Да хот один класс-одна длл без разници. Просто классы отвечающие за одну железку лежат в одной длл. Что в этом плохого?
IT>При желании можно использовать и стандарные типы вроде "System.String" если они конечно поддерживают твой интерфейс.
Ну это мне нафик не упало.

IT>В общем, в .NET это не "несколько проще", а совсем элементарно. У меня на подобной ерунде совместно с PropertyGrid'ом весьма навороченный визуальный редактор построен. Расширяется он во все стороны элементарно описанным выше способом.

Веришь нет но мое приложение тоже расширяется во все стороны знай себе дллки пиши.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.07.03 06:41
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хорошо, пусть не "провоцирует", а "...упрощает реализацию такого дизайна, который...".


Ну и смысл в этом высказывании? Можно так же сказать что удобный редактор кода упрощает copy&paste программирование. Отсюда делаем вывод — использование хорошего текстового редактора приводит к good text editor based design, который крив.

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


ГВ>Ну давай так, сторонний компонент, как ты правильно заметил, для C++, это либо plain-api (значит-исходники),


Хидеры а не исходники. Это не одно и то же.

ГВ> либо классы (значит — тоже исходники)


Опять же совершенно необязательно.

ГВ>И моя, кстати, негативная их оценка — тоже, несмотря на то, что это может оказаться единственным выходом. Ну сам посуди: что мне, радоваться что-ли, от того, что я, например получаю какой-нибудь IBase*, для которого надо клепать dynamic_cast<IDerived*>, обрабатывать потенциальные ошибки и т.п?


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

ГВ>Если бы смысл моей фразы был один, то и спорить было бы не о чем. И извини, но: а) на каком основании ты расписываешься за всех, кто читает этот топик, и б) смысл своей фразы буду объяснять я,


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

ГВ>особенно, если собеседники меня не поняли сразу. И ещё раз, я не говорил, что rtti — это абсолютно "кривой" дизайн.


Именно это ты и сказал.

AVK>>1) Мог использоваться отдельно в любом проекте без исходных кодов


ГВ>Исходный код — необходимое условие для C++ и ты это отлично знаешь.


Почему же? Есть ведь dll, СОМ

ГВ>Выполнение этого условия невозможно.


Неприспособленность языка для компонентного программирования?

ГВ>Исключение составляет ситуация, когда исходник или информация, достаточная для его восстановления "спарены" с бинарным кодом.


Ну вот и замечательно, так и реализуй.

ГВ>Условие неправомерно.


Почему это неправомерно? Очень даже.

AVK>>2) Мог сериализоваться в бинарный поток и xml


ГВ>Реализовать схему сериализации несложно,


Ну реализуй. Потом сравним с дотнетом.

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


Ага, опять С++ не подходит.

ГВ> Верно? Если так, то

ГВ>Условие неправомерно.

А по моему очень даже.

AVK>>3) Его экземпляр можно было бы передать по сети


ГВ>При наличии приёмника на другой машине — несложно.


Ну вот и покажи как. Сравним с дотнетом.

AVK>>4) Обеспечивался бы контроль версий класса


ГВ>Реализуемо соответствующей инфраструктурой.


Покажи как. Сравним с дотнетом.

AVK>>5) Можно было бы создать экземпляр по имени


ГВ>1. Где создавать?


В любом потребителе класса.

ГВ>2. По имени типа или экземпляра?


По имени типа и набору значений параметров конструктора.

AVK>>6) Можно было бы визуально отредактировать его свойства.


ГВ>Не надо путать IDE и язык.


А я и не путаю. Просто без rtti это сделать вобще невозможно практически.

ГВ>Напиши-ка мне то же самое на дотнете, но без использования визуального редактора?


PropertyGrid имеешь ввиду? Без проблем на самом деле. Собственно самый примитивный вариант без отработки вложенных объектов такой:
public void EditObject(object o, Form editForm)
{
    foreach (PropertyInfo pi in o.GetType().GetProperties())
    {
        TextBox tx = new TextBox();
        tx.Text = TypeDescriptor.GetConverter(o.GetType()).ConvertToString();
        tx.Tag = pi;
        editForm.Controls.Add(tx);
    }
    
    if (editForm.ShowDialog == DialogResult.OK)
        foreach (Control ctrl in editForm.Controls)
        {
            TextBox tx = ctrl as TextBox;
            if (tx != null)
                ((PropertyInfo)tx.Tag).SetValue(o, TypeDescriptor.ConvertFromString(tx.Text));
        }
}


Жду аналог на С++.

ГВ>Условие неправомерно.


А помоему очень даже.

ГВ>Сначала разберёмся с предметом спора, а там посмотрим.


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

ГВ>>>Фраза на самом деле не "абсолютно односмысленная", поскольку содержала неопределённое понятие "в сущности".

AVK>>Опять ты пытаешься перевести спор на термины. В общем неубедительно.

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


Только все таки должны быть рамки этого, иначе разговор будет попросту невозможен. Я могу тебя назвать м@#$%ом, а потом сказать что я изъясняюсь на особом диалекте русского языка, на котором слово м@#$% означает уважаемый господин. Так и здесь. Я еще понимаю если бы исходная фраза была недостаточно ясной или многосмысленной. Но высказался ты вполне определенно и попытки твои теперь представить это в ином свете лично для меня абсолютно неубедительны.
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[45]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.07.03 06:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ниче не понимаю. Ну вот в плюсах же нет этой проблемы, так?


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

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

public interface ISomeObj
{
    int Y(int x);
    // Согласись - сказать меняет этот метод состояние объекта или нет заранее невозможно
}

...

private void SomeMethod(const ISomeObj someObj)
{
    int y = someObj.Y(25);
    // А вот теперь объясни мне - как компилятор может узнать - нарушает ли это выражение константный констрейн или нет?
}


AVK>>Почему не можешь? Вполне.

S>Хм. Во как. А метод не того, извините, класса, я вызвать могу?

Нет.

S>Там же вроде как проверяется, что объект позволяет вызывать этот метод.


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

S>Ну. Объявляю.

S>Вот есть у меня интерфейс
S>
S>interface ISome {
S>  int GetProperty() const;
S>    void SetProperty(int v);
S>}
S>

S>пусть теперь у кого-то будет метод

S>
S>void XXX::SomeMethod(const ISome some)
S>{
S>    some.GetProperty(); // ok
S>    some.SetProperty(5); // нельзя. 

Собственно почему нельзя? Как ты это определил? По наличию префикса Set в имени метода?

S>}
S>

S>В чем проблема-то?

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

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

S>Не вижу ничего прозрачного в необходимости делать так:
S>
S>class ISomeConstWrapper {
S>private
S>  ISome _wrapped;
S>public
S>  ISomeConstWrapper(ISome wrapped) {}
S>  int GetProperty() {return _wrapped.GetProperty();}
S>}
S>void XXX::SomeMethod(ISomeConstWrapper some)
S>{
S>...
S>}
S>

S>Потому, что код этих враппров будет до жути однообразным.

Они нужны только для чужих объектов. Свои ты можешь сделать заранее read only с возможностью менять параметры только в конструкторе. И уж это будет точно более красиво нежели const модификаторы, поскольку вместо сущности структурного программирования — константный параметр, вводит ОО сущность — константный класс. Согласись, в ОО-дизайне это выглядит несколько получше.

S>Кроме того, нет никакой гарантии того, что на самом деле метод GetProperty не нарушает своего обещания не трогать объект.


Гарантия тому ты сам.

S> В плюсах ха этим следит копилятор.


А здесь компилятор не может этого отследить в принципе, это можно сделать только в рантайме. Кстати есть еще такой модификатор readonly
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[39]: Будущее C#
От: Sergey Россия  
Дата: 10.07.03 07:22
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Это еще не клинический случай. Бывает куд страшнее. Хтя даже этот код на шарпе был бы короче и понятнее.


А как, кстати, подобный код на шарпе будет выглядеть? Скажем, вызов 2-х функций ( одна — с тремя, другая — с пятью параметрами) внутри некоторого обрамления. Способ, когда первая половина обертки — в конструкторе вспомогательного класса, а вторая — в деструкторе (финализаторе и т.д.), не катит.

VD>Скорее выигрыл. Так как без буста тут бы было еще строк 30-40 кода. Но вот в скорости компиляции проиграл сильно. Ведь если были бы делегаты, то все тоже самое стало бы проще и быстрее.


Делегаты умеют "привязывать" параметры на ходу? А переставлять аргументы местами? Или придется вспомогательные классы/функции писать?

S>>Макросы тоже бывают полезны. Но значительно реже, чем шаблоны.


VD>Шаблонами можно только универсальный код создавать. Это конечно очень часто удобнее.


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

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


Угу.

VD>>>Это не прямая, а обратная аналогия.


S>>Поясни.


VD>Что? Что такое обратная аналогия?


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

VD>http://www.i-u.ru/biblio/arhiv/books/chelpanov_ul/ec24.asp


В этой статье нет даже слова "обратная"

VD>Ну, и в ya.ru на слова "обратная аналогия" и демагогия.


Уж послал так послал

S>>А кто с этим спорит? __closure, или как она там называется, давно пора в язык.


VD>Ты тему внимательно читал? Тут именно с этим и спорят.


Цитату, плиз. Ничего такого я в этой ветке не заметил.

VD> А еще (и это самое противное) с этим спорят разные Страуструпы и другие хранители традиций из ANSI.


Страуструп — хранитель традиций? Не смеши. Он в основнем С++ и развивал, а пользователи его пинали, чтоб не слишком от С отходил

S>>При чем здесь частичная специализация? Для написания рекурсивных шаблонов обычно вполне хватает полной специализации. Хотя, конечно, часто код в отсутствии поддержки частичной специализации компилятором получается сложнее, чем с частичной специализацией. Но все равно — получается.


S>>А смысл в таком преобразовании? Алгоритм что, понятней от этого стал, что ли?


VD>А то нет? Или читать эзопов язык это щастье?


Нет, конечно. Рекурсия — вполне приемлемый (для меня, по крайней мере ) способ записи алгоритмов. Впрочем, не нравится рекурсия — можно попробовать использовать алгоритмы из boost::mpl, там вроде компил-тайм циклы есть.

S>>А некоторым жалко бошку с указателями работать Про них еще Дейкстра кажись писал.


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


Но уметь работать с ними — надо.

S>>Не, не зря. Там новый (ну не для всех, конечно, он новый) подход к шаблонным извращениям описан.


VD>Заметь, к извращениям. А я бы хотел получать просые и эффектинве решения без оных.


Извращения — это для тренировки мозгов. После которой простые и эффективные решения будут писаться куда проще и эффективней
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[46]: Будущее C#
От: m.a.g. Мальта http://dottedmag.net/
Дата: 10.07.03 07:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>private void SomeMethod(const ISomeObj someObj)

AVK>{
AVK> int y = someObj.Y(25);
AVK> // А вот теперь объясни мне — как компилятор может узнать — нарушает ли это выражение константный констрейн или нет?
AVK>}
AVK>[/c#]

Да очень просто: не сказано, что не меняет состояние объекта — значит меняет
... << RSDN@Home 1.1 beta 1 >>
Re[39]: Будущее C#
От: Sergey Россия  
Дата: 10.07.03 07:54
Оценка: -1
Здравствуйте, VladD2, Вы писали:

S>>А не нужен мне ни MC++, ни дотнет. А нужна только метаинформация в компил-тайме.


VD>Дык похоже, что это тперь будет только в дотнете и Яве. Так что выбор не велик. Да и не ясно в чем проблема то? С++ там тот же, только с метаданными.


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

S>>Кому как. Мне так и typeof нужен, и список членов класса, и граф наследования. А дальше уж я б на них шаблоны бы натравил.


VD>Оно все есть. Вот только шаблны в виду их статичности, ну, никак не прикрунишь. Скорее кодогенератор.


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

S>> Если б С++ была возможность получить хотя бы список членов класс и перебрать предков класса (в компил-тайме, само собой),


VD>Не батенька. В компайл тайме перебрать — это конечно концепция интересная, но пока никем не реализованная.


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

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


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

S>> сгенерить код сериализации класса на С++ не совтавляло бы почти никакого труда.


VD>Но генерить ты будешь его уже в рантайме или в отдельном тулзе.


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

VD>Хотя конечно при наличии полноценного TypeInfo сдалать такую утилиту было бы можно.


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

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


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


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

S>>Естественно, потому как С++ такой информации и не предоставляет.


VD>Ну?! О том и речь. Тот же МС++ дает полную информацию о себе. Т.е. сделать то можно.


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

VD>Вот только ортодоксы типа Страуструпа всю малину портят.


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

VD>>>А анализировать при компиляции особо нечего.


S>>Это как сказать.


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


Нет.

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


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

VD>Поверь, у всех.


Проверял на всех ?

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


Твоей практикой, заметь. Или еще чьей-то?

VD> Есть конечно некоторая доля задачь, которую проще далеть на плюсах, но она все время уменьшается.


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

S>>Есть живучесть, а есть надежность. Живучесть у шарпного кода может и выше, а вот с надежностью все не так однозначно.


VD>Очень даже однозначно. При проектировании еще Явы этот пункт ставили в приоритеты. А уж о дотнете и говорить не приходится.


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

S>>Мы, видимо, на его постинги с разных позиций смотрим.


VD>И тем неменее. Там есть четкий приговор метаданным.


Там есть четкий приговор метаданным в твоем понимании

VD>В общем, займись дотнетом и посмотрим на твои позиции чезе годик.


Противно Язык примитивный, рантам жирный, коммерчески применять (для нашей компании) рано...
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[42]: Будущее C#
От: WolfHound  
Дата: 10.07.03 08:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Поздравляю. Ты изобрел COM.

В шарпе надо обьявить класс публичным, у меня занести в карту экспорта. Работы практически одинаково.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: Будущее C#
От: WolfHound  
Дата: 10.07.03 08:17
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здесь немного поподробнее, плз. CreateObject<>() как я понял, реализован в exe-шнике. Далее он обращается к конкретному синглтону (например — C_MyCoolSingleton), который создаёт объект Sensor. Ну там понятно: карта, по которой отображается sensorName на конкретный синглтон и т.п.

Каждая длл содержит указатель на супер фабрику классов те обьект который содержит карту фабрик. Супер фабрика может возвращать только I_OBject. CreateObject реализован в длл вобще это просто удобный акцессор к супер фабрике со встроенным dynamic_cast

ГВ>Мне просто нужно понять структуру зависимостей модулей. Если вызов dynamic_cast<C_MyCoolSensor> есть в исходниках exe-шника, и других библиотеках, это одно, а если только в библиотеках сенсоров, то — другое.

Только в длл ехешник об обьектах ни чего не знает.

ГВ>Вот тут тоже немного не понятно: указатель на объект, содержащий фабрику классов передаётся в экспортируемую функцию? Логично было бы предположить, что указатель передаётся из неё...

Указатель на супер фабрику в длл, указатель на енумератор фабрик из длл. После чего фабрики из енумератора заносятся в карту супер фабрики.

ГВ>Ещё, ты говорил, что библиотеки содержат формы настройки. Формы просто в виде модальных диалогов или в виде чего-то типа PropertyPage? В смысле — они встраиваются в какой-то оборачивающий диалог или показываются независимо?

Да как угодно.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.03 11:41
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>А типа const неля послать к чертям?
В каком это смысле послать к чертям?
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[46]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.03 12:01
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А в плюсах внутрь метода не может попасть класс, неизвестный компилятору.

Может-можеет.
S>>Нельзя ни присвоить, ни привести константную ссылку неконстантной. Приведи пример того, что ты имеешь в виду.
AVK>
AVK>public interface ISomeObj
AVK>{
AVK>    int Y(int x);
AVK>    // Согласись - сказать меняет этот метод состояние объекта или нет заранее невозможно
AVK>}
Ну почему невозможно-то? Во-первых, отсутствие слова const - значит меняет. Если есть слово конст - ну все. Это означает, что внутри не должно быть вызовов методов, не помеченных const. А также присваиваний. Рекурсивное определение позволяет компилятору достаточно шустро определить, имееет ли место нарушение. Еще раз: почему-то плюсовый компилятор делает это. И не особо напрягаясь. Пока что я не услышал ни одного внятного аргумента в пользу того, почему этот интеллект может быть недоступен шарповому компилятору.
[c#]
private void SomeMethod(const ISomeObj someObj)
{
    int y = someObj.Y(25);
    // А вот теперь объясни мне - как компилятор может узнать - нарушает ли это выражение константный констрейн или нет?
    // Извини, ты не пометил Y словом const. На этом компилятор останавливается.
}


S>>Хм. Во как. А метод не того, извините, класса, я вызвать могу?

AVK>Нет.
AVK>Тем не менее приватные методы через рефлекшен зовуться. В любом случае — проверка происходит в рантайме.
Вот именно, Андрей, вот именно. Рефлекшн — это очень медленно по-любому. И доп. проверка несущественно ухудшит быстродействие и без того медленного кода.
S>>Ну. Объявляю.
S>>Вот есть у меня интерфейс
S>>
S>>interface ISome {
S>>  int GetProperty() const;
S>>    void SetProperty(int v);
S>>}
S>>

S>>пусть теперь у кого-то будет метод

S>>
S>>void XXX::SomeMethod(const ISome some)
S>>{
S>>    some.GetProperty(); // ok
S>>    some.SetProperty(5); // нельзя. 

AVK>Собственно почему нельзя? Как ты это определил? По наличию префикса Set в имени метода?
По отсутствию постфикса const! Ты бы сразу сказал, что не знаешь семантики const в плюсах. Я бы рассказал подробнее. 
S>>

S>>В чем проблема-то?

AVK>Да в том и проблема что подобные фокусы можно отловить только в рантайме, в отличие от плюсов.

Нет! Ведь не каждый же вызов метода приводит к верификации каста? Это означает, что очень много чего можно проверить статически. Есть очень ограниченное количество способов подменить сигнатуру метода. А точнее, ровно один — рефлекшн. Про него мы уже поговорили.

S>>Потому, что код этих враппров будет до жути однообразным.

AVK>Они нужны только для чужих объектов. Свои ты можешь сделать заранее read only с возможностью менять параметры только в конструкторе. И уж это будет точно более красиво нежели const модификаторы, поскольку вместо сущности структурного программирования — константный параметр, вводит ОО сущность — константный класс. Согласись, в ОО-дизайне это выглядит несколько получше.
Андрей, еще раз. Не все объекты можно сразу сделать readonly.
AVK>Гарантия тому ты сам.
Ну не смеши меня. А как насчет гарантии того, что метод не бросает исключений, кроме декларированных в сигнатуре? Тоже на программиста обязанность гарантировать возложим? Лишь бы компилер не устал... А хотя чего мелочиться — давай проверку типов параметров тоже возложим на программиста! Как это в сях было.

AVK>А здесь компилятор не может этого отследить в принципе, это можно сделать только в рантайме. Кстати есть еще такой модификатор readonly

Почему не может-то? У него все метаданные есть!
А можно чуть подробнее про модификатор?
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[43]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.07.03 12:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Поздравляю. Ты изобрел COM.

WH>В шарпе надо обьявить класс публичным, у меня занести в карту экспорта. Работы практически одинаково.

В метаданных храняться не только публичные данные, там храниться все
... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[47]: Будущее C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.07.03 12:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

AVK>>А в плюсах внутрь метода не может попасть класс, неизвестный компилятору.

S>Может-можеет.

Как? Через какой нибудь дайнамик кост?

S>Ну почему невозможно-то? Во-первых, отсутствие слова const — значит меняет.


А, так ты предлагаешь все методы, которые не меняют значение модификатором const размечать? Нафик нафик.

AVK>>Тем не менее приватные методы через рефлекшен зовуться. В любом случае — проверка происходит в рантайме.

S>Вот именно, Андрей, вот именно. Рефлекшн — это очень медленно по-любому. И доп. проверка несущественно ухудшит быстродействие и без того медленного кода.

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

AVK>>Они нужны только для чужих объектов. Свои ты можешь сделать заранее read only с возможностью менять параметры только в конструкторе. И уж это будет точно более красиво нежели const модификаторы, поскольку вместо сущности структурного программирования — константный параметр, вводит ОО сущность — константный класс. Согласись, в ОО-дизайне это выглядит несколько получше.

S>Андрей, еще раз. Не все объекты можно сразу сделать readonly.

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

AVK>>Гарантия тому ты сам.

S>Ну не смеши меня. А как насчет гарантии того, что метод не бросает исключений, кроме декларированных в сигнатуре? Тоже на программиста обязанность гарантировать возложим? Лишь бы компилер не устал... А хотя чего мелочиться — давай проверку типов параметров тоже возложим на программиста! Как это в сях было.

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

AVK>>А здесь компилятор не может этого отследить в принципе, это можно сделать только в рантайме. Кстати есть еще такой модификатор readonly

S>Почему не может-то? У него все метаданные есть!

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

S>А можно чуть подробнее про модификатор?


Можно конечно

When a field-declaration includes a readonly modifier, the fields introduced by the declaration are readonly fields. Direct assignments to readonly fields can only occur as part of that declaration or in an instance constructor or static constructor in the same class. (A readonly field can be assigned to multiple times in these contexts.) Specifically, direct assignments to a readonly field are permitted only in the following contexts:

In the variable-declarator that introduces the field (by including a variable-initializer in the declaration).
For an instance field, in the instance constructors of the class that contains the field declaration; for a static field, in the static constructor of the class that contains the field declaration. These are also the only contexts in which it is valid to pass a readonly field as an out or ref parameter.
Attempting to assign to a readonly field or pass it as an out or ref parameter in any other context is a compile-time error.

... << RSDN@Home 1.1 beta 1 >>
AVK Blog
Re[48]: Будущее C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.03 13:20
Оценка:
Здравствуйте, AndrewVK, Вы писали:
Почти убедил
... << RSDN@Home 1.1 alpha 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: Будущее C#
От: orangy Россия
Дата: 10.07.03 14:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

IT>>className можно в виде строки положить в базу или в любой конфигурационный файл по вкусу.

WH>У меня тоже причем этим уже давно пользуются. И это было заложено с самого начала.
Не подумайте про меня плохо, но такую фичу я делал еще ...ммм... где-то в 95ом году. Это не были стандартные средства С++, это был пост-процессор, принимавший на вход OBJ-файлы (COFF, делалось для djgpp) и выдававший некий DLM (dynamic link module). Там же был специальный run-time, который прикреплялся в ввиде stub к exe-шнику. Там была именно отложенная линковка, т.е. не GetProcAddress, а именно позднее связывание. В том числе там была фича под названием Named Classes. Использование выглядело примерно так:
int main()
{
 Base *pb,*pd;
 pb=new Base(10);        // Create an instance of Base. Nothing unusual.
 pb->f();                   // Base::f()

 pd=new("Derived") Base(4); // Create an instance of Derived.
                            // Actually Derived(4) will be called.

 pd->f();                   // Derived::f()
 delete pd;                 // Destructors are virtual so Derived::~Derived
 delete pb;                 // Base::~Base
};


Интересно, что скажут местные гуру? Было ли это компонентным программированием в зачатке или фигней полной?

Если кому интересно подробнее, вот есть какой-то древний хелп к DLM. Прошу пардону за кривой english и прочие ляпы — давно это было...
[RSDN@Home 1.1 beta 1] Сейчас 21:00, слушаю тишину
"Develop with pleasure!"
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.