www.digitalmars.com         C & C++   DMDScript  

c++ - more bugs in 8.22 (for Walter) - 1 attachment

reply DigitalMars <plaur crosswinds.net> writes:
The code in attachment takes extremely long time to compile.  With "sc -c -
o+none parse_cfg.cpp", it compiles immediately, with -o+all it takes about 
3-5 minutes, and with -o+space I stopped it after about 10-12 minutes...  
Even more, Ctrl-C doesn't kill SCPPN: the process remains in the background, 
and takes 99% of my CPU time.  I'm using Win2k Pro, with all available 
updates applied.

Maybe I ran into optimizer bugs?  The compile time is a little too big for 
an 1.1GHz Athlon... ;)

Something else wrt source code: DMC forced me to declare a default 
constructor, although I don't need one (I don't even want one - look at the 
code).  I think DMC instantiates all the methods in a template, instead of 
instantiating only the used ones, like it should (Borland and GNU only 
instantiate used methods, and, according to Bruce Eckel, this is what they 
should do).  I'm using Borland's free command-line compiler since it's the 
most ISO-C++ compliant compiler available - I didn't try gcc-3, maybe it's 
even better.

About compiler regression tests: gcc had some regression tests (they removed 
it at some point due to copyright uncertainties), and also Bruce Eckel's 
"Thinking in C++" book has a pretty good ISO-C++ test suite.  I'm not sure, 
but there were some very extensive tests on the Net... maybe from the same 
guys that did KAI-C++?  I don't remember...  Anyway, probably that namespace 
std issue must be solved first, otherwise most of them will fail, if not 
all!

DMC doesn't let me apply mutable to a reference, member of a class.  Good!  
It's normally harmless to do so, but it's good that DMC complains about it.

Regards,
  Laurentiu Pancescu
Nov 05 2001
next sibling parent reply Christof Meerwald <cmeerw web.de> writes:
On Mon, 5 Nov 2001 20:30:12 +0000 (UTC), DigitalMars wrote:
[...]
 code).  I think DMC instantiates all the methods in a template, instead of 
 instantiating only the used ones, like it should (Borland and GNU only

AFAIK, since version 8.20 only the used methods of a class template are instantiated. Even this one compiles (which makes it obvious that "g" isn't instantiated): #include <stdio.h> template<class T> struct A { void f() { printf("Hello world.\n"); } void g() { ( } }; int main(int argc, char *argv[]) { A<int> a; a.f(); return 0; }
 should do).  I'm using Borland's free command-line compiler since it's the 
 most ISO-C++ compliant compiler available - I didn't try gcc-3, maybe it's 
 even better.

Yes, g++ 3.0 is one of the most standards compliant compilers available.
 guys that did KAI-C++?  I don't remember...  Anyway, probably that namespace 
 std issue must be solved first, otherwise most of them will fail, if not 
 all!

As a temporary workaround you can probably just compile your code with the command line switch "-Dstd=". But I also hope that DM's namespace support will soon be stable enough to get this issue solved. bye, Christof -- http://cmeerw.cjb.net JID: cmeerw jabber.at mailto cmeerw at web.de ...and what have you contributed to the Net?
Nov 05 2001
next sibling parent Heinz Saathoff <hsaat bre.ipnet.de> writes:
Christof Meerwald schrieb...
   #include <stdio.h>
 
   template<class T>
   struct A
   {
     void f()
     {
       printf("Hello world.\n");
     }
 
     void g()
     {
       (
     }
   };

Is this allowed even if g is not instatiated? I thought that the template must be syntactically valid (not semantically) at this point. If this wasn't true you should also be able to exclude a '}'. But if a '}' is missing the end of the template could not be detected correctly. Regards, Heinz
Nov 05 2001
prev sibling parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
Christof Meerwald <cmeerw web.de> wrote in
news:9s6v3h$2elr$1 digitaldaemon.com: 

 On Mon, 5 Nov 2001 20:30:12 +0000 (UTC), DigitalMars wrote:
 [...]
 
 AFAIK, since version 8.20 only the used methods of a class template are
 instantiated. 
 

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.
 Yes, g++ 3.0 is one of the most standards compliant compilers
 available. 

I still have to do some work on Win32, and even DOS. MinGW only has 2.95.3 implemented, not 3.0.x... Maybe I should try to make a gcc-3.0.2 cross compiler from Linux to Win32? :)
 As a temporary workaround you can probably just compile your code with
 the command line switch "-Dstd=". But I also hope that DM's namespace
 support will soon be stable enough to get this issue solved.

