www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.119 release

reply "Walter" <newshound digitalmars.com> writes:
More dusty old bugs fixed.

http://www.digitalmars.com/d/changelog.html
Mar 18 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d1f58u$1gq5$1 digitaldaemon.com...
 More dusty old bugs fixed.

 http://www.digitalmars.com/d/changelog.html

new in dmd-119 on WinXP. The following causes dmd to crash template Foo(alias tail) { } struct List(V) { mixin Foo!(tail); V tail; } int main(){ List!(int) x; return 0; } MinTL uses template to share code between parametrized structs so I found the ability to pass data member names to templates very useful. -Ben ps - should we post regressions to D.bugs or follow up to the announcement?
Mar 18 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d1faqu$1pir$1 digitaldaemon.com...
 -Ben
 ps - should we post regressions to D.bugs or follow up to the

I think in D.bugs.
Mar 18 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d1faqu$1pir$1 digitaldaemon.com...
 new in dmd-119 on WinXP. The following causes dmd to crash
 template Foo(alias tail) {
 }
 struct List(V) {
   mixin Foo!(tail);
   V tail;
 }
 int main(){
   List!(int) x;
   return 0;
 }

 MinTL uses template to share code between parametrized structs so I found
 the ability to pass data member names to templates very useful.

The problem is 'tail' being forward referenced by the mixin. It works if you swap the declaration order of Foo!(tail) and tail.
Mar 19 2005
parent =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter wrote:

| "Ben Hinkle" <bhinkle mathworks.com> wrote in message
| news:d1faqu$1pir$1 digitaldaemon.com...
|
|>new in dmd-119 on WinXP. The following causes dmd to crash
|>template Foo(alias tail) {
|>}
|>struct List(V) {
|>  mixin Foo!(tail);
|>  V tail;
|>}
|>int main(){
|>  List!(int) x;
|>  return 0;
|>}
|>
|>MinTL uses template to share code between parametrized structs so I
|>found the ability to pass data member names to templates very useful.
|
|
| The problem is 'tail' being forward referenced by the mixin. It works
| if you swap the declaration order of Foo!(tail) and tail.

Added to DStress as
http://dstress.kuehne.cn/run/mixin_07.d
http://dstress.kuehne.cn/run/mixin_08.d

Thomas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCPSFc3w+/yD4P9tIRAnY0AKCc2zKszxc68Po7tFoMKCc/oAA/jgCeMbAd
OmCdM+f1usXxa1K6AbG62aw=
=l8Sk
-----END PGP SIGNATURE-----
Mar 19 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d1faqu$1pir$1 digitaldaemon.com...
 new in dmd-119 on WinXP. The following causes dmd to crash
 template Foo(alias tail) {
 }
 struct List(V) {
   mixin Foo!(tail);
   V tail;
 }
 int main(){
   List!(int) x;
   return 0;
 }

 MinTL uses template to share code between parametrized structs so I found
 the ability to pass data member names to templates very useful.

The problem is the forward reference to tail. I have it fixed to diagnose it now, the fix for the code is to reverse the mixin and tail declarations.
Apr 05 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 The problem is the forward reference to tail. I have it fixed to diagnose 
 it
 now, the fix for the code is to reverse the mixin and tail declarations.

yup. I updated the mintl code after your initial post. I'm glad you have added a check for it. Are the rules about forward references documented? It seems fragile. Every now and then something subtle changes and people start reporting code breaking in non-obvious ways.
Apr 05 2005
parent "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d2v5i7$5hq$1 digitaldaemon.com...
 The problem is the forward reference to tail. I have it fixed to


 it
 now, the fix for the code is to reverse the mixin and tail declarations.

yup. I updated the mintl code after your initial post. I'm glad you have added a check for it. Are the rules about forward references documented? It seems fragile. Every now and then something subtle changes and people start reporting code breaking in non-obvious ways.

I'd like to eventually make D work with all forward references. Unfortunately, this has turned out to be harder than I expected. What works and doesn't is often subtle. My first priority is to at least correctly diagnose the problems.
Apr 05 2005
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
Walter wrote:
 More dusty old bugs fixed.
 
 http://www.digitalmars.com/d/changelog.html

