0

please see the following code:

namespace std {
    template <std::size_t I, class T>
    auto& get(my_tuple_like_type<T>& t)
    {
        std::size_t ext = t.template extent<I>(); // This line
        // .... do something with ext and return
    }
}

As you can see, I'm trying to specialize (overload) std::get to make my own class template my_tuple_like_type somewhat std::tuple-like.

But gcc 5.4.0 complains that the constant I is not a type name. It seems that the reason is there is already a name std::extent which is a class template.

A workaround I can think of is to forward the call to a free-standing implementation function declared outside namespace std. But I wonder, is this the right behavior according to the standard? Or is it just another bug of gcc?

I guess this should be a bug, since clang and MSVC both compile the above code just fine. On the other hand, Nvidia's CUDA compiler (nvcc) produces a similar error message.

Thank you.

EDIT:

Providing overloads inside namespace std is forbidden (Should you overload swap in the std namespace?), so I was doing a wrong thing.

But I can't see potential problems this may induce. Is there any reason why overloadings on user-defined types are forbidden?

Community
  • 1
  • 1
Junekey Jeon
  • 1,496
  • 1
  • 11
  • 18
  • 3
    Why are you breaching `std`? To do so leaves your program with undefined behavior officially. You should put your class in a namesapce, add a `my_namesapce::get` function, and let ADL do the rest. – StoryTeller - Unslander Monica Apr 26 '17 at 10:06
  • @StoryTeller AFAIK, specializing templates in std with respect to my own type is OK. For example, ``std::iterator_traits`` is even intended to be specialized by users, isn't it? – Junekey Jeon Apr 26 '17 at 10:08
  • 1
    @JunekeyJeon I was about to reply the same thing to StoryTeller, but this is actually an overload, not a specialization, so UB indeed. – Quentin Apr 26 '17 at 10:10
  • @Quentin Hmm, but it is then impossible to customize the behavior of ``std::get`` when dealing with user-defined class templates, so I think this must be permitted..., and I don't think the standard indeed banned this. – Junekey Jeon Apr 26 '17 at 10:14
  • 3
    @JunekeyJeon - [It very much bans it](http://eel.is/c++draft/namespace.std#1). Adding an overload falls under adding definitions. Specialization is a different beast. – StoryTeller - Unslander Monica Apr 26 '17 at 10:18
  • 1
    It's forbidden because standard library implementors may need to introduce helper classes/functions to implement standard behavior. And the standard committee doesn't want to limit them in pursuing good clean efficient implementations. Other than the public names defined for namesapce std, all other identifiers within are reserved to the implementors. – StoryTeller - Unslander Monica Apr 26 '17 at 10:32
  • @JunekeyJeon - the trick is to not overload a template function in namespace `std`. See if you can get the behaviour you need using a `std::tuple`, rather than implementing your own tuple type. That way, among other things, you won't need to mess around trying to overload a function from namespace `std`. – Peter Apr 26 '17 at 10:35
  • @StoryTeller Thank you very much, but i can't understand how what you said is related to prevention of providing overloads for user-defined types.. – Junekey Jeon Apr 26 '17 at 10:38
  • @JunekeyJeon - Because you cannot know if the implementor uses their own `my_tuple_like_type` in any way shape or form, or how names in your implementation will be resolved inside namespace std (this is precisely why your error occurs, btw). – StoryTeller - Unslander Monica Apr 26 '17 at 10:41
  • @StoryTeller Okay, I understand something may become wrong with unqualified identifiers, but how about fully qualified identifiers? And it is still unclear to me if resolving ````extent```` in ````t.template extent```` to ````std::extent```` is right.... What should happen if I change ````std```` to some other namespace containing a template class ````extent````? GCC still thinks ````extent```` is not a member of ````t````.... – Junekey Jeon Apr 26 '17 at 16:51

0 Answers0