Re: Are homonymous non-template and template classes incompatible?

Barry Kelly wrote:
  > "kanze" <kanze@gabi-soft.fr> wrote:

  >> Sylvain GUILLEY wrote:

  >>> template<typename T> struct my_class: my_class // Implementation
  >>> {
  >>> void do_it() {}
  >>> };
  >>> my_class<int> my_obj; // Object instanciation
  >> And how on earth is the reader of the code -- compiler or human
  >> being -- supposed to know which one is meant where?

  > This idiom, deriving a generic class from an abstract class of
  > the same name is somewhat common in C# and the .NET world. In
  > C#, type names are overloaded based on the number of generic
  > type parameters they accept, in much the same way that as C++
  > function templates can be overloaded on the basis of the
  > number and kind of template parameters.

Sounds like an argument against C#. But I suppose you're not
forced to use the "feature".

  > For example:

  > ---8<---
  > #include <iostream>

  > template<typename T1>
  > void f()
  > {
  > std::cout << "T1\n";
  > }

  > template<typename T1, typename T2>
  > void f()
  > {
  > std::cout << "T1, T2\n";
  > }

  > int main()
  > {
  > f<int>();
  > f<int,int>();
  > }
  > --->8---

That's not function overloading -- and it only works in a few
special cases in C++, as a side effect of other rules. And of
course, no programmer would ever actually write something like
that, except as intentional obfuscation.

  >>> Is this a limitation of the compiler or of the C++ language?

  >> It's more along the lines of a basic principle common to just
  >> about every modern language -- in a given context, a symbol
  >> has one, and only one meaning. (In the case of C++, there
  >> are a few strange exceptions, for reasons of C compatibility.
  >> But they don't affect this example in any way.)

  > A symbol may have one semantic meaning, but that doesn't rule
  > out overloaded identifiers as a useful language construct.

Within certain, very constrained limits. It's also a very
powerful tool for obfuscation.

One of the most essential limits is that the overloads all
concern the same sort of things: in C++, for example, you can
overload functions, but you cannot overload a function with a
variable. I could more or less see some sort of reasoning to
accept overloading templates ... say rather than partial
specialization, allowing two class templates with the same name
to have a different number of parameters. But overloading
templates and non-templates. That seems carrying things way too
far.

  >>> My opinion is that if the compiler parser was able to cope
  >>> with the syntax, then the generated code would be supported by
  >>> any linker because of the different mangling of non-template
  >>> and template homonymous classes.

  >> And if pigs had wings, they could fly. How on earth could
  >> the compiler parser possibly cope with this? For that
  >> matter, how on earth could a human reader cope with it?

  > It's not difficult when you get used to it. It's a common
  > mistake in the C# world for people to confuse a generic type
  > T<P> with T, when the two are completely different things with
  > no relationship - just like the two functions above are two
  > different things with no relationship.

The problem is that you then have ambiguities in interpreting
the <. In C++, it's clear: if the token preceding the < is the
name of a template (or the keyword template), the < opens a
template parameter list; otherwise, it is less than. What's the
rule here? (Note that this is already a weakness in C++: the
role of a symbol is context dependant. And it doesn't improve
the readability of C++ programs.)

  > Because two sibling generic type instantiations in C# have no
  > type-system relationship (you need to dig into reflection to
  > establish any commonality between List<int> and List<string>,
  > for example), a common way to link the whole set of all
  > possible instantiations of a generic type together for
  > polymorphic and virtual dispatch reasons is to derive from a
  > common, non-generic type. It's then natural to name the common
  > non-generic base class as the generic's name, without the type
  > parameters.

It sounds like a recepe for obfuscation to me. What's wrong
with AbstractMyTemplateClass, or MyTemplateClassBase? Works for
me.

--
James Kanze kanze.james@neuf.fr
Conseils en informatique orient?e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]