rani_sharoni@hotmail.com (Rani Sharoni) wrote in message
news:<df893da6.0209010607.d7b2bef@posting.google.com>...

> I recently posted this issue to c.l.c++.m, but did not receive any
> replies. I thought that maybe this newsgroup is more appropriate for
> such issues, and I will appreciate any comments.

> Lately I have come to think that 14.6/7 is defective and should be
> rephrased. The problem with 14.6/7 is that it defines when template
> definition is ill-formed in way that we can't, in general, verify.

> First I'll quote 14.6/7:
> Knowing which names are type names allows the syntax of every template
> definition to be checked. No diagnostic shall be issued for a template
> definition for which a valid specialization can be generated. If no
> valid specialization can be generated for a template definition, and
> that template is not instantiated, the template definition is
> ill-formed, no diagnostic required. [Note: if a template is
> instantiated, errors will be diagnosed according to the other rules in
> this Standard. Exactly when these errors are diagnosed is a quality of
> implementation issue. ]

> Can we check, in general, whether no valid specialization can be
> generated for a template definition? IMHO the answer is NO [...]

And so we can create a program that is ill-formed, but for which no
diagnostic is required.

My point is rather independant of the original discussion, but I think
it not without interest.  As the standard is currently formulated, if a
program is not legal, but no diagnostic is required, we have a case of
undefined behavior.  A similar situation occurs if you write something
like:

    #include <iostream>

    int
    main()
    {
        std::cout << "Hello, world\n" ;
    }

In both of these cases, in practice, you don't have undefined behavior.
Either the compiler will emit an error, or the program will work as
expected, with defined semantics.  (In no case will your hard disk be
reformatted.  In no case will you even get a core dump.)

I would suggest that the next version introduce a new category of error
for these cases: a compiler is not required to diagnose an error, but if
it doesn't the program must function correctly.  (In the case of the
library, this would mean that if you include at least one library
header, and use a library functionality not defined in any of the
library headers included, the program is ill-formed, but the compiler is
not required to diagnose the error.  I believe that this formulation is
the equivalent to allowing any library header to include any other.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]