"Roly Perera" <rolyp@private.nethead.co.uk> wrote:

>Since non-type template args must have external linkage,

What!? What about:

  template <int i>
  class x { ... };

  x<5> y;

Since the literal, 5, doesn't have external linkage, is the above
illegal?

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

phalpern@truffle.ma.ultranet.com (Pablo Halpern) writes:

>"Roly Perera" <rolyp@private.nethead.co.uk> wrote:
>
>>Since non-type template args must have external linkage,
>
>What!? What about:
>
>  template <int i>
>  class x { ... };
>
>  x<5> y;
>
>Since the literal, 5, doesn't have external linkage, is the above
>illegal?

No, the above is legal.  Only non-type template args of pointer or
reference type need to have external linkage.  Non-type template args
of integer, enumeration, or pointer-to-member type don't need to
have external linkage.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Pablo Halpern <phalpern@truffle.ma.ultranet.com> wrote:

> "Roly Perera" <rolyp@private.nethead.co.uk> wrote:
>
> >Since non-type template args must have external linkage,
>
> What!? What about:
>
>   template <int i>
>   class x { ... };
>
>   x<5> y;
>
> Since the literal, 5, doesn't have external linkage, is the above
> illegal?

Sorry - non-type POINTER or REFERENCE template args must refer to objects
with external linkage.  Int/enum literals are OK.

Roly Perera
----
Interactive Computers Ltd
3 Cumberland Road
Acton
London  W3 6EX
Phone: +44 (956) 414 395
Phax:  +44 (181) 932 2490
Email: rolyp@private.nethead.co.uk
----
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>> I wonder why it is not a logical thing to allow the treatment of names
>>> in templates as identifiers, or general compile-time strings; e.g.
>>>
>>> template<class T>
>>>  class List {
>>>      T data;
>>>       ...
>>>      void T##List();     // a method name derived from instance type
>>>      T& #T() { return data; }   // another
>>>      void error()
>>>           { cerr << "error in T##List\n" ; }
>>                                ^^^^^^^ I believe this will not work.
>>>     }
>>>
>>> Particularly, the ability to have specialized errors, logs, etc. from
>>> each instance type would seem useful.
>>
>> If you want this, add just a string to the container. And fill it in at
>> construction time. That way you get really customized error logs (a name
>> pro instance).
>
> If all you want is specialized error messages you could try using RTTI if
> your compiler supports it, that would give you the name of the class as a
> string.

Both the proposed solutions have disadvantages.  Adding data members and
constructor params unnecessarily encumbers the templated class; RTTI is
usually pretty messy.  The easiest way to add customised error messages to
a template class is via a non-type parameter, e.g.:

template <class T, const char* szMessage>
class X
{
 const char* GetMessage () {return szMessage;}
 // etc;
};

const char* const szMsg1 = "int error message";
const char* const szMsg2 = "float error message";

X<int,szMsg1> x1;
X<float,szMsg2> x2;

That way you get a simple class, and no run-time type queries.

Roly Perera
----
Interactive Computers Ltd
3 Cumberland Road
Acton
London  W3 6EX
Phone: +44 (956) 414 395
Phax:  +44 (181) 932 2490
Email: rolyp@private.nethead.co.uk
----
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Roly Perera" <rolyp@private.nethead.co.uk> writes:

>constructor params unnecessarily encumbers the templated class; RTTI is
>usually pretty messy.

