hideakitai / arxtypetraits Goto Github PK

When i include your library in my code it's compile but when I try to run it on Atmega 2560 suddenly board print someof the first char in my setup code

delay(2000);
Serial.begin(9600);
Serial.println("Initialize");

eth1 = new DataLinkLayer<HardwareSerial, HardwareSerial>(&Serial1, &Serial, 0xF6, 9600);
eth2 = new DataLinkLayer<HardwareSerial, HardwareSerial>(&Serial2, &Serial, 0xF7, 9600);
eth3 = new DataLinkLayer<HardwareSerial, HardwareSerial>(&Serial3, &Serial, 0xF8, 9600);
eth4 = new DataLinkLayer<SoftwareSerial, HardwareSerial>(&Serial4, &Serial, 0xF9, 9600);

sei(); // Enable interrupts

and then restart
even if i'm not calling any of your functions including your library causing the board to stop i select the code i needed from your lib and use it in my code by copy that part but i hope you can find the problem

is_base_of_v is not working as expected.

c++ is_base_of_v https://godbolt.org/z/br9PY996W works as expected, but this one doesnt detect its base of child.

I've been using this library today (rather, the one bundled with MsgPack, but that's the same as far as this issue is concerned) and ran into some issues.

In my sketch, I'm using the ArduinoSTL (uclibc++ and STL) library, which contains implementation of most of C++98 stdlibc++ (which is otherwise missing on AVR), making everything available under the standard names (e.g. <algorithm>). When I add the MsgPack.h include, this starts producing conflicts because ArxTypeTraits defines some classes and functions, which are also defined by ArduinoSTL. e.g.:

.../ArduinoSTL/src/algorithm:380:37: error: redefinition of 'template<class T> void std::swap(T&, T&)'
  template<class T> _UCXXEXPORT void swap(T& a, T& b){
.../MsgPack/MsgPack/util/ArxTypeTraits/ArxTypeTraits/type_traits.h:382:10: note: 'template<class T> void std::swap(T&, T&)' previously declared here
     void swap(T& a, T& b)

I already tried two things to work around this, without luck so far:

• I could remove all standard includes (e.g. #include <algorithm> from my code and rely on ArxTypeTraits to provide the needed declarations and implementations. However, this makes the code less portable, and more importantly does not work when using third party code (e.g. I'm also using ArduinoJson now, which also does #include <string> (which indirectly includes <algorithm> as well).
• I tried modifying ArxTypeTraits to not define anything (i.e. by removing #define ARX_TYPE_TRAITS_DISABLED) and instead letting it include standard header files (which would then include ArduinoSTL), but there I ran into the problem that uclibc++ does not offer <tuple>, since that was added in C++11.

One way to fix this seems to be to let ArxTypeTraits offer the functionality under the proper header names, e.g. let it actually have a file called algorithm. This does have some downsides:

• If it does not implement everything that that header should implement, then any other users of the same header might end up missing things.
• This can be somewhat worked around by using e.g. ArduinoSTL instead, and putting it earlier in the include path (by including it before ArxTypeTraits in the .ino file), but then you'd again end up missing C++11 bits (for e.g. <tuple>, this would work because ArduinoSTL does not offer the file at all, so the include would fall through to ArxTypeTraits, but for other stuff, like std::enable_if_t, that was added to existing header files, this would not work.
• This is also a bit tricky to combine with the approach of including ArxTypeTraits in other libraries that need it, since it would end up in the util subdirectory and not on the include path (but given it is a header only library and uses #ifndef header guards, it could maybe work in this case to just include the library twice: Once bundled in e.g. MsgPack, and once as a standalone library, as long as the libraries define the same things, that should be ok).

Another way I can imagine might work, is to tell ArxTypeTraits about what parts of libstdc++ are (not) available. Right now, it assumes that on a few Arduino architectures, libstdc++ is completely unavailable, and defines parts of it itself, and everywhere else it assumes that libstdc++ (C++11 always, newer versions depending on the __cplusplus macro). I'm ignoring the handling of new.h now, which I think might need fixing separately.

It could help if we could just use ArduinoSTL and then tell ArxTypeTraits (e.g. through a macro or so) that libstdc++98 is available, letting it just include the standard header files, and defining only the things that were added in c++11 and later. This might still end up being somewhat problematic (since I think ArduinoSTL currently defines some things from c++11 but far from everything), but it might be a good place to start.

For now, this is not blocking me since I can test on other platforms than AVR for a while, but I might end up trying the latter approach at some point.