Hi,
Steve Clamage (stephen.clamage_nospam@eng.sun.com) wrote:
: For
: example, if you tried to do something like this (for an invented
: implementation that provided both forms):
:  #include <classic/iostream.h>
:  #include <iostream>
: the code would not compile. For one thing, each header defines a type
: named "ostream", but the definitions are completely different.

Well, when "classic/iostream.h" was introduced, there were no
namespaces and 'cout', as well as the whole other IOStream stuff in a
standard conforming implementation, lives in 'std'. Since the classic
IOStream stuff can (must?) be put into the global namespace, conflicts
of names can be avoided. Of course, there have to be some
synchronization issues to be resolved between 'std::cout' and '::cout'
but this should be only a relatively minor problem... I haven't tried
it [yet] but I think it is possible to have two different
implementations of IOStreams in the same program. What I know that
works is to have at least partial implementations of both in one
program: I'm using classic IOStreams to generate debug output in myown
implementation of IOStreams. However, I have deliberatly avoided
typedefs for 'ostream' (and the others) and the predefined IOStreams
use a slightly different name.

: Use the same form (classic or standard) of iostreams throughout any
: one program.

Although I agree with this advice, I think it should be possible to use
two different implementations of IOStreams in one program as long as
namespaces are supported.
--
<mailto:dietmar.kuehl@claas-solutions.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Steve Clamage wrote:

> On 04 Dec 97 16:12:15 GMT, "J|rgen Placke" <placke@ugs.com> wrote:
>
> >I've hered, that some structures in the standard-iostream-lib
> >(<iostream>, <sstream>, ...) and the old version (<iostream.h>,
> ><strstrea.h>,...  ; for example MS VC4.2) are incompatible. Is ist
> >right? Is there a chance to use the 2 versions in the same
> project,[...]
>
> [...]
> It seems very unlikely that you would be able to use both versions of
> iostreams in the same program even if the versions were kept isolated
> in different translation units. For one thing, each library has an
> object called "cout", but with different types. There will almost
> certainly be other clashes as well.
> Use the same form (classic or standard) of iostreams throughout any
> one program.
> ---
> Steve Clamage, stephen.clamage_nospam@eng.sun.com
> ( Note: remove "_nospam" when replying )

Is there realy no chance to use both forms of iostreams in one programm?
So because I use a foreign 4GL-lib in classic iostream-form,  I have to
code my own sources also in classic iostream-form. When the 4GL-vendor
changes the iostream-form to standard, I have to rewrite my own souces.
What's  the matter, when someone has to use some foreign 4GL-lib's with
different iostream-forms?I can't believe that this behaviour was planed
by the standard-committee, because this hints the introduction of the
good new standard much.

 Juergen

----------------------------------------------------------------------
  Juergen Placke                    email: juergen.placke@ugs.com
  Fa. Schuler & Partner             phone: +49 7445 830124
  Karl-Berner-Str. 4                fax: +49 7445 830166
  D-75285 Pfalzgrafenweiler
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

J|rgen Placke wrote:
>
> Steve Clamage wrote:
>
> > On 04 Dec 97 16:12:15 GMT, "J|rgen Placke" <placke@ugs.com> wrote:
> >
> > >I've hered, that some structures in the standard-iostream-lib
> > >(<iostream>, <sstream>, ...) and the old version (<iostream.h>,
> > ><strstrea.h>,...  ; for example MS VC4.2) are incompatible. Is ist
> > >right? Is there a chance to use the 2 versions in the same
> > project,[...]
> >
> > [...]
> > It seems very unlikely that you would be able to use both versions of
> > iostreams in the same program even if the versions were kept isolated
> > in different translation units. For one thing, each library has an
> > object called "cout", but with different types. There will almost
> > certainly be other clashes as well.
> > Use the same form (classic or standard) of iostreams throughout any
> > one program.
> > ---
> > Steve Clamage, stephen.clamage_nospam@eng.sun.com
> > ( Note: remove "_nospam" when replying )
>
> Is there realy no chance to use both forms of iostreams in one programm?

