<iostream.h> again 
Author Message
 <iostream.h> again

I would like to thank with all my heart people who decided to drop old
streams from Visual Studio 2003.

Never mind that it broke some ages-old code that used fstreams.
It could be fixed, since the code is ours.
But now I am up against a very {*filter*} problem I don't know how to solve.

I have a third party library written around 1993 or so that uses old streams.
Thus, it has externals such as fstream::fstream() and friends, that must be
resolved. They used to be resolved to be in msvcirt.dll, but they are now gone.

The library is discontinued long time ago.
There will be no new version. Never.

Now what am I supposed to do?
I am stuck for good.

Best regards
Ivan Krivyakov



Tue, 11 Oct 2005 00:40:06 GMT  
 <iostream.h> again
Considering that it is ~10 years old, I think it's expecting a lot for
Microsoft to keep things around forever to maintain compatibility with
code that no longer matches the C++ standard.

So, unfortunately, you'll probably need to find a new library, or
continue to use old versions of VC++.
This time, hopefully you'll use a library that provides source.  :(



Tue, 11 Oct 2005 01:15:10 GMT  
 <iostream.h> again

Quote:

> Considering that it is ~10 years old, I think it's expecting a lot for
> Microsoft to keep things around forever to maintain compatibility with
> code that no longer matches the C++ standard.

From purely philosophical point of view this argument may be valid.
From practical point of view, this argument does not work.

The standard was too little too late.

They (MS) kept the old "for" syntax after all, didn't they?
And they kept CString, despite the fact that the standard has a
conformant implementation for string class.

Besides, four years after standard, VC++ 7.0 was not very conformant anyway.
Don't even mension that it gave an "internal compiler error" on boost library.
Will check it with 7.1 soon.

Quote:
> So, unfortunately, you'll probably need to find a new library, or
> continue to use old versions of VC++.

This does not help me much.

Ivan



Tue, 11 Oct 2005 01:27:46 GMT  
 <iostream.h> again

Quote:

> This does not help me much.

Well, you can continue to use an old version of VC++ to use your 10 year
old (binary-only) library, or you can figure out a way of replacing your
library.  Seems pretty clear to me.  :\

If I was in your position, I'd be spending my time figuring out how to
replace my 10 year old library, not how to get Microsoft to change
something that's already been released.  After all, they'll more than
likely tell you to use an older version of VC++.  If you need 7.1 for
better compliance, then your 10 year old non-compliant, binary-only code
doesn't exactly fit into the equation.



Tue, 11 Oct 2005 02:41:00 GMT  
 <iostream.h> again
Hello,

You could turn it into a dll and build only that dll
in previous version.


Quote:
> I would like to thank with all my heart people who decided to drop old
> streams from Visual Studio 2003.

> Never mind that it broke some ages-old code that used fstreams.
> It could be fixed, since the code is ours.
> But now I am up against a very {*filter*} problem I don't know how to solve.

> I have a third party library written around 1993 or so that uses old
streams.
> Thus, it has externals such as fstream::fstream() and friends, that must
be
> resolved. They used to be resolved to be in msvcirt.dll, but they are now
gone.

> The library is discontinued long time ago.
> There will be no new version. Never.

> Now what am I supposed to do?
> I am stuck for good.

> Best regards
> Ivan Krivyakov



Tue, 11 Oct 2005 22:04:13 GMT  
 <iostream.h> again

Quote:

> Hello,

> You could turn it into a dll and build only that dll
> in previous version.

Yeah, I thought about it.
It has pretty huge interface though.

I found a temporary workaround.

The library has many includes, and <fstream.h> is used in only one of them.
I kinda faked that include by replacing <fstream.h> with <fstream> and
putting std:: where needed.

Obviously, the include does not match the library anymore, but I don't
use that class directly anyway. It looks like that in my situation it's used
only internally by the library itself, and the library itself was of course
compiled with the right include. Nonetheless, this is a dangerous trick.

Then I linked my EXE against the old iostream library from VC 6
(msvcirt[d].lib).

