I need to port an existing application to DOS16 or DOS32 (if the dos extender works on our platform). The application makes heavy use of STL.

Is there any way to use STLPort?

I'm currently using SGI STL, but have the following problem when including certain headers, such as <string>:
---------
dmc test.cpp -cpp -mld -ID:\dm\stl-sgi

class __Named_exception : public __STL_EXCEPTION_BASE {
^
D:\Programs\dm\stl-sgi\stdexcept(26) : Error: identifier expected
D:\Programs\dm\stl-sgi\stl_algo.h(1001) : Error: ')' expected
D:\Programs\dm\stl-sgi\stl_algo.h(1025) : Error: ')' expected
D:\Programs\dm\stl-sgi\stl_algo.h(1050) : Error: ')' expected
D:\Programs\dm\stl-sgi\stl_algo.h(1072) : Error: ')' expected
Fatal error: too many errors
-----------
or
-----------
E|> dmc test.cpp -cpp -Ae -Ar -mld -ID:\dm\stl-sgi
{
^
D:\Programs\dm\bin\..\include\exception(25) : Error: typedef name 'type_info' ca
nnot be used following class-key
public:
^
D:\Programs\dm\bin\..\include\exception(29) : Error: '=', ';' or ',' expected
bool __cdecl operator==(const type_info& rhs) const;
^
D:\Programs\dm\bin\..\include\exception(31) : Error: static or non-member functi
ons can't be const or volatile
bool __cdecl operator!=(const type_info& rhs) const;
^
D:\Programs\dm\bin\..\include\exception(32) : Error: static or non-member functi
ons can't be const or volatile
bool __cdecl before(const type_info& rhs) const;
^
D:\Programs\dm\bin\..\include\exception(33) : Error: static or non-member functi
ons can't be const or volatile
Fatal error: too many errors
--- errorlevel 1
-----------


Any ideas?

Are there any other STL implementations out there that may help me?

Thanks,
Jason

Jason Mills wrote:
> Are there any other STL implementations out there that may help me?

You could try the recent STLport 4.6.2 code I just released. STLport continued development on the SGI code base.

In article <cjuolq$iot$2@digitaldaemon.com>, Scott Michel says...
>
>Jason Mills wrote:
>> Are there any other STL implementations out there that may help me?
>
>You could try the recent STLport 4.6.2 code I just released. STLport continued development on the SGI code base.

I downloaded 4.6.2 from STLPort's website, but it failed to compile. It does not have a make file for dmc, so I used an older one. I don't know if that is the source of the problem.

Other newgroup posts suggests STLPort does not work when compiling
for DOS16 or DOS32. So maybe its a waste of effort trying to compile 4.6.2,
unless support for DOS has been added.

Jason Mills wrote:
> I downloaded 4.6.2 from STLPort's website, but it failed to compile. It
> does not have a make file for dmc, so I used an older one. I don't know
> if that is the source of the problem.
> 
> Other newgroup posts suggests STLPort does not work when compiling
> for DOS16 or DOS32. So maybe its a waste of effort trying to compile 4.6.2,
> unless support for DOS has been added.

<clue>Read the c++.stl.port newsgroup</clue>

I haven't attempted to create DOS32 or DOS16 libraries, but if you're willing to put a little effort, you can probably use my dm.mak makefiles as a template to get you started.

That said, it might be a waste of time if others aren't successful.


-scooter

"Jason Mills" <Jason_member@pathlink.com> wrote in message news:cjv14p$rbo$1@digitaldaemon.com...
> In article <cjuolq$iot$2@digitaldaemon.com>, Scott Michel says...
> >
> >Jason Mills wrote:
> >> Are there any other STL implementations out there that may help me?
> >
> >You could try the recent STLport 4.6.2 code I just released. STLport continued development on the SGI code base.
>
> I downloaded 4.6.2 from STLPort's website, but it failed to compile. It does not have a make file for dmc, so I used an older one. I don't know if that is the source of the problem.
>
> Other newgroup posts suggests STLPort does not work when compiling for DOS16 or DOS32. So maybe its a waste of effort trying to compile
4.6.2,
> unless support for DOS has been added.

You might want to look at \dm\stlport\diff.txt, which is the changes needed to make STLPort work with DMC++.

One problem you'll run into with DOS16 and DOS32 is that there isn't much of any support for wide characters. There's no way to add it in, either, since DOS doesn't support unicode.

Walter wrote:
> One problem you'll run into with DOS16 and DOS32 is that there isn't much of
> any support for wide characters. There's no way to add it in, either, since
> DOS doesn't support unicode.

This can be turned off by tweaking stlport\stl\stl_dm.h when you build a custom version of the libraries (which is what Jason will probably have to do.) Unless, of course, you happen to need it... or are willing to interface a Unicode library to the runtime. :-)

I kept the wide character code turned on because that's what a lot of people will use in Win32.


-scooter