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

IT>Запускаешь компилятор из под студии и хоть оботлаживайся.

Т.е. из-под студии запускается отладка компилятора, который компилирует твой код?

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

E>Т.е. из-под студии запускается отладка компилятора, который компилирует твой код?

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

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

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

E>>Да уж...
E>>И какое именно? Инкапсуляция? Полиморфизм? Не о наследовании же говорить?

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

E>>Тем не менее, ты мне не ответил.

O>Дизайнеры C++ не думали о том, что C++ будут использовать для метапрограммирования. Дизайнеры Nemerle постулировали это с самого начала.

O>Это, конечно, не отменяет возможности использования Nemerle для чего-то совершенно третьего, о чём ни мы ни разработчики Nemerle не догадываются (чего они не планируют, точнее). И вот это-то и приведёт к проблеме использования неподходящих средств (средств, которые предполагалось использовать иначе) для решения проблемы. Но разговор сейчас о метапрограммировании, я так понимаю

E>>Вообще Nemerle славословят, но не используют. Я припоминаю только одного участника обсуждений, который использовал Nemerle вместо Delphi.

O>Дык он же только-только становится известным. Потерпи чуток


Ну известным я врядли стану... (если это всетаки я имелся в виду)

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

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

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

Короче, шло обсуждение как сделать на таком-то языке одно, на таком-то другое, здесь лучше подходит третье...
Зашел разговор про Форт...
Сколько было слов про его синтаксис, про его низкоуровневость... про его привязку к стеку и т.д.
про отсутствие IDE тоже говорили...
Ну с IDE в конце концов разобрались — Были IDE для форта — например ПараФорт...
Шла жаркая дисскуссия, было написано немерянное количество слов и буковок...
И вот один из пользователей ПараФорта написал:
=> Мне в ПараФорте нехватает:
=> 1...
=> 2...
порядка 10 пунктов написал...
а в конце добавил...
=> А вообще я тихо счастлив...

Так вот и я с Nemerle? ну пусть не счастлив — но тихо доволен...

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

M>
M>Ну известным я врядли стану... (если это всетаки я имелся в виду)

Я о Nemerle говорил Но если о тебе — почему нет?

M>да и программки которые я пишу в основном использую только я, да еще пяток людей — не больше...

Всё равно — ты его реально используешь. Это уже больше, чем мои текущие отношения с Nemerle, например.

M>Так вот и я с Nemerle? ну пусть не счастлив — но тихо доволен...



От себя добавлю, что реального кода, к сожалению, я на нём не пишу. Зато когда пишу примеры — душа радуется

Oyster wrote:
> C>Сам подумай, в Python'е и Ruby можно к объекту динамически подключать и
> C>удалять методы. Как ты себе это представляешь в CLR без интерпретатора?
> Эти методы просто не будет видно другим языкам (или будет какое-нить
> хранилице делегатов у каждого объекта). Ну а остальные будет видно.
А как хранилище передавать параллельно с объектом? Хранить глобальный
hash_map из weak-ссылок — не катит.

И что там с мультиметодами, например?

В общем, пока не будет стандартного формата динамических объектов — то
.NET не сильно ушел дальше обычного С в плане интероперабельности.