Hmmm... this would transform "using namespace std;" in "using namespace;", so... identifier expected! A clean implementation on the compiler side would be the best bet. Thanks, Laurentiu
Nov 06 2001
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Nov 06 2001
next sibling parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
"Walter" <walter digitalmars.com> wrote in
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'.

Well, I also think it (still) is... But others seem to be somehow cleaner. WRT that default constructor problem, RogueWave's implementation from BCC- 5.5.1 works fine, and also the STL headers that come with gcc-2.95.3 (it seems gcc uses the original SGI/HP STL, but with all that config stuff, the same source may behave extremely different from gcc to DMC). Since STLport works fine with DMC, maybe it's just a cfg problem.
 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.

"was intending"... sounds good! It seems we'll have a good namespace implementation, and std:: compliance, before template support is finished? I hope so, the templates are pretty complex now, in ISO-C++, and I think they not trivial to implement. WRT to those 22 headers that wrap standard C files, maybe we could help? Having new <iostream> and friends instead/in addition of the old one could be also solved by making STLport officially supported... Regards, Laurentiu
Nov 06 2001
parent reply "Walter" <walter digitalmars.com> writes:
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>.

"Laurentiu Pancescu" <plaur crosswinds.net> wrote in message
news:Xns9151CC2C2E9D5plaur 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in
 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'.

Well, I also think it (still) is... But others seem to be somehow

 WRT that default constructor problem, RogueWave's implementation from BCC-
 5.5.1 works fine, and also the STL headers that come with gcc-2.95.3 (it
 seems gcc uses the original SGI/HP STL, but with all that config stuff,

 same source may behave extremely different from gcc to DMC).  Since

 works fine with DMC, maybe it's just a cfg problem.

 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.

"was intending"... sounds good! It seems we'll have a good namespace implementation, and std:: compliance, before template support is finished? I hope so, the templates are pretty complex now, in ISO-C++, and I think they not trivial to implement. WRT to those 22 headers that wrap standard C files, maybe we could help? Having new <iostream> and friends instead/in addition of the old one could be also solved by making STLport officially supported... Regards, Laurentiu

Nov 06 2001
next sibling parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
"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
Nov 07 2001
next sibling parent "Walter" <walter digitalmars.com> writes:
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

 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

 to me!).

 WRT contributions, I wouldn't expect to get paid (I have a programming

 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

 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

Nov 08 2001
prev sibling parent reply Chris <chris widdows.demon.nl> writes:
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... :(

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

Nov 08 2001
parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
Chris <chris widdows.demon.nl> wrote in
news:kqvlut4l3ftd54llhmi3k9cg1n8g6ctskl 4ax.com: 

 Could you tell me more about the V port, I wasn't very succesfull
 finding info on that. 
 
 Chris.
 

About V GUI (well, searching for V on the 'Net can be tough ;), you can visit www.objectcentral.com. Shortly said, it's a LGPL'd GUI toolkit, portable across platforms. With the same source code, you can build binaries for Win32, OS/2, GNU/Linux and other UN*X flavors (using MIT Athena, Motif or GTK in the background) and I'm not sure if Mac is on the list. It's small, looks reasonably good, while maintaing platform-specific look-n-feel. Crossplatform is important for me, so I'm using it. It even has platform-independent printing support and OpenGL support! About the DMC port of V, unless someone has done it independently, I don't think you'll find anything for now... I didn't publish it yet! (web-space provider problems). For now, I only have the main DMC Makefile working, and a few (not all) of the demos. Unfortunately, VIDE is not on the list yet... The problem is DMC's make does not support implicit rules that generates/(depends on) files in different directories. So I had to write custom Perl scripts to generate makefiles for Walter's make (not for smake). Another issue is that, AFAIK, with DMC you cannot have WinMain() placed in a library, as with other compilers (BCC, gcc), so you'll have to link vstartup.obj explicitly each time, besides vgui.lib. Pretty weird limitation, but oh well... :) Regards, Laurentiu
Nov 09 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Laurentiu Pancescu" <plaur crosswinds.net> wrote in message
news:Xns91545E3A4A10Fplaurcrosswindsnet 63.105.9.61...
 The problem is DMC's make does not support implicit rules that
 generates/(depends on) files in different directories.  So I had to write
 custom Perl scripts to generate makefiles for Walter's make (not for
 smake).

Why not just use smake?
 Another issue is that, AFAIK, with DMC you cannot have WinMain() placed in
 a library, as with other compilers (BCC, gcc), so you'll have to link
 vstartup.obj explicitly each time, besides vgui.lib.  Pretty weird
 limitation, but oh well... :)

