This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] Add constexpr specifiers to std::shared_ptr, std::unique_ptr, etc
> To be clear: those tests were obviously incorrect, because unique_ptr
> and shared_ptr are not literal types.
Agreed that unique_ptr and shared_ptr are not literal types.
However, those cons/constexpr.cc tests aren't testing if they are
literal types... I don't see how these tests were obviously incorrect.
Can you explain this to me please?
Shouldn't
constexpr std::unique_ptr<int> a;
work now, if indeed constexpr constexpr() is implemented?
The only use I see right now for a default-constructed constexpr
unique_ptr is to have a non-dymamically-initialized check for a "null"
unique_ptr. So I'm a bit curious about this design decision.
Anyway.
I agree with your point about the constexpr data tests: they are not
really testing constexpr data members at the moment, just static. Duly
noted. I am hoping to improve those with the scan-assembler trick Jason
suggested. Hang on, we'll get there.
-benjamin
- References:
- [v3] Add constexpr specifiers to std::shared_ptr, std::unique_ptr, etc
- Re: [v3] Add constexpr specifiers to std::shared_ptr, std::unique_ptr, etc
- Re: [v3] Add constexpr specifiers to std::shared_ptr, std::unique_ptr, etc
- Re: [v3] Add constexpr specifiers to std::shared_ptr, std::unique_ptr, etc
- Re: [v3] Add constexpr specifiers to std::shared_ptr, std::unique_ptr, etc
- Re: [v3] Add constexpr specifiers to std::shared_ptr, std::unique_ptr, etc
- Re: [v3] Add constexpr specifiers to std::shared_ptr, std::unique_ptr, etc
- Re: [v3] Add constexpr specifiers to std::shared_ptr, std::unique_ptr, etc