Re: compilation error related to template parameter
* Bo Persson:
Alf P. Steinbach wrote:
::
:: For the compiler needs to be informed -- somehow -- that "at" is
:: meant to be assumed to be a member function of vector<T>. Because
:: whether it is or not depends on T, which is unknown during the
:: first pass through the template definition. For example, "at"
:: could be a global function.
::
:: <speculation>
:: I always find the explanation I gave above to be lacking, but it
:: is the one usually offered. It's a bit lacking because before
:: two-phase template instantiation was standardized, compilers
:: managed code such as above very well thank you, as evidently
:: Visual C++ still does, without needing to be informed about
:: anything. A more Real(TM) reason why it matters could be that
:: "export" needs a context-independent template definition (that
:: could also help explain why "export" is so unpopular, only
:: officially supported by Comeau). </speculation>
::
It doesn't really work, it just pretends.
Yes.
Note that the OP used
"-std=c++98 -pedantic" with g++. That is definitely not the default
setting for VC++.
As you certainly know, in "compatibility mode" VC++ will pick whatever
it finds at instantiation time, a vector<mytype>::at() or some other
visible at() function, or just fail if none is present. I think this
is an ODR violation in disguise.
Isn't it better to fix the problem up front with the original
template, and not wait for the third case (or debug case two for a
month)?
Assuming you think I've argued that the pre-standard behavior was more
practical than the current standard behavior: no, I didn't argue that,
but yes, since you seem to mention it, I do think it was better because
it made the most common case require no extra typing, i.e. a reasonable
default, so that time spent fixing actual problems was, I think, less
than the time now required to prevent in advance problems that probably
won't occur, fighting the compiler instead of one's own bugs (which are
preventable). But having been weaned on Pascal and Modula-2 I also
agree with you that strong type checking and context-independence for
meaning of a definition is Good(TM), /when it's done right/. It's just
that the current rules as I see it don't do it right.
The current rules have it backwards. They require some extra indication
that "yes, I really mean to use a class member here". At least for
other than unqualified type names it would be much more sensible to
require an extra indication that "nope, this here ain't no class member,
I'm using something global", and for a standard-conforming compiler get
a diagnostic if such indication is not present and no corresponding
class member is found on instantiation.
But hey, it's like most of the defaults in C++ are backwards, by
historical accident.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?