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

begin 644 parse_cfg.zip



M:8>#OHEQCTZ7
MF(%2\?-FNUMN=EOUI%0H!$H69:$W;XHCD_DSQ6W1%H]WPP$>/#H+:=TF)<+'
MXI) PU0&E2C$<X%>LT2PE9%H+Q!37FE!WP7922+'6$FGS5* 7.Y(D$.E#P(:
MN:,W0=;RYZ0"[>?J]('^D&Q;H>M/J7%HB+L8U!D$8-JR3P5?& 2)ZIJ_+2ID
MUCGR/;!W9/.P0&]F7?4L',6C4PC`%-K!^/S2N%Q97>'B6B-9C[GKIU&9IC*D


MWWV.&6'SA;$^B^^W7%4PLM!A &7M-WO<;M.N557!M^,02.#ZJ.
M"I+'J)56*^ZEHQZ,.9\N;^;=F,022-I_;.X4'&-'T/+D R-[.PS'^0)'ZWU^


M#U

M?<?&)I`F9*7E`?#XFQ_^9CSV_3T4I)0LIJOUA!8%-,_XRYB.1O >#N[OX;7D
M2C$!R7L$3Z0JF5"\ G^)H$S2:C 8#O[B F95RF`N59KQ9+)Y:`MY+E7)R.Y$
MO#HK12$7ZXYHSZC*RZY)Q4I2"UMB[[B>C=>6TUQ(1822)_*,"V9$PP'ZK:B"
M-!D.#L,!X(\?0`2"[)COI=5N]^X%(>Q)Z9M!`(</"S/&H8X;;D4(:5XE&8/;

M`;6U&?08<!'+BT:DU=>N&O6N^X,%-PXQ;C/"[\S9^Z(VW-FR7 W8V'9D(;Z>
M)XI3)S9<H_QCIG-DZ^ 8S'SN'V4RA%9H2<PRM ML-G,)\SD4Y3HVX>*_%P'6
M200>Z'E\4&:5) T&5^*U)UR0=EVYU*'IR/8Y3X^[R7=NZ\J=I\D#I$21A$B[
M:#N8%)7<Q`FA6Q]KPGOQ0G ) CX(*R3/<)6(=+_]"M^G"/T^[0?]MTH0A>]^
MV"-%U".]`MIKT+X?)/EZ1Q!GOOW0+<*V_9!GA#Q
M"/KQK1^T1LSZ2F)T7OHA;SORABC]Z0=2G1AZ)3$_$?.S'_*$D*<KI9+J2DG[

M]6X^V$T-E)7EF:U?":+;B\IU6Q2P[-A=>DOAS9R%>J_;H6EASJ8^/?Q_IB'<
MC>\"+;A;BCNG=J[?M'Q$NM&5RO0,[(?.H>V.M"KU,1MK#T9>"=PI J7&9RQR
M;$Q3,_&ZP46#OV;*1.-H"#LF E-61B-KIUEE[3B*)/^?Q>J]8,!>T$G;RF3%
M1>I["TN[?C3U&K=H]$61RZ#AX.C1H3L&M3,_"-J8,QGK3CMN/_'Y2DJA0P`D
M*C<L<K$G&:\Y`^^\&<>GS=ZLC<+31'%1L9;PH\N7._RZJZH2G/6Q+MA+<$(P
M'H]9=4D#F1S
MO$&M<.A3KD]KMS$3MN;"#V8
M%R[>M=BL.Y7 1M]V9!_M*KLQJI<JZ[1F/N7Z]PJF$EN1OPJ]*=$(4H:-P3MG
MJ]G42P]R80OL3\KI0IOJ!NQU7.N[22<V%-ITU'<PS/?*-_4VH;&NKR`P70J3
MF9UK9W4//'6*Z%:3NMCVC$&:%^_^:3&%)V44 KVR-46I"]77482 .Z]M_KU=
MMKYW_0)02P,$%``"`` `B[E3*^4=V.IW````J0````L```!P87)S95]C9F<N

M6I2:5Y)9JA"0F)><6IQ<RLO%RZ6<F9:7DIJF$!\?X! 4[.KLYA[O$1\/%`<*
M9N:E8HCS<I7E9Z8 [-;0M`8;DYJ7DIFF`+0270,`4$L!`A0`%``"`` `P'5D
M*X*H`)!1`0``B ,```L``````````0` `````````&-O;G-T86YT<RYH4$L!
M`A0`%``"`` `&&YD*\_RQ6S9````10$```8``````````0` ````> $``&QI
M;F4N:%!+`0(4`!0`` `(`->I92M,!D)>$00``,(,```-``````````$`(```
M`'<"``!P87)S95]C9F<N8W!P4$L!`A0`%``"`` `B[E3*^4=V.IW````J0``
M``L``````````0` ````LP8``'!A<G-E7V-F9RYH4$L%! `````$``0`X0``
'`%,'````````
`
end
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


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


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 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...  :(


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


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


 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???


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


call

 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... :)


You're right, cannot find something similar to /include used in MSVC linker
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




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


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




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.


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




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?


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!  :)


It is the same, so it would go nicely with V, mainly for image processing.
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


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






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


most

 ;-)


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




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


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


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


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