Сторонний раннер тоже вариант, да.
А почему мой вариант не подходит для embedded? Что нужно изменить?
Я планирую его запускать в отладчике, поэтому printf'ы вообще можно убрать, на самом деле. Просто, если тест не проходит — while(1){;}. И отладчик останавливается как раз на проваленном тесте, это даже удобнее, чем искать по информации из лога.
У меня ощущение, что мы с вами смотрим в разные версии буста. Я вижу вот такой файл counter.hpp:
# /* **************************************************************************
# * *
# * (C) Copyright Paul Mensonides 2005. *
# * Distributed under the Boost Software License, Version 1.0. (See *
# * accompanying file LICENSE_1_0.txt or copy at *
# * http://www.boost.org/LICENSE_1_0.txt) *
# * *
# ************************************************************************** */
#
# /* See http://www.boost.org for most recent version. */
#
# ifndef BOOST_PREPROCESSOR_SLOT_COUNTER_HPP
# define BOOST_PREPROCESSOR_SLOT_COUNTER_HPP
#
# include <boost/preprocessor/slot/detail/def.hpp>
#
# /* BOOST_PP_COUNTER */
#
# define BOOST_PP_COUNTER 0
#
# /* BOOST_PP_UPDATE_COUNTER */
#
# define BOOST_PP_UPDATE_COUNTER() <boost/preprocessor/slot/detail/counter.hpp>
#
# endif
Он инклудит сам себя и файл def.hpp, который явно что-то делает, но вот только что — совершенно неясно
# * *
# * (C) Copyright Paul Mensonides 2002.
# * Distributed under the Boost Software License, Version 1.0. (See
# * accompanying file LICENSE_1_0.txt or copy at
# * http://www.boost.org/LICENSE_1_0.txt)
# * *
# ************************************************************************** */
#
# /* See http://www.boost.org for most recent version. */
#
# ifndef BOOST_PREPROCESSOR_SLOT_DETAIL_DEF_HPP
# define BOOST_PREPROCESSOR_SLOT_DETAIL_DEF_HPP
#
# /* BOOST_PP_SLOT_OFFSET_x */
#
# define BOOST_PP_SLOT_OFFSET_10(x) (x) % 1000000000UL
# define BOOST_PP_SLOT_OFFSET_9(x) BOOST_PP_SLOT_OFFSET_10(x) % 100000000UL
# define BOOST_PP_SLOT_OFFSET_8(x) BOOST_PP_SLOT_OFFSET_9(x) % 10000000UL
# define BOOST_PP_SLOT_OFFSET_7(x) BOOST_PP_SLOT_OFFSET_8(x) % 1000000UL
# define BOOST_PP_SLOT_OFFSET_6(x) BOOST_PP_SLOT_OFFSET_7(x) % 100000UL
# define BOOST_PP_SLOT_OFFSET_5(x) BOOST_PP_SLOT_OFFSET_6(x) % 10000UL
# define BOOST_PP_SLOT_OFFSET_4(x) BOOST_PP_SLOT_OFFSET_5(x) % 1000UL
# define BOOST_PP_SLOT_OFFSET_3(x) BOOST_PP_SLOT_OFFSET_4(x) % 100UL
# define BOOST_PP_SLOT_OFFSET_2(x) BOOST_PP_SLOT_OFFSET_3(x) % 10UL
#
# /* BOOST_PP_SLOT_CC_x */
#
# define BOOST_PP_SLOT_CC_2(a, b) BOOST_PP_SLOT_CC_2_D(a, b)
# define BOOST_PP_SLOT_CC_3(a, b, c) BOOST_PP_SLOT_CC_3_D(a, b, c)
# define BOOST_PP_SLOT_CC_4(a, b, c, d) BOOST_PP_SLOT_CC_4_D(a, b, c, d)
# define BOOST_PP_SLOT_CC_5(a, b, c, d, e) BOOST_PP_SLOT_CC_5_D(a, b, c, d, e)
# define BOOST_PP_SLOT_CC_6(a, b, c, d, e, f) BOOST_PP_SLOT_CC_6_D(a, b, c, d, e, f)
# define BOOST_PP_SLOT_CC_7(a, b, c, d, e, f, g) BOOST_PP_SLOT_CC_7_D(a, b, c, d, e, f, g)
# define BOOST_PP_SLOT_CC_8(a, b, c, d, e, f, g, h) BOOST_PP_SLOT_CC_8_D(a, b, c, d, e, f, g, h)
# define BOOST_PP_SLOT_CC_9(a, b, c, d, e, f, g, h, i) BOOST_PP_SLOT_CC_9_D(a, b, c, d, e, f, g, h, i)
# define BOOST_PP_SLOT_CC_10(a, b, c, d, e, f, g, h, i, j) BOOST_PP_SLOT_CC_10_D(a, b, c, d, e, f, g, h, i, j)
#
# define BOOST_PP_SLOT_CC_2_D(a, b) a ## b
# define BOOST_PP_SLOT_CC_3_D(a, b, c) a ## b ## c
# define BOOST_PP_SLOT_CC_4_D(a, b, c, d) a ## b ## c ## d
# define BOOST_PP_SLOT_CC_5_D(a, b, c, d, e) a ## b ## c ## d ## e
# define BOOST_PP_SLOT_CC_6_D(a, b, c, d, e, f) a ## b ## c ## d ## e ## f
# define BOOST_PP_SLOT_CC_7_D(a, b, c, d, e, f, g) a ## b ## c ## d ## e ## f ## g
# define BOOST_PP_SLOT_CC_8_D(a, b, c, d, e, f, g, h) a ## b ## c ## d ## e ## f ## g ## h
# define BOOST_PP_SLOT_CC_9_D(a, b, c, d, e, f, g, h, i) a ## b ## c ## d ## e ## f ## g ## h ## i
# define BOOST_PP_SLOT_CC_10_D(a, b, c, d, e, f, g, h, i, j) a ## b ## c ## d ## e ## f ## g ## h ## i ## j
#
# endif
В фильме с Нортоном показывали, как он превращается в Халка, и под ним кресло проминается.
Конечно, это тоже не стопроцентное свидетельство изменения массы, но другое объяснение дать довольно трудно (хотя одно мнение я привел выше).
Помню на одном IRC-канале высказывалось мнение, что масса у него не меняется, но резко возрастает парусность к космическим лучам. И они просто начинают очень сильно вдавливать его в землю.
В таком случае, опять-таки, просто нужно написать embedded runtime. Для С и С++ стандартные библиотеки тоже приходится переписывать, тут ничего особенного нет.
Вероятно, переписывать придется больше, чем для rust, но ничего невозможного или запредельно трудного я в этом не вижу.
Насколько я знаю D поддерживает ручное управление памятью и подсчет ссылок, так что runtime без сборщика мусора тоже можно реализовать.
Ну, отчасти вы правы. Есть ведь и embedded python и java. И даже javascript.
Другое дело, что эти языки (особенно javascript) плохо подходят по другим причинам. В embedded хочется видеть тот же С, только безопасный.
Язык D не подразумевает наличие сборщика мусора, стандартная библиотека подразумевает, как вы сами сказали. Ссылку на минимальный рантайм я уже кидал. Вот если бы в D вообще нельзя было бы удалить объект вручную, без сборщика мусора, тогда я бы с вами согласился.
Собственно, по своему (не очень большому) опыту могу сказать, что в embedded и на С стандартная библиотека нужна довольно редко. И она тоже должна быть написана специально, хотя бы из соображений экономии памяти.
Я спрашиваю потому, что сам читал книжку из комментария выше и там как основной минус Unity как раз приводилась его невозможность регистрировать новые тесты автоматически.
И мне, собственно, казалось, что на чистом С этого сделать и нельзя. Не могли бы вы рассказать поподробнее?
В частности, поэтому сам я использую cppUtest, который тоже в той книжке упоминался, в симуляторе среды Keil. На мой взгляд он не лишен проблем, в частности, ему нужно море динамической памяти и вообще для embedded он толстоват.
А почему мой вариант не подходит для embedded? Что нужно изменить?
Я планирую его запускать в отладчике, поэтому printf'ы вообще можно убрать, на самом деле. Просто, если тест не проходит — while(1){;}. И отладчик останавливается как раз на проваленном тесте, это даже удобнее, чем искать по информации из лога.
Он инклудит сам себя и файл def.hpp, который явно что-то делает, но вот только что — совершенно неясно
Конечно, это тоже не стопроцентное свидетельство изменения массы, но другое объяснение дать довольно трудно (хотя одно мнение я привел выше).
Вероятно, переписывать придется больше, чем для rust, но ничего невозможного или запредельно трудного я в этом не вижу.
Насколько я знаю D поддерживает ручное управление памятью и подсчет ссылок, так что runtime без сборщика мусора тоже можно реализовать.
Другое дело, что эти языки (особенно javascript) плохо подходят по другим причинам. В embedded хочется видеть тот же С, только безопасный.
Язык D не подразумевает наличие сборщика мусора, стандартная библиотека подразумевает, как вы сами сказали. Ссылку на минимальный рантайм я уже кидал. Вот если бы в D вообще нельзя было бы удалить объект вручную, без сборщика мусора, тогда я бы с вами согласился.
Собственно, по своему (не очень большому) опыту могу сказать, что в embedded и на С стандартная библиотека нужна довольно редко. И она тоже должна быть написана специально, хотя бы из соображений экономии памяти.
Как ни странно, у компилятора armcc (родного для keil) есть атрибут с точно таким же именем (и, вероятно, действием).
Здорово!
И мне, собственно, казалось, что на чистом С этого сделать и нельзя. Не могли бы вы рассказать поподробнее?
В частности, поэтому сам я использую cppUtest, который тоже в той книжке упоминался, в симуляторе среды Keil. На мой взгляд он не лишен проблем, в частности, ему нужно море динамической памяти и вообще для embedded он толстоват.