Same problem in DigMars C++ 7.51, Win32 environment, newly arrived on CD. A
solution would be appreciated.
Like Steve, I also found that it was necessary to include the path to
dm/stlport/stlport and also the same+ /stl in order to recognize <iostream>,
dirent.h, etc. That would appear to be an omission in C++ as delivered.
A related puzzle: whereas the syntax errors reported by Steve listed 'fgetwc',
'fgetws', 'fputwc', and 'fputws' as the offending "unidentified identifiers",
the compiler is telling me instead that 'fgetws', 'fputws', 'getwchar' and
'getwc' can't be found, while it doesn't complain about 'fgetwc' and 'fputwc'.
In any case, these identifiers are in fact not found in wchar.h, which is
included in <cwchar>, which is evidently invoked by something else up the chain
to <iostream>.
- Ralph Bertonaschi

I will say that using <iostream.h> without including the stlport Include and the
std:: designation works fine so the problem isn't grave. I just wondered.
http://www.obsoletedigital.com
"To play is to pray"
--Rev. Lance Swagger

Same problem in DigMars C++ 7.51, Win32 environment, newly arrived on CD. A
solution would be appreciated.
Like Steve, I also found that it was necessary to include the path to
dm/stlport/stlport and also the same+ /stl in order to recognize <iostream>,
dirent.h, etc. That would appear to be an omission in C++ as delivered.

Not really. STLport is open source software, as to be bundled separately
from DM proper. Plus, there're a program that likely depend on the older
header files.
You're always free to change/modify/update/hack/maim/slaughter the
sc.ini file in any way you see fit. Add the \dm\stlport\stlport
directory to the INCLUDE setting.

A related puzzle: whereas the syntax errors reported by Steve listed 'fgetwc',
'fgetws', 'fputwc', and 'fputws' as the offending "unidentified identifiers",
the compiler is telling me instead that 'fgetws', 'fputws', 'getwchar' and
'getwc' can't be found, while it doesn't complain about 'fgetwc' and 'fputwc'.
In any case, these identifiers are in fact not found in wchar.h, which is
included in <cwchar>, which is evidently invoked by something else up the chain
to <iostream>.

I'm not entirely sure which version of STLport Walter is shipping with
DM these days. I haven't gotten around to porting STLport 5 yet, but an
updated version 4.6.2 for DMC can be had from
http://mordred.cs.ucla.edu/STLport_DMC/
Hope that helps.

<iostream> relies on wide character support in the operating system, which
does not exist for DOS and DOS memory models. Besides, <iostream> is simply
too big for 16 bit programs.
Use instead the older <iostream.h> when working with DOS.
STL in general is not supported in 16 bit memory models.

<iostream> relies on wide character support in the operating system, which

too big for 16 bit programs.
Use instead the older <iostream.h> when working with DOS. STL in general is not
supported in 16 bit memory models.

Thanks - I'm in the IDDE and Win32 environment, and anyway it's the same problem
w/ <iostream.h>; maybe it's <string> that does it. I guess I should have put my
query in the STLport newsgroup, which I've just found and read. "Drake" in Apr
'04 suggested this:
#define _STLP_NO_NATIVE_WIDE_FUNCTIONS = 1
which I did, in the program I'm using to evaluate DMC compared some other
compilers. It then got past the "unidentified identifiers" 'getwchar" etc. So
far so good, having compiled just that file via the IDDE editor, but when I try
project "build", those identifiers are still missing and the build fails.
I took a look at the STLport download information at the UCLA site that Scott
suggested and ... well, having seen the difficulties reported by some evidently
very competent individuals in the STLport newsgroup thread, it would seem to be
a poor use of time to go ahead and download the thing, figure out what all of
the flags mean, and hope get it right, all on the if-come that it just might
work under 4.6.2, when the real objective (for this non-Computer Science person)
is to get an application written and running. Hopefully another DMC release
will solve this problem, which is evidently not mine alone.
I remain amazed at the prompt replies to me and at the hard work, intelligence
and attention to detail that are evident from the dialogues in the news forum,
on the part of individuals (like yourselves) who must be extraordinarily busy.
- RB

too big for 16 bit programs.
Use instead the older <iostream.h> when working with DOS. STL in general

supported in 16 bit memory models.

Thanks - I'm in the IDDE and Win32 environment, and anyway it's the same

w/ <iostream.h>; maybe it's <string> that does it. I guess I should have

query in the STLport newsgroup, which I've just found and read. "Drake" in

'04 suggested this:
#define _STLP_NO_NATIVE_WIDE_FUNCTIONS = 1
which I did, in the program I'm using to evaluate DMC compared some other
compilers. It then got past the "unidentified identifiers" 'getwchar"

far so good, having compiled just that file via the IDDE editor, but when

project "build", those identifiers are still missing and the build fails.

STLPort wasn't designed to work for 16 bit builds nor was it tested for 16
bit builds. There are two iostream.h's:
\dm\include\iostream.h
\dm\stlport\stlport\iostream.h
Use the first one, which means do not allow \dm\stlport\stlport to be on
your INCLUDE path. Check the INCLUDE environment variable, and any sc.ini
you're using, and the default sc.ini in \dm\bin to make sure the stlport one
isn't being included.
While DMC++ fully supports exception handling and templates for 16 bit code,
the full featured bloat of STL is too big for 16 bit programming, where
saving every byte is a necessary fact of life.