archibate
commented
1 month ago Backgrounds
C++ has a mechanism called argument-depandent lookup (ADL). That is, when invoking unqualified free-functions on objects, the namespace within which the object is defined will be take in to account when looking up for the name of the free-function (not only lookup in the global namespace), e.g.:
namespace ns {
struct Object {};
void function(Object o) {}
}
ns::Object o;
function(o);
// equivalent to:
ns::function(o);ADL is used to achieve static polymorphism, as you may have multiple classes within their own namespaces and free-functions are placed inside namespaces, invoke only with unqualified name to achieve static dispatch.
For your problem
Thus, when vec is std::vector, begin(vec) is actually automatically deduce as std::begin(vec).
However, if vec is fixed_containers::FixedVector, then begin(vec) will first try to deduced as fixed_containers::begin.
However, it seems that they didn't define such a free-function named begin in their namespace fixed_containers. That's why the expression begin(vec) != end(vec) failed to compile when vec is fixed_containers::FixedVector, making debug_is_cond_range evaluate to false.
So, fixed_containers::FixedVector only supports accessing begin and end iterator with member functions vec.begin() and vec.end(). You may woundering why I didn't use vec.begin() != vec.end() as test expression for debug_is_cond_range, that's because I'd like to support C-style array as printable range too. std::begin and std::end supports getting starting and ending iterators (actually pointers) of const T[] arrays. And this is why C++17 range-based loops (for (auto x: arr)) syntax supports C-style arrays, which definitely have no .begin() or .end() as member functions.
Solution
Sorry! My fault for assuming all container libraries to have free-functions named begin and end in the same namespace in which their container class are defined.
The good news is, std::begin can automatically detect if the argument type are classes and have member .begin() and .end(), if they are not C-arrays.
So the solution might be changing begin(...) into std::begin, and everything will work well (including C-arrays and td::vectors), while making debug_cond_is_range compatible to libraries like fixed_containers who didn't feel like defining begin and end as free-functions.
using ComparisonFixed = decltype(std::begin(std::declval<FixedVector const &>()) != std::end(std::declval<FixedVector const &>()));
using ComparisonStd = decltype(std::begin(std::declval<std::vector<int> const &>()) != std::end(std::declval<std::vector<int> const &>()));As of constraints
Actually, debug-hpp did used C++20 concepts for checking ranges and other requirements.
The story is, debug-hpp actually have been originated from my other library co_async which is about C++20 coroutines and forcing C++20 anyway.
However, after extracted debug-hpp as an individual project, many debug-hpp users argues C++17 or even C++11 support, which means no concepts or require clause anymore.
I used to try maintain two version of debug-hpp: when C++20 detected, switch to the "concept version" and vice versa. But switching back and forth takes too much maintanance efforts and soon I end up only keeping the SFINAE version till now...
stellarpower
Hi,
Nice library; I'm having some real issues though with a container type. I'm using FixedVector from the fixed-containers library. The underlying storage has a fixed size, so
tuple_size_vis well-defined and is 0 on this type. Therefore, the print formatter is resolving it as an empty tuple, and printing out{}, instead of a std-compatible container and iterating over the elements.What has my head completely spinning though, is that the iterator functions are well-defined and working on it, but the trait for if it's a range is false. I have compared it side-by-side with std::vector:
I'm really struggling to folow the logic of what's meant to happen here.
debug_cond_is_rangeexpands towhich surely means that if debug_void<....>::type exists on both of them, the true_type version is well-defined and selected. Both are
debug_cond_is_range<T, void>, yet evidently true_type is being selected for the std::vector and false_type for the FixedVector. All whilst both have bool as the type of the iterator comparison, and both have void as the nested type.If the traits ultimately have to be specialised, I think it'd be much clearer simply to use a boolean non-type argument rather than inheriting from bool_constant. Or some clarification on what should be expected, because defaulting to void and also using it as a nested type adds some confusion. void to me indicates a failure to expand something, and so should be falsey, yet it seems it's being used as the nested type to denote success in resolving the type of the iterator comparison and so is truthy. Or, using constraints would ideally be much more readable, but I understand this would force C++20 support and so may not be acceptable.
But, is this as expected? Admittedly I'm going a bit screen-blind right now, but I'm struggling to see how the compiler is able to select a different specialisation when the comparison is well-defined and thus debug_void<....>::type is defined for both cases.
I also did this directly in the header file at the print specialisation - just in case there's some name lookup issue. Are begin/end custom, or did the std:: get missed off? I don't see a definition in the header file so that seems a potential point of difference, but still not following how they are both deduced as bool. I am using the xmake package, so on #ec10419.
Thanks!