AVR, round trips, and who wants 64-bit floats on an 8-bit MCU...

[malachib]

Continuation of #11

[malachib]

OK, firstly @jk-jeon -- what does "shortest-roundtripping formatting and the latter does fixed-precision one" mean? I presume we're not talking 9000000000 places because it can't find a floor, round, ceil, etc. But... what is it?

Secondly, there are ways of detecting AVR toolchain. There's a conversation to be had about making a soft dependency on estdlib. The last thing we want to do is couple you to an embedded environment. I agree 100% uglifying your code is to be strongly resisted.

What I was gearing up to do when I was debating importing your lib into estd was to detect the presence of AVR/GCC (which estdlib already helps with) and then alias out memcpy, uint32_t and the few others you call out to std for. Reasoning is this: if the platform doesn't support std namespace anyway, then there's no harm in detecting than and aliasing it exactly. I do this with some constituents already and "the audience seems to like it".

I definitely missed some details with 64-bit support. Imagine that... you, the floating point expert, founds things I didn't! :) I'll try to save my skin and fast forward to yes... let's not do 64-bit for now.

I missed the bit_cast, that particular one I haven't put into estd yet. In a pinch sometimes I copy, paste and adapt from LLVM source. I won't claim it's the cleanest code. I did that with a lot of type_traits and even std::forward! It gets the job done!

[jk-jeon]

