digitalmars.D - D2's feature set?
- Kristian Kilpi (15/15) Jun 06 2009 I think I shouldn't post this because I could very well start one of tho...
- Christopher Wright (5/22) Jun 06 2009 You need to do escape analysis and whole program analysis to determine
- Kristian Kilpi (5/21) Jun 06 2009 Yep. Well, I would be happy with it even if you could only assing newly ...
- Steven Schveighoffer (18/33) Jun 06 2009 Not really. A scope member would be placed in the same memory block as ...
- Jarrett Billingsley (30/38) Jun 06 2009 asy
- Steve Schveighoffer (19/62) Jun 06 2009 You are looking at a different problem. This problem already exists:
- Brad Roberts (7/47) Jun 06 2009 Can't work like that since it's subject to the object slicing problem. ...
- Steve Schveighoffer (23/70) Jun 06 2009 Structs are already part of the class data. I don't believe something
I think I shouldn't post this because I could very well start one of those mega-threads... :D Of course, only Walter & Co know what D2 will include when it's finally 'released'. Concurrency stuff has been developed lately. But something more? Or is that it? What do you think? I haven't thought about it too much, but lets say something... ;) 1) Scoped members. For example: class Foo { scope Bar bar; // gets destructed with Foo object } 2) There have been threads about the import/package system. So maybe it could be improved as well. (I'm not gonna discuss it more here.) But yeah, I guess this would require too much work to be done within D2's schedule. Oh, macros would also be nice, but maybe they will/should wait for D3... :)
Jun 06 2009
Kristian Kilpi wrote:I think I shouldn't post this because I could very well start one of those mega-threads... :D Of course, only Walter & Co know what D2 will include when it's finally 'released'. Concurrency stuff has been developed lately. But something more? Or is that it? What do you think? I haven't thought about it too much, but lets say something... ;) 1) Scoped members. For example: class Foo { scope Bar bar; // gets destructed with Foo object }You need to do escape analysis and whole program analysis to determine whether there are aliases to a scope member. Failing that, it's pretty easy to introduce bugs that are difficult to find. It would be fine as long as you always assign with a NewExpression.
Jun 06 2009
On Sat, 06 Jun 2009 16:35:15 +0300, Christopher Wright <dhasenan gmail.com> wrote:Kristian Kilpi wrote:Yep. Well, I would be happy with it even if you could only assing newly created objects to a scoped member. (And you could always remove this restriction when the escape analysis will be available (if ever).)I think I shouldn't post this because I could very well start one of those mega-threads... :D Of course, only Walter & Co know what D2 will include when it's finally 'released'. Concurrency stuff has been developed lately. But something more? Or is that it? What do you think? I haven't thought about it too much, but lets say something... ;) 1) Scoped members. For example: class Foo { scope Bar bar; // gets destructed with Foo object }You need to do escape analysis and whole program analysis to determine whether there are aliases to a scope member. Failing that, it's pretty easy to introduce bugs that are difficult to find. It would be fine as long as you always assign with a NewExpression.
Jun 06 2009
On Sat, 06 Jun 2009 09:35:15 -0400, Christopher Wright <dhasenan gmail.com> wrote:Kristian Kilpi wrote:Not really. A scope member would be placed in the same memory block as the owner class. So an alias to the member would be the same as an alias to the owner class because the same memory block would be referenced. Both wouldn't be collected until neither is referenced. It's the equivalent of this in C++: class Bar { } class Foo { Bar bar; } The only issue left to decide is how the member is initialized. There must be some rules, like if bar has no default constructor, it must be new'd in the constructor. And it can't be rebound. -SteveI think I shouldn't post this because I could very well start one of those mega-threads... :D Of course, only Walter & Co know what D2 will include when it's finally 'released'. Concurrency stuff has been developed lately. But something more? Or is that it? What do you think? I haven't thought about it too much, but lets say something... ;) 1) Scoped members. For example: class Foo { scope Bar bar; // gets destructed with Foo object }You need to do escape analysis and whole program analysis to determine whether there are aliases to a scope member. Failing that, it's pretty easy to introduce bugs that are difficult to find.
Jun 06 2009
On Sat, Jun 6, 2009 at 11:17 AM, Steven Schveighoffer<schveiguy yahoo.com> wrote:asyYou need to do escape analysis and whole program analysis to determine whether there are aliases to a scope member. Failing that, it's pretty e=theto introduce bugs that are difficult to find.Not really. =A0A scope member would be placed in the same memory block as=owner class. =A0So an alias to the member would be the same as an alias t=o theowner class because the same memory block would be referenced. =A0Both wouldn't be collected until neither is referenced.Regardless of how/where it's allocated, Chris is still right, unless 'scope' becomes a type constructor instead of a storage attribute. Consider: class A { void fork() { writeln("fork!"); } } class B { scope A a; this() { a =3D new A(); } } A a; void foo() { scope b =3D new B(); a =3D b.a; // waaait } void main() { foo(); a.fork(); // AGHL } If it were impossible to assign a "scope A" into an A, this wouldn't be a problem. Or, full escape analysis, either way.
Jun 06 2009
On Sat, 06 Jun 2009 11:26:37 -0400, Jarrett Billingsley wrote:On Sat, Jun 6, 2009 at 11:17 AM, Steven Schveighoffer<schveiguy yahoo.com> wrote:You are looking at a different problem. This problem already exists: A a; void foo() { scope al = new A(); a = al; } I'm talking about scope members, that is, members whose storage is contained within the owner. This allows destructors to access members before the members' memory is destroyed, because both the member and the owner's memory is destroyed at the same time. There would have to be some special treatment for a scope member by the compiler -- the member should not be rebindable, and I think you would not need to store a separate reference to the member, because it's reference address is statically decided. In other words, yes, scope members would be treated differently, but I don't think scope needs to be a type constructor for that. -SteveRegardless of how/where it's allocated, Chris is still right, unless 'scope' becomes a type constructor instead of a storage attribute. Consider: class A { void fork() { writeln("fork!"); } } class B { scope A a; this() { a = new A(); } } A a; void foo() { scope b = new B(); a = b.a; // waaait } void main() { foo(); a.fork(); // AGHL } If it were impossible to assign a "scope A" into an A, this wouldn't be a problem. Or, full escape analysis, either way.You need to do escape analysis and whole program analysis to determine whether there are aliases to a scope member. Failing that, it's pretty easy to introduce bugs that are difficult to find.Not really. A scope member would be placed in the same memory block as the owner class. So an alias to the member would be the same as an alias to the owner class because the same memory block would be referenced. Both wouldn't be collected until neither is referenced.
Jun 06 2009
Steven Schveighoffer wrote:On Sat, 06 Jun 2009 09:35:15 -0400, Christopher Wright <dhasenan gmail.com> wrote:Can't work like that since it's subject to the object slicing problem. Class size can't be known in advance since subclasses can add an arbitrary amount of additional storage requirements. If you restrict it to structs or other value types, then it could work but would be awfully restrictive. Later, BradKristian Kilpi wrote:Not really. A scope member would be placed in the same memory block as the owner class. So an alias to the member would be the same as an alias to the owner class because the same memory block would be referenced. Both wouldn't be collected until neither is referenced. It's the equivalent of this in C++: class Bar { } class Foo { Bar bar; } The only issue left to decide is how the member is initialized. There must be some rules, like if bar has no default constructor, it must be new'd in the constructor. And it can't be rebound. -SteveI think I shouldn't post this because I could very well start one of those mega-threads... :D Of course, only Walter & Co know what D2 will include when it's finally 'released'. Concurrency stuff has been developed lately. But something more? Or is that it? What do you think? I haven't thought about it too much, but lets say something... ;) 1) Scoped members. For example: class Foo { scope Bar bar; // gets destructed with Foo object }You need to do escape analysis and whole program analysis to determine whether there are aliases to a scope member. Failing that, it's pretty easy to introduce bugs that are difficult to find.
Jun 06 2009
On Sat, 06 Jun 2009 10:57:08 -0700, Brad Roberts wrote:Steven Schveighoffer wrote:Structs are already part of the class data. I don't believe something like this will work class A : B {} class C { scope A a; this() {a = new B;} } It would not work any differently than how scope classes are allocated on the stack. Just instead of the stack, you are allocating the scope class inside the class data instead of a stack (well, if the owner class was allocated on the stack, it would be on the stack). You would not have any slicing issues. Either: 1. The class contains not only the member class data but also a reference to it (and in this case, the reference could be re-bound). 2. The class can not reassign the member once it is assigned (i.e. head- const). When it passes the class member to a function, the compiler would pass a reference to the contained class data. This is what I was expecting. The benefit would be that you can control the destruction order of the members in the owner's destructor. -SteveOn Sat, 06 Jun 2009 09:35:15 -0400, Christopher Wright <dhasenan gmail.com> wrote:Can't work like that since it's subject to the object slicing problem. Class size can't be known in advance since subclasses can add an arbitrary amount of additional storage requirements. If you restrict it to structs or other value types, then it could work but would be awfully restrictive.Kristian Kilpi wrote:Not really. A scope member would be placed in the same memory block as the owner class. So an alias to the member would be the same as an alias to the owner class because the same memory block would be referenced. Both wouldn't be collected until neither is referenced. It's the equivalent of this in C++: class Bar { } class Foo { Bar bar; } The only issue left to decide is how the member is initialized. There must be some rules, like if bar has no default constructor, it must be new'd in the constructor. And it can't be rebound. -SteveI think I shouldn't post this because I could very well start one of those mega-threads... :D Of course, only Walter & Co know what D2 will include when it's finally 'released'. Concurrency stuff has been developed lately. But something more? Or is that it? What do you think? I haven't thought about it too much, but lets say something... ;) 1) Scoped members. For example: class Foo { scope Bar bar; // gets destructed with Foo object }You need to do escape analysis and whole program analysis to determine whether there are aliases to a scope member. Failing that, it's pretty easy to introduce bugs that are difficult to find.
Jun 06 2009