I should have noticed.......

The missing command line option is '-Ab'. This instructs the compiler to define the keyword bool.

The line causing the problem shows that bool is not defined (if you look at the source code).

There are two configuration files (in stlport directory):

 stl_user_config.h              This file is used by the user to tweak the library.
 config/stl_digital_mars.h   This file contains the Compiler setup.

Digital Mars only suports the STL part of STLport due to some limitations with templates.

If you have any problems or fixes for STLport please let us know as the official STLport site has not yet been informed of the changes made to support this compiler.


Damian.


On Tue, 5 Jun 2001 21:56:04 +0100, "Damian Dixon" <damian.dixon@virgin.net> wrote:
> Jan Knepper <jan@smartsoft.cc> wrote in message news:3B1D41A1.F61EB1A7@smartsoft.cc...
> > "Mark D. ANderson" wrote:
> >
> > CC:ed to c++.stl.port
> >
> > > "Damian Dixon" <damian.dixon@tenetdefence.com> wrote in message
> news:1103_991727358@dilbert...
> > > > The following code compiles and runs on my machine:-
> > > >
> > > > -------start of mda1.C
> > > > #include <iostream>
> > > >
> > > > int main()
> > > > {
> > > >   cout << "Hello" << endl;
> > > >   return 1;
> > > > }
> > > > -------end of mda1.C
> > >
> > > that works for me too.
> 
> As I expected :>
> 
> > > however, amazingly, if I change it to this:
> > > -----
> > > #include <hash_map>
> > >
> > > int main()
> > > {
> > >   return 1;
> > > }
> > > -----
> > >
> > > i get obscure compiler errors again:
> > > ...
> > >       'd:/devtools/C/dm-stlport-4.0/stlport\stl/_relops.h'
> > > d:/devtools/C/dm-stlport-4.0/stlport\stl/_relops.h(38) : Error: function
> expected
> > > template <class _Tp>
> > >        ^
> > > ...
> > > i thought it first it might be because of using unix line endings in
> mda1.C (does dm support those?)
> >
> > Never had a problem with those... Move my files around all the time...
> 
> I will have a look when I get into work on Wednesday. I will reserve comment until then :>
> 
> >
> > > this has got to be something basic.
> > > note that all i did was unzip the dm compiler, and unzip the stlport,
> and go.
> > > i didn't edit any config files, either ini or config.h. but that should
> work, right?
> >
> > I think you might need certain 'defines' for STLport to work. Damian: Is there any #define that you require for your patches to go active during compilation???
> 
> You should not need to do anything to get it all to compile. It has all been
> preconfigured
> (see the digital mars README for additional information, for my test
> configuration).
> 
> All you need to do is point the compiler to where STLport has been installed.
> 
> > The best person to talk to is Damian Dixon.
> >
> > I myself use the HP STL and SGI STL that are also available on the site.
> >
> > HTH
> > Jan
> 
> Damian (Home)
> 
> 

"Mark D. ANderson" wrote:

> > Compiled with:
> > sc Test.cpp -cpp -Ae -Ar -mn -WA -S -5 -a8 -Nc -c -g -Ab -D_CONSOLE=1 -D_DEBUG=1 -I..\.. -I. -o.\Test.obj
> > link /NOI /DO /DE /E /PACKF /XN /NT /ENTRY:mainCRTStartup /VERS:1.0 /BAS:4194304 /A:512 @Test.LNK
> > ren .\$SCW$.EXE Test.EXE
> > .\Test.EXE built
>
> ah. now we are making progress. that exact command line worked for me.
> i did a binary search of options to figure out what the ingredient was, and discovered that the -Ab is necessary.
> so i can now compile this program:
> #include <hash_map>
> int  main () {
>    return (  0 );
> }
> using this command line:
> d:/devtools/C/dm-815c/bin/SC -cpp -Ab -Id:/devtools/C/dm-stlport-4.0/stlport -o -w  nothing.C  -o nothing
> that is, with stlport and just -cpp -Ab

I think you can just start:
sc <Enter>
and get all the command line switches.

