[ moderator's note: This discussion has drifted into specifics of
  how to use a particular compiler implementation. Let's keep
  further discussion on-topic for this newsgroup. How to use
  VC++ belongs in a VC++ newsgroup, not comp.std.c++. -sdc ]

I wrote:
> Microsoft VC++ (5.0), [...] does not supply a
> (backwards compatible) <strstream.h> header; instead, it's named
> <strstrea.h>.  Why they would bother truncating a semi-standard
> header name to fit into their obsolete 8.3 naming convention is
> beyond me (after all, VC++ is designed for Windows, which has no
> trouble supporting long file names).  This sort of thing is just
> one more roadblock, among many, for trying to write portable code.

AllanW@my-dejanews.com suggested:
> But you're wrong; the standard installation does use the 'm' in the
> filename. You have a non-standard installation.
>
> Several things could cause this:
> ...

No, as far as I can tell, my installation is fine (I installed the
"typical" install, as far as I remember).  I am installing onto
Windows NT 4.0, so I'm quite certain I'm not using 16-bit drivers,
and I'm not installing across a network.  I can read long filenames
on CDs without any problem.

Another clue is that I have both "strstrea.h" and "STRSTREAM" files
in the vc/include installation directory; the latter is a 9.0
long filename, so I'm certain NT isn't having problems with long
filenames.

OTOH, we probably don't have the very latest sp3 of VC++; I think
we're using the very first release of VC++ 5.0.  We've installed
it on several machines, and they all have the same problem.

Could you tell me which version of VC++ 5.0 you're using?

And BTW, we can't simply rename the installed header, because
we expect our customers to have pretty much the same software
we have; we aren't in a position to tell them to rename 3rd
party files.

-- David R. Tribble, dtribble@technologist.com --


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> >Perhaps you should learn what the standard says before criticizing it.

> Well, that is kind of difficult since most of us aren't the holy ones who
> have actually seen it. From what I understand, the only way a regular
> person can see the standard is to pay $265.

So that makes it OK to criticize it without reading it?
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
In article <B1EE6C72-4E7A06@192.168.0.2>,
  "John Daniel" <jdaniel@harmonysoftware.com> wrote:
> On Sat, Aug 1, 1998 1:24 PM, Andrew Koenig <mailto:ark@research.att.com>
> wrote:
> >Perhaps you should learn what the standard says before criticizing it.

> Well, that is kind of difficult since most of us aren't the holy ones who
> have actually seen it. From what I understand, the only way a regular
> person can see the standard is to pay $265.

$265? Sounds pretty cheap to me. I invested roughly $4500 to attend half a
dozen committee meetings, not including the money spent by the company since
I got some support and not including the costs for the work. The Holy Ones
have probably spent at least 10 times as much. So what are you complaining
about?

Also, the FAQ of comp.std.c++ lists sources of the Nov'96 DWP. This is not the
standard but it is quite close. Knowing that since this DWP nothing
fundamentally changed but things were only corrected, this is also a suitable
document to critize the standard: Nobody would complain about critics of
specific stuff in the Nov'96 DWP which have been corrected since then.

The initial complaints were all based on a particular C++ implementation and
had nothing to do at all with standard C++. This would have been clear even
from reading, er, browsing, the Nov'96 DWP. --
<mailto:dietmar.kuehl@claas-solutions.de> homepage:
<http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35C7300A.3846@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
[Snippage]
> Microsoft VC++ (5.0), [...] do[es] not supply a
> (backwards compatible) <strstream.h> header; instead, it's named
> <strstrea.h>.  Why they would bother truncating a semi-standard
> header name to fit into their obsolete 8.3 naming conventions is
> beyond me (after all, VC++ is designed for Windows, which has no
> trouble supporting long file names).  This sort of thing is just
> one more roadblock, among many, for trying to write portable code.

But you're wrong; the standard installation does use the 'm' in the
filename. You have a non-standard installation.

