Brian Parker wrote:
[...]
> However, the example goes on to state that if Z had been
> instantiated with an int, then g(1) would become type-dependent and hence
> the example would be well-formed. My understanding was that g(T(1)) would be
> required to make g(1) type-dependent. Earlier in the example, three ways a
> function call can be type-dependent are listed and the second seems to imply
> that g(1) is
> type-dependent for T an int. The third is a (non-template) example that in a
> template class would seem to me not to be type-dependent.

It's an editorial mistake. (Fortunately ;-)

[...]
> ---------
> Page 18-15 Sec 18.5.1 Clause 7 defines type_info::name() as
> implementation-defined, so a conforming implementation could simply return a
> null string for all types, effectively making name() unusable. Ideally, it
> should be defined to return the type name in some canonical form e.g. a
> fully-qualified elaborated type-id with no redundant spaces (although e.g.
> pointer non-type template parameters would require further specification).
[...]

Agreed.

 Daveed
---
[ 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 all,
I have been browsing the December 1996 draft standard and have jotted down
some notes on areas that were unclear to me. If anyone has any comments on
these notes (particularly where I have just misunderstood the draft), I
would be grateful to hear them before I submit this as an official comment.
Thanks.
(BTW does anyone know if ANSII accepts comments from outside the US?)

Re: Comments on December 1996 Draft C++ standard.
Brian Parker (bparker@gil.com.au)
----------------------------------------------------------------------------
-----
Page 14-22 Sec 14.6.2 Clause 2 has an example
 template<class T> class Z {
 public:
  void f() const {
     g(1);
  }
 };
 void g(int);

and states that this is ill-formed because g(1) is not type-dependent and so
is looked up at template definition. This is confirmed in an example in Sec
14.6.3. However, the example goes on to state that if Z had been
instantiated with an int, then g(1) would become type-dependent and hence
the example would be well-formed. My understanding was that g(T(1)) would be
required to make g(1) type-dependent. Earlier in the example, three ways a
function call can be type-dependent are listed and the second seems to imply
that g(1) is
type-dependent for T an int. The third is a (non-template) example that in a
template class would seem to me not to be type-dependent.
----------------------------------------------------------------------------
-----
Page 14-26 Sec 14.6.5 Clause 2 and footnote 126 states that a friend
declaration in a template class does not inject the name into any scope. It
then gives an example of a = gcd(a,b) and states that gcd is looked up
inside number<double> by the argument-dependent lookup rules in 3.4.2. By my
reading, however, 3.4.2 states that lookup starts in the enclosing
namespace, not inside the template class.
----------------------------------------------------------------------------
------
Page 14.30 Sec 14.7.2 gives examples with two syntaxes for an explicit
instantiation of a template function where all the arguments can be deduced i.e.
 template void sort(Array<char>&); or
 template void sort<>(Array<char>&);
Are these equivalent by design?
This same issue arises in explicit specialization Sec 14.7.3
----------------------------------------------------------------------------
--------
Page 5-23 Sec 5.9 Clause 2 describes how comparing two (non-null/ non-void)
pointers converts them to a composite pointer type similar to one of them,
but doesn't state which one. I think this should state that it is the
pointer that has an implicit conversion from the other one (if it exists).
----------------------------------------------------------------------------
---------
Page 3-20 Sec 3.5 Clause 6
In the example, why does extern int i have external linkage and not the
internal linkage of the earlier static i definition?
----------------------------------------------------------------------------
---------
Page 18-15 Sec 18.5.1 Clause 7 defines type_info::name() as
implementation-defined, so a conforming implementation could simply return a
null string for all types, effectively making name() unusable. Ideally, it
should be defined to return the type name in some canonical form e.g. a
fully-qualified elaborated type-id with no redundant spaces (although e.g.
pointer non-type template parameters would require further specification).
This would allow name() to be used to label types in a persistence library
(e.g. a recent Microsoft
Systems Journal described such a library). Failing this, I think that at
least name() should be defined to return a unique string for each type to
allow type_info to be used as a hook to further user-defined type
information (as envisaged by Dr Stroustrup in D&E.)
In D&E page 318, it is suggested that typeid(*p).name() or &typeid(*p) could
be used as an index into a map for this purpose, but currently neither
expression is defined to be unique for different types.
----------------------------------------------------------------------------
-----------
Page 14-34 Sec 14.7.3 Clause 16
The example isn't of a member template as stated.
----------------------------------------------------------------------------
-----------
Various trivial editorial changes:
Grammar page A-5: There are two identical id-expression productions.
Page 5.79 Sec 5.2.7 Clause 9: last two dynamic casts in void g() should be
from &d not &dr.
Page 14-26 Sec 14.6.4.2: "not just considered" to "not just considering".
Page 14-34 Sec 14.7.3 Clause 16: "specialized class is not be" to "
specialized class is not".
Page 14.34 Sec 14.8 Clause 2 "Each function template" to "each function
template specialization".
Page 14-41 footnote 128: "non-teplate" to "non-template"
Page 13-24 Sec13.6 Clause 15: There is no footnote 123.
----------------------------------------------------------------------------
---------------
End of file.

---
[ 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
]