What is necessary is some reference that pulls it in from the library.
Nov 09 2001
parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
"Walter" <walter digitalmars.com> wrote in
news:9sh1ca$1pn2$1 digitaldaemon.com: 

 "Laurentiu Pancescu" <plaur crosswinds.net> wrote in message
 news:Xns91545E3A4A10Fplaurcrosswindsnet 63.105.9.61...
 The problem is DMC's make does not support implicit rules that
 generates/(depends on) files in different directories.  So I had to
 write custom Perl scripts to generate makefiles for Walter's make (not
 for smake). 

Why not just use smake?

When I started the V port for DMC, it was in the early days when "a CD will be available soon" (yes, even before you kindly sent me a DMC alpha - thanks again for this!). Your make was the only one available for DMC. After I bought the CD, I already had a working Perl script, so... :) And, I must admit, I was too lazy to read SMAKE's manual (which SMAKE I understood is not available for free download, and I want to provide the V DMC port to everybody, not just CD owners). But maybe I should take a look at SMAKE, after all!
 Another issue is that, AFAIK, with DMC you cannot have WinMain()
 placed in a library, as with other compilers (BCC, gcc), so you'll
 have to link vstartup.obj explicitly each time, besides vgui.lib. 
 Pretty weird limitation, but oh well... :) 

What is necessary is some reference that pulls it in from the library.

Yes, I remember our discussion about this, but I still haven't figured out a solution to generate a ref to WinMain(), without calling it. AFAIK, I'm not supposed to call the entry function in a C++ program (the Standard refers to main(), but I guess that's also true for WinMain). But I'm open to suggestions... :) What's still unclear to me is why DMC's startup code doesn't trigger WinMain (), since it probably calls it (that's what happens in BCC, c0w.obj calls an external WinMain, and it's extracted from the LIB, without the need for any hack). Laurentiu
Nov 09 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Laurentiu Pancescu" <plaur crosswinds.net> wrote in message
news:Xns9154E58631580plaur 63.105.9.61...
 Yes, I remember our discussion about this, but I still haven't figured out

 solution to generate a ref to WinMain(), without calling it.  AFAIK, I'm

 supposed to call the entry function in a C++ program (the Standard refers

 main(), but I guess that's also true for WinMain).  But I'm open to
 suggestions... :)

 What's still unclear to me is why DMC's startup code doesn't trigger

 (), since it probably calls it (that's what happens in BCC, c0w.obj calls

 external WinMain, and it's extracted from the LIB, without the need for

 hack).

 Laurentiu

Does this help? www.digitalmars.com/ctg/acrtused.html
Nov 09 2001
parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
"Walter" <walter digitalmars.com> wrote in
news:9si877$9n$1 digitaldaemon.com: 

 
 "Laurentiu Pancescu" <plaur crosswinds.net> wrote in message
 news:Xns9154E58631580plaur 63.105.9.61...
 Yes, I remember our discussion about this, but I still haven't figured
 out a solution to generate a ref to WinMain(), without calling it. 
 AFAIK, I'm not supposed to call the entry function in a C++ program
 (the Standard refers to main(), but I guess that's also true for
 WinMain).  But I'm open to suggestions... :)

 What's still unclear to me is why DMC's startup code doesn't trigger
 WinMain (), since it probably calls it (that's what happens in BCC,
 c0w.obj calls an external WinMain, and it's extracted from the LIB,
 without the need for any hack). 

 Laurentiu

Does this help? www.digitalmars.com/ctg/acrtused.html

I read it - the thing that amazed me is that it seems that it's not the startup code that triggers main() or WinMain(), but it's the main() that triggers the stratup code??? Hmmm... maybe declaring a static function that calls WinMain, and never call that will do the trick? After all, specifiying vstartup.obj at each link isn't that hard. Thanks, Laurentiu
Nov 10 2001
parent "Walter" <walter digitalmars.com> writes:
"Laurentiu Pancescu" <plaur crosswinds.net> wrote in message
news:Xns91558A4C83D8Fplaur 63.105.9.61...
 Does this help? www.digitalmars.com/ctg/acrtused.html

startup code that triggers main() or WinMain(), but it's the main() that triggers the stratup code???

Yes. I wished to avoid having to specify the startup code to the linker.
 Hmmm... maybe declaring a static function that calls WinMain, and never

 that will do the trick?  After all, specifiying vstartup.obj at each link
 isn't that hard.