The program compiles and even links :-)
It looks like it runs fine too, although more extensive testing is required.

Probably, at a later stage I will extract old iostream includes from VC6,
put them in some safe place, and make library includes reference them,
so that library includes will match the library again.

Thanks for the tip.

Ivan



Tue, 11 Oct 2005 23:00:23 GMT  
 <iostream.h> again

Quote:

> Now what am I supposed to do?

I'd suggest that you make a copy of msvcirt from your previous version of
Visual C++. Check that in to your sources as any other third party library
component that doesn't ship with Visual Studio. Aside from that, I would
start looking for something to replace the code with this dependency.

Cheerio!

--
Brandon Bray                                          Visual C++ Compiler
This posting is provided AS IS with no warranties, and confers no rights.



Wed, 12 Oct 2005 00:10:49 GMT  
 <iostream.h> again
Hi, Ivan.

Quote:
>The standard was too little too late.

I'm curious about this particular point of view. Would
you care to elaborate on it a little? I'm asking about
this because I feel like the C++ standards committee is
driving the language into inevitable fossilizitaion, and
I would like to know if others share my point of view.


Wed, 12 Oct 2005 02:01:25 GMT  
 <iostream.h> again

Quote:

> >The standard was too little too late.

> I'm curious about this particular point of view. Would
> you care to elaborate on it a little?

Well, the "too late" part is obvious in my opinion.

By the time the standard came out, commercial C++ compilers existed
for several years and most of them had their own set of "semi-standard"
types.

For instance, before std::string was introduced, everybody and their
grandmother had their own string class. Most C++ book actually contained
a (somewhat contrived) string class as an example.

The same goes for arrays, maps, exceptions, and almost everything else
in the standard library.

The result is that things like Microsoft's CString or Borland's TArray
are to remain with us (at least with Windows programmers) for a very
long time, because they are firmly embedded into frameworks and
it will take a major revolution to remove them.

Furthermore, after the standard came out, it took compiler
writers several years to become at least somehow conformant.
Writing standard-conforming C++ compiler is not for the faint of heart.

The "too little" part is more controversial and subjective.

Among "strategic" things I think more effort should have been done in the
field of binary compatibility. Having every compiler implement name mangling
in their own way may be good for freedom and portability, but in the real world
it makes libraries from different compilers inherently incompatible and
interoperability reduced to nil. Interoperability was a very strong side of "C"
language and it is lost in C++.

Ignoring threads was also not very good idea in my opinion. Threads do
exist in most modern OSes, and not addressing them led to a zoo
of incompatible thread libraries that basically do the same thing.
Yes, I know about POSIX, but this is "C" interface.

Among smaller omissions I could name absence of reference-counted
pointer class. You can't make vector of auto_ptr's, can you? Then what
do you do if you need a polymorphic container (=> container of pointers)
that owns its items and ought to kill them when it dies? The solution is
rc_ptr, but oops, it's not there.

There are also a couple of "tactical" annoyances.

For instance, std::string class is of very limited use in real life, since it
cannot be passed to "C" APIs that want a writeable string buffer. And
there are plenty of those APIs in many OSes.

The issue of whether or not std::vector occupies contiguous memory
was also a source of big confusion. Luckily, it seems to be resolved
in favor of "yes". Without it, C++ would lack type that could be
passed to "C" APIs that want a pointer to plain "C" array.

These are just a couple of things that annoy me daily and are always on my mind.
I am sure I could name much more if I was to write a big essay about the problem.

Ivan



Wed, 12 Oct 2005 03:05:48 GMT  
 <iostream.h> again

Quote:

> I'd suggest that you make a copy of msvcirt from your previous version of
> Visual C++. Check that in to your sources as any other third party library
> component that doesn't ship with Visual Studio.

Yes, this is exactly what I did.
Thank you.

Quote:
> Aside from that, I would start looking for something to replace
> the code with this dependency.

This one is hopeless.

The library in question supports an old piece of hardware, and both
the library and the hardware are discontinued.