Several things could cause this:
  * Your CD-Rom uses an old 16-bit driver. In this case you would
    get hundreds of errors during the install. If you pressed "ignore"
    and then manually copied the library, everything might work, but
    your header files would allhave 8.3 filenames.
  * You installed MSVC onto a network drive, and the network didn't
    allow long filenames. (We had that problem at one point ourselves;
    we changed the network to use long filenames shortly *after* the
    install, and then we had to do the install all over again.)
  * You backed up your hard drive, and later restored it, using old
    backup software that doesn't understand "long" filenames.

BTW, in each case, the root cause was that the 8.3 filenames aren't
as obsolete as you think they are. Which means that even if Microsoft
was guilty of these things, your criticism is rather harsh.

In any case, my MSVC++ install doesn't have that problem. I suggest
that you rename it back to the "real" filename at once.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Darron Shaffer  <darron.shaffer@beasys.com> wrote:
> >> You can even get some useful information by making misinformed angry
> >> postings to this newsgroup.
>
> Jim Cobban wrote:
> > I disagree with this criticism, and strongly sympathize with the
> > original writer's complaint.
>
>  [snip]
>
> > Some specific points.  The current generation books and the standard
> > never mention the .h versions of the headers.  Since they never
> > mention the .h headers, of course they do not discuss the rationale
> > for defining new names for all of the headers.  The point is made by
> > Darron and others that there were a few compiler vendors who used
> > headers ending in .hpp or .hxx.  Well, those vendors were brain dead.
> > The original CFRONT and Stroustrup's definition of the language in the
> > ARM always used .h so any company which deviated from that defacto
> > standard deserves to crash and burn.  The overwhelming majority of us
> > who used compilers which conformed to the defacto norm should not have
> > to pay, through conversion costs, for the poor design decisions of a
> > couple of stupid vendors.
>
> Just a minor point, but one that serves as a good example of the
> point made above.  Microsoft VC++ (5.0), which today is probably
> the closest to ISO C++ for WinTel platforms, still has some
> conformance issues.  In particular, they do not supply a
> (backwards compatible) <strstream.h> header; instead, it's named
> <strstrea.h>.  Why they would bother truncating a semi-standard
> header name to fit into their obsolete 8.3 naming conventions is
> beyond me (after all, VC++ is designed for Windows, which has no
> trouble supporting long file names).  This sort of thing is just
> one more roadblock, among many, for trying to write portable code.

Backward compatibility?
If strstreams appeared before 1995 (and therefore before Win95),
then the header files *had* to obey the 8.3 rule. (The same holds
later, if they still wanted to support 16-bit Windows.)
They could of course have then added an strstream.h header which
simply includes the old strstrea.h header when Win95 came out.