That sounds like it should work.
Nov 11 2001
prev sibling parent reply Chris <chris widdows.demon.nl> writes:
On Fri, 9 Nov 2001 08:15:24 +0000 (UTC), Laurentiu Pancescu
<plaur crosswinds.net> wrote:

Chris <chris widdows.demon.nl> wrote in
news:kqvlut4l3ftd54llhmi3k9cg1n8g6ctskl 4ax.com: 

 Could you tell me more about the V port, I wasn't very succesfull
 finding info on that. 
 
 Chris.
 

About V GUI (well, searching for V on the 'Net can be tough ;), you can visit www.objectcentral.com. Shortly said, it's a LGPL'd GUI toolkit, portable across platforms. With the same source code, you can build binaries for Win32, OS/2, GNU/Linux and other UN*X flavors (using MIT Athena, Motif or GTK in the background) and I'm not sure if Mac is on the list. It's small, looks reasonably good, while maintaing platform-specific look-n-feel. Crossplatform is important for me, so I'm using it. It even has platform-independent printing support and OpenGL support!

Yes, I knew of Bruce's site, just when started nearing usability he dropped the support. Hadn't been there for some time, but it is far less bulky than say WxWindows, and seems better constructed. Need to look into it more.
About the DMC port of V, unless someone has done it independently, I don't 
think you'll find anything for now... I didn't publish it yet!  (web-space 
provider problems).  For now, I only have the main DMC Makefile working, 
and a few (not all) of the demos.  Unfortunately, VIDE is not on the list 
yet...

Well perhaps it could be published on the DM site (a question and suggestion rolled into 1), and more people could help finishing it. I use the IDDE quite often (I like the source code parsing, and have found that the resource editor does somethings differently when used from the IDDE (like use resource.h, instead of resource.k ??? when invoked outside the IDDE). Did you have to alter any source code?
The problem is DMC's make does not support implicit rules that 
generates/(depends on) files in different directories.  So I had to write 
custom Perl scripts to generate makefiles for Walter's make (not for 
smake).

Another issue is that, AFAIK, with DMC you cannot have WinMain() placed in 
a library, as with other compilers (BCC, gcc), so you'll have to link 
vstartup.obj explicitly each time, besides vgui.lib.  Pretty weird 
limitation, but oh well... :)

would do it.
Regards,
  Laurentiu

Nov 09 2001
parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
Chris <chris widdows.demon.nl> wrote in
news:uq0putkl1sdh3udc53kmc5tmp0ucn2a7b9 4ax.com: 

 On Fri, 9 Nov 2001 08:15:24 +0000 (UTC), Laurentiu Pancescu
 <plaur crosswinds.net> wrote:
 
Chris <chris widdows.demon.nl> wrote in
news:kqvlut4l3ftd54llhmi3k9cg1n8g6ctskl 4ax.com: 

Yes, I knew of Bruce's site, just when started nearing usability he dropped the support. Hadn't been there for some time, but it is far less bulky than say WxWindows, and seems better constructed. Need to look into it more.

