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


announcement?

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




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.


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


Walter, since this is now the new spot that you're going to post the future D
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


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.


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'll try that.


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