iostream + iostream.h

[S. Nurbe]

Hi,

probably this is a common problem but I couldn't find yet a proper
solution (and I hope there is one).

I have two relative complex frameworks: one uses only iostream.h the
other one only iostream.
Is it somehow possible to put them together to one framework and solve
the iostream problem (also other header are effected, e.g. fstream)?
If I just change the header in one framework I get lots of errors,
which are very difficult to fix (at least for me).

It's really important so I'm happy for every help.
Thanks,

S. Nurbe

[Victor Bazarov]

"S. Nurbe" <re*******@yahoo.de> wrote...

probably this is a common problem but I couldn't find yet a proper
solution (and I hope there is one).

I have two relative complex frameworks: one uses only iostream.h the
other one only iostream.
Is it somehow possible to put them together to one framework and solve
the iostream problem (also other header are effected, e.g. fstream)?
If I just change the header in one framework I get lots of errors,
which are very difficult to fix (at least for me).

Perhaps it's not going to be of much help, but believe me, you will be
so much better off if you just bite the bullet and fix all the errors
you get when you change the header to <iostream>. <iostream.h> is not
a standard header, basically not supported any more, old and ugly, and
sometimes slow or buggy. Tell your boss you need a couple of days to
clean all this mess up, and just do it.

Difficult does not mean impossible. You will learn a great deal while
making those fixes. Not only you will have a working system based on
the standard library, you will gain experience on code cleanup and in
dealing with fragile legacy frameworks the right way.

Best of luck!

V

[Dietmar Kuehl]

S. Nurbe wrote:

probably this is a common problem but I couldn't find yet a proper
solution (and I hope there is one).
I think this issue was discussed several times in past in this
forum though you might not like the answers.
I have two relative complex frameworks: one uses only iostream.h the
other one only iostream.
Is it somehow possible to put them together to one framework and solve the iostream problem (also other header are effected, e.g. fstream)?
Put very plain and simple: there is *NO* way to mix code compiled
with these headers. You have no other choice than transforming the
code using the ".h" version into code which does not use them. One
of the problems is that the libraries share certain common symbols
for objects with different object layouts.
If I just change the header in one framework I get lots of errors,
which are very difficult to fix (at least for me).

You should not just change the header but also add a using directive.
For example:

| #include <iostream.h>

should become

| #include <iostream>
| using namespace std;

The using directive is generally frowned upon, especially if it is
put into headers, but for a short-term approach to the conversion
it is essentially the only viable approach. On approach which often
works and eases the transistion is to provide your own version of
the .h-headers which essentially look something like below:

| // mystd/iostream.h
| #if !defined MYSTD_IOSTREAM_H
| #define MYSTD_IOSTREAM_H
| #include <iostream>
| using namespace std;
| #endif

You would direct the compiler to start searching for headers in the
directory you put the headers in, normally with a "-I" option like
'-Imystd'. Using headers like this should resolve most problems. A
few remaining problems would be caused by certain names which are
not supported by the standard like 'ios::nocreate' (this particular
flag can simply be dropped).

This should resolve the majority of problems. Actually, off-hand I
can't remember any other problems I had for projects where I made
the transistion. However, I'm quite familiar with the standard
IOStreams library and resolve most problems related to it without
much thinking. If you did as above and are still stuck with
problems you cannot resolve, I'm pretty sure somebody here can help
you out if you can post a small (but complete) fragment which causes
a problem when being compiled.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Dietmar Kuehl]

S. Nurbe wrote:

probably this is a common problem but I couldn't find yet a proper
solution (and I hope there is one).
I think the only solution to this problem was discussed in this
forum several times. You might, however, not like the answer:
essentially, you have no alternative than changing the code to
use the standard headers.
Is it somehow possible to put them together to one framework and solve the iostream problem (also other header are effected, e.g. fstream)?
Yes: change all uses of the .h-headers to uses of the standard
headers. Since the standard headers define their names in namespace
'std' you also need to change your code to search the names therein.
The easiest approach for a transistion like this is to use a using
directive, that is, you would change