I think for some other reason (related to #63) I will probably just hard-code the entries for the small table, which removes the necessity of reading entries from the big table in compile-time.

Still, I need to keep things constexpr when compiled with C++20+ (that's a promise I want to keep for the next release), so you may need to do something with your pgm_array to claim conformance. In case you weren't aware of, you can do branching on whether or not the function is called in a constexpr context by either doing if (std::is_constant_evaluated()) (C++20+) or doing if consteval (C++23+).

The thing is, afaik according to the current spec, if a function template is marked constexpr, then not every specialization of it needs to be constexpr, and there just need to exist at least one specialization of it which is indeed constexpr, even though such a specialization does not need to be materialized. If there is no such specialization, it's UB. So, as long as there is a "theoretical" specialization that is constexpr, then "actual" specializations that are really used don't need to be constexpr (plz correct me if I'm wrong). Of course in that case those "actual" specializations can't be used for computing constexpr variables though.

The point is, though my to_decimal and others are marked as constexpr, it can still call pgm_array::operator[] even if it's not constexpr, but in that case there must exist a template specializations to_decimal and others that avoid any usages of pgm_array::opereator[], although those specializations don't need to be the one that users end up actually calling. Otherwise, it's technically UB. Nevertheless, I am pretty sure no compiler will try to actually diagnose and complain or do anything nasty even if I don't provide such a specialization, and I don't plan to provide such a specialization just to avoid this hypothetical issue.

In case it wasn't clear, I am merely pointing out a theoretical issue that is probably irrelevant in practice, but still it's good to be aware of. What I mean is that the following is technically UB, but every compiler will probably just compile it fine:

template <class T>
struct A {
    void f() {}
};

template <class T>
constexpr void call_f(A<T> a) {
    a.f();
}

(https://godbolt.org/z/e54M4nqxf)

Note that a.f() is not constexpr so it's illegal to unconditionally call it in a constexpr function, but the compiler doesn't complain because call_f is a template. In effect, what happens here is that the constexpr marker is just silently ignored. As I said this is UB in theory, but probably will not cause any problem in practice.

Which means, even if you don't do anything on pgm_array, it will probably just work fine after I replace the metaprogramming I mentioned earlier into a hard-coded array (of course then the user can't call Dragonbox in compile-time when pgm_array is used), but it's technically UB which is worth to be aware of and warn about.

Once again, thanks a lot for helping me. Investigating this AVR porting issue led me to not only better overall design of the library but also to many optimization ideas.

[Alcaro]

Well ackshually, that code is 100% legal C++, compiler is not allowed to complain or otherwise treat it as UB. You can specialize A<> into something where f() is constexpr, which can then form the required constexpr-legal specialization. https://godbolt.org/z/ojMqrT898

Your actual point stands, though. I've never seen any compiler try to enforce that 'a constexpr codepath must exist' thing, and there's no valid reason to. (And unless you want to solve the halting problem, you'll have to accept some false-positive errors.)

[jk-jeon]

@Alcaro I can add a compatible specialization later on, yes, but since there is none at the point of compilation (at least in this TU) I think the code is UB as-is. But yeah, as you pointed out it's in general impossible to check it and there is no actual benefit of trying to check it either.

[malachib]

I think for some other reason (related to #63) I will probably just hard-code the entries for the small table, which removes the necessity of reading entries from the big table in compile-time.

Bummer, but you gotta do what you gotta do!

Still, I need to keep things constexpr when compiled with C++20+ (that's a promise I want to keep for the next release), so you may need to do something with your pgm_array to claim conformance. In case you weren't aware of, you can do branching on whether or not the function is called in a constexpr context by either doing if (std::is_constant_evaluated()) (C++20+) or doing if consteval (C++23+).

Do you mean if constexpr(std::is_constant_evaluated())? In any case, a fascinating suggestion. Might go a long way to addressing the AVR pgm-hates-constexpr scenario.

The thing is, afaik according to the current spec, if a function template is marked constexpr, then not every specialization of it needs to be constexpr, and there just need to exist at least one specialization of it which is indeed constexpr, even though such a specialization does not need to be materialized. If there is no such specialization, it's UB. So, as long as there is a "theoretical" specialization that is constexpr, then "actual" specializations that are really used don't need to be constexpr (plz correct me if I'm wrong). Of course in that case those "actual" specializations can't be used for computing constexpr variables though.

The point is, though my to_decimal and others are marked as constexpr, it can still call pgm_array::operator[] even if it's not constexpr, but in that case there must exist a template specializations to_decimal and others that avoid any usages of pgm_array::opereator[], although those specializations don't need to be the one that users end up actually calling. Otherwise, it's technically UB. Nevertheless, I am pretty sure no compiler will try to actually diagnose and complain or do anything nasty even if I don't provide such a specialization, and I don't plan to provide such a specialization just to avoid this hypothetical issue.

If I understand your meaning here, that all makes sense. Since constexpr demands a function CAN be compile time resolved, but not that it MUST.

Once again, thanks a lot for helping me. Investigating this AVR porting issue led me to not only better overall design of the library but also to many optimization ideas.

It's a fun journey, and I get a lot of it too. The proof is that I keep coming back for more despite life shenanigans :)

[jk-jeon]

Bummer, but you gotta do what you gotta do!

I'll get back to you when I do so. It will be very helpful for me if you can test things out again after that.

Do you mean if constexpr(std::is_constant_evaluated())?

No, if (std::is_constant_evaluated()) is correct; i.e., it is in principle a runtime branch which would be elided by the optimizer. You can find many info about why it works like that in the Internet. But honestly, in my humble opinion std::is_constant_evaluated() was just a complete misfeature which fortunately got replaced by a much saner if consteval in C++23. Its sole meaning of existence is that if consteval doesn't exist in C++20.

If I understand your meaning here, that all makes sense. Since constexpr demands a function CAN be compile time resolved, but not that it MUST.

More or less yes. It sounds like you will constexpr-ify your pgm_array some day so I guess there will be no further issue.

It's a fun journey, and I get a lot of it too. The proof is that I keep coming back for more despite life shenanigans :)

Thanks! I will probably pawn off my CMake and platform testing homeworks on you at some point in the future lol
(Un)fortunately I am quite loaded with other things to do right now.

[Alcaro]

Shouldn't I anyway not include C++ standard headers, as they don't exist

Sounds like a job for __has_include (standard since c++17, gcc extension before that).

e: oh, that's how those discussions work. It was supposed to be a response to the above, not freestanding. (Not gonna delete and repost, that'd spam email subscribers.)

[jk-jeon]

Hehe I did the same mistake