Nevertheless, the demand to support this type of hardware in newer
versions of the program remains.

Ivan



Wed, 12 Oct 2005 03:08:50 GMT  
 <iostream.h> again
Quote:
>Well, the "too late" part is obvious in my opinion.

>By the time the standard came out, commercial C++
compilers existed
>for several years and most of them had their own set
of "semi-standard"
>types.

>For instance, before std::string was introduced,
everybody and their
>grandmother had their own string class. Most C++ book
actually contained
>a (somewhat contrived) string class as an example.

>The same goes for arrays, maps, exceptions, and almost
everything else
>in the standard library.

>The result is that things like Microsoft's CString or
Borland's TArray
>are to remain with us (at least with Windows

programmers) for a very

Quote:
>long time, because they are firmly embedded into
frameworks and
>it will take a major revolution to remove them.

I agree. The most horrid example that comes to mind is
MFC, which is almost littered with such artifacts. I wish
native (unmanaged) C++ developers on the Winodws platform
had another viable option other than MFC, something
aching to System.Forms in the CLR.

Quote:
>Furthermore, after the standard came out, it took
compiler
>writers several years to become at least somehow
conformant.
>Writing standard-conforming C++ compiler is not for the
faint of heart.

>The "too little" part is more controversial and
subjective.

>Among "strategic" things I think more effort should have
been done in the
>field of binary compatibility. Having every compiler

implement name mangling
Quote:
>in their own way may be good for freedom and

portability, but in the real world
Quote:
>it makes libraries from different compilers inherently
incompatible and
>interoperability reduced to nil. Interoperability was a

very strong side of "C"
Quote:
>language and it is lost in C++.

>Ignoring threads was also not very good idea in my
opinion. Threads do
>exist in most modern OSes, and not addressing them led
to a zoo
>of incompatible thread libraries that basically do the
same thing.
>Yes, I know about POSIX, but this is "C" interface.

>Among smaller omissions I could name absence of
reference-counted
>pointer class. You can't make vector of auto_ptr's, can
you? Then what
>do you do if you need a polymorphic container (=>

container of pointers)

Quote:
>that owns its items and ought to kill them when it dies?
The solution is
>rc_ptr, but oops, it's not there.

>There are also a couple of "tactical" annoyances.

On the subject of threads and reference-counted pointer
classes, have you given the Boost library any thought?
It's God-sent as far as I'm concerned. It works right
now, and I don't have to hold my breath until the
committee deems it apropriate to include all such
omissions into the standard library.

One of the things that I would really like to see is more
dynamic type information support similar to the
reflection facilities in .Net and Java, although it
sounds next to impossible to have in C++. Standardizing
dynamic linking would also be very useful, and not nearly
as impossible as reflection. But such additions require
more than just proper libraries.

By the way, had anyone ever had this paranoid feeling
that I often have, in which the Windows platform is often
treated like the bastard child of OS's in literature and
by community figures? I mean, okay, it's not Unix, but
it's the most widely used platfom in this corner of the
universe. Of cource such sentiments, if true, reflect
also on the developers working on this platform.



Wed, 12 Oct 2005 03:52:33 GMT  
 <iostream.h> again
Quote:

> ...
> I agree. The most horrid example that comes to mind is
> MFC, which is almost littered with such artifacts. I wish
> native (unmanaged) C++ developers on the Winodws platform
> had another viable option other than MFC, something
> aching to System.Forms in the CLR.

 > ...

Have you tried WTL?  To quote Chris Sells - "WTL is, spiritually at
least, what the MFC team would've come up with had they started with the
C++ language as it is today" [1].

It's a great way to use templates for windows programming (and for
mixing as much or as little of the standard library as you like :-) ).

-Daniel

[1] http://www.sellsbrothers.com/tools/#wtl



Wed, 12 Oct 2005 04:24:42 GMT  
 <iostream.h> again

Quote:

> On the subject of threads and reference-counted pointer
> classes, have you given the Boost library any thought?
> It's God-sent as far as I'm concerned. It works right
> now, and I don't have to hold my breath until the
> committee deems it apropriate to include all such
> omissions into the standard library.