| #include <iostream.h>

to become

| #include <iostream>
| using namespace std;

Using namespace directives like above, especially in headers, is
frowned upon and should normally not be done. However, it is a
viable approach if you need to port pre-standard C++ code. The
uses should eventually be removed and new code should neither
introduce them nor assume they are used somewhere else.

An approach easing this transistion is to provide your own version
of the .h-headers which look essentially like this:

| // file: mystd/iostream.h
| #if !defined(MYSTD_IOSTREAM_H)
| #define MYSTD_IOSTREAM_H 1
| # include <iostream>
| using namespace std;
| #endif /* MYSTD_IOSTREAM */

You would then direct the compiler to search the directory where
you put the headers first, typically with an option looking like
this: '-Imystd' (without the delimiting quotes, of course).

The remaining problems should be simple to resolve. Essentially,
only a few unnecessary flags (like 'ios::nocreate') were defined
in the pre-standard headers. You might also encounter uses of
'opfx()', 'osfx()', 'ipfx()', or 'isfx()' which are unavailable.
These are replaced by uses of 'std::ostream::sentry' and
'std::istream::sentry' but actually this is quite unlikely
(unless you had an IOStream expert in your team...). I don't
remember any other problems from the transistion (but then, I'm
quite familiar with the IOStreams library and just fix the code
rather than thinking much about it).
If I just change the header in one framework I get lots of errors,
which are very difficult to fix (at least for me).

There shouldn't be any problems which are difficult to fix. If
you did as described above and you are still stuck with a problem
I'm sure you can get help in this forum: just post a short excerpt
which displays the problems (you might want to search the group
archives for the respective problem before that since I remember
helping people with resolving the transistion problems before).
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Dietmar Kuehl]

Dietmar Kuehl wrote:
[a second reply to the original question...]

The beta of the google groups interface suc^Hffers from
substantial problems: it reported an error for my first reply
("Server error") and the article didn't show up for quite a
while. This lured me into writing a second reply... (which is,
however, a little bit more complete than the first one as I
remembered a particular but rare problem).
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[record700]

Hi,

it was less work to rewrite the code than I thought (curiously) but
now, when I add a library which previously worked I get a lot of linker
errors ~40, all from the same type) which I cannot solve:
one of them is this:
msvcprtd.lib(MSVCP71D.dll) : error LNK2005: "public: bool __thiscall
std::ctype<char>::is(short,char)const " (?is@?$ctype@D@std@@QBE_NFD@Z)
already defined in Calibration.obj

When I ignore msvcprtd.lib I get approx 400 linker errors like the
following:

NumRecCpp.lib(brent.obj) : error LNK2001: unresolved external symbol
"__declspec(dllimport) public: unsigned short __thiscall
std::basic_ios<unsigned short,struct std::char_traits<unsigned short>

::fill(void)const " (__imp_?fill@?$basic_ios@GU?$char_traits@G@std@@@s td@@QBEGXZ)

NumRecCpp.lib(mnbrak.obj) : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: unsigned short __thiscall
std::basic_ios<unsigned short,struct std::char_traits<unsigned short>::fill(void)const "

(__imp_?fill@?$basic_ios@GU?$char_traits@G@std@@@s td@@QBEGXZ)
referenced in function
__ehhandler$??$?6GU?$char_traits@G@std@@V?$allocat or@G@1@@std@@YAAAV?$basic_ostream@GU?$char_traits@ G@std@@@0@AAV10@ABV?$basic_string@GU?$char_traits@ G@std@@V?$allocator@G@2@@0@@Z

BTW: it's from numerical recipies...

What can that be?
P.S. The 'ios::nocreate' flag can just be ignored?

[record700]

OK, I fixed it - there was a problem with the compilation of one of the
libs...

[red floyd]

re*******@yahoo.de wrote:

Let me guess... you're using MATLAB 6.5(.x).

I had the same issue.