>> > Кстати, он у тебя стоит (судя по словам "судя по скорости работы
>> > точно")? Можно попробовать скомпилить какую-нить сборку, а потом
>> > посмотреть Reflector-ом.
> C>Проще сделать RTFS.
> Стандарт на Python.NET? Или Ruby.NET?
Исходники реализаций

Oyster wrote:
> C>В .NET CLR _НЕТ_ стандарта на динамические объекты. Ну создам я пару
> C>динамических методов, но как их передать другому несвязаному коду?
> Инстанс делегата отдашь.
Как мне передать цельный объект?

Создавать делегаты для интеропа очень напоминает создание 'extern "C"'
функций по удобству использования и разработки.

> C>И я уж не говорю, что семантика объектов в .NET всего лишь немного
> C>беднее языка Эллы-людоедочки. И различные нетривиальные фичи типа
> C>мультиметодов и динамического вызова отображаются на него только с
> C>большими приседаниями.
> Мультиметоды — reflection и атрибуты тебе помогут, если надо красиво.
Чем? Мультиметод относится к нескольким классам — чего рефлектить?

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

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

C>Как мне передать цельный объект?

Если ты его передал динамически, то, естественно, никак. Правда, можно в рантайме сгенерить код и передать ссылку типа object, а дальше reflection и вперёд. Я говорил о том, что даже те же компиляторы Питона под .NET всё-таки компиляторы — они умеют генерировать полноценный IL.

C>Чем? Мультиметод относится к нескольким классам

Ну и что?

C>- чего рефлектить?

Reflection будет использоваться в реализации, неявно. Тебе написать какой-нить мультиметод на C#?

C>Можно эмулировать мультиметоды (типа создавать классы
C>String_Int_Methods), но нет никакого стандарта на это. И шансы что два
C>языка будут использовать один и тот же метод кодирования — близки к нулю.

А.. ты всё про interop. Ясно, что как только начинают юзаться language-specific фичи, все идут в сад — об этом уже говорилось.

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

C>А как хранилище передавать параллельно с объектом? Хранить глобальный
C>hash_map из weak-ссылок — не катит.

Да базовый класс соорудить и юзать вместо object.

C>И что там с мультиметодами, например?

От прицепился ты к этим мультиметодам Видно, часто их используешь

А если серьёзно, то не буду повторяться про language-specific фичи, которые не входят в CLS, и о том, куда они идут при интеропе.

C>В общем, пока не будет стандартного формата динамических объектов — то
C>.NET не сильно ушел дальше обычного С в плане интероперабельности.

Т.е. пока такое не будет включено в CLS? Потому что только включение в CLS гарантирует, что все CLS consumers смогут такой код использовать.

>> C>Проще сделать RTFS.
>> Стандарт на Python.NET? Или Ruby.NET?
C>Исходники реализаций

А... Source, а не Standard... Так бы и сказал. И всё равно натурный эксперимент поставить быстрее.

Oyster wrote:
> C>А как хранилище передавать параллельно с объектом? Хранить глобальный
> C>hash_map из weak-ссылок — не катит.
> Да базовый класс соорудить и юзать вместо object.
В пределах всех языков?

> C>И что там с мультиметодами, например?
> От прицепился ты к этим мультиметодам Видно, часто их используешь
Ага. Причем на С++.

> А если серьёзно, то не буду повторяться про language-specific фичи,
> которые не входят в CLS, и о том, куда они идут при интеропе.
Проблема в том, что в CLS почти ничего и не входит. Только самая базовая
функциональность, которой соответствуют C#/VB.NET.

Unsafe не учитываем — тут CLR не лучше обычного машинного кода.

> C>В общем, пока не будет стандартного формата динамических объектов — то
> C>.NET не сильно ушел дальше обычного С в плане интероперабельности.
> Т.е. пока такое не будет включено в CLS? Потому что только включение в
> CLS гарантирует, что все CLS consumers смогут такой код использовать.
Да. Как вариант — нужен стандарт на эмуляцию нужных фич.

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

>> Да базовый класс соорудить и юзать вместо object.
C>В пределах всех языков?

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

>> От прицепился ты к этим мультиметодам Видно, часто их используешь
C>Ага. Причем на С++.

Тю. Так и на C# их юзать проще простого. Мы-то вроде говорим об интеропе с языками, где мультиметоды first-class citizens.

C>Проблема в том, что в CLS почти ничего и не входит. Только самая базовая
C>функциональность, которой соответствуют C#/VB.NET.

Ну да.

C>Unsafe не учитываем — тут CLR не лучше обычного машинного кода.

Да.

>> C>В общем, пока не будет стандартного формата динамических объектов — то
>> C>.NET не сильно ушел дальше обычного С в плане интероперабельности.
>> Т.е. пока такое не будет включено в CLS? Потому что только включение в
>> CLS гарантирует, что все CLS consumers смогут такой код использовать.
C>Да. Как вариант — нужен стандарт на эмуляцию нужных фич.

Стандарт распухнет — это раз. Никому на самом деле это не нужно — это два

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

>> От прицепился ты к этим мультиметодам Видно, часто их используешь
C>Ага. Причем на С++.

из сишного клиентского кода, вероятно?

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

E>>Т.е. из-под студии запускается отладка компилятора, который компилирует твой код?

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

Ну, например. Есть у меня кусок моего кода:

...
Oyster.Macro.Fact(12)
...

и у меня закрадываются подозрения, что именно в этом моем коде Fact(12) дает неправильный результа. Могу ли я установить в студии точку прерывания на эту строку и войти в отладку вызова Fact(12) из моего кода при компиляции моего кода?

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

E>Могу ли я установить в студии точку прерывания на эту строку и войти в отладку вызова Fact(12) из моего кода при компиляции моего кода?

Ну да.

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

E>>Могу ли я установить в студии точку прерывания на эту строку и войти в отладку вызова Fact(12) из моего кода при компиляции моего кода?

O>Ну да.

Если это правда, то круто!
Вот только не могу понять, как же это делается...

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

E>Вот только не могу понять, как же это делается...

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

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

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

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

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

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

O>Почему нет? Ты знаешь что-то, чего не знаю я?

Ага
Предлагаю попробовать.

В С++ каждая операция м/у этими типизированными величинами описывается только 1 раз. В дотнет необходимо будет описать всевозможные сочетания величин для каждой операции. Это очень большое число. Т.е., даже если автоматизировать эту задачу, и сгенерить автоматом все перестановкой, то ее решение потеряет смысл.

O>Потому что мне кажется, что смогу.

Попробуй.

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

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

Погоди, ты это сам реально проделывал?

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

Или же я чего-то не помнимаю? Можно на пальцах объяснить?

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

V>В С++ каждая операция м/у этими типизированными величинами описывается только 1 раз. В дотнет необходимо будет описать всевозможные сочетания величин для каждой операции.

Зачем? Не забывай, что у нас есть макросы. Например, такой макрос можно писать:

macro plus(x1, x2)
{
    <[ $x1 + $x2 ]>
}

И он будет работать. Не сможет скомпилить — ругнётся (причём разумно ругнётся). Сможет — прохавает.

O>>Потому что мне кажется, что смогу.

V>Попробуй.

Попробую

Дарней wrote:
>> > От прицепился ты к этим мультиметодам Видно, часто их используешь
> C>Ага. Причем на С++.
> из сишного клиентского кода, вероятно?
Хуже. Из VBAшного.