"Walter" <walter@digitalmars.com> wrote in news:9s9r4r$2djk$2@digitaldaemon.com:

> No, I didn't try your example, because I've seen the issue before, and if it does eventually terminate, it is the same old problem. Sometimes innocent looking code (!) can bloat up enormously once all the inline functions and templates get instantiated (now where have I seen code like that...).

Hmmm... it this a subtle hint? ;)  I did this sometimes, some time ago, but I like to believe that my C++ knowledge has improved since then... :)

I don't think my particular code sample generates extremely bloated code (I only push_back a few items, and then scan the vector with iterators). Indeed, there are some header files to process, and compiling parse_cfg.cpp also takes a little longer with both gcc and BCC, but it's about 1-2 seconds more than for other files, not 10 minutes.  This amazed me because DMC compiles the other files faster, and generates smaller code than the other 2 compilers (less than half the size of BCC gen'd code, even in X32 version - awesome!!).

> The ^C bug I need to check into. The compiler does ^C trapping so it will clean up half-built .obj files and dangling resources.

Oh, I'm getting back the prompt, but the process stays in the back (still compiling, probably, since it gets 99% CPU time, and doesn't stop unless I kill it from Task Manager).  It looks like it detaches from its console, but never terminates.

Thanks for your prompt answer!

Laurentiu

"Walter" <walter@digitalmars.com> wrote in news:9s9r4q$2djk$1@digitaldaemon.com:

> I have no ideological preference between the various STL versions, I'm just a victim of practicality. The requirements are:
> 
> 1) It conforms as much as practical to the C++98 standard.
> 2) It comes with unrestricted redistributable source & documentation.
> 3) Digital Mars can sell it on the Digital Mars CD as well as make it
> freely available online.
> 4) Digital Mars is happy to acknowledge any copyrights or trademarks of
> the authors.
> 5) No fees or royalties are charged for redistribution.
> 6) I don't understand all the legal ramifications of using GPL'd code,
> so I'd rather avoid it for now.
> 
> SGI's STL fits the bill. If another does a better job, I'd be happy to switch (or provide both). I'd welcome any contributions, though I cannot pay you for them. When DMC++ sells for $500/copy, then I can pay real salaries <g>.

I think STLport also fits your requirements (I'm not sure if you may charge for distributing STLport, by itself - I'm no lawyer, take a look at http://www.stlport.org/doc/license.html.  It looks like a BSD-style license to me!).

WRT contributions, I wouldn't expect to get paid (I have a programming job, and I'm earning enough).  I would be happy to contribute... I already ported the V GUI toolkit to DMC, and provided some DEF files, but, since my repeated calls for a contrib repository were ignored by DigitalMars, I thought maybe you don't need any help...  :(

Of course, making a standard compliant iostream lib for DMC (or other fundamental C++ library) would be much more challenging than porting GUI stuff!!!  ;)

So, if you have any idea of something useful for DMC, let us know!  I really like the compiler, and having a code base as large as possible, wouldn't hurt at all!

Regards,
  Laurentiu

Walter wrote:
> I have no ideological preference between the various STL versions, I'm
> just a victim of practicality. The requirements are:
> 1) It conforms as much as practical to the C++98 standard.
> 2) It comes with unrestricted redistributable source & documentation.
> 3) Digital Mars can sell it on the Digital Mars CD as well as make it
> freely available online.
> 4) Digital Mars is happy to acknowledge any copyrights or trademarks of
> the authors.
> 5) No fees or royalties are charged for redistribution.
> 6) I don't understand all the legal ramifications of using GPL'd code,
> so I'd rather avoid it for now.

