Thread overview | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 05, 2001 more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Attachments: | 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 |
November 05, 2001 Re: more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Posted in reply to DigitalMars | 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? |
November 06, 2001 Re: more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christof Meerwald | 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
|
November 06, 2001 Re: more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christof Meerwald | 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 |
November 06, 2001 Re: more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Posted in reply to DigitalMars | 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 > > |
November 06, 2001 Re: more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Posted in reply to Laurentiu Pancescu | "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. |
November 06, 2001 Re: more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "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 |
November 06, 2001 Re: more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "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 |
November 06, 2001 Re: more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Posted in reply to Laurentiu Pancescu | 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 |
November 06, 2001 Re: more bugs in 8.22 (for Walter) - 1 attachment | ||||
---|---|---|---|---|
| ||||
Posted in reply to Laurentiu Pancescu | 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 |
Copyright © 1999-2021 by the D Language Foundation