Re: Why is this still not allowed by gcc while MSVC does(NULL as template-argmument)?

[John Love-Jensen <eljay at adobe dot com>]

Hi Chen,

> If you try that code with MSVC, you'll know that that code works just what
I(and everyone, I think) expect, no language and semantic ambiguity!

However, MSVC++ is not ISO 14882 compliant in that regard.

That is to say, you are using a MSVC++ extension.  A "quasi-C++" or "C++++".
(Note: GCC has a few neat extensions too, which if used makes the source
more of "G++" than "C++".  Alas, some of those neat extensions have already
been removed, and others are deprecated and slated for removal.)

A facility that may not be available in future versions of MSVC++ as they
become more compliant to ISO 14882.  (Ditto for those neat "G++" extensions
to C++.)

> If we allow NULL to be a valid "template-argument for a non-type
/template-parameter/ of pointer type", does it cause harm to C++ code already
existed in the world?

Good question.  I don't know - I'm not sure of the rationale for ISO 14882
14.1.4 which precludes that.  But I have some idle speculation (see below).

> Since C++ 98 allows an int number for a "non-type /template-parameter/
> of *integral type*", then why in the world does he not allow 0 for a
> "non-type /template-parameter/ of pointer type"?

>From my experience with the standard -- which is just that as a user -- it
seems that the standards committee would cut a feature (such as the one you
are asking about), if there was another already pre-existing way to
accomplish the same thing.  (e.g., that's why there isn't a "super" keyword,
since the user can add that with a typedef:  typedef baseclassfoo super;.)

Since there is a pre-existing way to accomplish the same thing by using a
class parameter (with a pointer value wrapped inside or a member method that
returns a pointer value), instead of a naked pointer value, I suspect (by
pure idle speculation without any evidential basis) that is why they decided
not to add that feature.

Less likely, but also possible, perhaps those waters were tried and found to
have subtle interaction problems with implicit conversions.

Aside - if you change your template's USER_TYPE valInvalid to int
valInvalid, then your code works.

> It seems the standard does not state this. If you know, I'm very grateful to
hear from you.

The standard does not contain much in the way of exegeses at all.  :-(

You'll have to go to the WG21 site to look at the documentation that details
how the decisions were reached for some of the dusty corners of C++.

Stroustrup wrote an interesting book called The Design & Evolution of C++.
I wish there was a sequel covering the next 10 years.

HTH,
--Eljay