Yep, hasn't been updated for more than a year. I'd like to have some notebook-like control (tabbed control, in Win), and maybe a tree control. They exist in GTK, Win32 and Motif, so they should be there, IMHO... The GTK port is also behind... too bad! :( WxWindows is too big and bulky, IMHO. Another cross platform toolkit that I like is FLTK (www.fltk.org). I've been using it on GNU/Linux, mainly...
 Well perhaps it could be published on the DM site (a question and
 suggestion rolled into 1), and more people could help finishing it. I
 use the IDDE quite often (I like the source code parsing, and have
 found that the resource editor does somethings differently when used
 from the IDDE (like use resource.h, instead of resource.k ??? when
 invoked outside the IDDE). Did you have to alter any source code? 

I don't remember, probably not (even if I did, there were probably minor changes, otherwise I would have remembered about doing that). Too much work, I guess... :) I'll finish the port, and then try to convince Walter to put some INCOMING dir on the ftp.digitalmars.com, or some contrib section on DigitalMars. Perhaps I'm not the only one wishing to contribute code... ;)
 You're right, cannot find something similar to /include used in MSVC
 linker would do it.

I think it's a rather minor inconvenient. BTW, vdraw, one of the demo apps, has only 158k, statically linked with DMC port of V. Not bad at all! :) Laurentiu
Nov 10 2001
parent reply Chris <chris widdows.demon.nl> writes:
On Sat, 10 Nov 2001 12:32:45 +0000 (UTC), Laurentiu Pancescu 

<snip>
WxWindows is too big and bulky, IMHO.  Another cross platform toolkit that I 
like is FLTK (www.fltk.org).  I've been using it on GNU/Linux, mainly...

I don't know fltk (except coming across it once or twice), but WxWindows was churning out multi meg apps with ease, so that turned me right off. Zinc for the desktop is free now, when I last looked at that it seemed pretty good. Anyway, I think it would be nice to a cross-platform option alongside the current Win/MFC stuff (which I want also).
 Well perhaps it could be published on the DM site (a question and
 suggestion rolled into 1), and more people could help finishing it. I
 use the IDDE quite often (I like the source code parsing, and have
 found that the resource editor does somethings differently when used
 from the IDDE (like use resource.h, instead of resource.k ??? when
 invoked outside the IDDE). Did you have to alter any source code? 

I don't remember, probably not (even if I did, there were probably minor changes, otherwise I would have remembered about doing that). Too much work, I guess... :) I'll finish the port, and then try to convince Walter to put some INCOMING dir on the ftp.digitalmars.com, or some contrib section on DigitalMars. Perhaps I'm not the only one wishing to contribute code... ;)

I'm all for it, heck I might even have time to add to the effort to ;-) I had a go at imagemagick, but ran into all sorts of problems. The Watcom compiler did manage to get more going, but ended up just getting a little Win only shareware lib. Pity, imagemagick looks pretty good. Perhaps I should have another go, and keep posting the problems. One thing that made things a little difficult was that some libs took the __SC__ define as meaning Mac code, which didn't help. And the OLE/template stuff went haywire. DM++ has come quite far since then, so perhaps I should give it another go.
 You're right, cannot find something similar to /include used in MSVC
 linker would do it.

I think it's a rather minor inconvenient. BTW, vdraw, one of the demo apps, has only 158k, statically linked with DMC port of V. Not bad at all! :)

No, very nice, and that would compile/run wo alteration on Linux?
Laurentiu 

Nov 13 2001
parent reply "Laurentiu Pancescu" <lpancescu fastmail.fm> writes:
"Chris" <chris widdows.demon.nl> wrote in message
news:pk73vtojpt6sqsjfuogv8hp75nku1g4lrk 4ax.com...
 On Sat, 10 Nov 2001 12:32:45 +0000 (UTC), Laurentiu Pancescu

 <snip>
WxWindows is too big and bulky, IMHO.  Another cross platform toolkit


like is FLTK (www.fltk.org).  I've been using it on GNU/Linux, mainly...

I don't know fltk (except coming across it once or twice), but WxWindows was churning out multi meg apps with ease, so that turned me right off. Zinc for the desktop is free now, when I last looked at that it seemed pretty good. Anyway, I think it would be nice to a cross-platform option alongside the current Win/MFC stuff (which I want also).

FLTK is very good, I developped several apps with it, it's very fast and small. And good looking, at least for someone used to SGI X apps (it emulates XForms). About Zinc: I tend to be a little careful (to be read: -fpedantic) when saying something is "free". Zinc is free like in "zero-price", but not like in "freedom". I cannot use it for embedded software, for instance. Since I develop proprietary sofware for a living (embedded software, to be exact), writing free software (free like in GPL) in my spare time became important. So, if I'd develop something that I might expect to run one day on some embedded system, I thik I'd use NanoGui, or MicroWindows (at least one of them is LGPL, but I forgot which :). Oops, I guess we're far from topic of this newsgroup... I hope Jan won't ban me! :)
I'll finish the port, and then try to convince Walter to put some


dir on the ftp.digitalmars.com, or some contrib section on DigitalMars.
Perhaps I'm not the only one wishing to contribute code... ;)

I'm all for it, heck I might even have time to add to the effort to ;-) I had a go at imagemagick, but ran into all sorts of problems. The Watcom compiler did manage to get more going, but ended up just getting a little Win only shareware lib. Pity, imagemagick looks pretty good. Perhaps I should have another go, and keep posting the problems. One thing that made things a little difficult was that some libs took the __SC__ define as meaning Mac code, which didn't help. And the OLE/template stuff went haywire. DM++ has come quite far since then, so perhaps I should give it another go.

Unfortunately, I'm very caught with my "money-earning" work now (release season, apparently), and I will only have time for this during weekends, and not even that fully. :( Is ImageMagick that you talk about the same lib I know from GNU/Linux? Were you using it for GUI elements, or image processing? I never used it... yep, "non-free" stuff again! :)
 You're right, cannot find something similar to /include used in MSVC
 linker would do it.

I think it's a rather minor inconvenient. BTW, vdraw, one of the demo


has only 158k, statically linked with DMC port of V.  Not bad at all! :)

No, very nice, and that would compile/run wo alteration on Linux?

AFAIK, yes... I only got V GUI and VIDE as tar-gz sources, and compiled them on both Win32 and GNU/Linux. My Debian GNU/Linux came with V GUI 1.22, but I considered that to be too old... :) Laurentiu
Nov 14 2001
next sibling parent Jan Knepper <jan smartsoft.cc> writes:
 Oops, I guess we're far from topic of this newsgroup... I hope Jan won't ban
 me!  :)

