Re: help
On Mar 18, 4:08 pm, "Christopher Dearlove"
<chris.dearl...@baesystems.com> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:57e11aaa-e2ec-4645-929e-72a21b56a918@t3g2000yqa.googlegroups.com...
On Mar 17, 6:43 pm, "Christopher Dearlove"
Since I've had experience of it not working, I wouldn't
expect it to work. And the compiler vendor has to draw the
line somewhere. And I'm quite happy if <iostream.h> is
over in the "don't care" area, as I have no code that uses
it, or I expect ever to.
That's because you're younger than I am.
Maybe, maybe not, I don't know how old you are. Now if you'd
said that's because you've not been using C++ for as long as I
have, that would have been true. But I did first write
software before Bjarne Stroustrup started C with classes (but
I think he had started before I got paid for any). Fortran
however.
I wrote my first programs (admittedly, not as a professional)
somewhere around 1964. I don't think that there are many people
here whose experience goes back that far.
But you're right---what counts is that I have to deal with C++
code which is 15 or more years old. (Whether I was the one who
wrote it or not is really irrelevant. Although I do have some
C++ code that I wrote before 1990.)
Realistically, a compiler vendor will have to drop it some
time. But I'd consider anything less than 20 years as
irresponsible on his part.
But if he's also a new kid on the block, only been selling C++
compilers for, say, a decade, then there's no reason for him
to have ever added it.
True, but that's not the case for any of the vendors I know. In
fact, it depends on his target market. If he wants to capture
customers from other vendors, he might want to consider it.
Fully implementing a complete pre-standard <iostream.h> is a lot
of work, but some vendors do have a hacked version---the file
name is <iostream.h>, and it puts things like istream and
ostream in the global namespace, but the rest of the interface
is closer to the standard iostreams than to the classical ones.
In all cases, the issue of development costs must be considered.
If the vendor already has an implementation of <iostream.h>,
conform to the pre-standard defacto standard, it shouldn't be
too expensive to continue maintaining it; dropping it, or even
shifting to the hack above, is a bit irresponsible vis-a-vis his
clients. If a vendor doesn't have such, it's another issue.
Note that this affects a lot of things. I'm sure that most
vendors would prefer supporting pre-standard name lookup in
templates, to avoid breaking client code. But supporting two
completely different name lookups is expensive, and templates
weren't really that widely used before the standard was adopted,
so the trade offs are different.
But in contrast consider this deprecated code
bool b = false;
++b;
Now even if this hypothetical compiler writer were releasing
his first working version tomorrow, he should still support
that, as it's still part of the standard. (But a warning would
be good practice.)
Just because something is part of the standard doesn't mean that
vendors will implement it---look at export. In this case, you
can probably expect it because it is officially part of the
standard AND it is cheap to implement.
If I did get involved in something that used it, yes, I'd have
to pick my compiler with a different set of criteria. As it
is, <iostream.h> working is nowhere on my list. This is quite
different to a deprecated feature.
Not really. You have to choose your compiler according to your
specific needs. Period.
You say not really, but your comment says the same as mine. We
each pick our compilers according to our own criteria. Your
criteria have more backward compatibility issues than mine. (I
didn't say I don't have any.) If I had a different code base
to support, my criteria would change.
Yes. Most big companies do have some older code that they have
to maintain. But not necessarily everywhere.
--
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