Oyster wrote: >> > Да базовый класс соорудить и юзать вместо object. > C>В пределах всех языков? > Нет, конечно. С каждым языком интеропить по своему — я только об этом > говорю.
Вот с этим и проблемы. .NET претендует на универсальную платформу, а
полноценный интероп обеспечивает только в своих языках.
> C>Да. Как вариант — нужен стандарт на эмуляцию нужных фич. > Стандарт распухнет — это раз. Никому на самом деле это не нужно — это два
Стандарт может быть совершенно отдельным. Но он все равно нужен.
Дарней wrote: > C>В реакторе происходит двойная (или тройная) диспетчеризация. Писать > C>таблицы уже достало. > а что есть реактор по своей сути? Уж не ком-объект ли?
Да.
В нем по CLSID объектов происходит диспетчеризация.
Здравствуйте, Cyberax, Вы писали:
C>Вот с этим и проблемы. .NET претендует на универсальную платформу, а C>полноценный интероп обеспечивает только в своих языках.
Есть CLS. Хочешь стать "своим" — соответствуй CLS.
C>Стандарт может быть совершенно отдельным. Но он все равно нужен.
Дык и начинай активные действия в этом направлении
Здравствуйте, VladD2, Вы писали:
L>>Он немножко другое имел в виду: может ли он поставить брейкпоинт не в теле макроса, а на строчке в исходном коде, где он вызывается.
VD>Тогда он полностью не умеет формулировать мысли.
Или внимательнее читать нужно. А не выдавать собственные мысли за чужие слова.
VD>Да и это вообще не вопрос. Это же просто код программы. Макрос в нем выглядит как функция или атрибут. На макросе в коде поставить точку останова нет проблем. А на атрибуте конечно нельзя, так как конструкция деларативная. Но и отлаживать там нечего. Отлаживать нужно код макроса.
Ага, конечно. У тебя, наверное, никогда наведенных ошибок не было. Когда код проходит все unit-тесты, но в одном из двадцати реальных прогонов почему-то ломается.
А вставлять в код макроса Assert(false) -- это вариант. Про него я не знал. Только вот насколько он удобен, если макрос раз 50-100 вызывается за время компиляции.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Значит, нужно стартовать его под отладкой отдельно. Если так, то как узнать, в какой момент времени компилятор начнет вызывать не просто макрос Fact, а максрос Fact из нужного мне места программы, которая еще не скомпилировалась?
А зачем ждать когда тебя вызовут из нужного места? Если ты отлаживашь конктретную проблему, то проще сэмулировать ее на коротком примере.
Если же проблема не ясна, то прийдется трассировать выполнение программы или ориентироваться на параметры.
ЗЫ
Вообще, явно видно, что ты не понимашь сути макросов. От того и непонимание. Макрос — это не функция вызываемая из кода. Макрос — это метапрограмма меняющуая или генерирующая код. Код объектной прогрммы (т.е. программы где макрос применяется) для макроса не более чем входные данные.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>Интересно на сколько таких отладочных сессий хватит терпения (у рядового программера) прежде чем макросы пойдут фтопку?
Нескажу за рядовых, но если человек хоть раз отлаживал DLL-сборку или просто Win-DLL, то проблем не возникает вообще.
Зато отладка макроса может очень многое сказать о самой подсистеме макросов.
K> В свое время имено из-за гемора с отладкой я перестал юзать циклы с итераторами и вещи типа for_each и перешел на классический for(int i = 0;...).
А я пересат использовать С++. Помогает значительно лучше. При этом проблем с foreach-ем и т.п. нет в принципе.
K> Писанины не намного больше,
Писанины намного больше. Да и for не эквиалентен foreach-у. Попробуй, анпример, через for перебрать элементы хэш-таблицы или связанного списка. А через foreach легко.
K> зато хорошо видно на каких i,j,k произошел превед, и ситуацию легко снова повторить в дебаггере.
А зачем видить внутреннюю реализацию паттерна? Мне достаточно видеть то, что код перебирает элементы коллекции. Остальное не важно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, FR, Вы писали:
FR>>В общем да, но с другой стороны фаза компиляции (в байт код) тоже присутствует.
O>Ну так, значит, IronPython не явзяется просто интерпретатором, раз он генерит CIL-код?...
Лично я не могу судить о IronPython. Если он генерирует именно MSIL, то несомненно он компилятор. Если же генерируется ней свой байткод который потом интерпретируется, а что-то еще, и это что-то потом интерпретируется, то это интерпретатор.
Вообще-то отделение компилятора от интерпетатора может быть очень непрстым. Часть кода может выполняться непосредственн, а часть интерпретироваться. Или может порождаться код который будет зниматься неким рантайм-анализом и по сути мало чем отличаться от интерпретации. Напирмер, VB6 имел компилятор, но при работе с вариантами тот вместо полноценного машинного влеплял некие процедуры интерпретирующие значения варинтов. Это конечно все завязано на реализацию варинтов, но все же характиристики кода скорее уже получались как у интерпретатора.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>В .NET CLR _НЕТ_ стандарта на динамические объекты.
Чё?
C> Ну создам я пару C>динамических методов, но как их передать другому несвязаному коду?
Очевидно другой од тоже должен быть динамическим, работать через заранее известный интерфейс или вызвать порождаемый код через рефлексию.
C>И я уж не говорю, что семантика объектов в .NET всего лишь немного C>беднее языка Эллы-людоедочки.
С Эллочкой сранвивать не буду. Но где-то в ЯП есть лучше?
C> И различные нетривиальные фичи типа C>мультиметодов и динамического вызова отображаются на него только с C>большими приседаниями.
С динамическими вызовами никаких проблем нет. Что касается мултиметодов, то это фича языка, а не рантайма. Деспечиризация — это, ведь, алогоритм.
Забавно, что вызов метода через рефлекшон как раз имеет поведение как у мультиметода, так как производится диспечерезация по нескольким аргументам.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
VD>>Данный вопрос ни к ФП, ни к Александреску отношения не имеет. Это именно что прямое использование возможности параметризовать тип константами и получить эффект от того, что компилятор генерирует уникальные типы для разных значений констант.
FR>Прямого отношения не имеет, но замечал тот кто любит ковырятся в шаблонах намного легче осваивает функциональщину (принимает не всегда, но во всяком случае понимает быстро, а то я тут уже и с клиническими случаями встречался )
Это уже к делу не относится. Эдак можно и про шахматистов сказать, например.
VD>>Примеры из буста, раз уж в прикладном коде подобное встретить невозможно.
FR>Так мое мнение: такой код и не должен быть прикладным, он должен лежать в библиотеках.
Я просил пример. Просто интересно для чего кроме надуманного примера (приведенного выше по теме) и метапрограммирования можно использовать параметризацию константами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>На самом деле, это были исходники этой химии, но их понимать необязательно. Суть в том, что создаются типизированные аналоги простым типам, т.е. типизированные синонимы int, float, double и т.д., соответственно синтаксис использовани аналогичен использованию этих встроенных типов. В прикладном коде будет не за что бить линейкой...
А какова цель этого?
Пойми, ведь если есть цель, то очень вероятно, что ее можно достигнуть разными средствами.
Например, если мы ведем речь о операциях над некими физическими величинами, то можно описать эту величину как просую структуру содержащую нужну информацию, а в макросах контролировать правильность операций и если он прошел удачно заменять структуры на простые типы.
В общем, приведи осмысленный пример применения данного изврата и можно будет подумать как добиться того же эффекта.
VD>>Например, в Немерле можно делать операторы макросами. При этом во время компиляции доступны любые проверки типов. То есть мы можем контролировать любые аспекты поведения оператора явно, используя те же возможности языка, что и в прикладных программах. По-моему, это намного более простой, понятный и гибкий подход.
V>Нет, на Немерле ты не сможешь спроектировать подобную систему для произвольной получаемой размерности и их произвольных комбинаций.
Что же мне помешает?
V>Она решается очень чудесно на С++, в том плане, что оба, как пользовательский код, так и итоговый бинарник аналогичен использованию встроенных типов. А вся "химия" работает только в compile-time.
Ну, и в Немерле это можно сделать. Вот только соменваюсь, что это будет просто. Ведь на С++ это просто только потому, что все что нужно уже встроено в язык/компилятор.
V>Более упрощенные варианты используют практически ВСЕ (без комбинаторики, просто различные заменители целевым типам, очень часто такие типы называют с приставкой tagged_).
Хм. А не лучше (а главное логичнее) было бы ввести в язык алиасы (что-то вроде typedef, но порождающий новый тип)?
V>Т.е. выделение домена — это как бы естественно при проектировании прикладного кода.
Ага. Не естественнен способ которым это делается.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Oyster, Вы писали:
O>Не скажи. Для меня эта задача имеет интерес, но чисто спортивный.
Пенесометрия и есть спорт. Но я уж лчше пойду в спортзал.
O> Повод потренироваться и показать другим, что может делать Nemerle. Осталось только найти немного времени...
Хм. Потренироваться — это дело. Но ведь можно тренироваться на куда более полезных кошках! Например, мне хочется доработать напильником макрос $ (тот, что используется в строке $" ... $(...) "), так чтобы он делал отсупы и форматировние. Ну, так чтобы использовать его вместо SreingTemplate.
O>Ну а с точки зрения последующего использования... да, private members measuring в чистом виде.
Не понял.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