Nag! Jan
Nov 15 2001
prev sibling parent reply Chris <chris widdows.demon.nl> writes:
On Thu, 15 Nov 2001 00:41:09 +0100, "Laurentiu Pancescu"
<lpancescu fastmail.fm> wrote:

<snip>
Unfortunately, I'm very caught with my "money-earning" work now (release
season, apparently), and I will only have time for this during weekends, and
not even that fully. :(

Is ImageMagick that you talk about the same lib I know from GNU/Linux?  Were
you using it for GUI elements, or image processing?  I never used it... yep,
"non-free" stuff again!  :)

AFAIK it is free in the sense that you get the source and can do with it what you want. It doesn't cost any money either, at least that is how I read the license. It is a massive library, but does a lot you wouldn't find even the expensive 'market leaders'. Pity that I couldn't get it compile with DM++, once I got the stuff through the compiler (by leaving modules out) it started to bark when linking the demo apps. I listed the dll's and sure enough, the symbols were right there. After that I stopped trying. <snip>
 No, very nice, and that would compile/run wo alteration on Linux?

AFAIK, yes... I only got V GUI and VIDE as tar-gz sources, and compiled them
on both Win32 and GNU/Linux.  My Debian GNU/Linux came with V GUI 1.22, but
I considered that to be too old...  :)


Laurentiu

better (if only for the reason it can do Brief keymappings better than most ;-) Chris
Nov 15 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Chris" <chris widdows.demon.nl> wrote in message
 Pity that I couldn't get it compile
 with DM++, once I got the stuff through the compiler (by leaving modules
 out) it started to bark when linking the demo apps. I listed the dll's and
 sure enough, the symbols were right there. After that I stopped trying.

Can you reduce it down to a small bug report?
Nov 15 2001
parent reply Chris <chris widdows.demon.nl> writes:
On Thu, 15 Nov 2001 16:41:07 -0800, "Walter" <walter digitalmars.com>
wrote:

"Chris" <chris widdows.demon.nl> wrote in message
 Pity that I couldn't get it compile
 with DM++, once I got the stuff through the compiler (by leaving modules
 out) it started to bark when linking the demo apps. I listed the dll's and
 sure enough, the symbols were right there. After that I stopped trying.

Can you reduce it down to a small bug report?

Walter, sorry, ImageMagick is massive, and of course it only surfaced when I reached the final stage, the demo app. I started out by using the MSVC dsw file as a reference and using the IDDE, built the project, compiling each subproject (quite a few of them). Had trouble with both the static lib version and the DLL version (which I was aiming for), but more so with the DLL. Noticed some took __SC__ as meaning macintosh, which didn't help. Also, there was one lib that used OLE quite a lot, which the compiler didn't like at all (from memory, FHQ or FQX? subproject). From what I gathered at the time, something was going wrong with calling convention decoration of the symbols, when compiling for export it was producing something else than when producing the symbol to link with. Anyway, it wasn't clear to me if DM was to blame, or that the code was being led into the wrong direction by all those cross-platform defines. But the sheer size was enough for me to stop trying, I bought a shareware lib for $30 which saved me hours of work and worked fine. But, it would be nice if some of these cross-platform tools would work easily for DM. But it is a major effort keeping up with the developments of these tools, so probably the only 'easy' way would be to have a MS VC switch, so the compiler and linker would react to the source as the stuff from MS, or get the maintainer to support and validate the tool for DM. If I have the time I could start rebuilding the port, and once it starts producing errors, send you the whole project, but that will not be small be any means. Your thoughts..... Chris
Nov 17 2001
parent "Walter" <walter digitalmars.com> writes:
Since DM can compile MFC and still be binary compatible with MSVC, it is
pretty compatible. Of course, there always will be differences. I'll be
happy to address them in small bug reports, but debugging a massive app is
more than I'm willing to do at the moment :-(

"Chris" <chris widdows.demon.nl> wrote in message
news:ovscvtcvqcrljim56u87bh379hgomg0osv 4ax.com...
 On Thu, 15 Nov 2001 16:41:07 -0800, "Walter" <walter digitalmars.com>
 wrote:

"Chris" <chris widdows.demon.nl> wrote in message
 Pity that I couldn't get it compile
 with DM++, once I got the stuff through the compiler (by leaving



 out) it started to bark when linking the demo apps. I listed the dll's



 sure enough, the symbols were right there. After that I stopped trying.

Can you reduce it down to a small bug report?

Walter, sorry, ImageMagick is massive, and of course it only surfaced when I reached the final stage, the demo app. I started out by using the MSVC dsw file as a reference and using the IDDE, built the project, compiling each subproject (quite a few of them). Had trouble with both the static lib version and the DLL version (which I was aiming for), but more so with the DLL. Noticed some took __SC__ as meaning macintosh, which didn't help. Also, there was one lib that used OLE quite a lot, which the compiler didn't like at all (from memory, FHQ or FQX? subproject). From what I gathered at the time, something was going wrong with calling convention decoration of the symbols, when compiling for export it was producing something else than when producing the symbol to link with. Anyway, it wasn't clear to me if DM was to blame, or that the code was being led into the wrong direction by all those cross-platform defines.

 the sheer size was enough for me to stop trying, I bought a shareware lib
 for $30 which saved me hours of work and worked fine. But, it would be

 if some of these cross-platform tools would work easily for DM. But it is

 major effort keeping up with the developments of these tools, so probably
 the only 'easy' way would be to have a MS VC switch, so the compiler and
 linker would react to the source as the stuff from MS, or get the
 maintainer to support and validate the tool for DM.

 If I have the time I could start rebuilding the port, and once it starts
 producing errors, send you the whole project, but that will not be small

 any means.

 Your thoughts.....

 Chris

Nov 17 2001
prev sibling parent reply "Laurentiu Pancescu" <plaur crosswinds.net> writes:
"Chris" <chris widdows.demon.nl> wrote in message
news:v8h8vtsqm18577lbobf2t7t77ghe0u3vp3 4ax.com...
 So V seems pretty good, and whilst VIDE is probably very good, DM's is IMO
 better (if only for the reason it can do Brief keymappings better than

 ;-)

DM's IDDE is really good, actually is by far the best I've seen on Win32. Compared to that, VIDE is rather primitive, but it has something that IDDE lacks: integrated support for generating VGUI apps, and support for different environments (BCC 5.5.1, Sun's JDK, gcc flavors). It's even more important on GNU/Linux, where you don't find that many IDEs with low resource consumption. About Brief... well, I'm using GNU Emacs on both Win32 and GNU/Linux! :) Laurentiu
Nov 16 2001
parent Arjan Knepper <arjan jak.nl> writes:
Laurentiu Pancescu wrote:

 DM's IDDE is really good, actually is by far the best I've seen on Win32.

<dreaming> DM's IDDE and compiler runnig native on the FreeBSD LINUX OSX..... </dreaming> Arjan
Nov 16 2001
prev sibling parent Christof Meerwald <NOSPAM_seeMySig fastrun.at> writes:
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?
Nov 07 2001
prev sibling parent reply "Damian Dixon" <damian.dixon tenet.co.uk> writes:
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


 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

 on that after the template stuff was working satisfactorilly.

Nov 07 2001
parent "Walter" <walter digitalmars.com> writes:
"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.
Nov 08 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
The optimizer can take a long time if there are a lot of nested loops in a
single function. Try compiling with -v to see which function it is.

AMD should thank me for finding a use for all those gigahertz <g>.

"DigitalMars" <plaur crosswinds.net> wrote in message
news:Xns9150DCC3A6E18plaur 63.105.9.61...
 The code in attachment takes extremely long time to compile.  With

 o+none parse_cfg.cpp", it compiles immediately, with -o+all it takes about
 3-5 minutes, and with -o+space I stopped it after about 10-12 minutes...
 Even more, Ctrl-C doesn't kill SCPPN: the process remains in the

 and takes 99% of my CPU time.  I'm using Win2k Pro, with all available
 updates applied.

 Maybe I ran into optimizer bugs?  The compile time is a little too big for
 an 1.1GHz Athlon... ;)

 Something else wrt source code: DMC forced me to declare a default
 constructor, although I don't need one (I don't even want one - look at

 code).  I think DMC instantiates all the methods in a template, instead of
 instantiating only the used ones, like it should (Borland and GNU only
 instantiate used methods, and, according to Bruce Eckel, this is what they
 should do).  I'm using Borland's free command-line compiler since it's the
 most ISO-C++ compliant compiler available - I didn't try gcc-3, maybe it's
 even better.

 About compiler regression tests: gcc had some regression tests (they

 it at some point due to copyright uncertainties), and also Bruce Eckel's
 "Thinking in C++" book has a pretty good ISO-C++ test suite.  I'm not

 but there were some very extensive tests on the Net... maybe from the same
 guys that did KAI-C++?  I don't remember...  Anyway, probably that

 std issue must be solved first, otherwise most of them will fail, if not
 all!

 DMC doesn't let me apply mutable to a reference, member of a class.  Good!
 It's normally harmless to do so, but it's good that DMC complains about

 Regards,
   Laurentiu Pancescu

