Semi OT: Mixing iostream and iostream.h

[red floyd]

Disclaimer: yes. I know that iostream.h is non-standard. However, I
have some third party precompiled code that uses it. Yes, some of this
is app specific, and I did ask on the appropriate newsgroup (see below).

However, I think there is a potentially relevant issue, namely mixing
standards compliant code with third party legacy code.

Specifically, I'm mixing standards compliant code with compiled MATLAB
code (and yes, I have asked on comp.soft-sys.matlab). The MATLAB
compiled code includes files that #include <iostream.h> (and I can't
change it).

Has anyone successfully mixed legacy thirdparty library code that uses
pre-Standard iostreams with standard compliant iostreams?

What issues did you come across, and what workarounds were necessary?

Thanks,

red floyd

 

[Victor Bazarov]

[..]
Has anyone successfully mixed legacy thirdparty library code that uses
pre-Standard iostreams with standard compliant iostreams?

I have and it's ugly.

What issues did you come across, and what workarounds were necessary?

Name clash. Solution: keep new stuff in 'std::' and don't use "using".

Interestingly, it actually worked in VC++ v6. I hated every minute of
it, though.

V

 

[Chris Jefferson]

Disclaimer: yes. I know that iostream.h is non-standard. However, I
have some third party precompiled code that uses it. Yes, some of this
is app specific, and I did ask on the appropriate newsgroup (see below).

However, I think there is a potentially relevant issue, namely mixing
standards compliant code with third party legacy code.

Specifically, I'm mixing standards compliant code with compiled MATLAB
code (and yes, I have asked on comp.soft-sys.matlab). The MATLAB
compiled code includes files that #include <iostream.h> (and I can't
change it).

Has anyone successfully mixed legacy thirdparty library code that uses
pre-Standard iostreams with standard compliant iostreams?

What issues did you come across, and what workarounds were necessary?

In my compiler at least (g++ 3.3.3) iostream.h just includes iostream,
and then does "using std::iostream; using std:stream;...", and I
believe this is what most compilers do. In this case there shouldn't
really be any problems at all, unless you do something stupid (like
define your own functions with the same names as things in std)

Chris

 

[Dietmar Kuehl]

Has anyone successfully mixed legacy thirdparty library code that uses
pre-Standard iostreams with standard compliant iostreams?

I have mixed different version of IOStreams in a program (of course,
not counting the case where I use my own IOStream implementation in
a different namespace than std...) and it was a rather fragile thing,
nothing I would do in production code. Essentially, I encountered
some name clashes, particularily for global names like 'cout': both
the old and the new version did not use any name mangling for
namespaces. The only approach to address this was to abandon use of
'cout' and relatives ('cerr', 'cin', ...) in my code and to remove
the corresponding object files from the new standard library archive.
The tricky thing is that there are more things than just the IOStream
objects which the legacy library depends upon: e.g. the definition of
some character classification routines, etc. may differ.

Of course, it was impossible to use streaming operations between the
library and my own code (the types mismatched). I had some spurious
crashes, though, and gave up on the approach in favour of writing my
own library. I did not locate the source of the crashes, i.e. they
may have been due to other problems.