Дарней wrote:
> C>Классы — элементарно заменяются COM-интерфейсами. Массивы, строки —
> C>SAFEARRAY, BSTR. Исключения — HRESULT+IErrorInfo.
> плавали, знаем, что это за трах. Рядом с CLI даже и близко не валялось.
COM со встроеной языковой поддержкой (Delphi, VB, VBA) чрезвычайно
удобен для использования. Вы вот попробуйте C# через PInvoke
использовать из кода на С.

> Вот и превратилась вся твоя крутейшая C++ интероперабельность в один
> сплошной COM.
Так я вроде ничего другого и не утверждал. Обидно то, что CLI недалеко
от всего этого ушел.

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

VD>Оппонент:
VD>- В С++ вообще нет средств отладки.
VD>- Ага. А единственное средство отладки макросов Немерла — это печать в косоль!...
VD>- Позвольте, макрос тот же код и его можно отлаживать просто отладчиком.
VD>- А как же начать отладку?
VD>- Поставить точку останова в макросе или влепить в код ассерт.
VD>- (даже не пробуя) Это не удобно!!! Убого!!!...
VD>- Да все ОК.

Ага, за не именеем лучшего сойдет и то, что есть.

VD>- Неужели IDE не может упростить отладку?
VD>- Может. Но ее нет.
VD>- А вот Смолтоке.

А вот на Смолтолк не мешало бы посмотреть. Чтобы знать, к чему стремиться.

VD>В общем, поиск фатальных недостатков.

Вот именно. Достоинств в Nemerle и без меня нашли бесчетное множество.

VD>Вывод просто потрясающий. Немерле это хреново, так как нет супер-кул-фич вроде точек останова времени компиляции.

Покажи, где я озвучивал такой вывод.

VD>Так что будем пока что использовать С++ в котром вообще невозможна отладка метакода и Руби для которого вообще отладчика нет.

Откуда дровишки про отсутствие отладчика в Ruby?

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

C>Вы вот попробуйте C# через PInvoke использовать из кода на С.

месье тонкий извращенец

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

WH>Ты можешь не верить но когда я пишу на C# все примерно так и происходит. Я могу несколько дней долбить код без компиляции. После компиляции (как правило все компилируется сразу ибо ReSharper рулит) и устранении пары исключений (причем на C#2 и этого скорей всего не понадобится ибо генерики) все действительно работает как надо.

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

WH>Чего не скажешь про С++ в котором наведенку можно ловить произвольное колличество времени.

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

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

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

WH>Тебе уже раз 10 сказали что это один из способов причем не самый удобный.

Я понял это с первого раза. Сказали, однако, не сразу. А потом стали повторять как попугаии.

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

Собственно я о том, что при работе со сторонней библиотекой макросов у тебя может не быть ее исходных кодов. А всего два варианта библиотеки -- release (без отладочной информации) и debug (с отладочной информацией). Хотя входить отладчиком в чужой код... Тот еще геморой, я согласен.

Дарней wrote:
> C>Вы вот попробуйте C# через PInvoke использовать из кода на С.
> месье тонкий извращенец
Есть другие предложения?

И помните, CLR — это _кроссплатформенная_ технология.

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

E>А вот я применительно к отладке макросов во время компиляции другого не понимаю. Почему этого нельзя сделать путем установки точки прерывания в IDE на месте обращения к макросу в моем коде?

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

Почему это до сих пор не сделано — вопрос к MS. Им это как раз нужно больше всего. Видимо на то есть какие-то технические причины.

Oyster wrote:
> Ну и интерфейс у метода можно сделать такой же, как тот, что видит VBA,
> естественно (а что ещё нужно вызывающей стороне?...):
Ничего, в общем-то.

> void Process(object obj1, object obj2, [собственно параметры метода])
> {
> //...
> }
Чуть по-другому:

void Process(object obj1, object obj2, VARIANT par1)
{
     //...
}
void Process(object obj1, object obj2, VARIANT par1, VARIANT par2)
{
     //...
}
...

В С++ это делаю с помощью BOOST_PP

> Дальше в реализации на .NET есть как минимум три варианта:
Точно так же, как и в реализации С++.

> 2. Декларативное описание реализации для данных двух типов. Тут
> атрибуты и reflection, так что всё в рантайме. Зато никакого
> хардкодинга и максималоно упрощено добавление новой реализации.
Аналогично для С++, только в compile-time на шаблонах. Можно и в runtime
через IDispatch.

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

WH>Ты можешь не верить но когда я пишу на C# все примерно так и происходит. Я могу несколько дней долбить код без компиляции. После компиляции (как правило все компилируется сразу ибо ReSharper рулит) и устранении пары исключений (причем на C#2 и этого скорей всего не понадобится ибо генерики) все действительно работает как надо.

