www.digitalmars.com         C & C++   DMDScript  

c++.announce - new C++ 8.29.5 beta

reply "Walter" <walter digitalmars.com> writes:
with better template support.

www.digitalmars.com/dmc/dmcppDownload.html
Jul 03 2002
parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
Thanks, that's a step... er, a leap, in the right direction!
- Rajiv

"Walter" <walter digitalmars.com> wrote in message
news:ag0l69$d1e$1 digitaldaemon.com...

 with better template support.

 www.digitalmars.com/dmc/dmcppDownload.html
Jul 03 2002
parent reply Damian <damiandixon netscape.net> writes:
Walter,

Thanks for the new template support.

However I'm having a problem :<. The compiler runs out of memory but 
does not give an indication as to why or where.

Is there anything I can turn on to find out where the compiler has got 
to so that I can attempt to create an RBT.

I am trying to build the very latest STLport from www.stlport.org, and 
thus pushing the new template code in the compiler rather hard. I don't 
mind if the output is large or slows the compiler down, just so that I 
can narrow the problem down to a few lines of code.

I know that you have listed the new template functionality, but could 
you please elaborate the actual acceptable syntax that you have 
implemented, as it is proving difficult to work out what may not have 
been implemented. I think I may have found a few problems but I am not 
totally sure that I am not expeecting too much for now. I will try to 
create some examples that demonstrate the problems (but not the crash 
one), but it may take me a while as I want to check against g++ (v3.03) 
and GreenHills (3.5) just to make sure it's not me!
Regards
Damian
Jul 08 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
I appreciate greatly the help you're giving. The way to find out where the
compiler is possibly hanging is to compile with -e -l, and then a .lst file
will be created up to the point where it failed. If that doesn't work, the
only think left is to try the binary approach (delete the second half of the
source, if it still fails, delete the second half of what's left, etc.).

"Damian" <damiandixon netscape.net> wrote in message
news:3D29A93E.4030603 netscape.net...

 Walter,

 Thanks for the new template support.

 However I'm having a problem :<. The compiler runs out of memory but
 does not give an indication as to why or where.

 Is there anything I can turn on to find out where the compiler has got
 to so that I can attempt to create an RBT.

 I am trying to build the very latest STLport from www.stlport.org, and
 thus pushing the new template code in the compiler rather hard. I don't
 mind if the output is large or slows the compiler down, just so that I
 can narrow the problem down to a few lines of code.

 I know that you have listed the new template functionality, but could
 you please elaborate the actual acceptable syntax that you have
 implemented, as it is proving difficult to work out what may not have
 been implemented. I think I may have found a few problems but I am not
 totally sure that I am not expeecting too much for now. I will try to
 create some examples that demonstrate the problems (but not the crash
 one), but it may take me a while as I want to check against g++ (v3.03)
 and GreenHills (3.5) just to make sure it's not me!
 Regards
 Damian
Jul 08 2002
parent Damian <damiandixon netscape.net> writes:
Thanks for the suggestion Walter.

I have moved my discussion to the c++ newsgroup as suggested by Christof

Regards
Damian


Walter wrote:


 I appreciate greatly the help you're giving. The way to find out where the
 compiler is possibly hanging is to compile with -e -l, and then a .lst file
 will be created up to the point where it failed. If that doesn't work, the
 only think left is to try the binary approach (delete the second half of the
 source, if it still fails, delete the second half of what's left, etc.).
 
 "Damian" <damiandixon netscape.net> wrote in message
 news:3D29A93E.4030603 netscape.net...
 

Walter,

Thanks for the new template support.

However I'm having a problem :<. The compiler runs out of memory but
does not give an indication as to why or where.

Is there anything I can turn on to find out where the compiler has got
to so that I can attempt to create an RBT.

I am trying to build the very latest STLport from www.stlport.org, and
thus pushing the new template code in the compiler rather hard. I don't
mind if the output is large or slows the compiler down, just so that I
can narrow the problem down to a few lines of code.

I know that you have listed the new template functionality, but could
you please elaborate the actual acceptable syntax that you have
implemented, as it is proving difficult to work out what may not have
been implemented. I think I may have found a few problems but I am not
totally sure that I am not expeecting too much for now. I will try to
create some examples that demonstrate the problems (but not the crash
one), but it may take me a while as I want to check against g++ (v3.03)
and GreenHills (3.5) just to make sure it's not me!
Regards
Damian
Jul 09 2002
prev sibling parent Christof Meerwald <cmeerw web.de> writes:
Maybe we should move this discussion to the c++ group - i've set a
Followup-To...

On Mon, 08 Jul 2002 16:01:18 +0100, Damian wrote:

 However I'm having a problem :<. The compiler runs out of memory but 
 does not give an indication as to why or where.


Maybe it's a recursive macro that DMC doesn't correctly handle yet (I think
I have reported the bug a few months ago), try to compile/preprocess this
test-case:

  #define A(x) x
  #define test A(test)
  test

And yes, STLport uses these kind of constructs...



 I am trying to build the very latest STLport from www.stlport.org, and


I have already made some progress trying to compile STLport-4.5.3. I am even
able to compile simple programs like these (with an unofficial 8.29.7n beta):

#include <string>

int main()
{
  std::string a;
  
  return 0;
}


But as soon as I add some string operations (something like
a.assign("test")), I get an "Internal error: struct 3273".

Walter, can you give me a hint what I should be looking for to track it
down?


BTW, I have put a diff against STLport-4.5.3 on my Web-page:
http://cmeerw.org/files/dm/STLport-4.5.3-dm.diff (you need the Cygwin tools
or a Linux/Unix machine to apply the patch with "patch -sp1
<STLport-4.5.3-dm.diff" inside your STLport-4.5.3 directory)


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw jabber.at
mailto cmeerw at web.de

...and what have you contributed to the Net?
Jul 08 2002