Re: Rationale for two C++ features
On Feb 13, 9:30 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
sean_in_rale...@yahoo.com wrote:
I'm curious what the rationale was for two
oddities in C++.
I'll give you my understanding, but these may be flawed.
Hopefully someone will correct me if I'm wrong.
1) Why did the standards committee choose
the oddball no-extension names for the standard
headers (<string>, e.g.)? I can understand them wanting to
emphasize that an included entity is not necessarily
a file, but they say "header file" throughout the standard,
and calling it something like "string.hpp" would not have implied
that it was necessarily a file.
Originally, the headers were iostream.h, string.h, etc.
Originally, the names varied from one implementation to the
next: strstrea.hpp vs. strstream.h, for example. I suspect that
the absense of a suffix is mainly due to an inability to be able
to agree on what that suffix should be.
When the standard library got moved into the std namespace,
the most straightforward way to avoid breaking backward
compatibility was to have new headers #include the old headers
within the new namespace:
/* <iostream> */
namespace std {
#include <iostream.h>
}
Except that there are very definite differences in addition to
the namespace ones. To begin with, the classes in <iostream>
are all (except ios_base) templates; none of those in
<iostream.h> were. And there are other, subtle differences: the
initial values for the format flags were changed, filebuf does
code translation according to the current locale, unless you
specify otherwise, etc.
Most of the other headers didn't even exist in pre-standard C++.
Anywhere, I rather prefer the shorter header names. They're
easier to read, and easier to type.
Pragmatically, however, most implementations map them to a file
of the same name, and having file names without suffixes is a
bit of a pain. (Witness all the problems caused by the fact
that executables don't have a suffix under Unix. If I want to
clean out all of the generated files under Windows, I type "rm
*.obj *.lib *.exe". Under Unix, "rm *.o *.a *" is NOT
recommended---you have to name each of the executables
directly.)
2) Why was the following use of the conditional operator
made illegal?
class B { };
class D1 : public B { };
class D2 : public B { };
int main(int argc, char **argv) {
B *p1 = argc == 1 ? new D1() : new B();
B *p2 = argc == 1 ? new D1() : new D2();
}
In the code above, the p1 assignment is legal,
while the p2 assignment is not (according to
the standard's expr.cond.5, and the Comeau
and GNU compilers I tried). Why not just
treat it as the following:
B *p2;
if (argc == 1)
p2 = new D1();
else
p2 = new D2();
The ternary operator constitutes an expression, and (unlike
the if/else tree) must have a single static type. In the case
you've shown, there is a clear an obvious choice; however,
that may not always be the case.
One could have imagined using the most derived common type, or
some such rules. I wouldn't like to have to formulate that in
standardese, however, and as you say, there could be cases where
it would be ambiguous.
If neither sub-expression has a type convertible to the other's, then
finding the right super-type may be non-trivial. For example:
struct A { }
struct B { };
struct D1: B { };
struct D2: B { };
Didn't you want multiple inheritance here? Otherwise, there's
no ambiguity later.
int main(int argc, char** argv[]) {
D1 d1;
D2 d2;
A const* const a = argc > 2 ? &d1 : &d2;
B const* const b = argc > 2 ? &d1 : &d2;
return 0;
}
Supposing you meant multiple inheritance, one could still
imagine something like the rule for overload resolution when
taking the address of a function. I'm not sure that's a road I
want to take, however.
When in doubt, of course, the best solution for the committee is
to ban it. You can always add support for something that was
previously illegal in a later version, if the need becomes felt,
or the situation becomes clearer. Once you've defined a
specific support, however, you can't remove it if it turns out
to be a mistake.
As far as I know, there've been no propositions to support the
above, even in a limited fashion (e.g. by saying it is an error
if there is an ambiguity). So presumably, no one has felt that
it was an important enough issue to address.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34