I have some questions about things in the september 20 WP.


1) function templates

 The following is. as I understand it, illegal:

 template <class T>  T max (T a, T b) {return a > b ? a : b;}
 int max (int a, int b) {return a > b ? a : b;}

 void f (int x, int y) {max (x, y);}  // err: dupl definition of max


 In order to have a special version for ints, you have to have a
 specialization of the template (with specialization syntax):

 template <class T>  T max (T a, T b) {return a > b ? a : b;}
 int max <int> (int a, int b) {return a > b ? a : b;}

 void f (int x, int y) {max (x, y);}  // ok


 This means that:

 a) I can not discover generalities from special cases and write a
    general version, without changing the special cases that are
    still special.

 b) I can not use one vendors (or my own) templates with another
    vendors good/important/life-saving special cases (that just
    happens to be special cases of some general template).

 c) Later additions of templates may cause ripple-effects wrt syntax
    changes, even of things that are not "semantically" connected to
    the template.


 If I have got the above right, it is (to me) obvious that something
 has got to be done about this situation.


 As I understand it, "int max (int, int); " just governs the overload
 resolution, when used with templates.

 Why not make the guiding syntax "int max <int> (int, int); "?


2) name injection

 What, exactly, is name injection (wrt templates)?
 What problems do they solve (and create)?
 Could someone show a few good examples?


3) I/O library

 In a previous wp, I seem to recall some code that looked
 something like this:


 float x;
 float y;

 is >> '(' >> x >> ',' >> y >> ')';

 complex c (x, y);


 In a wild experiment in wishful thinking, I hoped that
 something to the effect of the following should be defined
 in the standard:

 template <class T)
 istream&
 operator >> (
     istream&   is,
     const T&   t) // since it is const, non-lvalues are allowed
 {
     T input;

     is >> input;
     if (input != t)
  throw naugthy_error();

     return is;
 }


 Or, at least, that this behaviour would be defined for
 the builtin types. I do not find anything about this
 in the WP, but it would be really nice if it hided in there
 somewhere.

 Is this the case?


4) "no type-specifiers" defaults to int

 I have heard that this particular rule makes a lot
 of things a lot harder. If this is true, how much
 of a fuzz (compared to the fuzz caused by the other
 non-C compatible changes) would it be to to say that
 you have to have at least one type-specifier
 (e.g. in function decls).


-----------------------------------------------------------------------------
Jonas M   ls           | Numerical Analysis and Computing Science
jbm@nada.kth.se    | Royal Institute of Technology, S-10044 Stockholm, Sweden
-----------------------------------------------------------------------------