Здравствуйте, vdimas, Вы писали:
V>Да. Особенно в прикладном коде. Особенно там, где сложность формул преттендует на write-only... хоть какая-то проверка на "здравый смысл".
Ну, привел бы пример из своего кода. И статистику сколько их таких.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Так и то другое все-таки вычисления во время компиляции(что и просил Влад).
Такие вычисления может делать почти любой компилятор почти любого языка.
Речь же шла о вычислениях во время компиляции. Вычислениях которые могут дать нечто более полезное для программиста нежели просто сложение двух констант.
И тот кто отвечал прекрасно знает ответ на данный вопрос. А данная шутка юмора родилась только потму, что ему очень нехочется честно озвучить этот ответ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Вот мне интересно эти трудозатраты будут сопоставимы с затратами на C++?
Это сопоставление неализованной возможности и ее реализации универсальными средствами. Подобное сравнение имеет такой же смысл, как сравение вызова функции и ее реализации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Или внимательнее читать нужно. А не выдавать собственные мысли за чужие слова.
Куда уж внимательнее. Просто с твоего восприятия офигеть можно. Ты уж извини.
Лучше бы чем разводить пустые споры и распросы взял бы и попробовал сам.
Только будь окуратен. Видишь, многие попробовавшие и оценившие подсаживаются на иглу.
E>Ага, конечно. У тебя, наверное, никогда наведенных ошибок не было.
Бывали. В основном когда писал на С/С++ и скриптах разных. На Шарпе что-то наведенки крайне мало, и она легко отлавливается. С Немерлом пока тоже вроде все понятно в отладке.
E> Когда код проходит все unit-тесты, но в одном из двадцати реальных прогонов почему-то ломается.
Я на скриптах не пишу. Так что техники безопасного секса не так актуальны. Нет у меня обычно юнит-тестов... Обычно все и так неплохо работает.
E>А вставлять в код макроса Assert(false) -- это вариант. Про него я не знал. Только вот насколько он удобен, если макрос раз 50-100 вызывается за время компиляции.
Теперь ты эту фразу будешь повторять 10 раз полностью закрывая глаза на то, что тебе два дня назад сказали, что можно просто поставить точку останова в отладчике.
Право... надоело.
Обясняю последний раз и закроем тему.
Сначла терминалогия. Объектный код — это код компилируемой программы. Именно он содержит обращения к макросам. И именно он после компиляции и раскрытия макросов превращается в исполняемый модуль.
Макросы не вызваются из объектного кода. Они раскрываются в объектном коде заменяясь реальным кодом. Так что после того как код использующий макросы был скомпилирован ловить в нем уже нечего! Если в рантайме поставить точку останова в объектном коде в месте "вызова" макроса, то ты "увидишь" не вызов, а сгенерированный код. А точка останова будет находиться в его начале. "Увидишь" взято в ковычки, так как фактически не предпринимая специльных действий, ты вообще ничего не увидишь. Ведь генерируемый код не виден взору.
Так что идея поставить точку останова на "вызове" макроса — это нелепица вызванная не пониманием приципа действия макросов.
Теперь, что касается отлова нужного места.
1. Место не должно влиять на результат, если макрос написан грамотно. Надо стараться делать так, чтобы разные обращения к макросам с одинаковыми параметрами приодили к одинаковому результату. Побочные эффекты иногда конечно полезны, но нужно четко осознавать их опасность. Это ничем не отличается от создания прикладного кода.
Это позволит отлаживать макросы просто передавая им на вход набор тестовых данных.
2. Для отлова места, если поведение макроса зависит от порядка вызова или того где он исползуется, если это очень нужно можно использовать другой, отладочный, макрос который взведет некую переменную которую можно проверить в основном макросе и отловить точкой останова.
3. Если нужно отловить n-ый вызов макроса, можно поставить точку останова с условием или просто навести отладочную переменную в макросе которая будет увеличиваться при кождом следующем вызове макроса. Остальное дело техники.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Вот мне интересно эти трудозатраты будут сопоставимы с затратами на C++?
VD>Это сопоставление неализованной возможности и ее реализации универсальными средствами. Подобное сравнение имеет такой же смысл, как сравение вызова функции и ее реализации.
Пусть так но мне хочется понять насколько велики возможности немерли. Просто если реализация очень сложна то практически можно сказать что этой возможности нет.
Здравствуйте, VladD2, Вы писали:
E>>Ага, конечно. У тебя, наверное, никогда наведенных ошибок не было.
VD>Бывали. В основном когда писал на С/С++ и скриптах разных. На Шарпе что-то наведенки крайне мало, и она легко отлавливается. С Немерлом пока тоже вроде все понятно в отладке.
E>> Когда код проходит все unit-тесты, но в одном из двадцати реальных прогонов почему-то ломается.
VD>Я на скриптах не пишу. Так что техники безопасного секса не так актуальны. Нет у меня обычно юнит-тестов... Обычно все и так неплохо работает.
Ну-ну. Работает и пусть работает. Ты мне еще расскажи, что статическая типизация на 99% устраняет необходимость тестирования приложений. Что после успешной компиляции нужно проверить всего две вещи -- что программа успешно стартует и столь же успешно завершается. Если эти условия выполняются, значит все работает корректно.
Увольте, батенька. Рассказывай эти сказки начинающим программистам, которые кроме окошек в WinForms ничего не программируют.
VD>Обясняю последний раз и закроем тему.
Не нужно считать окружающих тупее себя. То, что ты излагаешь ниже я и без тебя прекрасно понимаю, благо разные преобразователи исходных текстов писать приходилось.
Я просто хотел понять, что делать в случае, когда я вижу, что некий макрос, производящий compile-time вычисления подставляет мне в код явно не правильную константу. Причем делает это он не всегда, а один раз в некотором месте исходного кода.
То, что нельзя зайти в код макроса из обычной отладки моего кода я и без вас с IT прекрасно понимал.
Я не понимал, как войти в отладку кода макроса, когда этот код работает в отдельном параллельном процессе ncc. Оказалось, что провоцируется отладка процесса компилятора путем подстановки в код макроса специальных провоцирующих отладку инструкций (вроде Assert(false)). После этого стало понятно. Напомнило, как некоторые товарищи в C/C++ код вставляли asm { int 3h; } (вроде так).
Только для этого способа, как я понимаю, нужно иметь компилируемый исходный код макроса чтобы вставить в него Assert(false) и перекомпилироваться.
VD>1. Место не должно влиять на результат, если макрос написан грамотно. Надо стараться делать так, чтобы разные обращения к макросам с одинаковыми параметрами приодили к одинаковому результату. Побочные эффекты иногда конечно полезны, но нужно четко осознавать их опасность. Это ничем не отличается от создания прикладного кода.
Прописная истина. Если бы программы писались так просто, необходимости в отладке вообще бы не было.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Пенесометрия и есть спорт. Но я уж лчше пойду в спортзал.
Я и туда хожу Люблю спорт, панимаишь
VD>Хм. Потренироваться — это дело. Но ведь можно тренироваться на куда более полезных кошках! Например, мне хочется доработать напильником макрос $ (тот, что используется в строке $" ... $(...) "), так чтобы он делал отсупы и форматировние. Ну, так чтобы использовать его вместо SreingTemplate.
Понимаешь, Влад, у меня пока нет реальных проектов, на которых я могу применить Nemerle. Скоро один такой появится, если я проявлю достаточно настойчивости. До этого момента большие проекты я начинать не хочу и тренируюсь эпизодически на хомячках
И вот как-то эта (простенькая, на самом деле) задача про физические величины мне, что называется, "впилась". Реализация на C++ мне понравилась с точки зрения ценителя настоящих извращений и захотелось просто написать то же самое, но на Nemerle. Вот и всё.
O>>Ну а с точки зрения последующего использования... да, private members measuring в чистом виде.
VD>Не понял.
Ну эта... private, member, а дальше пусть каждый думает в меру своей распущенности
У кого-то на форуме даже подпись про C++ на эту тему пробегала
Здравствуйте, IT, Вы писали:
> Да, лучше перестраховаться и объявить Nemerle и его создателей врагами > народа, дизертирами и вредителями колхозных колосков.
Можешь показать цитаты, хотя бы близкие по смыслу к этому?
> ЗЫ. Мне, кстати, тоже интересно, доколе народ будет заниматься охотой на > ведьм? Я так понимаю, что удовольствие получается уже от самого процесса >
А вот я применительно к отладке макросов во время компиляции другого не понимаю. Почему этого нельзя сделать путем установки точки прерывания в IDE на месте обращения к макросу в моем коде? Нет, про разные этапы компиляции и отладки, про то, что макросы это уже объектный код и прочие прописные истины ... все это я уже слышал. Это все попытка доказать всем, что так делать нельзя потому, что сейчас это невозможно.
Ну а если чуть-чуть подумать. Преставим, что в IDE на строке своего исходника я устанавливаю точку прерывания. Запускаю компиляцию, IDE подгружает внутри себя процесс компилятора и передает ему дополнительную информацию: имя файла и номер строки с точкой прерывания. Когда компилятор доходит до этого места в процессе компиляции, он сообщает IDE об этом и позволяет IDE войти в режим отладки.
Компонентная, в конце-концов .NET среда или так просто, погулять вышла? Компилятор может быть таким компонентом, который IDE подгружает в себя. IDE получает от компилятора интерфейс для управления компиляцией. IDE передает компилятору свой callback интерфейс. IDE дергает метод компилятора для начала компиляции с перечислением точек прерываний. Когда компилятор добирается до одной из них, он дергает callback интерфейс IDE и говорит, где и как нужно начать отладку.
Получается нормальная IDE для полноценного использования и отладки средств метапрограммирования Nemerle.
Или такое все же принципиально невозможно?
AFAIK, IDE для Smalltalk-а давно так работают. Чуть ли не с рождения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
K>>Интересно на сколько таких отладочных сессий хватит терпения (у рядового программера) прежде чем макросы пойдут фтопку?
VD>Нескажу за рядовых, но если человек хоть раз отлаживал DLL-сборку или просто Win-DLL, то проблем не возникает вообще.
Просто потом это надоедает и начинаешь юзать более простые вещи.
K>> В свое время имено из-за гемора с отладкой я перестал юзать циклы с итераторами и вещи типа for_each и перешел на классический for(int i = 0;...). K>> Писанины не намного больше,
VD>Писанины намного больше. Да и for не эквиалентен foreach-у. Попробуй, анпример, через for перебрать элементы хэш-таблицы или связанного списка. А через foreach легко.
А через for трудно?
// связный список. код из реального проекта
FB_Curve *c, *c2;
// split poly-curves if need:for ( c = curves.first(); c; c = c2 )
{
c2 = curves.next(c);
c->split(); // может добавить элементы в список поэтому сначала делаем next()
}
// tessfor ( c = curves.first(); c; c = curves.next(c) )
c->tess();
Хэш таблица — аналогично, только там массив списков, не вижу никаких трудностей. Кому трудно может написать макрос для среды который заготовки циклов в редактор вставляет. Хотя мне и руками не трудно написать, на обдумывание все равно времени гораздо больше уходит.
VD>А зачем видить внутреннюю реализацию паттерна? Мне достаточно видеть то, что код перебирает элементы коллекции. Остальное не важно.
А мне важно знать номер итерации на которой произошла ошибка (или ID обьекта, если он есть), циклы большие обьем входных данных тоже не мальнький, а корректность никто не гарантирует. Как отлаживатся то?
В каждый обьект уникальный ID пихать?
Здравствуйте, eao197, Вы писали:
E>А вот я применительно к отладке макросов во время компиляции другого не понимаю. Почему этого нельзя сделать путем установки точки прерывания в IDE на месте обращения к макросу в моем коде? Нет, про разные этапы компиляции и отладки, про то, что макросы это уже объектный код и прочие прописные истины ... все это я уже слышал. Это все попытка доказать всем, что так делать нельзя потому, что сейчас это невозможно.
если очень хочется — возьми и сделай, благо исходники доступны
E>AFAIK, IDE для Smalltalk-а давно так работают. Чуть ли не с рождения.
рассказать тебе снова, в чем принципиальная разница между Немерле и Смоллтоком?
Здравствуйте, Дарней, Вы писали:
Д>если очень хочется — возьми и сделай, благо исходники доступны
Я вот одного не пойму -- то о чем я написал для Nemerle принципиально не нужно? Ну т.е. совсем. Даже в светлом будущем, когда толпы народу Nemerle использовать будут?
E>>AFAIK, IDE для Smalltalk-а давно так работают. Чуть ли не с рождения.
Д>рассказать тебе снова, в чем принципиальная разница между Немерле и Смоллтоком?
Извини за грубость, но встречный вопрос: а ты сам-то знаешь?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Я вот одного не пойму -- то о чем я написал для Nemerle принципиально не нужно? Ну т.е. совсем. Даже в светлом будущем, когда толпы народу Nemerle использовать будут?
Нужно. Но сейчас есть вопросы намного более актуальные.
В С++ вообще никакой отладки для хитрых рекурсивных шаблонов нет, даже трассировки. И ничего, живут же люди. Или тебе просто раздуть очередного слона из мухи?
Д>>рассказать тебе снова, в чем принципиальная разница между Немерле и Смоллтоком?
E>Извини за грубость, но встречный вопрос: а ты сам-то знаешь?
В контексте нашего обсуждения, разница очень проста. В Смоллтоке компилятор выполняет минимальную работу, основной упор делается на рантайм. А в Немерле — наоборот.
Дарней wrote: > C>В нем по CLSID объектов происходит диспетчеризация. > и эти люди запрещают мне ковыряться в носу (С) > такой же диспатч под CLI делается без проблем и намного проще
В чистом С++ оно тоже делается намного проще. Но нужен именно VBA.
VladD2 wrote: > Лично я не могу судить о IronPython. Если он генерирует именно MSIL, то > несомненно он компилятор. Если же генерируется ней свой байткод который > потом интерпретируется, а что-то еще, и это что-то потом > интерпретируется, то это интерпретатор.
Iron.Python (как и Jython до этого) пытается производить вывод типов,
в тех случаях когда это удается — вставляет готовый IL. В остальных
случаях использует интерпретатор.
VladD2 wrote: > C> Ну создам я пару > C>динамических методов, но как их передать другому несвязаному коду? > Очевидно другой од тоже должен быть динамическим, работать через > заранее известный > интерфейс или вызвать порождаемый код через рефлексию.
Откуда он "заранее известен"? У нас есть на него стандарт?
> C>И я уж не говорю, что семантика объектов в .NET всего лишь немного > C>беднее языка Эллы-людоедочки. > С Эллочкой сранвивать не буду. Но где-то в ЯП есть лучше?
В той же ParrotVM, например.
> C> И различные нетривиальные фичи типа > C>мультиметодов и динамического вызова отображаются на него только с > C>большими приседаниями. > С динамическими вызовами никаких проблем нет.
Есть. В .NET нет проблем только с рефлексивными вызовами.
> Что касается мултиметодов, то это фича языка, а не рантайма. > Деспечиризация — это, ведь, алогоритм.
А вы попробуйте совместить диспетчеризацию и модульность. То есть мы
подключаем новый модуль — и старые мультиметоды могут начать по-другому
работать. Да и не надо забывать, что в некоторых языках отсутствует
понятие "компиляция".
Здравствуйте, Cyberax, Вы писали:
>> такой же диспатч под CLI делается без проблем и намного проще C>В чистом С++ оно тоже делается намного проще. Но нужен именно VBA.
а что, по твоему "чистый С++" эквивалентно CLI по возможностям интеропа?
И статистику сколько их таких.
Если нам не помогут, то мы тоже никого не пощадим.