Hmm, the STLport license (http://www.stlport.org/doc/license.html) seems to also fit your requirements - it's definitely not GPL'd.


bye, Christof

-- 
http://cmeerw.cjb.net                             JID: cmeerw@jabber.at mailto cmeerw at web.de

...and what have you contributed to the Net?

I would prefer STLport over the SGI version, basically because it goes significantly further then just STL.

It also includes most of the new standard library.

At the moment the best I can do is to get the STL part kind of working of STLport because it is more heavily dependent on a fuller template implementation then the SGI STL.

Regards
Damian

"Walter" <walter@digitalmars.com> wrote in message news:9s92qc$1sur$3@digitaldaemon.com...
>
> "Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:Xns915168DFD699Fplaurcrosswindsnet@63.105.9.61...
> > Yes, you're right... the problem is caused by the STL implementation DMC 8.22 comes with (stl_vector.h, line 672).  It works fine with STLport. Perhaps it would be better to make STLport the official STL
implementation
> > that comes with DMC?  AFAIK, Borland also plans to do this in BCC 6.x, instead of using the RogueWave implementation, as they currently do.
>
> I really have no idea of the merits of the various implementations. I thought the SGI one was the standard one. I did my best to compile it 'as is'.
>
> As for namespaces, the namespaces are implemented per the ARM. Unfortunately, the feature evolved a lot since then. I was intending to
work
> on that after the template stuff was working satisfactorilly.
>
>

> This amazed me because DMC compiles the other files faster, and generates smaller code than the other 2 compilers (less than half the size of BCC gen'd code, even in X32 version - awesome!!).

"There can be only one" - High Lander

Jan Knepper <jan@smartsoft.cc> wrote in news:3BE93F17.5871B782@smartsoft.cc:

>> This amazed me because DMC compiles the other files faster, and generates smaller code than the other 2 compilers (less than half the size of BCC gen'd code, even in X32 version - awesome!!).
> 
> "There can be only one" - High Lander

Easy, McLeod, I only said "smaller", not faster... :)

My real app is executed in:
- 485 seconds (MinGW)
- 350 seconds (DMC 8.22)
- 217 seconds (BCC 5.5.1)
- 115 seconds (MSVC6SP5, they seem to be real good in fp!)

As I mentioned, the bottle neck is the large number of integrations, so it's a weird loop that is optimized better or worse by different compilers.  Even a few cycles gained due speculative execution side-effects (Athlon has more FPUs) really make a difference in this case.  Unrelevant, though... before rewriting the code, DMC was first, followed by gcc and BCC.  Maybe I should rewrite it again, so gcc would get first?  ;)

But, as we all already know, DMC *is* a very good compiler: very good code quality in most cases, and many supported targets.  The only thing that I miss in DMC in ISO-C++ compliance.  But I hope this will come...


Laurentiu

The license for STLport looks good. It might be worthwhile to support both, but it also seems clear that the compiler template support has to get better before STLport will work.

As for useful contributions and that I'd appreciate, any of the missing standard library code would be great!

I don't know anything about V GUI and I do apologize for that. It's all I can do to keep up with C, C++, D and Dscript.

"Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:9saukl$b9e$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in news:9s9r4q$2djk$1@digitaldaemon.com:
>
> > I have no ideological preference between the various STL versions, I'm just a victim of practicality. The requirements are:
> >
> > 1) It conforms as much as practical to the C++98 standard.
> > 2) It comes with unrestricted redistributable source & documentation.
> > 3) Digital Mars can sell it on the Digital Mars CD as well as make it
> > freely available online.
> > 4) Digital Mars is happy to acknowledge any copyrights or trademarks of
> > the authors.
> > 5) No fees or royalties are charged for redistribution.
> > 6) I don't understand all the legal ramifications of using GPL'd code,
> > so I'd rather avoid it for now.
> >
> > SGI's STL fits the bill. If another does a better job, I'd be happy to switch (or provide both). I'd welcome any contributions, though I cannot pay you for them. When DMC++ sells for $500/copy, then I can pay real salaries <g>.
>
> I think STLport also fits your requirements (I'm not sure if you may
charge
> for distributing STLport, by itself - I'm no lawyer, take a look at http://www.stlport.org/doc/license.html.  It looks like a BSD-style
license
> to me!).
>
> WRT contributions, I wouldn't expect to get paid (I have a programming
job,
> and I'm earning enough).  I would be happy to contribute... I already ported the V GUI toolkit to DMC, and provided some DEF files, but, since
my
> repeated calls for a contrib repository were ignored by DigitalMars, I thought maybe you don't need any help...  :(
>
> Of course, making a standard compliant iostream lib for DMC (or other fundamental C++ library) would be much more challenging than porting GUI stuff!!!  ;)
>
> So, if you have any idea of something useful for DMC, let us know!  I really like the compiler, and having a code base as large as possible, wouldn't hurt at all!
>
> Regards,
>   Laurentiu