Did you test if VC++ possibly includes the strstrea.h header on
#include <strstream.h>? Since the mapping of the std headers to
file names is not fixed, this would be possible. (Alternatively,
try #include <strstream>)

[...]


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote in article <35C7300A.3846@noSPAM.central.beasys.com>...
> Just a minor point, but one that serves as a good example of the
> point made above.  Microsoft VC++ (5.0), which today is probably
> the closest to ISO C++ for WinTel platforms, still has some
> conformance issues.  In particular, they do not supply a
> (backwards compatible) <strstream.h> header; instead, it's named
> <strstrea.h>.

Uh, neither <strstream.h> nor <strstrea.h> are required by the C++
Standard, AFAIK. So their presence or absence hardly constitutes
a conformance issue. The C++ Standard *does* require the header
<strstream>, which is present in VC++ V4.2 and V5.0.

>                      Why they would bother truncating a semi-standard
> header name to fit into their obsolete 8.3 naming conventions is
> beyond me (after all, VC++ is designed for Windows, which has no
> trouble supporting long file names).

As I recall, both <strstrea.h> and <strstream.h> have appeared in
past implementations. The former reflects the DOS heritage that
Microsoft cares about somewhat.

>                                                     This sort of thing is just
> one more roadblock, among many, for trying to write portable code.

Uh, no comment.

> It's tempting to declare, based on the evidence, that Microsoft
> (and probably others) have absolutely no intention of making it
> easy for you to write code that runs on anything other than their
> O/S.

Maybe, but not based on *this* evidence.

>           This is why standards, like ISO C++, are a good thing, in
> that they force a certain amount of interchangeability amongst
> vendors, giving us a fighting chance at portability.  More power
> to the people!

Uh, yeah.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Sat, Aug 1, 1998 1:24 PM, Andrew Koenig <mailto:ark@research.att.com>
wrote:
>Perhaps you should learn what the standard says before criticizing it.
>--
>    --Andrew Koenig
>      ark@research.att.com
>      http://www.research.att.com/info/ark

Well, that is kind of difficult since most of us aren't the holy ones who
have actually seen it. From what I understand, the only way a regular
person can see the standard is to pay $265.

[ mod note: See also the FAQ. -sdc ]

John Daniel

Harmony Software
info@harmonysoftware.com
www.harmonysoftware.com

"Just because you're paranoid doesn't mean they aren't out to get you."




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Darron Shaffer  <darron.shaffer@beasys.com> wrote:
>> You can even get some useful information by making misinformed angry
>> postings to this newsgroup.

Jim Cobban wrote:
> I disagree with this criticism, and strongly sympathize with the
> original writer's complaint.

 [snip]

> Some specific points.  The current generation books and the standard
> never mention the .h versions of the headers.  Since they never
> mention the .h headers, of course they do not discuss the rationale
> for defining new names for all of the headers.  The point is made by
> Darron and others that there were a few compiler vendors who used
> headers ending in .hpp or .hxx.  Well, those vendors were brain dead.
> The original CFRONT and Stroustrup's definition of the language in the
> ARM always used .h so any company which deviated from that defacto
> standard deserves to crash and burn.  The overwhelming majority of us
> who used compilers which conformed to the defacto norm should not have
> to pay, through conversion costs, for the poor design decisions of a
> couple of stupid vendors.

Just a minor point, but one that serves as a good example of the
point made above.  Microsoft VC++ (5.0), which today is probably
the closest to ISO C++ for WinTel platforms, still has some
conformance issues.  In particular, they do not supply a
(backwards compatible) <strstream.h> header; instead, it's named
<strstrea.h>.  Why they would bother truncating a semi-standard
header name to fit into their obsolete 8.3 naming conventions is
beyond me (after all, VC++ is designed for Windows, which has no
trouble supporting long file names).  This sort of thing is just
one more roadblock, among many, for trying to write portable code.

It's tempting to declare, based on the evidence, that Microsoft
(and probably others) have absolutely no intention of making it
easy for you to write code that runs on anything other than their
O/S.  This is why standards, like ISO C++, are a good thing, in
that they force a certain amount of interchangeability amongst
vendors, giving us a fighting chance at portability.  More power
to the people!

-- David R. Tribble, dtribble@technologist.com --
-- Win95: Start me up... You make a grown man cry...
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 30 Jul 98 18:56:13 GMT, clamage@Eng.Sun.COM (Steve Clamage) wrote:
>"Mike Ost & Martha Wade" <wade_ost@metro.net> writes:
>>I think the new C++ standard is an abomination.

>So where were you while it was being developed?

I personally dislike having the vector template, since I do lots of
geometry where vectors are of set length and have properties like
magnitudes, dot products, and cross products.  However, isn't there a
solution for most of the names one dislikes anyway?  Something on the
order of:

namespace my_std
{
 typedef std::vector dyn_array; // for dynamic array
 [...]
};

Andrew Bell
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <vzaogu74cus.fsf@dalibm2.beasys.com>,
Darron Shaffer  <darron.shaffer@beasys.com> wrote:
>
>You can get real information about the new standard (as opposed to the
>information you seem to have) by:
>
>    a) Buying a recent book.
>    b) Read the comp.lang.c faq.
>    c) Studying one of the publicly available copies of the draft standard.
>    d) Searching for previous postings on these subjects in this
>       newsgroup.
>    e) Asking questions in this newsgroup.
>    f) Buying a copy of the standard, once it is available.
>
>You can even get some useful information by making misinformed angry
>postings to this newsgroup.