Nov 06 2001
parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
"Walter" <walter digitalmars.com> wrote in
news:9s92qb$1sur$2 digitaldaemon.com: 

 The optimizer can take a long time if there are a lot of nested loops
 in a single function. Try compiling with -v to see which function it
 is. 

I did... the last line is ostream_iterator<db>::ostream_iterator<db>, and, if I remove that copy() call at the end, the last line (I mean before the long wait) is basic_string<...>::c_str(). In both cases, the first line that appears after the wait is basic_string<...>::empty. I checked with both DMC SGI-STL, and STLport, it's the same behaviour. This is annoying, neither c_str nor empty should contain too many loops... ;) Did you try to compile the code in attachment? What's more annoying is that SCPPN doesn't die on Ctrl-C, but remains somehow in the background. I don't know about long compile time (seems like some bug in optimizer, no problem, gcc-2.95.2 also had such a bug, that generated an internal infinite loop during optimization), but SCPPN not terminating really needs to be fixed...
 AMD should thank me for finding a use for all those gigahertz <g>.

LOL - you should put this in the Features section on digitalmars.com!! :D Regards, Laurentiu
Nov 06 2001
parent reply "Walter" <walter digitalmars.com> writes:
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...).

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.

"Laurentiu Pancescu" <plaur crosswinds.net> wrote in message
news:Xns9151CDFBE422Bplaur 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in
 news:9s92qb$1sur$2 digitaldaemon.com:

 The optimizer can take a long time if there are a lot of nested loops
 in a single function. Try compiling with -v to see which function it
 is.

I did... the last line is ostream_iterator<db>::ostream_iterator<db>, and, if I remove that copy() call at the end, the last line (I mean before the long wait) is basic_string<...>::c_str(). In both cases, the first line that appears after the wait is basic_string<...>::empty. I checked with both DMC SGI-STL, and STLport, it's the same behaviour. This is annoying, neither c_str nor empty should contain too many loops... ;) Did you try to compile the code in attachment? What's more annoying is that SCPPN doesn't die on Ctrl-C, but remains somehow in the background. I don't know about long compile time (seems

 some bug in optimizer, no problem, gcc-2.95.2 also had such a bug, that
 generated an internal infinite loop during optimization), but SCPPN not
 terminating really needs to be fixed...

 AMD should thank me for finding a use for all those gigahertz <g>.

LOL - you should put this in the Features section on digitalmars.com!! :D Regards, Laurentiu

Nov 06 2001
parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
"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
Nov 07 2001
parent reply Jan Knepper <jan smartsoft.cc> writes:
 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
Nov 07 2001
parent reply Laurentiu Pancescu <plaur crosswinds.net> writes:
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
Nov 07 2001
parent reply "Walter" <walter digitalmars.com> writes:
"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

 a weird loop that is optimized better or worse by different compilers.

 a few cycles gained due speculative execution side-effects (Athlon has

 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.
Nov 09 2001
parent Laurentiu Pancescu <plaur crosswinds.net> writes:
"Walter" <walter digitalmars.com> wrote in
news:9sg1cf$nsn$1 digitaldaemon.com: 

 
 "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.

Actually, this is how I compared: with fast floating point support on all compilers (I know I don't need correct denormal comparison, since, if I'm getting someting else than finite numbers and Infs in sigularities, I'm in real trouble anyway). So the flags were "-o+all -6 -ff" for DMC, "-O2 -6 - ff" for bcc32, and similar for gcc (I also added -mieee-fp to -ffast-math, since I was testing for NaNs and denormals). It's just a loop, and DMC generates very good code for it. Visual C++ seems to generate excellent FPU code, and I have to admit this, even if I'm anything but a Microsoft fan. Maybe I should mention that in my test case with MSVC, I only had normal numbers, no special cases like Inf, NaN, etc., so I don't know about MSVC's IEEE fp compliance. Laurentiu
Nov 09 2001