🚀 go-pugleaf

>>>>> "E" == "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
[...]
E> 1) Clause [temp.res] verse 1 requires that all types dependent on the
E> template parameter must be qualified by 'typename' keyword - supposedly to
E> allow checking the template syntax. But it does not help anything as _each_
E> instance will have to be checked anyway:
[...]

I don't think that `typename' was introduced with the intention of avoiding
instantiation checks. I expect at least one of the goals was to permit the
development of more refined tools (e.g., for the analysis of generic as
opposed to instantiated code).

E> 2) Clause [temp.dep] verse 5 states that base class scope names hide the
E> template parameter:
[...]

Although I didn't check the issue, I would tend to agree with you here.
In particular, consider:

	template<typename B>
	struct D: public B {
	    // Cannot guarantee that a member of B won't hide the
	    // classname itself.
	}

Again, I didn't check this (i.e., what I say above may be unfounded).

E> 3) Clause [temp.arg.explicit] verses 2-3 requires that for explicit arg in
E> member template to be present it must be qualified by 'template' keyword,
E> e.g.
E>      X *p; p->template alloc<200>();
E> But to use operator -> we need X class definition anyway - so we know that
E> alloc() is a template. Thus this keyword is redundant and likely to be
E> forgotten (if I am not mistaken, it is in fact missing from some examples
E> in lib.locale section).

Same as 1).

E> 4) Clause [temp.deduct] verse 4. Why the conversions other than Derived* ->
E> Base* are not allowed in template deduction (at least default conversions
E> like char->int; user conversions would be even better)?

I suppose this is a matter of avoiding complexity. Remember that the more
possibilities the compiler must consider, the more time it will take to
compile this code (and in this case we're talking about superlinear 
growth). From a maintainability point of view, implicit conversion can
also be a hassle.

[...]
E> PS. Am I the only one who does not like the current drift in the C++ syntax
E> from symbolic (C-like)
E>    int a[10];
E> to verbose (Pascal-like)
E>    var
E>      a: array[0..9] of integer;
E> way of expressing things? Why don't use, for instance, cast_d instead od
E> dynamic_cast (ugh). Yeah, I know we are not using 10-cps terminals Richie
E> (sp?) did, but anyway... (and it consumes compiler memory space :-)
[...]

I think that what you're observing is the tendency to require (or encourage)
us to ``say what we mean''. The new casting syntax, the ban on implicit int,
the explicit keyword, the uses of `typename' and `template' syntax that you
mention and even the bool type are all ways to make more explicit in the
source code what is going on. Considering the things that already happen
automatically in C++ (virtual dispatch, template instantiation, destruction,
user-defined conversions, ...), I am rather happy that those things that do
not require transparency are made explicit.

	Daveed


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]