> [aside: if i'm compiling C++, it should presume the bool type. -Ab should be irrelevant]

Why?
There is legacy code...
May be a new thing for the next compiler would be -Ab- to turn it off. Walter?

> however, the program fails with sgi stl (using any of the options):
> d:/devtools/C/dm-815c/bin/SC -cpp -Ae -Ar -mn -WA -S -5 -a8 -Nc -c -g -Ab -D_CONSOLE=1 -D_DEBUG=1 -Id:/devtools/C/sgistl-3.20 -o -
> w    nothing.C   -o nothing
> d:/devtools/C/sgistl-3.20\stl_algo.h(875) : Error: ')' expected
> [looking at that line in the file, i'm guessing it considers some parameter to be a macro? who knows.]

Will have to check into that one.
Have you tried to compile the samples that I think come with SGI STL?
I think they reside in SGI/SC

> furthermore, if i'm feeling lucky and try to add to my program, stlport still fails too:
> #include <hash_map>
> #include <iostream>
> using namespace std;
> int main() {
>   cout << "Hello" << endl;
>   return (0);
> }
>
> d:/devtools/C/dm-815c/bin/SC -cpp -Ae -Ar -mn -WA -S -5 -a8 -Nc -c -g -Ab -D_CONSOLE=1 -D_DEBUG=1 -Id:/devtools/C/dm-stlport-4.0/s
> tlport -o -w    nothing.C   -o nothing
> using namespace std;
>                    ^
> nothing.C(3) : Error: identifier expected

I think that should be #ifdef'ed out as Symantec just recognizes the keywords, but does not have the semantic's implemented yet...

> but it works without the namespace statement. so is there yet another option that is supposed to enable namespaces?

Nop...

> btw, what is the origin of that command line above? is this what the symantec gui generates?

Yes, it is what the IDDE generates...

> am i the only one in the world trying to use the win32 dm compiler armed with just emacs and gmake?

No. There are previous Symantec C++ users that have the IDDE into which the newer compilers fit without any problems.

Actually, I think the CD-ROM is for sale right now on the website, which contains a complete IDDE for Win32, Win32s and Win16...

> > > btw Jan -- why are you using HP and SGI STL instead of stlport?
> >
> > Personal preference I guess. I guess I was the first to use (port) SGI STL with Digital Mars C++. John Fletcher did some work on porting the string part.
> my understanding is that the HP stl is older and crustier than just about everything.

Probably... I personally think that the *idea* of STL was nice, but that the *design* and *implementation* could have been done a LOT
better.

> how much different is stlport from sgi stl?

Not much I think. I thought, but I am not sure that STLport actually uses one of the SGI STL versions...

> is there some benefit to using a patched sgi stl, rather than using stlport?

Not that I am aware of.

Jan

> > [aside: if i'm compiling C++, it should presume the bool type. -Ab should be irrelevant]
>
> Why?
> There is legacy code...
> May be a new thing for the next compiler would be -Ab- to turn it off. Walter?

my feeling is that out of the box, a compiler should successfully compile a program
compliant with the most recent international standards (C99 and C++98).
it should take options to make it work with legacy programs.

and of course the error message should be improved, and the documentation should make the situation clearer.

> Have you tried to compile the samples that I think come with SGI STL? I think they reside in SGI/SC

the sgi stl download from the dm web site has no subdirs at all.

> > using namespace std;
> >                    ^
> > nothing.C(3) : Error: identifier expected
>
> I think that should be #ifdef'ed out as Symantec just recognizes the keywords, but does not have the semantic's implemented
yet...

yikes, dm has no namespace support? is this documented in some salient place that i missed? is there a summary of what parts of the standard are not implemented?

and btw, where is the config for sgi stl? in the sgi stl download, stl_config.h has no mention of symantec, zotech, or digitalmars. there is also no README.digital_mars file as there is with the stlport download.

in the stlport download, i did find the stlport/config/stl_digital_mars.h.
looking at that, there seem to be quite a few things no supported (ah, and i see among them
the #define __STL_HAS_NO_NAMESPACES 1).

so i think my current situation is:
1. stlport works with -cpp -Ab.
2. the sgi stl download seems to not work, but that isn't too surprising since there is no sign in the download
of any ifdef's for symantec or digital_mars.
3. my code has avoid using a variety of standard C++ capabilities, whose documentation i currently can't find;
they are certainly not mentioned in http://www.digitalmars.com/ctg/ctgLanguageImplementation.html which seems
oblivious to the C++98 standard even existing.

-mda

"Mark D. ANderson" wrote:

> the sgi stl download from the dm web site has no subdirs at all.

What did you download? the .zip or the .gz file?

> > > using namespace std;
> > >                    ^
> > > nothing.C(3) : Error: identifier expected
> >
> > I think that should be #ifdef'ed out as Symantec just recognizes the keywords, but does not have the semantic's implemented
> yet...
> yikes, dm has no namespace support? is this documented in some salient place that i missed?
> is there a summary of what parts of the standard are not implemented?

Well, there is 'namespace' support, but that is according to the first lines written about namespace definition which was rather
unclear at that particular time.

> and btw, where is the config for sgi stl? in the sgi stl download, stl_config.h has no mention of symantec, zotech, or digitalmars. there is also no README.digital_mars file as there is with the stlport download.

Look for __SC__ and / or __DMC__ which are macro's defined by the compiler.
You'll find a section in 'stl_config.h' and 'string' were changes have been made to support the compiler.

> in the stlport download, i did find the stlport/config/stl_digital_mars.h.
> looking at that, there seem to be quite a few things no supported (ah, and i see among them
> the #define __STL_HAS_NO_NAMESPACES 1).

Yup! You'll find the same thing in stl_config.h in the #ifdef __SC__ block.

> so i think my current situation is:
> 1. stlport works with -cpp -Ab.
> 2. the sgi stl download seems to not work, but that isn't too surprising since there is no sign in the download of any ifdef's
> for symantec or digital_mars.

Better look again...

> 3. my code has avoid using a variety of standard C++ capabilities, whose documentation i currently can't find; they are
> certainly not mentioned in http://www.digitalmars.com/ctg/ctgLanguageImplementation.html which seems
> oblivious to the C++98 standard even existing.

I don't think the compiler was ever brought up to the C++98 standard. (I could be wrong). There are things deviating from that standard as 'namespace' usage and several template things.

Jan

"Mark D. ANderson" wrote:

> the sgi stl download from the dm web site has no subdirs at all.

Get the .tar.gz file. WinZip can extract that for you.
So can PKZip I think.

Jan

> > the sgi stl download from the dm web site has no subdirs at all.
>
> What did you download? the .zip or the .gz file?

the zip. i just now downloaded the .gz.
not only does it have the subdir, it has different contents for common files!
there are slight differences in stl_config.h and string, for example.

in fact, the sgi stl from the tar ball *does* compile my simple program, while the one from
the zip does not (errors sent out earlier in the thread):
#include <hash_map>
#include <iostream.h>
int main() {
  cout << "Hello" << endl;
  return (0);
}

so using the CVS release tar ball (instead of the zip file), i'm now at the same level of ability with the stlport and sgi libraries. that is, i'm now up to the point of confronting unspecified noncompliance by the compiler, but no longer mysteries buried in the standard libraries.

so what is the point of the hp/sgi/stlport zip downloads at all?
the download page could certainly clarify what those downloads are, since apparently
they don't correspond to any version in CVS?
the download page should have an alert there which says:
      NOTICE: We are prominently placing these zip downloads just to waste your time; they don't work.

(sorry, letting off steam).

> Look for __SC__ and / or __DMC__ which are macro's defined by the compiler.
> You'll find a section in 'stl_config.h' and 'string' were changes have been made to support the compiler.

ah yes, i found them. but as they differ between the tar ball and the zip, and neither has any proper dm-specific readme file, it is hard to decipher the status.

>I don't think the compiler was ever brought up to the C++98 standard. (I could be wrong).

is this being worked on? what is the status?


-mda

"Mark D. ANderson" wrote:

> > > the sgi stl download from the dm web site has no subdirs at all.
> >
> > What did you download? the .zip or the .gz file?
>
> the zip. i just now downloaded the .gz.
> not only does it have the subdir, it has different contents for common files!
> there are slight differences in stl_config.h and string, for example.
>
> in fact, the sgi stl from the tar ball *does* compile my simple program, while the one from
> the zip does not (errors sent out earlier in the thread):
> #include <hash_map>
> #include <iostream.h>
> int main() {
>   cout << "Hello" << endl;
>   return (0);
> }

That's what I was afraid of.
The problem is that all the sources are kept in CVS. There is a RELEASE and a HEAD export every night which
both are being placed in .tar.gz files.
Appearantly I *never* created a new .zip file with the latest changes.

> so using the CVS release tar ball (instead of the zip file), i'm now at the same level of ability with the stlport and sgi libraries. that is, i'm now up to the point of confronting unspecified noncompliance by the compiler, but no longer mysteries buried in the standard libraries.

You should be...

> so what is the point of the hp/sgi/stlport zip downloads at all?

Ancience I guess...
The files *used* to be available in .zip only. Than the site was transferred from smartsoft.cc to
digitalmars.com and because we host the sites ourselved features have been added such as the timely CVS exports
while older stuff stayed on for historical reasons.

> the download page could certainly clarify what those downloads are, since apparently they don't correspond to any version in CVS?

That's correct.

> the download page should have an alert there which says:
>       NOTICE: We are prominently placing these zip downloads just to waste your time; they don't work.
>
> (sorry, letting off steam).

<g>
The site isn't overly clear about it. That's true. However, I would say that someone who reads all the
information *before* downloading anything could have made up the the RELEASE version in .tar.gz format is
probably the best download.

> > Look for __SC__ and / or __DMC__ which are macro's defined by the compiler.
> > You'll find a section in 'stl_config.h' and 'string' were changes have been made to support the compiler.
> ah yes, i found them. but as they differ between the tar ball and the zip, and neither has any proper dm-specific readme file, it is hard to decipher the status.

Sorry, the status is 'work in progress' I guess... <g>
I think the RELEASE version states clear enough on the website that it is being used in application
development...
The RELEASE version is basically 'patched to work with DMC++'
I think the current RELEASE and HEAD version are the same, but I am not completely sure.

> >I don't think the compiler was ever brought up to the C++98 standard. (I could be wrong).
> is this being worked on? what is the status?

Last I understood from Walter is that he is planning on changing this, but that might take some time. The first goal was to get the product complete and sellable again.

Jan

Just to clear up some mis-conceptions:

STLport for Digital Mars is based on version 4.0 of STLport.

STLport is closer to the standard  then the HP STL or the SGI STL on the Digital Mars web-site.

The Readme for Digital Mars does mention the '-Ab' flag being required. It just took me awhile to realise what was missing from the command line :<

A series of tests are provided in the test directory (I have to admit that they require the GUI to build. I will look at updating to allow command line build via a makefile).

STLport includes STL plus a standard library header wrapper and C++ library
(where the C library leaves off and the C++ standard takes over).
HOWEVER only the STL part of STLport has been configured and tested
(testing is limited to the tests provided with STLport see comments above).

SGI STL does not include the standard header wrappers or the new
C++ library. When the compiler becomes more compliant the reasons for
using STLport will become greater. For now the main reason for using STLport
rather then SGI STL is that it is closer to the Standard STL and probably
contains more bug fixes and provides the header wrappers for the C
library.

'namesapce std' is not supported by STLport (digital mars configuration).

Exceptions have not been configured or tested for STLport.

Old iostreams are used rather then the new iostreams that comes with STLport

The following compiler limitations affect STLport configuration:

  template partial specialisation
  template specialisation

A more concise list can be found in stlport/config/stl_digital_mars.h. Comapre the defines against the STLport documentation on http://www.stlport.org

I think that covers most things. If either Mark or Jan have any questions please email me at damian.dixon@virgin.net and damian.dixon@tenetdefence.com as I only check the newsgroups once may be twice a day.


Regards,
Damian


On Tue, 05 Jun 2001 22:54:27 -0400, Jan Knepper <jan@smartsoft.cc> wrote:
> "Mark D. ANderson" wrote:
> 
> > oh, and in case it wasn't clear before, the test file *does* compile just fine, using the stlport or the sgi stl, using g++.
> 
> Could very well be...
> 
> There are a *LOT* of things Digital Mars C++ does perfectly well were the compiled code out of g++ fails. (Believe me... I soon have to port TONS of code to a Unix platform and I already know that g++ will not compile it as is....) I am not saying it's better, just that what you are familiar with usually works better or easier. For me it's Digital Mars C++...
> 
> Jan
> 
> 

Mark D. ANderson wrote in message <9fm19v$2t62$1@digitaldaemon.com>...
>so i think my current situation is:
>1. stlport works with -cpp -Ab.


The -Ab is a legacy from the bad old days when bool was a brand new keyword, and no code depended on it. It is certainly time to make it the default.

>3. my code has avoid using a variety of standard C++ capabilities, whose
documentation i currently can't find;
>they are certainly not mentioned in
http://www.digitalmars.com/ctg/ctgLanguageImplementation.html which seems
>oblivious to the C++98 standard even existing.


That bit of documentation is at least 5 years old, and you're right, it needs updating.