Здравствуйте, Cyberax, Вы писали:
C>Нормальный интерфейс к Java-коду. В том числе есть быстрый доступ к C>массивам, поддержка нативных буфферов (распределяем буффер в нативном C>коде и используем из Java) и т.п.
на то есть C++/CLI
если тебе лично хочется использовать plain C, и обязательно в роли клиента — это твоя сугубо личная интимная проблема.
Здравствуйте, Cyberax, Вы писали:
C>Аналогично для С++, только в compile-time на шаблонах. Можно и в runtime C>через IDispatch.
Ну значит изоморфно
Всё-таки хотелось бы глянуть на реализацию на C++, чтобы сравнить с тем же матчингом на Nemerle, например. Чисто интересно. Помню, видел только реализацию в Loki — эффективную, но громоздкую.
Здравствуйте, Дарней, Вы писали:
Д>на то есть C++/CLI Д>если тебе лично хочется использовать plain C, и обязательно в роли клиента — это твоя сугубо личная интимная проблема.
Если вы не в курсе, то С++/CIL не дает гарантии интероперабельности с нативным кодом (в Mono и PNet ее нет). Так что единственный реальный кроссплатформенный метод — PInvoke.
Oyster wrote: > Всё-таки хотелось бы глянуть на реализацию на C++, чтобы сравнить с тем > же матчингом на Nemerle, например. Чисто интересно. Помню, видел только > реализацию в Loki — эффективную, но громоздкую.
Использую модифицированый http://www.codeproject.com/cpp/mmvdd.asp
Здравствуйте, Cyberax, Вы писали:
C>Если вы не в курсе, то С++/CIL не дает гарантии интероперабельности с нативным кодом (в Mono и PNet ее нет). Так что единственный реальный кроссплатформенный метод — PInvoke.
ну во первых, про кроссплатформенность ты не говорил.
Во вторых — не беда, что с PInvoke придется попрыгать, чтобы получить кроссплатформенность. С С++ всё равно придется прыгать намного больше.
Здравствуйте, eao197, Вы писали:
WH>>Ты можешь не верить но когда я пишу на C# все примерно так и происходит. Я могу несколько дней долбить код без компиляции. После компиляции (как правило все компилируется сразу ибо ReSharper рулит) и устранении пары исключений (причем на C#2 и этого скорей всего не понадобится ибо генерики) все действительно работает как надо.
E>Ты прав. Не поверю. Даже если нет ошибок в коде, решающем задачу, есть ошибки в понимании самой задачи и, как следствие, неправильное поведение программы в реальных условиях.
Хмм. А как тут помогут юнит тесты? Их ведь как правило сам программист со своими "ошибками в понимании самой задачи" и делает.
WH>>А что ты без исходного кода отлаживать то будешь? Я конечно понимаю что можно отлаживать и исполняемый код... я и сам этим занимался но это такой геморой что лучше с этим не связываться.
E>Собственно я о том, что при работе со сторонней библиотекой макросов у тебя может не быть ее исходных кодов. А всего два варианта библиотеки -- release (без отладочной информации) и debug (с отладочной информацией). Хотя входить отладчиком в чужой код... Тот еще геморой, я согласен.
Здравствуйте, ie, Вы писали:
E>>Ты прав. Не поверю. Даже если нет ошибок в коде, решающем задачу, есть ошибки в понимании самой задачи и, как следствие, неправильное поведение программы в реальных условиях.
ie>Хмм. А как тут помогут юнит тесты? Их ведь как правило сам программист со своими "ошибками в понимании самой задачи" и делает.
Они могут помочь в случаях:
-- если их готовит кто-то другой, например, коллега за соседним столом
-- если их начинать писать до написания кода;
-- если их пишут исходя не из написанного кода, а исходя из имеющейся спецификации.
Они точно помогают, когда программа модифицируется через некоторое время. Когда про некоторые тонкие моменты забываешь, а старые unit-тесты про это помнят.
E>>Собственно я о том, что при работе со сторонней библиотекой макросов у тебя может не быть ее исходных кодов. А всего два варианта библиотеки -- release (без отладочной информации) и debug (с отладочной информацией). Хотя входить отладчиком в чужой код... Тот еще геморой, я согласен.
ie>+1
Вот, кстати, пример вспомнился. В состав VC++ всегда входил MFC в виде библиотек и в виде исходников. И при отладке MFC приложений временами доводилось входить отладчиком в код MFC. Но вот кто-нибудь изменял код MFC, перекопилировал его и заменял штатные MFC библиотеки компилятора на собственные? Думаю, что таких не много.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>>Ты прав. Не поверю. Даже если нет ошибок в коде, решающем задачу, есть ошибки в понимании самой задачи и, как следствие, неправильное поведение программы в реальных условиях.
ie>>Хмм. А как тут помогут юнит тесты? Их ведь как правило сам программист со своими "ошибками в понимании самой задачи" и делает.
E>Они могут помочь в случаях: E>-- если их готовит кто-то другой, например, коллега за соседним столом
+1, но эта ситуация, по крайней мере в наших проектах, редка
E>-- если их начинать писать до написания кода; E>-- если их пишут исходя не из написанного кода, а исходя из имеющейся спецификации.
Как правило так и делается, НО вами описана ситуация когда "есть ошибки в понимании самой задачи". Если задача понята неправильно, то тестироваться "правильная" задача не будет.
E>Они точно помогают, когда программа модифицируется через некоторое время. Когда про некоторые тонкие моменты забываешь, а старые unit-тесты про это помнят.
+1
Здравствуйте, eao197, Вы писали:
E>Вот, кстати, пример вспомнился. В состав VC++ всегда входил MFC в виде библиотек и в виде исходников. И при отладке MFC приложений временами доводилось входить отладчиком в код MFC. Но вот кто-нибудь изменял код MFC, перекопилировал его и заменял штатные MFC библиотеки компилятора на собственные? Думаю, что таких не много.
таких много. Слишком много, я бы сказал. Некоторые, особо "продвинутые" даже залезают в бинарники студии и правят
Здравствуйте, vdimas, Вы писали:
V>боже упаси, при чем тут спесь
Не люблю такие словечки
V>просто привести пример сложения — это было на грани прикола
Ну.. значит, ты не понял то, что я пытался сказать. А я пытался сказать то, что в Nemerle мы можем генерировать достаточно сложный код, используя единожды написанный метакод (если только этот код имеет регулярную структуру, как в обсуждаемом случае).
Задумайся, например, над тем, как бы я смог написать что-то подобное приведённому мной примеру "на грани прикола" на C#...
Дарней wrote: > ну во первых, про кроссплатформенность ты не говорил.
Сказал. Точнее намекнул.
> Во вторых — не беда, что с PInvoke придется попрыгать, чтобы получить > кроссплатформенность. С С++ всё равно придется прыгать намного больше.
Ага, конечно.
Здравствуйте, Cyberax, Вы писали:
C>Однако, в Boost'е есть утилита, которая позволяет интерактивно с консоли C>выполнять макросы (в том числе и по шагам) и смотреть за результатом их C>работы. Чем не отладчик?
Ни фига не смешно. Вом уже 21-ый раз повторяют, что макросы Немерла == коду находящемуся в ДЛЛ. И что этот код можно без кмких либо проблем отлаживать статным отладчиком. При этом в отличии от макросов С у макросов немерла нет кучи проблем (вроде не гигееничности) и есть полнота по Тьюрингу. То есть на них можно сделать хоть черта лысого и при этом не иметь тех проблем что есть в С.
C>Представим тоже самое для Nemerle — мы пишем код, вставляем макрос и C>нажимаем кнопку "отладка". Тут же мы видим во что этот макрос C>развертывается, можем по шагам проследить Nemerle'вский код и т.п.
Для этого нужно просто поставить точку останова и запустить компилятор под отладкой. Если хочется тольоко посмотреть результат, так вообще можно использовать макрос печатающий результат раскрытия другого макроса.
C>Все это давно уже есть в Smalltalk'е, как уже говорилось много раз. И C>метапрограммирование в Smalltalk'е тоже есть, кстати.
Рад за Смолток. Что же ты личнь не выкинишь плюся и не сядишь на него?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Видишь ли, unit-тесты приобретают большое значение не тогда, когда ты их написал. А тогда, когда ты про них забыл уже. Они тебе показывают, что после внесенных в одном месте изменений, что-то в другом месте перестало работать.
Видил ли, я и бен них делаю огромные изменения в коде не испытаывая после этого проблем. Для этого просто вместь Руби и VIM нужно использовать C# и VS2005.
E>Понимание это, однако, не сразу приходит. Для этого нужно некоторое время заставлять себя писать unit-тесты, даже при том, что текущие изменения прекрасно и без unit-тестов отлаживаются.
Я ничего не имею против юнит-тестов. В некоторых задачах они полезны. Но я не хочу жить на юнит тестах и писать их ко всем задачам.
Вот для маросов может юнит тесты и будут полезны, так как они являются порождающими сущьностями. А к примеру, для формы ввода они на фиг не упали.
E>>>Увольте, батенька. Рассказывай эти сказки начинающим программистам, которые кроме окошек в WinForms ничего не программируют.
VD>>Кто-там у нас постоянно рассуждал как другие неумеют воспринимать чужое мнение?
E>Я. О тебе. И постоянно в этом убеждаюсь.
Ну, вот к зеркалу подойди...
E>Да к тому, что про способ установить в теле макроса Assert(false), который прервет работу ncc и выдаст макрос в отладчик, я элементарно не знал.
А ничего, что ты уже 22 раз повторил про ассерты и продолжашь повторять. И это при том, что в первый раз тебе ответили про банальную точку останова?
E>Процесс ncc работает отдельно от процесса Visual Studio
Скажу тебе по сикрету, что Студии на машине вообще может не быть.
E> и отдельно от процесса, в который превратиться моя программа при отладке после компиляции.
Естественно. На то NCC и отдельный процесс. Только как это может помешать его отладке?
E>>> После этого стало понятно. Напомнило, как некоторые товарищи в C/C++ код вставляли asm { int 3h; } (вроде так).
VD>>Нда, маразм крепчал (с). Какие на фиг "asm { int 3h; }"? Где их ставить?
E>Прочти внимательно выделенное.
Прочел. Смысла в словах не обнаружил.
E> В свое время это был популярный способ заставить C++ программу в каком-то месте под нагрузкой вывалиться в отладку.
Для тех кто не знал, что есть assert-ы. А asm в С++ в общем-то и нет. Это расширение некоторых компиляторов. К С++ имеет такое же отношение как, например, поддержка COM-а.
E> Вставка Assert(false) напомнила мне этот способ. Только и всего. Никуда я не предлагал его вставлять. Это еще раз к восприятию чужого мнения.
В С++ нельзя вставить ни Assert(false), ни int 3 в код макроса или шаблонный метакод. Причем просто потому, что этот код не компилируется, а интерпретируется компилятором.
Так что о чем ты говоришь я все равно не понимаю.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
VD>>и поставить точку останова внутрь if-а. Далее остается вписать вызов BreakMyCacro() в нужном месте объектного кода (перед не верно работающим вызовом MyCacro).
E>И тебе кажется, что это не костыли?
Хм. Я подобными способами пользовался 15 лет в совершенно разных языках и разных местах. Это общие проблемы отладки. Какие тут костыли? Конечно всегда можно создать IDE которая возьмет на себя еще одну возможность. Но пока такой нет приходится применять банальные паттерны отладки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>А если в цикле в этот же контейнер элементы добавляются/удаляются? Или нужна пара или тройка соседних элементов. К примеру есть массив точек и хотим посчитать длины сегментов. Для этого нужен i и i+1 элемент. Если углы то i-1,i,i+1. foreach подходит отнюдь не везде, а написать for у меня нет трудностей.
Вот если тебе нужны индексы, то нет проблем воспользоваться for-ом. А если тебе нужно просто перебрать элементы, то for — это перебор.
В коне намного чаще встречается тупой перебор нежели хитрый доступ к индексам. Если это не так, то скорее всего вместо перебора используется более сложный for.
Я тебе даже больше скажу. Зачастую и перебор то и тот лишний. Ведь перебор он не самоцель. В рельном случае нужно или найти что-то или преобразовать оду последовательность в дугую. Для этого и forech слишком низкоуровневое средсво. Лучше делать функции вроде IndefOf(), Filter/FindAll и т.п. Тогда код будет еще проще и понятнее. А вероятность ошибки еще ниже.
K>Давай с помощью forach ты напишешь простой и понятный код который вычисляет разность между соседними точками в массиве.
А давай ты с помощью for-а будешь условия прверять (вместо if-а). Слабо? Ну, вот и не нужо foreach использовать там где ему не место.
K>Давай без наездов. Пример из жизни: на 1024 итерации программа падает потому, что имеет место быть самопрересечение поверхности. Что мне даст контекст? вообщем-то ничего, т.к. контекст будет находится в тех подпрограммах которые были вызваны из главного цикла. Не зная номера или индекса отлаживатся будет песня. Плавали знаем. поэтому я никогда не связываюсь с вещами типа forach, себе дороже.
Поверо на слово, если не хочешь проверять... высокоуровневый код сам по себе предотвращает ошибки. Вернее он предотвращает возможность их появления.
K>И что мне от этой уникальности?
Индекс смысла не имеет если логика на уровне экземпляров строется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> Так проблема в том, что сам язык не очень подходит для вывода типов. >> Отсюда и трудности. Проще сразу ввести в язык нужные ограничения. Тогда >> вывод типов из шаманста становится четким алгоритмом. C>Просто вывод типов нужно делать постоянно.
В рантайме? Ну, так это и будет интерпретацией.
C>А вот почитатели динамических языков так не считают. И примеры C>Ruby'шного кода, которые приводит eao197 показывают, что это вполне полезно.
Ну, вот я как-то не вижу особой разницы в коде при том, что вижу разницу в контроле, надежности и скорости.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Откуда он "заранее известен"? У нас есть на него стандарт?
Это один из способов. Собственно он подразумевает наличие такого стандарта. Ты воодишь интерфейс который реализуется динамическим объектом. Очень частый случай. Интежфейс может быть как интерфейсом в полном смысле этого слова, так и неким делегатом/фанктором.
>> С Эллочкой сранвивать не буду. Но где-то в ЯП есть лучше? C>В той же ParrotVM, например.
Осталось только доказать это утверждение. Без этого с тем же успехом его можно назвать полным отстоем.
C>Есть. В .NET нет проблем только с рефлексивными вызовами.
Это тоже пустые слова.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Понимание это, однако, не сразу приходит. Для этого нужно некоторое время заставлять себя писать unit-тесты, даже при том, что текущие изменения прекрасно и без unit-тестов отлаживаются.
VD>Я ничего не имею против юнит-тестов. В некоторых задачах они полезны. Но я не хочу жить на юнит тестах и писать их ко всем задачам.
VD>Вот для маросов может юнит тесты и будут полезны, так как они являются порождающими сущьностями. А к примеру, для формы ввода они на фиг не упали.
А кто говорил, что unit-тесты должны быть всегда?
К тому же формы, имхо, не unit-тестами проверяют, а функциональными.
VD>А ничего, что ты уже 22 раз повторил про ассерты и продолжашь повторять. И это при том, что в первый раз тебе ответили про банальную точку останова?
Я повторяю ровно столько, сколько мне об этом напоминают.
VD>Естественно. На то NCC и отдельный процесс. Только как это может помешать его отладке?
Отсутствие Visual Studio на машине, например, как ты только что сказал по секрету.
Для тех, кто в танке: я не мог сообразить сначала, что отладка compile-time макроса должна осуществляться как отладка отдельного процесса ncc. Вот и все. Может ты уже при работе с Nemerle к таким заморочкам привык, но для других это может быть чем-то новым.
E>> В свое время это был популярный способ заставить C++ программу в каком-то месте под нагрузкой вывалиться в отладку.
VD>Для тех кто не знал, что есть assert-ы.
assert-ы банально вырубаются при NDEBUG. А вот asm { int 3h; } так не выключишь. Не говоря про то, что assert-ов может быть сотни по коду, а вот asm{} сразу в глаза бросаются.
VD> А asm в С++ в общем-то и нет. Это расширение некоторых компиляторов. К С++ имеет такое же отношение как, например, поддержка COM-а.
Не расписывайся в очередной раз в незнании C++:
7.4 The asm declaration [dcl.asm]
An asm declaration has the form
asm-definition:
asm ( string-literal ) ;
The meaning of an asm declaration is implementation-defined. [Note: Typically it is used to pass informa-
tion through the implementation to an assembler. ]
Т.е. ключевое слово asm -- это часть языка. А вот то, что внутри asm -- это уже зависит от компилятора.
VD>В С++ нельзя вставить ни Assert(false), ни int 3 в код макроса или шаблонный метакод. Причем просто потому, что этот код не компилируется, а интерпретируется компилятором.
VD>Так что о чем ты говоришь я все равно не понимаю.
Я говорил о том, что вставка Assert(false) в текст макроса Nemerle для того, чтобы ncc вывалился в нужном месте в отладчик, очень напоминает вставку int 3 в код C/C++ программы для того, чтобы программа вывалилась в нужном месте. Не макрос C/C++, не шаблон C++, а программа C/C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