Я запускаю компиляцию после каждого небольшого написанного или исправленного блока кода. Иногда по нескольку раз в минуту. Фактически, кнопка F7 у меня служит заменой Ctrl+Shift+S

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

C>Есть другие предложения?

не использовать C# из С

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

K>Обычные средства ООП, без метапрограммирования, написания собственных DSL и т.п.
K>Простые и хорошо обкатанные вещи не требуют танцев с бубном, и позволяют писать достаточно быстро и эфективно. т.к. все ходы и сайд эффекты хорошо изучены.

Структурное программирование ещё проще. Вот только насчёт простоты и эффективности Метапрограммирование — это возможность повторно использовать целые паттерны. Обрати внимание здесь на класс PersonAccessor. Для прикладного программиста куда уж проще, вообще никакого кода писать не надо. Для писателей макросов надо, но это того стоит.

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

K>А если в цикле в этот же контейнер элементы добавляются/удаляются?

Тогда используй for. Вот только таких случаев существенно меньше, чем простой перебор. Соотношение примерно как в C было между необходимостью использвовать while и do while.

Дарней wrote:
> C>Есть другие предложения?
> не использовать C# из С
Как можно, ведь CLI на световые годы лучше COMа (который с С
замечательно работает, причем элементарно переносится на другие платформы).

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

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

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

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

E>Ну-ну. Работает и пусть работает. Ты мне еще расскажи, что статическая типизация на 99% устраняет необходимость тестирования приложений. Что после успешной компиляции нужно проверить всего две вещи -- что программа успешно стартует и столь же успешно завершается. Если эти условия выполняются, значит все работает корректно.

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

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

E>Увольте, батенька. Рассказывай эти сказки начинающим программистам, которые кроме окошек в WinForms ничего не программируют.

Кто-там у нас постоянно рассуждал как другие неумеют воспринимать чужое мнение?

VD>>Обясняю последний раз и закроем тему.

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

Ты прочти тсвои сообщения вверх по ветке. Потом поговорим о степени твоего понимания.

E>Я просто хотел понять, что делать в случае, когда я вижу, что некий макрос, производящий compile-time вычисления подставляет мне в код явно не правильную константу. Причем делает это он не всегда, а один раз в некотором месте исходного кода.

Слушай, ты задолбал. Поставь себе Немерле и повозить с ним пару дней. Вопросы уйдут сами собой. Или будут хотя бы более осмысленны.

Путей отладить этот макрос масса:
1. Поставь точку останова на этом месте в объектном коде и погляди какие параметры передаются в макрос, а потом сэмулируй тоже поведение в тесте.
2. Создать еще один отладочный макрос который будет взводить некий флаг:

macro BreakMyCacro()
{
    Debug._dbgFlag = true;
}

module Debug
{
  intrnal bool _dbgFlag;
}

Далее в макросе написать нечто вроде:

macro MyCacro()
{
    if (Debug._dbgFlag)
    {
        _dbgFlag = false;
    }
    ...

и поставить точку останова внутрь if-а. Далее остается вписать вызов BreakMyCacro() в нужном месте объектного кода.
3. Воспользоваться макросом выводящим окончательный код пораждаемый макросом и разобраться что в нем не так.
4. Декомпилировать получаемую сборку с помощью Рефлектора и полядеть на получаемый код.

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

Да? Тогда к чему столь бесмысленные вопросы? Крышу рвет от метауровенй, что ли? Это бывает.

E>Я не понимал, как войти в отладку кода макроса, когда этот код работает в отдельном параллельном процессе ncc.

Отдельном от чего? От только в нем и работает.

E> Оказалось, что провоцируется отладка процесса компилятора путем подстановки в код макроса специальных провоцирующих отладку инструкций (вроде Assert(false)).

Тебе уже не один человек сказал, что это один из способв. Можно просто поставить точку останова в нужном месте макроса.

Это уже чистейшая клиника. Я устал повторять одно и тоже. Макрос выполняется при компиляции. Точка! Нет никаких параллельных процессов. Процесс один ncc.exe. Порождаемая (объектаная) программа в этот момент еще скопилирована и говорить ней бессмысленно.

E> После этого стало понятно. Напомнило, как некоторые товарищи в C/C++ код вставляли asm { int 3h; } (вроде так).

Нда, маразм крепчал (с). Какие на фиг "asm { int 3h; }"? Где их ставить? В метакоде? Ну, ды в нем можно и просто точку останова поставить. А asm { int 3h; } в прикладном коде будет просто набором AST-веток, то есть данных. Остановиться на этих данных невозможно.

Попробуй поставить asm { int 3h; } где-нибудь внутри макроса С++ или в метакоде на основе шаблонов. Будет смешно.

E>Только для этого способа, как я понимаю, нужно иметь компилируемый исходный код макроса чтобы вставить в него Assert(false) и перекомпилироваться.

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

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

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

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

VD>>1. Место не должно влиять на результат, если макрос написан грамотно. Надо стараться делать так, чтобы разные обращения к макросам с одинаковыми параметрами приодили к одинаковому результату. Побочные эффекты иногда конечно полезны, но нужно четко осознавать их опасность. Это ничем не отличается от создания прикладного кода.

E>Прописная истина. Если бы программы писались так просто, необходимости в отладке вообще бы не было.

Не скажи. Ошибки бывют логическими или от недопонимания чужого АПИ. У меня почему-то именно такие и встречаются.

ЗЫ

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

Дарней wrote:
> C>Как можно, ведь CLI на световые годы лучше COMа (который с С
> C>замечательно работает, причем элементарно переносится на другие
> платформы).
> он лучше для тех задач, для которых предназначался. Нативный саппорт
> допотопных языков в число этих задач не входит
Вот в Java, например, есть вполне так адекватный JNI.

VladD2 wrote:
> Нда, маразм крепчал (с). Какие на фиг "asm { int 3h; }"? Где их ставить?
> В метакоде? Ну, ды в нем можно и просто точку останова поставить. А asm
> { int 3h; } в прикладном коде будет просто набором AST-веток, то есть
Ну давайте объяснять медленно.

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

Однако, в Boost'е есть утилита, которая позволяет интерактивно с консоли
выполнять макросы (в том числе и по шагам) и смотреть за результатом их
работы. Чем не отладчик?

Представим тоже самое для Nemerle — мы пишем код, вставляем макрос и
нажимаем кнопку "отладка". Тут же мы видим во что этот макрос
развертывается, можем по шагам проследить Nemerle'вский код и т.п.

Все это давно уже есть в Smalltalk'е, как уже говорилось много раз. И
метапрограммирование в Smalltalk'е тоже есть, кстати.

VladD2 wrote:
> Так проблема в том, что сам язык не очень подходит для вывода типов.
> Отсюда и трудности. Проще сразу ввести в язык нужные ограничения. Тогда
> вывод типов из шаманста становится четким алгоритмом.
Просто вывод типов нужно делать постоянно.

> Изменение типов во время работы тоже приводит к проблемам. Ну, добавить
> метод еще моно, а удалить или изменить что-то в классе — это уже приплызд.
А вот почитатели динамических языков так не считают. И примеры
Ruby'шного кода, которые приводит eao197 показывают, что это вполне полезно.

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

C>Вот в Java, например, есть вполне так адекватный JNI.

а его адекватность заключается в чем?

Дарней wrote:
> C>Вот в Java, например, есть вполне так адекватный JNI.
> а его адекватность заключается в чем?
Нормальный интерфейс к Java-коду. В том числе есть быстрый доступ к
массивам, поддержка нативных буфферов (распределяем буффер в нативном
коде и используем из Java) и т.п.

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

VD>Я не говорю, что не нужна отладка. Я говорю, что юнит-тесты становятся не так актуальны и можно обойтись банальным тестированием изменяемой/добавляемой вещи.

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

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

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

E>>Увольте, батенька. Рассказывай эти сказки начинающим программистам, которые кроме окошек в WinForms ничего не программируют.

VD>Кто-там у нас постоянно рассуждал как другие неумеют воспринимать чужое мнение?

Я. О тебе. И постоянно в этом убеждаюсь.

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

VD>Да? Тогда к чему столь бесмысленные вопросы?

Да к тому, что про способ установить в теле макроса Assert(false), который прервет работу ncc и выдаст макрос в отладчик, я элементарно не знал. Первым про этот способ мне сказал Oyster. А ты с IT затем его вставляешь в каждое сообщение. Хотя я давно уже про него узнал.

VD>Крышу рвет от метауровенй, что ли? Это бывает.



E>>Я не понимал, как войти в отладку кода макроса, когда этот код работает в отдельном параллельном процессе ncc.

VD>Отдельном от чего? От только в нем и работает.

Процесс ncc работает отдельно от процесса Visual Studio и отдельно от процесса, в который превратиться моя программа при отладке после компиляции.

E>> После этого стало понятно. Напомнило, как некоторые товарищи в C/C++ код вставляли asm { int 3h; } (вроде так).

VD>Нда, маразм крепчал (с). Какие на фиг "asm { int 3h; }"? Где их ставить?

Прочти внимательно выделенное. В свое время это был популярный способ заставить C++ программу в каком-то месте под нагрузкой вывалиться в отладку. Вставка Assert(false) напомнила мне этот способ. Только и всего. Никуда я не предлагал его вставлять. Это еще раз к восприятию чужого мнения.