Closed TinyTinni closed 11 months ago
Wouldn't be better to solve the compatibility problems? I would rather remove the non CNTTP approach at all as it was all hack around incomplete compilers. Can you elaborate more about the problem you are facing?
Hi, Thanks for the answer. I would agree, removing the compatibility problem would be easier.
There is a library (CTVE - Issue Link I also talked a bit in private with the creator already) which generates strings for CTRE, just using functions instead of regex strings.
The problem is, that those generated strings are not compatible anymore with ctll::fixed_string
, which are now required by CNTPP, as much as I understand. They are not compatible, as ctll::fixed_string is just constructable using a C array type. CTVE saves the strings in an std::array<CharT, N>
.
I tried to fix and add a conversion method, but nothing really reliable + lots of code changes.
If you have any idea, on how to convert a constexpr std::array<char, N>
-> ctll::fixed_string<N>
, I would be glad and should have asked this question first.
As you already mentioned, that this is not the way into the future, which is absolutely understandable, please feel free to close the issues. I just thought, as this literals seems to be optional, that there might be some interest. 😃
Thanks.
This should be easy. I will look into it.
Try it now.
Oh thanks, I didn't mean that I needed exactly a std::array constructor, but it will definatly help.
I described the problem maybe a bit too rough. CTVE has a ctve::pattern, which contains a ctve::basic_string which is basically a std::array
Having a std::array constructor might help, when I can add an implicit conversion from ctve::basic_string to the now easily constructable std::array. I tried it some days ago a implicit conversion of ctve::basic_sring -> fixed_string over a fixed size C array, but something went wrong (I cannot remember exactly if the constructor was wrong or the implicit cast/construction). I will re-try it tomorrow with the new constructor or the pointer constructor, so that a ctll::fixed_string can be implicit constructed from a ctve::basic_string and so that not every ctve expression needs an explicit conversion step.
Thank you really much for the help.
You can also invoke ctll::fixed_string<N>(ctll::construct_from_pointer, ptr)
where ptr
is just const char *
You can also invoke ctll::fixed_string
(ctll::construct_from_pointer, ptr) where ptr is just const char *
This is exactly what I will try. std::array might be too problematic with N and N+1
Adding something like
template<size_t N>
class static_string{
std::array<char, N+1> m_data;
//...
// new conversion function:
constexpr operator ctll::fixed_string<N>() const{
return ctll::fixed_string<N>(ctll::construct_from_pointer{}, m_data.data());
}
//
};
not sure if it works
edit: const/constexpr
Works perfect, thank you ❤️
Btw totally unrelated, maybe it would be easier for the CTVE to just generate underlaying template CTRE is evaluating defined in include/ctre/atoms.hpp
Hi, currently, I try to build my projects with activated C++20.
Sadly, it doesn't work directly, as "CTRE_CNTTP_COMPILER_CHECK" gets activated which yields to some compatibility problems (in detail, there are conversion problems, as a custom object cannot be used to construct a ctll::fixed_string).
Therefore, I wanted to manually disable the new and shiny feature with pre-setting "CTRE_CNTTP_COMPILER_CHECK=0".
This works well, as long as the CTRE literals stays deactivated. When I activate literlals, the compiler cannot find
ctre::regular_expression
.But because it is such a new and shiny compiler with C++20 support, it gets auto activated.
Therefore, is there a possibility to deactivate auto-enable of CTRE_ENABLE_LITERALS?
Or would you think, that this is ok to add to the project? Something like CTRE_DISABLE_LITERALS in literals.hpp?
Or is there another solution to achieve the "old"-behaviour?
Info: Compiler is MSVC 17.6 with C++17/20 activated.