Visual C++ 6.0 had occasional INTERNAL COMPILER ERROR
with boost. It was frequent enough to make using boost
next to impossible.

If I remember correctly, Visual C++ 7.0 had a constant
INTERNAL COMPILER ERROR with one of the main header
files in boost, which made using boost totally impossible.

So much for standard compliance.

I did not check boost with 7.1 yet.

Quote:

> By the way, had anyone ever had this paranoid feeling
> that I often have, in which the Windows platform is often
> treated like the bastard child of OS's in literature and
> by community figures?

Well, Windows is not a real OS after all, is it? :-)

I think it's a mater of tradition.
Windows started as a graphics shell on top of DOS, that
hardly can be considered as "real" OS. Windows NT/2000/XP
have all functions of a "real" OS, but the tradition remains.

Ivan



Wed, 12 Oct 2005 06:03:12 GMT  
 <iostream.h> again

Quote:

> I agree. The most horrid example that comes to mind is
> MFC, which is almost littered with such artifacts.

Well, i Would not consider it horrid.
Given lack of standard classes for string, vector, etc. at the time,
it provided required basic services. But then it became a burden
because of backward compatibility with huge amount of code that uses it.

Ivan



Wed, 12 Oct 2005 06:06:45 GMT  
 <iostream.h> again


Quote:

> > On the subject of threads and reference-counted pointer
> > classes, have you given the Boost library any thought?
> > It's God-sent as far as I'm concerned. It works right
> > now, and I don't have to hold my breath until the
> > committee deems it apropriate to include all such
> > omissions into the standard library.

An excellent suggestion.

Quote:
> Visual C++ 6.0 had occasional INTERNAL COMPILER ERROR
> with boost. It was frequent enough to make using boost
> next to impossible.

> If I remember correctly, Visual C++ 7.0 had a constant
> INTERNAL COMPILER ERROR with one of the main header
> files in boost, which made using boost totally impossible.

> So much for standard compliance.

That product was not claimed to be fully
compliant with the standard.  Even v7.1
has a few acknowledged deviations.

Quote:
> I did not check boost with 7.1 yet.

Microsoft claims that v7.1 compiles boost
as-is.  So you might want to try it.

Quote:
> > By the way, had anyone ever had this paranoid feeling
> > that I often have, in which the Windows platform is often
> > treated like the bastard child of OS's in literature and
> > by community figures?

Only by certain ignorant bigots who get
their jollies by demeaning others.

Quote:
> Well, Windows is not a real OS after all, is it? :-)

Yuck, yuck.  Only idiots believe that.

Quote:
> I think it's a mater of tradition.
> Windows started as a graphics shell on top of DOS,

That is a canard.  It was never true.
Only people unfamiliar with the actual
structure of that O.S. are able to say
such a thing, unless they are liars.

Quote:
> that hardly can be considered as "real" OS.

Especially since it is but a fantasy.

Quote:
> Windows NT/2000/XP
> have all functions of a "real" OS, but the tradition remains.

That "tradition" is just a continuation
of a common human failing.

--
-Larry Brasfield
(address munged, s/sn/h/ to reply)



Wed, 12 Oct 2005 06:17:25 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Fw: <iostream>, <iostream.h>, Visual C++, g++

2. <iostream>, <iostream.h>, Visual C++, g++

3. <<<<<<<Parsing help, please>>>>>>>>

4. File Format conversion, ascii freeform -->.csv <-->.wk1<-->dbf<-->?HELP

5. <<<>>>Need C code advice with functions and sorting.<<<>>>

6. <><><>HELP<><><> PCMCIA Motorola Montana 33.6

7. >>>Windows Service<<<

8. cin::getline() different in <iostream> and <iostream.h>

9. <iostream.h> and <iostream> differences

10. : <iostream.h> or <iostream> with file created by CreateFile

11. <iostream> and not <iostream.h>

12. #include <iostream>???

 

 
Powered by phpBB® Forum Software