Jump to page: 1 24  
Page
Thread overview
more bugs in 8.22 (for Walter) - 1 attachment
Nov 05, 2001
DigitalMars
Nov 05, 2001
Christof Meerwald
Nov 06, 2001
Heinz Saathoff
Nov 06, 2001
Laurentiu Pancescu
Nov 06, 2001
Walter
Nov 06, 2001
Laurentiu Pancescu
Nov 06, 2001
Walter
Nov 07, 2001
Laurentiu Pancescu
Nov 08, 2001
Walter
Nov 08, 2001
Chris
Nov 09, 2001
Laurentiu Pancescu
Nov 09, 2001
Walter
Nov 09, 2001
Laurentiu Pancescu
Nov 10, 2001
Walter
Nov 10, 2001
Laurentiu Pancescu
Nov 11, 2001
Walter
Nov 10, 2001
Chris
Nov 10, 2001
Laurentiu Pancescu
Nov 13, 2001
Chris
Re: more bugs in 8.22 (for Walter) - off topic
Nov 14, 2001
Laurentiu Pancescu
Nov 15, 2001
Jan Knepper
Nov 15, 2001
Chris
Nov 16, 2001
Walter
Nov 17, 2001
Chris
Nov 17, 2001
Walter
Nov 16, 2001
Laurentiu Pancescu
Nov 16, 2001
Arjan Knepper
Nov 07, 2001
Christof Meerwald
Nov 07, 2001
Damian Dixon
Nov 08, 2001
Walter
Nov 06, 2001
Walter
Nov 06, 2001
Laurentiu Pancescu
Nov 06, 2001
Walter
Nov 07, 2001
Laurentiu Pancescu
Nov 07, 2001
Jan Knepper
Nov 07, 2001
Laurentiu Pancescu
Nov 09, 2001
Walter
Nov 09, 2001
Laurentiu Pancescu
November 05, 2001
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
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
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
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
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
"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
"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
"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
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
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


« First   ‹ Prev
1 2 3 4