"Damian Dixon" <damian.dixon@tenet.co.uk> wrote in message news:9sb8p2$i6u$1@digitaldaemon.com...
> I would prefer STLport over the SGI version, basically because it goes significantly further then just STL.
>
> It also includes most of the new standard library.
>
> At the moment the best I can do is to get the STL part kind of working of STLport because it is more heavily dependent on a fuller template implementation then the SGI STL.


It does sound like it will fit the bill better.

On Wed, 7 Nov 2001 09:24:38 +0000 (UTC), Laurentiu Pancescu
<plaur@crosswinds.net> wrote:

>"Walter" <walter@digitalmars.com> wrote in news:9s9r4q$2djk$1@digitaldaemon.com:
>
>> I have no ideological preference between the various STL versions, I'm just a victim of practicality. The requirements are:
>> 
>> 1) It conforms as much as practical to the C++98 standard.
>> 2) It comes with unrestricted redistributable source & documentation.
>> 3) Digital Mars can sell it on the Digital Mars CD as well as make it
>> freely available online.
>> 4) Digital Mars is happy to acknowledge any copyrights or trademarks of
>> the authors.
>> 5) No fees or royalties are charged for redistribution.
>> 6) I don't understand all the legal ramifications of using GPL'd code,
>> so I'd rather avoid it for now.
>> 
>> SGI's STL fits the bill. If another does a better job, I'd be happy to switch (or provide both). I'd welcome any contributions, though I cannot pay you for them. When DMC++ sells for $500/copy, then I can pay real salaries <g>.
>
>I think STLport also fits your requirements (I'm not sure if you may charge for distributing STLport, by itself - I'm no lawyer, take a look at http://www.stlport.org/doc/license.html.  It looks like a BSD-style license to me!).
>
>WRT contributions, I wouldn't expect to get paid (I have a programming job, and I'm earning enough).  I would be happy to contribute... I already ported the V GUI toolkit to DMC, and provided some DEF files, but, since my repeated calls for a contrib repository were ignored by DigitalMars, I thought maybe you don't need any help...  :(
>
Could you tell me more about the V port, I wasn't very succesfull finding info on that.

Chris.

>Of course, making a standard compliant iostream lib for DMC (or other fundamental C++ library) would be much more challenging than porting GUI stuff!!!  ;)
>
>So, if you have any idea of something useful for DMC, let us know!  I really like the compiler, and having a code base as large as possible, wouldn't hurt at all!
>
>Regards,
>  Laurentiu

"Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:Xns9152CF66AEA8Bplaur@63.105.9.61...
> My real app is executed in:
> - 485 seconds (MinGW)
> - 350 seconds (DMC 8.22)
> - 217 seconds (BCC 5.5.1)
> - 115 seconds (MSVC6SP5, they seem to be real good in fp!)
>
> As I mentioned, the bottle neck is the large number of integrations, so
it's
> a weird loop that is optimized better or worse by different compilers.
Even
> a few cycles gained due speculative execution side-effects (Athlon has
more
> FPUs) really make a difference in this case.

In many cases, DMC will generate slower FPU code because it takes pains to generate correct IEEE standard compliant code. This means, for example, that all comparisons need to be double checked for NANs. The last time I checked, MSVC did not do this. Also, floating point constant folding is NOT done if the folding would raise the inexact flag.

Much of this can be disabled with the -ff switch, which would be close to an apples-apples comparison with other compilers.