" C-style casts are no longer deprecated, they are now illegal." Yay! We've just entered a new era of programming! -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Mar 18 2005
prev sibling next sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <d1f58u$1gq5$1 digitaldaemon.com>, Walter says...
More dusty old bugs fixed.

http://www.digitalmars.com/d/changelog.html

release announements, could you please add the following new links to the main D webpage, under the "Community" section: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.announce http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.learn Since I do not use a news reader at work, it would be nice to be able to read and posts to these additional forum areas using the web-browser. Thanks in advance, David L. ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Mar 19 2005
parent "Walter" <newshound digitalmars.com> writes:
Good idea. Done. -Walter
Mar 19 2005
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d1f58u$1gq5$1 digitaldaemon.com...
 More dusty old bugs fixed.

" Now correctly diagnoses as an error attempts to access members of outer aggregate from within inner aggregate. " NOOOO! It's completely messed up my nice "property organization" in my project!! Before, I was able to write.. class A { public: struct propSet { int x(int x) { return _x=x; } int x() { return _x; } } private: int _x; } .. A a=new A; a.propSet.x=5; The propSet structure functioned as a nice organizational feature, acting as a sort of namespace. This is now illegal (for what reason, I don't know: nested functions can access outer function variables, but not nested aggregates?). Is there any way to simulate this now, or perhaps a way to access the "parent" this pointer? The way I have things set up, it is not possible to move the outer aggregate members into the inner aggregate, nor would it be possible to make the inner aggregate a separate, outer aggregate.
Mar 20 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:d1k8go$qtn$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:d1f58u$1gq5$1 digitaldaemon.com...
 More dusty old bugs fixed.

" Now correctly diagnoses as an error attempts to access members of outer aggregate from within inner aggregate. " NOOOO! It's completely messed up my nice "property organization" in my project!! Before, I was able to write.. class A { public: struct propSet { int x(int x) { return _x=x; } int x() { return _x; } } private: int _x; } .. A a=new A; a.propSet.x=5; The propSet structure functioned as a nice organizational feature, acting

 a sort of namespace.  This is now illegal (for what reason, I don't know:
 nested functions can access outer function variables, but not nested
 aggregates?).

 Is there any way to simulate this now, or perhaps a way to access the
 "parent" this pointer?  The way I have things set up, it is not possible

 move the outer aggregate members into the inner aggregate, nor would it be
 possible to make the inner aggregate a separate, outer aggregate.

The problem is this never worked in the first place, although it would compile and generate code as if the inner and outer structs were overlaid on top of each other. It was like a pointer to one struct being used to access the members of another, unrelated, struct. D's nested classes do not behave like Java inner classes, which implicitly have a member that is initialized to be the 'this' pointer of the outer class. You can emulate this behavior, however, by explicitly providing such a member and initializing it.
Mar 20 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d1keph$110c$1 digitaldaemon.com...
 The problem is this never worked in the first place, although it would
 compile and generate code as if the inner and outer structs were overlaid 
 on
 top of each other. It was like a pointer to one struct being used to 
 access
 the members of another, unrelated, struct.

I can see how that might be an ideological problem, but isn't it more useful to think of it that way? Usually when one defines an inner class, one intends for that inner class to be very tightly integrated into the outer class.
 D's nested classes do not behave like Java inner classes, which implicitly
 have a member that is initialized to be the 'this' pointer of the outer
 class. You can emulate this behavior, however, by explicitly providing 
 such
 a member and initializing it.

I'll try that.
Mar 20 2005
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:d1kja9$15c8$1 digitaldaemon.com...
 D's nested classes do not behave like Java inner classes, which 
 implicitly
 have a member that is initialized to be the 'this' pointer of the outer
 class. You can emulate this behavior, however, by explicitly providing 
 such
 a member and initializing it.


I managed to get it to work, but it's rather cumbersome. My code now looks like this: class A { public: this() { // I have to do "that=this" for every property set now pos.that=this; } struct propSetStruct { int x(int xx) { // I now have to use "that." every time I need access to an outer member return that._x=xx; } int x() { return that._x; } // every prop set needs a "that" pointer now private A that; } // every prop set must now be explicitly declared propSetStruct propSet; private: int _x; } It's ugly, cumbersome, and prone to bugs if I forget to add in all the appropriate code to add in a new property set. Like I said - it's probably idealogically better, but it's just a hassle.
Mar 20 2005