I disagree with this criticism, and strongly sympathize with the original
writer's complaint.

Yes there are many recent books, and some of them do a thorough job of
explaining how the standard language works.  However since the authors are
hoping that these books will provide them with royalty income for at least a
few years, they explicitly do NOT deal with the migration issues which are
required to translate CFRONT style code to the new standard.  To deal with
these issues would, in the minds of the authors, only confuse their readers.
Similarly the standard itself has more than enough on its plate trying to
precisely define the standard language to deal with these issues.  The
result is that the vast bulk of experienced programmers who encounter this
new language definition find themselves faced with a substantial conversion
workload and with no explanation of WHY they have to rewrite millions of
lines of working code.

Some specific points.  The current generation books and the standard never
mention the .h versions of the headers.  Since they never mention the .h
headers, of course they do not discuss the rationale for defining new names
for all of the headers.  The point is made by Darron and others that there
were a few compiler vendors who used headers ending in .hpp or .hxx.  Well
those vendors were brain dead.  The original CFRONT and Stroustrup's
definition of the language in the ARM always used .h so any company which
deviated from that defacto standard deserves to crash and burn.  The
overwhelming majority of us who used compilers which conformed to the
defacto norm should not have to pay, through conversion costs, for the poor
design decisions of a couple of stupid vendors.  On the other hand there are
some fundamental incompatibilities between the pre-standard library
definitions and the standard.  It turns out that the easiest way for
compiler vendors to deal with this, in order to permit old code
to compile with few if any code changes, while at the same time
permitting the development of new standard compliant applications, is to
have slightly different interpretation of #include <xxx.h> from #include
<xxx>.

As has been hashed out to death there are two mutually exclusive groups of
programmers, those who have been bedevilled with name conflicts from
imported code and those who have not.  Those who have had the problem are
pleased with the introduction of namespaces.  Those who have not repeatedly
ask why the h**l they have to rewrite their code to solve a problem they do
not have.  None of the current generation books nor the standard address
this issue, because they describe only how to write NEW code, not how to
rewrite code which until last week was totally conformant to the industry
standards.  I am quite confident that programmers are going to get sick and
tired of putting std:: in front of practically everything in really short
order.  But the books give all of their programming examples as if that will
be the way that people will code.

The new casting types are poorly described in every one of the new books I
have checked out, even in Stroustrup and in Plauger.  I promise to buy the
first book which does a decent job of explaining and justifying these.  For
now I keep the appropriate section of the draft standard as a convenient
bookmark.  Once again the problem is that the authors wish to describe the
way that code should be written.  They therefore fail to address the
problems of converting existing working code, and more importantly to
justify why corporations and individual programmers should expend money,
time, and effort to make these extensive changes.

In short, as a note to the authors of future C++ language manuals, please
include somewhere, even if only in an appendix, a rationale for the changes
from classic C++.  I understand that Stroustrup is writing an annotated
version of the standard, so possibly that will address this issue.

The bottom line is dollars and cents.  The introduction of this new standard
will cost us all in real money.  Probably it will be worth it, in terms of
more robust implementations and faster development times.  The problem
facing the advocates of the new language is to demonstrate that there will
be a net gain at the end.
--
Jim Cobban   |  jcobban@nortel.ca                   |  Phone: (613) 763-8013
Nortel (MCS) |                                      |  FAX:   (613) 763-5199
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Jim Cobban" <Jim.Cobban.jcobban@nt.com> writes:

