Use __STDC_HOSTED__

[johnmcfarlane]

When it is 0, avoid streaming?

[ckormanyos]

I was unaware of this constant. The draft of the standard ISO/IEC 14882:2011 claims... __STDC_HOSTED__ The integer constant 1 if the implementation is a hosted implementation or the integer constant 0 if it is not.

[ckormanyos]

__STD_HOSTED__ Sorry about the typing mistakes.

[ckormanyos]

I just can't get this spelling right. It is what you wrote in the title.

[johnmcfarlane]

Haha, that's the markdown messing with your underscores! Try:

\_\_STDC_HOSTED\_\_ 

to get __STDCHOSTED_\ or

`__STDC_HOSTED__`

to get __STDC_HOSTED__.

[johnmcfarlane]

OK, let me know if that helps. If there std macro is zero, should just work. Otherwise, there's a macro, CNL_USE_IOSTREAM which you can set to zero in you build settings. (Not very well tested though as i don't have your embedded dev environment.)

[johnmcfarlane]

@ckormanyos are you using this macro? I forget why I add it and it's not being used correctly. It seems to me that supporting a free-standing implementation involves a lot more than just hiding the streaming operators and I don't currently know how I'd test that CNL was properly complying without researching how the new freestanding stuff works. Any input appreciated.

[johnmcfarlane]

I just dug through saw the original email thread. I've fixed this up but still wonder whether it's actually necessary. Nothing about CNL requires that you use the streaming operators. And even without them, there are plenty of other standard library features that are #included by CNL which mean it won't compile under a strict freestanding implementation with standard library headers missing.

I think a better approach might be to individually test for existence of individual source files using __has_include. Optionally, additionally, I'd want to test for individual library/language features using a combination of the feature test macros and __STDC_HOSTED__.

Finally, testing is still a big problem. Ideally, I'd like to either

• find a freestanding implementation of C++ which I can use to build and test CNL in the pipeline, or
• maybe just install the compiler without installing the standard library. However, that would be prohibitively difficult given how much of the standard library I depend on. So really, I'd prefer the former.

Thoughts? Do you know of a good way to test support for freestanding platforms in the pipeline?

[ckormanyos]

find a freestanding implementation of C++ which I can use to build and test CNL in the pipeline

I have been meaning to do more work with CNL in general. In particular, I can try to compile on some OS-less bare metal systems like AMR Cortex, etc. I should really take a deeper dive into this before commenting definitively on this issue.

Even GCC with its -ffreestanding flag does not seem to really do much change. But maybe I'm not entirely sure on that either.

If some of these ARM builds can be successful, or made to be successful, I could hopefully support the CNL effort perhaps with some of the work I am doing at the moment. My work this part of my work intends to build and run ARM deeply embedded code compiled with arm-none-eabi within Ubuntu pipelines and running on QEMU. This pipeline, for instance, is close to getting finished with that state, but just needs the verification of either a Boolean value or the return value from main.

[johnmcfarlane]

@ckormanyos that is very interesting. I may have to use that as I have plans (#811) to refresh my CI images after the new Ubuntu/GCC/Clang drop in a month or two. In the list is exploration of a project that aims to recreate the C++ free-standing environment here. Perhaps some of the command lines in the associated Dockerfiles will be of help to you.

All the best, John

[ckormanyos]

If some of these ARM builds can be successful...

I made a benchmark program that runs scaled-integer through a quadratic equation.

I did successfully run it on an ARM Cortex-M4F core in hard real time and also on QEMU and also on Segger Debugger. The results were fascinating, excellent compact code with options for compile-time constexpr evaluation if desired.

I ended up using two data types

using fixed_point_bin_type = cnl::scaled_integer<std::int32_t, cnl::power<-10>>;
using fixed_point_dec_type = cnl::scaled_integer<std::int32_t, cnl::power<-3, 10>>;

I also build the standalone benchmark on arm-none-eabi-g++ with -std=c++20 in CI here

There is really a lot of information to discuss and I will write you a detailed report on the findings, all of which were positive.