I'll have to agree here.  Use of the pre-ANSI iostream package and
the ANSI iostream package will only cause confusion.

As Steve Clamage pointed out, duplicate global data can be only
one of the issues.  Although, the ANSI version should be std::cout
and a totally different object.

Developers moving up to an product that provides an implementation
of the ANSI I/O package should make sure that their code base
makes use of only one.

If, for example, a shared object was built and used the old iostream
package, then a new piece of a product was being developed and made
use of the ANSI I/O package.  The two binaries did not pass a
cout object through the API but depended on specific positioning
after API calls, the resulting mix would most likely fail over in
very strange ways.

Digital is recommending that its DIGITAL C++ V6.0 users stay with
the pre-ANSI I/O package or update all of their code to
the ANSI I/O package

> So because I use a foreign 4GL-lib in classic iostream-form,  I have
> to code my own sources also in classic iostream-form. When the
> 4GL-vendor changes the iostream-form to standard, I have to rewrite
> my own souces.

To be honest, the vendor should be able to deal with this, or at
least provide BOTH interfaces in an either/or manner.


> What's  the matter, when someone has to use some foreign 4GL-lib's
> with different iostream-forms?

In general, as long as a shared object or a separate API deals with its
output within itself, that is, all calls to output data are done
via calls to the API and the caller NEVER outputs directly to a stream, then the
API provider can do what ever they want.

Forgive my jump to UNIX and shared object but I need to provide an
example here.

Program foo:   Call_so_api_display_this("hi there");
so_api: Call_so_api_display_this: cout << "hi there";
Program foo:   Call_so_api_endl();
so_api: Call_so_api_endl:  cout << endl;
Program foo:   Call_so_api_display_this_and_endl("done");
so_api: Call_so_api_display_this_and_endl: cout << "done" << endl;

The output would be:
----------
hi there
done
----------

If so_api was compiled using the "classic" I/O package, everything is
fine.  However, in the following example, the endl may NOT result
in the flushing of the "hi there" string to the output stream:

Program foo:   Call_so_api_display_this("hi there");
so_api: Call_so_api_display_this: cout << "hi there";
Program foo:   cout << endl;
Program foo:   Call_so_api_display_this_and_endl("done");
so_api: Call_so_api_display_this_and_endl: cout << "done" << endl;

What COULD come out is:
----------

hi there done

---------

Note that program foo did its own output to cout.

> I can't believe that this behaviour was planed by the
> standard-committee, because this hints the introduction of the good
> new standard much.

Did you mean hurts ?  If so, yes any time upward or binary compatibility
is effected by a new product (if you want to call the standard a
product) then yes some people (many?) are going to be put off by
having to change their I/O model, or by having to provide one or
the other and a way for their users to use either.  The hit to move
up to the ANSI I/O package is a one-time hit, its not be best
situation, but given the different subtle differences in the
already released I/O packages out there, at least there is a Standard
now.

--
-----------------------------------------------------------------------
Brian J. McCarthy                  | mailto:mccarthy@hndymn.zko.dec.com
Digital Equipment Corp. Nashua, NH | DEC C++ Class Libraries
-----------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

On 15 Dec 1997 11:34:05 PST, "J=FCrgen Placke" <placke@ugs.com> wrote:

>Steve Clamage wrote:
>
>> On 04 Dec 97 16:12:15 GMT, "J|rgen Placke" <placke@ugs.com> wrote:
>>
>> >I've hered, that some structures in the standard-iostream-lib
>> >(<iostream>, <sstream>, ...) and the old version (<iostream.h>,
>> ><strstrea.h>,...  ; for example MS VC4.2) are incompatible. ...
>>
>> It seems very unlikely that you would be able to use both versions of
>> iostreams in the same program even if the versions were kept isolated
>> in different translation units. ...
>
>Is there realy no chance to use both forms of iostreams in one programm?
>So because I use a foreign 4GL-lib in classic iostream-form,  I have to
>code my own sources also in classic iostream-form. When the 4GL-vendor
>changes the iostream-form to standard, I have to rewrite my own souces.
>What's  the matter, when someone has to use some foreign 4GL-lib's with
>different iostream-forms?I can't believe that this behaviour was planed
>by the standard-committee, because this hints the introduction of the
>good new standard much.

To gain international acceptance, iostreams needed functionality not
available in classic iostreams, such as support for wide and multibyte
characters, and for locales. That in turn meant that the design of
iostreams had to be different at a fundamental level.

We could have introduced a completely new I/O library with all new
names. Whether or not we also standardized "classic" iostreams, that
would have created a host of problems for programmers and existing
programs. And there would still be the problem of trying to sychronize
I/O for the standard streams via two incompatible mechanisms.

Instead, we tried to keep as much source code compatibility as
possible. Many ordinary uses of stream I/O continue to be valid as
written. You need to modify only more advanced uses of stream I/O.

What about the case of working with 3rd party library code written for
classic iostreams? If your new compiler still supports classic
iostreams, allowing you to continue to use the 3rd-party code, you can
continue to write your own classic iostream code to go with it. At
some point, the library vendor will have to release a standard-
conforming version of the library. At that time you make the choice of
converting to standard iostreams or staying with classic iostreams.

You have to make the latter choice for all programs anyway. It is
really no different from the choices you made with each new major
release of your C++ compiler. Major releases typically marked changes
in the language that involved at minimum binary incompatibility, and
often some source-code incompatibility. You had to choose when and how
to make the transition.

With respect to iostreams, it is no different from the transition from
original C++ stream I/O as described in the first edition of "The C++
Programming Language" to classic iostreams introduced in 1989. For a
period of several years programmers and vendors had to contend with
two incompatible versions of stream I/O.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

On 04 Dec 97 16:12:15 GMT, "J|rgen Placke" <placke@ugs.com> wrote:

>I've hered, that some structures in the standard-iostream-lib
>(<iostream>, <sstream>, ...) and the old version (<iostream.h>,
><strstrea.h>,...  ; for example MS VC4.2) are incompatible. Is ist
>right?
>Is there a chance to use the 2 versions in the same project, because I
>have to use libs from a 4GL-Tool which are developed by
>using the old version of iostream-lib and I want to use the new
>standard-lib  in my own sources.

A lot of program code using iostreams will continue to work unchanged
if you switch from using classic to standard iostreams. But the old
and new libraries and headers themselves are not compatible. For
example, if you tried to do something like this (for an invented
implementation that provided both forms):
 #include <classic/iostream.h>
 #include <iostream>
the code would not compile. For one thing, each header defines a type
named "ostream", but the definitions are completely different.

It seems very unlikely that you would be able to use both versions of
iostreams in the same program even if the versions were kept isolated
in different translation units. For one thing, each library has an
object called "cout", but with different types. There will almost
certainly be other clashes as well.

Use the same form (classic or standard) of iostreams throughout any
one program.

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I've hered, that some structures in the standard-iostream-lib
(<iostream>, <sstream>, ...) and the old version (<iostream.h>,
<strstrea.h>,...  ; for example MS VC4.2) are incompatible. Is ist
right?
Is there a chance to use the 2 versions in the same project, because I
have to use libs from a 4GL-Tool which are developed by
using the old version of iostream-lib and I want to use the new
standard-lib  in my own sources.

Thanks for answer
Juergen

----------------------------------------------------------------------
  Juergen Placke                    email: juergen.placke@ugs.com
  Fa. Schuler & Partner             phone: +49 7445 830124
  Karl-Berner-Str. 4                fax: +49 7445 830166
  D-75285 Pfalzgrafenweiler
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]