> ... Yes there are many recent books, and some of them do a thorough job of
>explaining how the standard language works.  However since the authors are
>hoping that these books will provide them with royalty income for at least a
>few years, they explicitly do NOT deal with the migration issues which are
>required to translate CFRONT style code to the new standard.  To deal with
>these issues would, in the minds of the authors, only confuse their readers.

The problem is larger than that. Consider C. There were many dialects
of C, but they differed in fairly minor ways. It took a good-sized book
(by Harbison and Steele) to describe these differences.

C++ had the problem of being an evolving language, with no two
implementations quite the same at any given time, and no two
consecutive releases from the same vendor implementing quite the
same language. I don't see how you could write a book that could
cover these variations at all, let alone one that wouldn't be
obsolete before it reached bookstore shelves.  You don't have
to assign money-grubbing motives or elitist attitudes to authors
to explain the lack of such books. The job isn't doable, in my view.

>Some specific points.  The current generation books and the standard never
>mention the .h versions of the headers.  Since they never mention the .h
>headers, of course they do not discuss the rationale for defining new names
>for all of the headers.  The point is made by Darron and others that there
>were a few compiler vendors who used headers ending in .hpp or .hxx.  Well
>those vendors were brain dead.

As a C++ implementor, I never saw the need to use different file
suffixes for C++ header files than for C. But I did recognize
that other implementators thought it was useful, for a variety
of reasons. I didn't consider those implementors brain dead
just because they had priorities different from mine. Long after
the fact, we can see that a variety of spellings for standard
headers was not conducive to portable programming, but those
inconveniences were minor compared to differences in language
definition among implementations.

>In short, as a note to the authors of future C++ language manuals, please
>include somewhere, even if only in an appendix, a rationale for the changes
>from classic C++.

Some vendors routinely include a migration guide for programmers
moving from previous versions of the their compilers to whatever
the current version is. (Sun Microsystems, my employer, is one
example. I know there are others.) These books have a more manageable
task than the one I described above. They need only document the
changes from release to release that will affect programmers.
As a user of a C++ implementation, I'd expect such documentation.
(Such books serve another purpose for the vendor: they reduce
the number of support calls, saving far more money than they
cost to produce!)

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrew Bell wrote:
>
> On 30 Jul 98 18:56:13 GMT, clamage@Eng.Sun.COM (Steve Clamage) wrote:
> >"Mike Ost & Martha Wade" <wade_ost@metro.net> writes:
> >>I think the new C++ standard is an abomination.
>
> >So where were you while it was being developed?
>
> I personally dislike having the vector template, since I do lots of
> geometry where vectors are of set length and have properties like
> magnitudes, dot products, and cross products.  However, isn't there a
> solution for most of the names one dislikes anyway?  Something on the
> order of:
>
> namespace my_std
> {
>         typedef std::vector dyn_array; // for dynamic array
>         [...]
> };

Unfortunately, this doesn't work, since vector is a template.
If we had template typedefs, it would be

namespace my_std
{
  template<class T> typedef std::vector<T> dyn_array;
};

However, unfortunately we don't have template typedefs.

Another feature some people requested (at least at the newsgroups,
but I guess at the commitee as well) would be renaming in using
declarations, which would allow you to do something like

namespace my_std
{
  using dyn_array = std::vector; // ad-hoc syntax
};

But this feature isn't in the standard as well.

So I think you'll have to stick with the name vector.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Cobban wrote:
...
> Yes there are many recent books, and some of them do a thorough job of
> explaining how the standard language works.  However since the authors are
> hoping that these books will provide them with royalty income for at least a
> few years, they explicitly do NOT deal with the migration issues which are
> required to translate CFRONT style code to the new standard.  To deal with

I would expect that a book which dealt with those issues would have a
fairly large market. If no book current available addresses those issues
(which I consider unlikely) then there should be a decent profit
available to the first author who does deal with it.


