the requirement for pre-processing makes me a bit suspicious, it's going to be a pain to interact with other parts of the toolchain, so i would hope there's a very good reason for it. i would make this at the top of the README.md.
The same comments apply to a lesser extent to the C++14 requirement- does your framework really benefit from using C++14 features over say C++11 ? Again I would make this clear at the top of the README.
You are right. I'll make it clear in the README.
The preprocessing can be easy done by hand for those who want to skip the use of the preprocessor, it is actually pretty simple:
[...]
@test
[...]
is equivalent to:
iod_define_symbol(test, _test)
[...]
s::_test
[...]
Their is 3 reason for implementation of the @ syntax:
- Not having to pre-declare all the symbols.
- Replacing s::_ by @
- Suggesting a new simple but powerful feature to
the teams writing clang++ and g++.
And yes, silicon needs generic lambda function from C++14 . But this is less a problem since this is already in g++, clang++, and soon in the visual studio c++ compiler.
I'm too lazy/not interested enough in this to give it a try, and am not sure at all that they are powerful enough to do what you want, but have you considered using user-defined literals? The way I understand these work,
"test"@
could return an object that allows one to write
"test"@("hello"!)
The constructors called could, of course, also link that object in a global store.
The same comments apply to a lesser extent to the C++14 requirement- does your framework really benefit from using C++14 features over say C++11 ? Again I would make this clear at the top of the README.