Здравствуйте, eao197, Вы писали:
E>Ты думаешь в C++ проектах все сплошь и рядом пишут свои парсеры XML и HTML? E>Я в это не верю.
Я тоже в это не верю, но думаю много чего на C++ не было написано, только потому что надо было сначала найти какую-то библиотеку и научиться ей пользоваться. Сейчас это намного меньшая проблема.
E>>>Вот в том-то и дело. Что при переходе к объектно-ориентированному программированию изменение мышления происходит. А вот следующей такой идеи, которая бы еще раз сознание перевернула, пока не видно.
D>>Дело не только в языке java, а и в инструментах которые вокруг него есть. Вот отличия моего мышления сейчас, от того как я думал лет 5 назад, объекты оставим в стороне. В скобках — какие фенечки делают это возможным.
D>>1. Unit тесты и TDD.
E>Ну и причем тут языки?
Лично учавствовал в написании фреймфорка для unit тестов на C++ — то что удалось сделать существенно большее уродство, чем jUnit. А писали мы его потому что cppUnit уродство еще большее.
D>>2. Я существенно меньше думаю до написания кода, и существенно больше во время.
E>Давай перефразируем: "я меньше думаю до того, как переходить дорогу, чем когда иду на красный свет и гадаю, собьют ли на этот раз?". А современные системы тормозов у автомобилей и запреты водить машину в нетрезвом состоянии позволяют мне оставаться невредимым в большинстве случаев.
Скорее не так теперь: медицина достает меня с того света успешно и почти за бесплатно
E>Если сначала о чем-то хорошенько подумать, то часто оказывается, что все гораздо проще и не требует навороченного инструмента.
Но если инструмент есть, то думать эффективнее глядя на код, чем гадать, что потребуется в далеком будущем.
D>>3. Не заморачиваюсь на проблемы какой объект когда помрет (managed code). За исключением вопроса почему он до сих пор жив. E>А в Smalltalk ты об этом заморачивался?
А Smalltalk не mainstream
D>>4. Прямо сейчас вместо того чтобы писать свой собственный велосипед, я ищу подходящий, написанный кем-нить другим (поддежка reuse). E>И это опять не имеет прямого отношения к языкам.
Я в первом посте, в конце, написал, что сейчас неверно считать что понятие "язык" ограничивается синтаксисом, теперь это платформа с инструментами и стандартами.
А если поступать как 20 лет назад, пишу в текстовом редакторе; собираю make`ом; javadoc не пишу и не читаю, да и вообще не свой код не использую; про unit тесты ничего не слышал. Тогда действительно разница между java и C++ — GC, простой синтаксис и туча потерянных фич (множественное наследование, template, препроцессор, ...)
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, GlebZ, Вы писали:
GZ>>Здравствуйте, Gaperton, Вы писали:
G>>>В наших тоже, редко, но бывает. Сумрачный русский гений породил, например, такую злую и беспощадную чорную магию, как рефал. GZ>>рефал — функциональный язык? G>Насколько я знаю — не без этого .
А пролог?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Глеб Алексеев, Вы писали:
ГА>>Так вроде бы ФП не в наших университетах развивается. GZ>Насчет развивается, не сказал бы. Ну разве что Moscow ML. А вот преподается Lisp и Prolog — это да.
Насчет Moscow ML — good point. Хотя, если не ошибаюсь, последняя версия была в 2000м, а тот же SML/NJ обновился в 2005м (хотя нормальную документацию, как в Москау МЛ, так и не удосужились сделать).
GZ>А ведь было, было. И Рефал писали, и Lisp для БЭСМ, и много чего еще. И для Эльбруса вычислитель был крутой да параллельный.
Было. Развитие — оно должно быть из настоящего в будущее нацелено, а если последний раз наблюдалось 20 лет назад — увы .
Да, и маленькая деталь насчет "наших университетов" — мы со Зверьком еще более земляки, чем с вами, уважаемые граждане бывшего СССР.
Здравствуйте, GlebZ, Вы писали:
ГА>>Так вроде бы ФП не в наших университетах развивается. GZ>Насчет развивается, не сказал бы. Ну разве что Moscow ML. А вот преподается Lisp и Prolog — это да.
Moscow ML — вещь но по-моему ето автор (не помню как звать, или их двое было?) уже в эмиграции (вроде в германии) сделал(и), или доделал(и)...
Здравствуйте, Dyoma, Вы писали:
E>>Ну и причем тут языки?
D>Лично учавствовал в написании фреймфорка для unit тестов на C++ — то что удалось сделать существенно большее уродство, чем jUnit. А писали мы его потому что cppUnit уродство еще большее.
Мой первоначальный вопрос все равно остается в силе. Unit-тестинг так же возможен на C++, как и на Java. Просто выглядит это по другому. Взгляни хотя бы на Boost.Test.
А TDD -- единственный, на мой взгляд, способ писать на C++ работающие программы.
D>>>3. Не заморачиваюсь на проблемы какой объект когда помрет (managed code). За исключением вопроса почему он до сих пор жив. E>>А в Smalltalk ты об этом заморачивался?
D>А Smalltalk не mainstream
Но ведь не заморачивался же. Как сейчас Python или Ruby программисты не заморачиваются.
D>>>4. Прямо сейчас вместо того чтобы писать свой собственный велосипед, я ищу подходящий, написанный кем-нить другим (поддежка reuse). E>>И это опять не имеет прямого отношения к языкам.
D>Я в первом посте, в конце, написал, что сейчас неверно считать что понятие "язык" ограничивается синтаксисом, теперь это платформа с инструментами и стандартами.
Так вот я не согласен с этой мыслью. Язык определяет способ мышления. А инструменты всего лишь помогают твои мысли эффективнее записывать. Не более того.
D>А если поступать как 20 лет назад, пишу в текстовом редакторе; собираю make`ом; javadoc не пишу и не читаю, да и вообще не свой код не использую; про unit тесты ничего не слышал. Тогда действительно разница между java и C++ — GC, простой синтаксис и туча потерянных фич (множественное наследование, template, препроцессор, ...)
А если я поступаю как 10 лет назад: пишу в VIM; собираю почти что make-ом; Doxygen-комментарии пишу и читаю; про unit-тесты слышал, но не думаю, что это панацея. И все это на C++ и Ruby. Так что разница между Java и C++ -- GC, простой (?) синтаксис и туча потерянных фич...
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, GlebZ, Вы писали:
GZ>>>Здравствуйте, Gaperton, Вы писали:
G>>>>В наших тоже, редко, но бывает. Сумрачный русский гений породил, например, такую злую и беспощадную чорную магию, как рефал. GZ>>>рефал — функциональный язык? G>>Насколько я знаю — не без этого . GZ>А пролог?
А пролог нет.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, GlebZ, Вы писали:
GZ>>Здравствуйте, Gaperton, Вы писали:
G>>>В наших тоже, редко, но бывает. Сумрачный русский гений породил, например, такую злую и беспощадную чорную магию, как рефал. GZ>>рефал — функциональный язык? G>Насколько я знаю — не без этого .
Из лекции Сентенциальное программирование: Рефал
Рефал — предметно-эквациональный способ определения функций на свободном моноиде с дополнительной одноместной операцией.
(А. П. Бельтюков. Определение Рефала для чистых математиков.)
Рефал—замечательный язык!На нем можно запрограммировать все, что угодно, если, конечно, других языков не знать.
Студент УдГУ
Не читал саму лекцию полностью, и так и не узнал что обозначает "Сентенциальное программирование", но по началу рефал позиционируют как аналог Prolog.
IMHO Не знаю, стоит ли пролог называть функциональным(хотя он работает по такому же принципу). Но все таки он логический язык.
Такая вот загвоздка.
Здравствуйте, eao197, Вы писали:
D>>Лично учавствовал в написании фреймфорка для unit тестов на C++ — то что удалось сделать существенно большее уродство, чем jUnit. А писали мы его потому что cppUnit уродство еще большее.
E>Мой первоначальный вопрос все равно остается в силе. Unit-тестинг так же возможен на C++, как и на Java. Просто выглядит это по другому. Взгляни хотя бы на Boost.Test.
Посмотрел, правда, невнимательно — я сейчас далек от C++. На поверхности те же проблемы, что и у cppUnit — если я вижу в коде тест, это еще не значит, что он запускается, для того что бы в этом убедиться надо смотреть (читай искать) в другое место. В своей реализации мы хоть эту проблему решили.
E>А TDD -- единственный, на мой взгляд, способ писать на C++ работающие программы.
Заметь — изменилось твое мышление. Честное слово писали и без них.
D>>А Smalltalk не mainstream
E>Но ведь не заморачивался же. Как сейчас Python или Ruby программисты не заморачиваются.
Тык дискуссия о mainstream. А вообще хороших идей вокруг много... только недоделаны и не знает про них почти никто.
D>>Я в первом посте, в конце, написал, что сейчас неверно считать что понятие "язык" ограничивается синтаксисом, теперь это платформа с инструментами и стандартами.
E>Так вот я не согласен с этой мыслью. Язык определяет способ мышления. А инструменты всего лишь помогают твои мысли эффективнее записывать. Не более того.
Да, но только если на нем думать можно. На C++ и Java нельзя, на Smalltalk и ML можно. Вот пример — вычислить сумму чисел из массива.
Java/C
int sum = 0; // Какого фига я должен думать о том где храню результат?for (int i = 0; i < array.length; i++) { // Переведи на русский и прочитай вслух :) "Для скобка цел и равно..." :)))
sum += array[i]; // Ну вот это собственно я и думал :)
} // Это тоже надо подумать...
ML: (за синтакцическую корректность не отвечаю, но только в деталях)
fun sum(head::tail) = head + sum(tail) | sum([]) = 0.
Вариант от Smalltalk и ML это два разных способа мышления, а Java/C это сплошное спотыкание мысли и куча мусора.
D>>А если поступать как 20 лет назад, пишу в текстовом редакторе; собираю make`ом; javadoc не пишу и не читаю, да и вообще не свой код не использую; про unit тесты ничего не слышал. Тогда действительно разница между java и C++ — GC, простой синтаксис и туча потерянных фич (множественное наследование, template, препроцессор, ...)
E>А если я поступаю как 10 лет назад: пишу в VIM; собираю почти что make-ом; Doxygen-комментарии пишу и читаю; про unit-тесты слышал, но не думаю, что это панацея. И все это на C++ и Ruby. Так что разница между Java и C++ -- GC, простой (?) синтаксис и туча потерянных фич...
Не-е, если ты не исползуешь java (C#) и современные для них инструменты, это еще не значит, что все делают так же.
Здравствуйте, Dyoma, Вы писали:
D>Да, но только если на нем думать можно. На C++ и Java нельзя, на Smalltalk и ML можно. Вот пример — вычислить сумму чисел из массива.
D>Java/C D>
D>int sum = 0; // Какого фига я должен думать о том где храню результат?
D>for (int i = 0; i < array.length; i++) { // Переведи на русский и прочитай вслух :) "Для скобка цел и равно..." :)))
D> sum += array[i]; // Ну вот это собственно я и думал :)
D>} // Это тоже надо подумать...
D>
D>Smalltalk: D>array inject: 0 into: [:sum :element | sum + element]
D>ML: (за синтакцическую корректность не отвечаю, но только в деталях) D>fun sum(head::tail) = head + sum(tail) | sum([]) = 0.
D>Вариант от Smalltalk и ML это два разных способа мышления, а Java/C это сплошное спотыкание мысли и куча мусора.
На сях код заметно понятней (хотя тут может привычка сказывается), на мл менне но вполне понятно, но смолтолке — китайская грамота. Получается чтобы понять язык, надо прежде всего "голову сломать" (при такой фразе в первую очередь вспоминается перл — язык имхо очень хреново читаемый "нормальным" человеком.)
Вот и "думать на языке" после этого — что-то не очень показательно выглядит
GlebZ wrote:
> Из лекции Сентенциальное программирование: Рефал > Рефал — предметно-эквациональный способ определения функций на > свободном моноиде с дополнительной одноместной операцией. > (А. П. Бельтюков. Определение Рефала для чистых математиков.)
У меня друг вел практику по языкам программирования в УдГУ, в том числе
был и Рефал. Сейчас этот человек пишет кандидатскую на тему
распределенных сентенциальных вычислений, заимствующей идеи из Рефала —
достаточно интересная вещь.
Если кому интересно — могу рассказать подробнее об этом языке.
Практической пользы — почти никакой, но в качестве разминки для мозгов
подходит замечательно.
> Рефал—замечательный язык!На нем можно запрограммировать все, что > угодно, если, конечно, других языков не знать. > Студент УдГУ
Кажется именно этот студент написал крестики-нолики на Рефале
> Не читал саму лекцию полностью, и так и не узнал что обозначает > "Сентенциальное программирование", но по началу рефал позиционируют > как аналог Prolog.
Здравствуйте, Курилка, Вы писали:
D>>Да, но только если на нем думать можно. На C++ и Java нельзя, на Smalltalk и ML можно. Вот пример — вычислить сумму чисел из массива.
D>>Smalltalk: D>>array inject: 0 into: [:sum :element | sum + element]
D>>ML: (за синтакцическую корректность не отвечаю, но только в деталях) D>>fun sum(head::tail) = head + sum(tail) | sum([]) = 0.
D>>Вариант от Smalltalk и ML это два разных способа мышления, а Java/C это сплошное спотыкание мысли и куча мусора.
К>На сях код заметно понятней (хотя тут может привычка сказывается), на мл менне но вполне понятно, но смолтолке — китайская грамота. Получается чтобы понять язык, надо прежде всего "голову сломать" (при такой фразе в первую очередь вспоминается перл — язык имхо очень хреново читаемый "нормальным" человеком.) К>Вот и "думать на языке" после этого — что-то не очень показательно выглядит
Естественно чтобы думать на языке его надо для начала знать (и хорошо знать). Для того что бы мысль донести придется перевести:
В Smalltalk вызов метода выглядит так:
<объект> <имя_метода_и_аргументы>
в результате всегда получается объект, не бывает void-методов.
имя_метода_и_аргументы пишется по разному, в зависимости от "вида метода":
1. obj method — вызов метода без аргументов.
2. obj + arg — вызов infix`ного метода (имя метода состоит из небуквенных символов)
3а. obj method: arg — вызов метода с 1 аргументом.
3б. Имя метода с несколькими агрументами имеет вид part1:part2:part3:... где parti — части имени.
Например положить в список элемент в заданную позицию (аналог insert(int index, Object value) для java)
list at: index put: value
Имя метода at:put: аргументы вставляются внутрь имени. Очень убодно в месте вызова виден смысл параметра (а не только его порядковый номер)
В примере вычисляющем сумму у объекта array вызывается метод inject:into (о нем чуть позже) с параметрами 0 и [...].
Второй параметр — это блок кода [:arg1 :arg2 ...| <код>] где arg1, arg2, ... имена его параметров, а <код> это то что с ними на сделать. Результат последнего выражения — результат блока. Блок кода в Smalltalk это тоже объект и с ним можно делать все тоже что и с любым другим объектом.
Теперь методов inject:into: — проходит по всему массиву и вызвает второй параметр (блок) с аргументами 1-предыдущий результат блока, 2 — очередной элемент массива). На первый раз предыдущего заначения нет — вместо него передается первый параметр inject:into:
Очень удобно что такой метод есть у всех коллекций, это позволяет включить такую полезную операцию в свой "словарный запас".
Если буквально перевести на русский что там написано получится
"делать [элемент + текущий_результат] начальный 0 для_всех_элементов массив". Если закрыть глаза на корявось перевода то это и есть в точности "просуммировать все элементы", лишний тут только 0.
Нет ни слова о том что надо итерироваться на массиву и держать где-то результат (промежуточный результат просто есть в нужном месте), а все подробности как итерироваться и где хранить находятся в одном обще-применимом методе.
ML реализация действительно читается как
"сумма пустого_списка = 0, в_дугих_случаях сумма = прибавить первый_элемент к сумме остальных"
Опять же никакого мусора.
Здравствуйте, Dyoma, Вы писали:
E>>Мой первоначальный вопрос все равно остается в силе. Unit-тестинг так же возможен на C++, как и на Java. Просто выглядит это по другому. Взгляни хотя бы на Boost.Test.
D>Посмотрел, правда, невнимательно — я сейчас далек от C++. На поверхности те же проблемы, что и у cppUnit — если я вижу в коде тест, это еще не значит, что он запускается, для того что бы в этом убедиться надо смотреть (читай искать) в другое место. В своей реализации мы хоть эту проблему решили.
Вот я и говорю, что выглядит по другому. Ну нет в C++ рефлекшена. Поэтому вызовы тест-кейсов вручную нужно прописывать.
E>>А TDD -- единственный, на мой взгляд, способ писать на C++ работающие программы.
D>Заметь — изменилось твое мышление. Честное слово писали и без них.
Ничего подобного. Я просто узнал, как оно называется. А те, кто писал действительно успешные и работающие программы на C++ практически всегда так и делали. Написали две строчки -- скомпилировали. Написали еще две -- протестировали.
D>Тык дискуссия о mainstream. А вообще хороших идей вокруг много... только недоделаны и не знает про них почти никто.
Имхо, Python и Ruby тоже себе не плохие мейнстримы. И знает про них достаточное количество народу. И используют.
E>>Так вот я не согласен с этой мыслью. Язык определяет способ мышления. А инструменты всего лишь помогают твои мысли эффективнее записывать. Не более того.
D>Да, но только если на нем думать можно. На C++ и Java нельзя, на Smalltalk и ML можно. Вот пример — вычислить сумму чисел из массива.
D>Java/C D>
D>int sum = 0; // Какого фига я должен думать о том где храню результат?
D>for (int i = 0; i < array.length; i++) { // Переведи на русский и прочитай вслух :) "Для скобка цел и равно..." :)))
D> sum += array[i]; // Ну вот это собственно я и думал :)
D>} // Это тоже надо подумать...
D>
D>Smalltalk: D>array inject: 0 into: [:sum :element | sum + element]
D>ML: (за синтакцическую корректность не отвечаю, но только в деталях) D>fun sum(head::tail) = head + sum(tail) | sum([]) = 0.
Алаверды на Ruby:
a.inject { |s, v| s += v }
D>Вариант от Smalltalk и ML это два разных способа мышления, а Java/C это сплошное спотыкание мысли и куча мусора.
Так я тебе про то и говорю, что есть сдвиг серьезная смена мышления при переходе от процедурного программирования к объектно-ориентированному (с Паскаля или C на C++ или Java). Переключение с C++/Java на Smalltalk/Ruby -- это тоже небольшая смена. Но не большая, т.к. понятия там все равно объектнно-ориентированные. Причем в случае с Ruby такой переход вообще очень плавно происходит, т.к. Ruby позволяет программировать в чисто императивном стиле.
А вот вся тема строится вокруг того, может ли появится такой язык, который бы потребовал такой же смены мышления, как переход с C на C++ или с Паскаля на Smalltalk? И если такой язык появится, то инструментарий существующих языков будет не столь важен.
E>>А если я поступаю как 10 лет назад: пишу в VIM; собираю почти что make-ом; Doxygen-комментарии пишу и читаю; про unit-тесты слышал, но не думаю, что это панацея. И все это на C++ и Ruby. Так что разница между Java и C++ -- GC, простой (?) синтаксис и туча потерянных фич...
D>Не-е, если ты не исползуешь java (C#) и современные для них инструменты, это еще не значит, что все делают так же.
Абсолютно не значит. Но если кто-то программирует на Java в Idea или Eclipse он все равно будет вынужден строить практически такую же объектную модель, что и я на C++ в VIM. Т.к. модель строится не в редакторе/IDE, а в голове.
Более того, в VIM на той же Java я смогу сделать такое же решение, как ты в Idea. Может быть это будет медленнее. В первый раз. Но вот качество решения вряд ли будет различаться у кода, набранного в Far или VIM, и у кода из Eclipse/Idea. Потому что редакторы имеют к качеству кода очень посредственное отношение.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Не читал саму лекцию полностью, и так и не узнал что обозначает "Сентенциальное программирование", но по началу рефал позиционируют как аналог Prolog.
GZ>IMHO Не знаю, стоит ли пролог называть функциональным(хотя он работает по такому же принципу). Но все таки он логический язык.
Пролог здесь совершенно не при чем. Студент УдГУ, это конечно, очень круто. Но может посмотрим, что на эту тему думает сам автор Рефала? http://refal.net/english/xmlref_1.htm
А думает он, что...
Refal is a purely functional language based on pattern matching. This means that:
Computation is always an evaluation of some function call.
A function is defined by a number of sentences (rules, or equations), where in the left side we see a pattern of the argument (i.e. an argument which may be only partially defined), whereas in the right side we see an expression which must be substituted for the function call in one step of computation. Presented in this way the program looks declarative: it is much easier to read and handle than a program presented as a sequence of commands (instructions) which include jumps of the execution point from one place to another.
Паттерн матчинг — единственное, что роднит его с Прологом. И это совсем не уникальное свойство среди функциональных языков — это стандартная фича для современных ФЯ:
For some time after its inception, Refal was unique in combining these two features. In the 1980s a number of similar functional languages appeared, such as ML, Haskel, Miranda, etc. Comparing Refal with these languages we note, first of all, that it is the simplest language in the family.
А вот и существенное отличие Рефала от остальных ФЯ:
The most important difference between Refal and all known to us functional languages is the fundamental data type used for manipulation of symbolic information. Refal uses R-expressions (Refal expressions); other languages use lists, or S-expressions.
Здравствуйте, eao197, Вы писали:
E>>>Мой первоначальный вопрос все равно остается в силе. Unit-тестинг так же возможен на C++, как и на Java. Просто выглядит это по другому. Взгляни хотя бы на Boost.Test.
А программирование так же возможно на asm
Язык высокого уровня шаг — вперед, потому как это удобно. reflection — такой же шаг вперед.
E>Вот я и говорю, что выглядит по другому. Ну нет в C++ рефлекшена. Поэтому вызовы тест-кейсов вручную нужно прописывать.
Мы проблему с reflection макросами объехали вместо просто объявления метода он сразу еще и в статический вектор запихивался.
А по существу, да возможно, но не удобно и криво.
E>Ничего подобного. Я просто узнал, как оно называется. А те, кто писал действительно успешные и работающие программы на C++ практически всегда так и делали. Написали две строчки -- скомпилировали. Написали еще две -- протестировали.
Насчет все — не соглашусь. А сейчас если не TDD то хотя бы автоматическое тестирование mainstream. Опять же не будем забывать про тему. Обсуждается не последнии академические достижения, а то что обрело/обретет популярность т.е. mainstream.
D>>Тык дискуссия о mainstream. А вообще хороших идей вокруг много... только недоделаны и не знает про них почти никто.
E>Имхо, Python и Ruby тоже себе не плохие мейнстримы. И знает про них достаточное количество народу. И используют.
А ты посмотри вокруг сколько на них проектов делается на которых денег зарабатывают? Все клипают на C++, C#, Java, VB, Delphi... Очень печально, но так уж вышло... Про проекты на Python или Ruby ничего не слышал, Smalltalk видел... но очень мало. Вот я пишу это в RSDN@Home и посмотрел вставки на каких языках поддерживаются и знаешь нету Python, Ruby, Smalltalk, а есть 11 других языков. Показатель?
E>>>Так вот я не согласен с этой мыслью. Язык определяет способ мышления. А инструменты всего лишь помогают твои мысли эффективнее записывать. Не более того.
D>>Да, но только если на нем думать можно. На C++ и Java нельзя, на Smalltalk и ML можно. Вот пример — вычислить сумму чисел из массива.
E>Алаверды на Ruby: E>
D> Почти все что есть в нашей работе интересного требует для формализации логики предикатов первого порядка (например нам очень интересна арифметика),
а кто-нибудь пытался исследовать системы основанные на неформальной логике?
Пытался строить системы/языки — которые бы напрямую оперировали достоверностью, эвристиками, нечеткой логикой и т.д.?
eao197 wrote:
> D>Посмотрел, правда, невнимательно — я сейчас далек от C++. На > поверхности те же проблемы, что и у cppUnit — если я вижу в коде тест, > это еще не значит, что он запускается, для того что бы в этом > убедиться надо смотреть (читай искать) в другое место. В своей > реализации мы хоть эту проблему решили. > Вот я и говорю, что выглядит по другому. Ну нет в C++ рефлекшена. > Поэтому вызовы тест-кейсов вручную нужно прописывать.
DarkGray wrote:
> C>Заметьте, НИКАКОЙ ручной регистрации и макросов. > Атомарность изменений есть? > т.е. если закомментировать польностью первый тест, то работать будет?
Да.
> т.е. можно ли делать нумерацию тестов не последовательной?