> ... On the other hand there are
> some fundamental incompatibilities between the pre-standard library
> definitions and the standard. It turns out that the easiest way for
> compiler vendors to deal with this, in order to permit old code
> to compile with few if any code changes, while at the same time
> permitting the development of new standard compliant applications, is to
> have slightly different interpretation of #include <xxx.h> from #include
> <xxx>.

Could you explain that in more detail? Implementors are allowed to
interpret standard headers differently from ordinary ones, but why would
they need to treat xxx.h different from xxx? I would expect most
implementors to provide ordinary xxx.h and xxx header files, interpreted
exactly the same way as user-written header files. Cleverly chosen
preprocessor directives and use of reserved symbols should provide all
the flexibility they need.

...
> The new casting types are poorly described in every one of the new books I
> have checked out, even in Stroustrup and in Plauger.  I promise to buy the
> first book which does a decent job of explaining and justifying these.

I thought that Stroustrup did an excellent job of both those tasks (but
then, I'm the kind of person who finds it easier to learn a system from
a reference manual than from a tutorial - I know that for most people
it's the other way around). Could you be more specific about the
deficiencies of their explainations?
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mike Ost & Martha Wade wrote:
>
> I think the new C++ standard is an abomination. The class and method names
> in STL, especially, are incredibly cryptic and terse. BidItr? Come on! This
> is the 90s! Write it out!
>
> And two parallel sets of files for two incompatible stream implementations
> describing classes with the same names.... verbs fail me. There are
> "iostreams.h" and "iostreams" both of which will give you an istream and
> ostream. But they don't work together. Did they just run out of clever
> names?

Don't confuse an implementation with the standard. "BidItr" is not used
anywhere in the C++ Standard. And there are no C++ headers that end with
.h. Standard C++ uses only the bare names (except for the C headers, of
course). Microsoft tried to do people a favor by including their old
implementation (iostream.h) along with the new (iostream). Pick one or
the other. Prefereably the new one, because that's more portable.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
In article <35bf5d31.0@news.metro.net>,
  "Mike Ost & Martha Wade" <wade_ost@metro.net> wrote:
> I think the new C++ standard is an abomination. The class and method names
> in STL, especially, are incredibly cryptic and terse. BidItr? Come on! This
> is the 90s! Write it out!

Can you please cite where you have found the identifier 'BidItr' used in
standard C++? Hint: It is not used.

> And two parallel sets of files for two incompatible stream implementations
> describing classes with the same names.... verbs fail me. There are
> "iostreams.h" and "iostreams" both of which will give you an istream and
> ostream. But they don't work together. Did they just run out of clever
> names?

Where in the standard have you found that it is mandated that the streams from
<iostream> and <iostream.h> do NOT work together? Hint: It is not mandated. I
think it is not even mandated to provide the <iostream.h> at all (only .h
version of the C headers are required).

> It saddens me to know that I will have to live with this hard to work with
> library for the near future as a C++ programmer. I guess its more business
> for book publishers.

Please note that normally a compiler ships with an extended library compared
to the standard C++ library. The extensions have nothing to do with the
standard and you should be cautious to use only standard features if you want
your software to be portable. Unfortunately, for certain tasks, like eg.
windowing, you have to fall back to libraries specific for certain systems or
even certain compilers.

MSVC++ ships with a rather weird approach to IOStreams: To maintain
compatibility with the "old-fashioned" specification they keep the
"old-fashioned" implementation in the files with .h. The standard
implementation is found in the files without .h (BTW: If you need to include
a .h file to get something, it is an indication that this something is NOT
mandated by the standard). I haven't looked at the old MicroSoft interface
for IOStreams but normally it should be possible to provide both the new and
the older interface with an implementation (however, when using the old
interface, corresponding warnings should be issued). Using to separat
implementations is, IMO, a larger problem than breaking compatibility. One of
the problems you face with two incompatible implementations is that different
libraries will use different implementation: In the project I'm currently
working for, we use products which use the new IOStreams and the products
which use the old IOStreams. We had quite a few problems wth that... --
<mailto:dietmar.kuehl@claas-solutions.de> homepage:
<http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Mike Ost & Martha Wade" <wade_ost@metro.net> writes:

> I think the new C++ standard is an abomination. The class and method names
> in STL, especially, are incredibly cryptic and terse. BidItr? Come on! This
> is the 90s! Write it out!

Is BidItr an internal name?  I didn't find it in the draft.  I suspect
it is a name chosen by your implementor for a name not specified by
the standard.  This is most likely the name for a template argument,
and thus will never need to be used by you.

> And two parallel sets of files for two incompatible stream implementations
> describing classes with the same names.... verbs fail me. There are
> "iostreams.h" and "iostreams" both of which will give you an istream and
> ostream. But they don't work together. Did they just run out of clever
> names?
>

The standard only specifies ONE set of names -- the other set is a
bonus provided by your compiler vendor, to make it easier to compile
old code.  The new iostreams have more capabilities, but also some
incompatabilities.

The new names are specified without extensions in the source code, so
that every vendor, whaterver extension they used to use, can keep
thier old headers around for old code compatability.  The compiler is
NOT required to store the new headers on disk with no extension.  In
fact, the compiler is not required to store the headers on disk at all.

> It saddens me to know that I will have to live with this hard to work with
> library for the near future as a C++ programmer. I guess its more business
> for book publishers.

You can get real information about the new standard (as opposed to the
information you seem to have) by:

    a) Buying a recent book.
    b) Read the comp.lang.c faq.
    c) Studying one of the publicly available copies of the draft standard.
    d) Searching for previous postings on these subjects in this
       newsgroup.
    e) Asking questions in this newsgroup.
    f) Buying a copy of the standard, once it is available.