What's messy about it?
`typeid(foo).name()' doesn't seem very messy to me.

>That way you get a simple class, and no run-time type queries.

A good implementation should be able to resolve the "run-time" type queries
at compile time if the type is known.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Just noticed a mistake in my last posting:

> template <class T, const char* szMessage>
> class X
> {
>  const char* GetMessage () {return szMessage;}
>  // etc;
> };

Since non-type template args must have external linkage,

> const char* const szMsg1 = "int error message";
> const char* const szMsg2 = "float error message";

should've been:

    extern const char* const szMsg1 = "int error message";
    extern const char* const szMsg2 = "float error message";

(or the pointers could've been non-const).

> X<int,szMsg1> x1;
> X<float,szMsg2> x2;
>
> That way you get a simple class, and no run-time type queries.

Roly Perera
----
Interactive Computers Ltd
3 Cumberland Road
Acton
London  W3 6EX
Phone: +44 (956) 414 395
Phax:  +44 (181) 932 2490
Email: rolyp@private.nethead.co.uk
----



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <NEWTNews.837126114.15331.guthrie@csgrg.mum.edu>,
 <guthrie@miu.edu> wrote:
>> > I wonder why it is not a logical thing to allow the treatment of names
>> > in templates as identifiers, or general compile-time strings; e.g.
>> >
>> > template<class T>
>> >  class List {
>> >      T data;
>> >       ...
>> >      void T##List();     // a method name derived from instance type
>> >      T& #T() { return data; }   // another
>> >      void error()
>> >           { cerr << "error in T##List\n" ; }
>
>[...] the question was not about the preprocessor.
>
>It can easily be rephrased in terms of another symbol; T%%List.
>  then the user would say:
>       List<int> il;
>       il.intList();
>
>     and if this list was manipulated polymorphically,
>        it could give errors like: "Error in intList"

What if it's a list of pointers to int?  Allowing template parameter
names to create an identifier is not a good feature IMO because it's
not a general solution -- it only works for simple type names.

>A later suggestion was to have the user manually pass this information
>at construction time;
>  I think this is not optimal, it is a manual redundant specification
>at run-time, which could be automated by the compiler.

I agree, though it might be useful if the user wants to be more
specific than what a type name allows: "Error accessing List<Age>"
instead of "Error accessing List<int>" (remember, if Age is typedef'd
to an int templates treats it exactly as an int).

>Similarly for RTTI; Yes, it can be done, but is messy, user redudnant,
>and run-time.

Why is it messy or redundant?

 template<class T>
 T Stack<T>::pop() {
    if (_size==0)
       cerr << "Popping empty stack of " << typeid(T).name() << endl;
    //...

The only problem I see with this is that I don't think
type_info::name() is guaranteed to return a displayable string, but
that's a general problem with type_info and I think most
implementations do provide a displayable string.

>My original question was suggesting that the information of type
>specilization of a template class "should" be available in the compile
>time environment of the program, static names, strings, etc.

Since the utility of this feature seems to be in debugging messages as
opposed to production code, I think type_info::name() is "good 'nuf".
Remember, C/C++ doesn't provide a way to get the name of the current
function, either (though __FUNCTION__ is an extension on some
compilers).  It sems like that would be at least as useful as template
parameter names, and having one without the other is inconsistent.

Jamshid Afshar
jamshid@io.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I wonder why it is not a logical thing to allow the treatment of names
in templates as identifiers, or general compile-time strings; e.g.

template<class T>
 class List {
     T data;
      ...
     void T##List();  // a method name derived from instance type
     T& #T() { return data; } // another
     void error()
          { cerr << "error in T##List\n" ; }
    }

Particularly, the ability to have specialized errors, logs, etc. from
each instance type would seem useful.

I just used the existing pre-processor operators to string-ize the
type name.

I suspect that this, like so many other ideas, has been proposed and
considerd, but am interested in the conclusions.

Thanks.
gregory guthrie
guthrie@mum.edu
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi gregory,

guthrie@miu.edu wrote:
>
> I wonder why it is not a logical thing to allow the treatment of names
> in templates as identifiers, or general compile-time strings; e.g.
>
> template<class T>
>  class List {
>      T data;
>       ...
>      void T##List();     // a method name derived from instance type
>      T& #T() { return data; }   // another
>      void error()
>           { cerr << "error in T##List\n" ; }
                                ^^^^^^^ I believe this will not work.
>     }

You seem to forget that the preprocessor is run *before* compilation. So
instantiating

  List<int> intList;

won't change the member "void T ## List()" into "void intList()" but in
"void TList()".

You could do something as ugly as:

  #define T Int
  #include "List.h"   // here is all of your template
  // class def should read: template<class T> T ## List { ... };
  #undef T
  typedef TypeIntList<int> IntList;

But this is all very dubious. One major reason for templates were to
remove the need for macros. And you are bringing them in again.

>
> Particularly, the ability to have specialized errors, logs, etc. from
> each instance type would seem useful.

If you want this, add just a string to the container. And fill it in at
construction time. That way you get really customized error logs (a name
pro instance).

Bye,
  Dirk


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

guthrie@miu.edu writes:

> I wonder why it is not a logical thing to allow the treatment of names
> in templates as identifiers, or general compile-time strings; e.g.

The tokens # and ## are handle by the preprocessor, the compiler
itself never gets such a symbol.

> Particularly, the ability to have specialized errors, logs, etc. from
> each instance type would seem useful.

Nothing prevents you from specializing templates for specific
types. You can even define a preprocessor macro for specializing it
and defining whatever specific methods you wish.

I myself would do that by subclassing the standard template,
though...

--
Alexandre Oliva
oliva@dcc.unicamp.br
Universidade Estadual de Campinas, S=E3o Paulo, Brasil


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <31DD53A9.729D@rz.hu-berlin.de>,
Dirk Bonne <h0444xiv@rz.hu-berlin.de> wrote:
>guthrie@miu.edu wrote:
>>
>> I wonder why it is not a logical thing to allow the treatment of names
>> in templates as identifiers, or general compile-time strings; e.g.
>>
>> template<class T>
>>  class List {
>>      T data;
>>       ...
>>      void T##List();     // a method name derived from instance type
>>      T& #T() { return data; }   // another
>>      void error()
>>           { cerr << "error in T##List\n" ; }
>                                ^^^^^^^ I believe this will not work.
>>     }
>>
>> Particularly, the ability to have specialized errors, logs, etc. from
>> each instance type would seem useful.
>
>If you want this, add just a string to the container. And fill it in at
>construction time. That way you get really customized error logs (a name
>pro instance).

If all you want is specialized error messages you could try using RTTI if
your compiler supports it, that would give you the name of the class as a
string.

Dave
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In Article<31DD53A9.729D@rz.hu-berlin.de>, writes:
> guthrie@miu.edu wrote:
> >
> > I wonder why it is not a logical thing to allow the treatment of names
> > in templates as identifiers, or general compile-time strings; e.g.
> >
> > template<class T>
> >  class List {
> >      T data;
> >       ...
> >      void T##List();     // a method name derived from instance type
> >      T& #T() { return data; }   // another
> >      void error()
> >           { cerr << "error in T##List\n" ; }
>                                 ^^^^^^^ I believe this will not work.
> >     }
>
> You seem to forget that the preprocessor is run *before* compilation.
-- Yes it is, but that was not my point,
the idea was presented in a simple manner just to convey the goal.
Clearly the pre-processor is an anachronism anyway,
so we can define the language to work any way we want (within
pragmatics..), So the question was not about the preprocessor.

It can easily be rephrased in terms of another symbol; T%%List.
  then the user would say:
       List<int> il;
       il.intList();

     and if this list was manipulated polymorphically,
        it could give errors like: "Error in intList"

A later suggestion was to have the user manually pass this information
at construction time;
  I think this is not optimal, it is a manual redundant specification
at run-time, which could be automated by the compiler.

Similarly for RTTI; Yes, it can be done, but is messy, user redudnant,
and run-time.

My original question was suggesting that the information of type
specilization of a template class "should" be available in the compile
time environment of the program, static names, strings, etc.

Yes, there are ways to get around it.. Reminds me of doing OO
programming in a non-OO language, can be done, but not too well, the
proverbial "semantic-gap".

>  One major reason for templates were to
> remove the need for macros. And you are bringing them in again.
-- No, I am asking templates to do it; not the (weak) macro
preprocessor.

gegory guthrie
guthrie@Mum.edu
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]