You can even get some useful information by making misinformed angry
postings to this newsgroup.

--
 __  __  _
 _ ) ___ _\   Enterprise Middleware Solutions Darron J. Shaffer
 __) __    \  BEA Systems Inc.   Sr. Software Engineer
              17101 Preston Rd   darron.shaffer@beasys.com
              LB# 115, Ste 260    Voice: (972) 738-6137
              Dallas, TX 75248    Fax:   (972) 738-6111
       http://www.beasys.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Mike Ost & Martha Wade" <wade_ost@metro.net> writes:

>I think the new C++ standard is an abomination.

So where were you while it was being developed? People who
can do a good job of writing standards are few and far
between. More expert help would have been welcomed. Indeed,
during the entire 8-year standardization process, invitations
for one and all to join were issued frequently.

>The class and method names
>in STL, especially, are incredibly cryptic and terse. BidItr? Come on! This
>is the 90s! Write it out!

Too bad you didn't mention this abomination during any of the
public comment periods (announced here and in many other places).
Your first chance to have such problems addressed was in April 1995,
and the last in March 1998.

>And two parallel sets of files for two incompatible stream implementations
>describing classes with the same names.... verbs fail me. There are
>"iostreams.h" and "iostreams" both of which will give you an istream and
>ostream. But they don't work together. Did they just run out of clever
>names?

Those ".h" names are not in the standard (you did read what you are
criticizing, right?). They might be local extensions to allow
programmers a migration path from old to new iostreams. Or do you
prefer that no migration path be available, and that programmers
stay locked into obsolete implementations until they rewrite all
of their code?

You can find explantions of the old and new headers in various
FAQs, textbooks, and in the C++ newsgroups.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I think the new C++ standard is an abomination. The class and method names
in STL, especially, are incredibly cryptic and terse. BidItr? Come on! This
is the 90s! Write it out!

And two parallel sets of files for two incompatible stream implementations
describing classes with the same names.... verbs fail me. There are
"iostreams.h" and "iostreams" both of which will give you an istream and
ostream. But they don't work together. Did they just run out of clever
names?

It saddens me to know that I will have to live with this hard to work with
library for the near future as a C++ programmer. I guess its more business
for book publishers.

...mo
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]