www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - struct vs. class, int vs. char.

reply MLT <none anon.com> writes:
D is really an amazing language! It really is everything that C++ did not
manage to be, at least as far as my limited experience with it shows. 

I noticed a couple of "problems" with it, and wanted to comment on them. It
could easily be that these comments just stem from my ignorance.

1. struct vs. class
As far as I understand, these two reserved words, that in C++ mean very similar
things, in D are very different. A class variable is "really" a pointer,
whereas a struct is directly allocated memory.

What I don't like is that it seems that structs and classes should almost be
interchangeable - one might implement something as a class and later want it to
be a struct, or vice versa. It almost is actually a local decision. I might
want something to be a class in one place, and a struct in another.

And, it seems that struct and class refer to several different things: (1)
struct and class are allocated in different places, (2) struct is supposed to
ensure its structure, and (3) struct is copied by value, whereas class by
reference.
It seems to me that these are 3 different issues, and one should have control
over them separately.

I find this example a bit strange:
struct S { int x;}
class C {int x;}
void main() {
{
  S x ;
  x.x = 1 ;
  S y = x ;
  y.x =2 ;
  writefln(x.x) ; // x.x is 1
}
{
  C x = new C ;
  x.x = 1;
  C y = x ;
  y.x = 2 ;
  writefln(x.x) ; // x.x is 2
}
}

I would have preferred to declare directly that the variable y takes or doesn't
take a reference when assigned. Otherwise, it seems to me that a program that
uses both (struct and class) can get mightily confusing.
Maybe the solution is to not use struct (which is I guess what is recommended
unless you really need it.)


2. char[] vs. int[]
I think it is strange that 
char[] x = "1234" ;
x[0] = '4' ;

Produces a run time error, but
int[] x = [1,2,3,4] ;
x[0] = 4 ;
Doesn't. I think that they both should, or both shouldn't - to be consistent
(and it would be better if they both didn't). Best would be again, to allow the
programmer to specify where the array (or other stuff) should be stored.

3. Builtin types vs. classes
(Here I probably am just missing the right phobos reference). D's builtin
structures are very rich. Associative arrays with arbitrary keys! Given that,
it is even sadder than it is in C++, that one can not inherit from the basic
types. I want to implement something that is basically an associative array of
one of my classes, with additional features. To do that, I will probably have
to put the associative array as a component, and redefine all
components/operations, or inherit from an associative array  in a library...
Apr 28 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Welcome.

MLT:
 D is really an amazing language!<

Yep.
It really is everything that C++ did not manage to be, at least as far as my
limited experience with it shows.<

I also hope D will never be lot of the things C++ is, because C++ is too many things :-)
 1. struct vs. class As far as I understand, these two reserved words, that in
C++ mean very similar things, in D are very different.<

C++ classes are like structs, but their methods are private by default. In D structs have value semantics, are copied by value and keep the given order of the fields, while classes have reference semantics, are often allocated on the heap, and the compiler in theory can change the order of fields in memory. They are designed for different purposes, and I agree with such decision by Walter. C# has chosen in a similar way. But later practice has shown that you want struct constructors, and other things, so now D2 has them too. So structs are a bit closer to classes now in D2.
A class variable is "really" a pointer, whereas a struct is directly allocated
memory.<

A class is a "reference". There are some ways manual or automatic with "scope" to sometimes allocate classes on the stack to improve performance. I have seen that sometimes it gives a nice speedup. You can't create an array of scoped classes by normal means, you have to manually change the way they allocate memory. Generally you can do what you want, but you may need some work to do special kinds of memory allocation.
What I don't like is that it seems that structs and classes should almost be
interchangeable - one might implement something as a class and later want it to
be a struct, or vice versa. It almost is actually a local decision. I might
want something to be a class in one place, and a struct in another.<

In D they are by design different, because most of the times you want just one of the meanings.
It seems to me that these are 3 different issues, and one should have control
over them separately.<

Giving control over each thing is of course nice and it may even increase performance in special situations. But it surely leads to an increase of the complexity of the language (and its use). D tries to be less complex than C++ (and C++ today is probably one of the most complex languages, and such very high complexity is now slowly killing it), and this means that sometimes you have to give up on some flexibility. If the language is well designed then most of the times, in practical programs, you don't feel much of such limitations.
Otherwise, it seems to me that a program that uses both (struct and class) can
get mightily confusing.<

It's confusing if you are used to program in a language like Python, where everything acts according to a reference semantics (more or less, it's not exactly like that, it's a name-semantics). But D is more complex and powerful than Python, and lower level too, and it gives you both reference and data semantics. Once you know that, you just have to keep in memory that classes are by reference and structs are by values, and you can live well (you can also have pointer to structs. I think I have never used a pointer to class in D yet).
 Maybe the solution is to not use struct (which is I guess what is recommended
unless you really need it.)<

Structs are useful in D because classes have some overhead in both memory, and their methods are always virtual (and all the current D compilers are unable to devirtualize such methods, maybe not even GDC is able to do it, even if G++ is sometime able to devirtualize C++ virtual methods, I think it's the only C++ compiler able to do that)), and being usually allocated on the heap (D compilers aren't like HotSpot that is sometimes able to allocate classes on the stack when it is sure they not exit the scope) they aren't fit if you for example need small [x,y] vectors.
 2. char[] vs. int[]
 I think it is strange that 
 char[] x = "1234" ;
 x[0] = '4' ;
 
 Produces a run time error, but
 int[] x = [1,2,3,4] ;
 x[0] = 4 ;
 Doesn't. I think that they both should, or both shouldn't - to be consistent
(and it would be better if they both didn't).

I leave this to other people. in D2 strings are immutable, by the way, while static arrays are not.
Best would be again, to allow the programmer to specify where the array (or
other stuff) should be stored.<

That requires you to pay some complexity. And D designers/programmers may be unwilling to pay it.
Given that, it is even sadder than it is in C++, that one can not inherit from
the basic types.<

Yes, this is a problem of D2. Scala language shows that there are better ways to design types, as you say. Walter has recently changed the D2 language to allow a bit of this, using "this". With that you can define a struct that behaves for example like the built-in associative array, and you don't need to redefine all its almost-methods. Bye, bearophile
Apr 28 2009
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 28 Apr 2009 13:00:36 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:

 MLT:
 2. char[] vs. int[]
 I think it is strange that
 char[] x = "1234" ;
 x[0] = '4' ;

 Produces a run time error, but
 int[] x = [1,2,3,4] ;
 x[0] = 4 ;
 Doesn't. I think that they both should, or both shouldn't - to be  
 consistent (and it would be better if they both didn't).

I leave this to other people. in D2 strings are immutable, by the way, while static arrays are not.

This has been discussed. Most people agree that the behavior should be consistent. Any array literal should be exactly that -- an unchangable literal. In D2, it should be an immutable literal (and produce a compile time error if you try and change it). BTW, this behavior you noticed is only on certain OSes. On other OSes (I think windows), you get weird behavior: char[] x = "1234"; x[0] = '4'; // no runtime error char[] y = "1234"; // y actually now equals "4234"! -Steve
Apr 28 2009
parent MLT <none anon.com> writes:
Steven Schveighoffer Wrote:

 BTW, this behavior you noticed is only on certain OSes.  On other OSes (I  
 think windows), you get weird behavior:
 
 char[] x = "1234";
 x[0] = '4'; // no runtime error
 char[] y = "1234"; // y actually now equals "4234"!
 
 -Steve

Pretty nice. It would be even nicer if you had the following: char[] x = "1234"; x[0] = '4'; // no runtime error char[] y = "12"; // y now equals "42" ;)
Apr 28 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Yes, this is a problem of D2. Scala language shows that there are
 better ways to design types, as you say.

Could you please give a little more detail? And speaking of Scala, after having watched a presentation, I was left with the impression that traits are nothing but classes with parameterized base. I mean this: abstract class Person { def schedule:Schedule } trait Student extends Person { private var classSchedule:Schedule = ... override def schedule = classSchedule def learn() = {...} } trait Worker extends Person { private var workSchedule:Schedule = ... override def schedule = workSchedule def work() = {...} } class CollegeStudent(school:School, company:Company) extends Student with Worker { // ... } is really this (in Scala-D made-up language): abstract class Person { def schedule:Schedule } class Student(Base) extends Person { private var classSchedule:Schedule = ... override def schedule = classSchedule def learn() = {...} } class Worker(Base) extends Person { private var workSchedule:Schedule = ... override def schedule = workSchedule def work() = {...} } class CollegeStudent(school:School, company:Company) extends Worker!(Student!(CollegeStudent)) { // ... } Is that correct? Andrei
Apr 28 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Could you please give a little more detail?

My experience with Scala is near zero, I have written and compiled only small programs, like the ones from the Shootout and the ones of the first tutorial. Scala isn't a language as simple as they say, its type system is quite complex and powerful, so Scala isn't easy to learn if you want to use it well. You can use monads in Scala too, in a decent enough way: http://www.scala-lang.org/node/46 To give you a small answer, in Scala all types are used in a quite uniform way. This is useful. Even integers have a methods (as in Ruby, but Scala is statically compiled). You can add "methods" to all integers: object extendBuiltins extends Application { def fact(n: Int): BigInt = if (n == 0) 1 else fact(n-1) * n class Factorizer(n: Int) { def ! = fact(n) } implicit def int2fact(n: Int) = new Factorizer(n) println(10!) } Removing most of the distinction from built-in types and values and user-defined ones has some advantages. alias this of D2 is a little step in that direction. Like the idea of having first-class types. Once you have first-class types, with run-time-function-evaluation you may not need templates anymore. You have just functions that act on types that run at runtime too. The space of all possible computer languages is huge.
 And speaking of Scala, after having watched a presentation, I was left 
 with the impression that traits are nothing but classes with 
 parameterized base.

 Is that correct?

I don't know, I am sorry. I may be able to answer your question after reading the Scala docs, but you may do that yourself, and probably more efficiently, because you are smarter. Bye, bearophile
Apr 28 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Apr 28, 2009 at 12:07 PM, MLT <none anon.com> wrote:

 What I don't like is that it seems that structs and classes should almost=

nt it to be a struct, or vice versa. It almost is actually a local decision= . I might want something to be a class in one place, and a struct in anothe= r. I hear this all the time from C++ users. But in practice, it virtually never comes up. I have never, in my five years of using D, wanted to change a class to a struct or vice versa, or ever seen anyone else doing that (or complaining about its difficulty). The only people who complain are those who don't use the language ;)
 And, it seems that struct and class refer to several different things: (1=

d to ensure its structure, and (3) struct is copied by value, whereas class= by reference.
 It seems to me that these are 3 different issues, and one should have con=

Again, in practice, you will virtually always want *either* value semantics *or* polymorphism. In the few cases where you need both, you can imitate it with mixins and the like (and with D2, 'alias this' is nice).
 I find this example a bit strange:
 struct S { int x;}
 class C {int x;}
 void main() {
 {
 =A0S x ;
 =A0x.x =3D 1 ;
 =A0S y =3D x ;
 =A0y.x =3D2 ;
 =A0writefln(x.x) ; // x.x is 1
 }
 {
 =A0C x =3D new C ;
 =A0x.x =3D 1;
 =A0C y =3D x ;
 =A0y.x =3D 2 ;
 =A0writefln(x.x) ; // x.x is 2
 }
 }

 I would have preferred to declare directly that the variable y takes or d=

gram that uses both (struct and class) can get mightily confusing. Again, in practice, it doesn't :) You always use some types as values and others always as references. Are C programs that use both ints and char* s mighty confusing?
 Maybe the solution is to not use struct (which is I guess what is recomme=

Please don't make everything a class. This isn't Java ;) What is instead recommended is that you use structs for value types and classes for everything else.
Apr 28 2009
parent reply grauzone <none example.net> writes:
Jarrett Billingsley wrote:
 On Tue, Apr 28, 2009 at 12:07 PM, MLT <none anon.com> wrote:
 
 What I don't like is that it seems that structs and classes should almost be
interchangeable - one might implement something as a class and later want it to
be a struct, or vice versa. It almost is actually a local decision. I might
want something to be a class in one place, and a struct in another.

I hear this all the time from C++ users. But in practice, it virtually never comes up. I have never, in my five years of using D, wanted to change a class to a struct or vice versa, or ever seen anyone else doing that (or complaining about its difficulty). The only people who complain are those who don't use the language ;)

Often I'd wish to statically allocate an object in the current context, like you can do with a struct. scope partially gives me what I want. It would be nice if "scope" could be used in other places: class Bla { int member; } class Foo { scope Bla b; //object constructed here } static assert(Foo.classinfo.init.size == 5*4); Yeah, you'd need a solution for how to call the ctor. Maybe the (very annoying) way of how initialization of final/const members is handled would be useful here.
Apr 28 2009
parent reply grauzone <none example.net> writes:
 I belive it could be implemented as a library type, using Scope(T) template:

I don't like that approach to replace random language features by templates at all. And in this case, you really have to ask WHY? It's nice that it's possible, but there are some reasons that speak against this approach: 1. it's harder to understand in general (even if the language definition becomes smaller) 2. error messages turn into an incomprehensible mess 3. puts more stress on the compiler and it gets slower (you will understand when you have to _wait_ for your project to finish compilation, even if you use the superfast dmd)
 class Foo
 {
     Scope!(Bar) _bar;
 }

Would typeof(_bar) == Bar?
 Perphaps, Phobos could provide that functionality, then we could deprecate
"scope Foo foo = new Foo(args);" in favor of "auto foo = Scope!(Foo)(args);"
and eventually remove from language.

Apr 28 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Denis Koroskin wrote:
 ...

Scope stack-allocating is an optimisation. It doesn't guarantee it because that it's the point of scope. Given that you're hung-up about stack allocation, I can't imagine how you'd implement scope as a template. Hell, I can't imagine how you'd implement Scope as a template for *any* of its behaviours. class Foo { Scope!(Bar) _bar; } How do you guarantee deterministic destruction when it's inside a non-deterministic construct? -- Daniel
Apr 28 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 28 Apr 2009 21:42:51 +0400, grauzone <none example.net> wrote:

 Jarrett Billingsley wrote:
 On Tue, Apr 28, 2009 at 12:07 PM, MLT <none anon.com> wrote:

 What I don't like is that it seems that structs and classes should  
 almost be interchangeable - one might implement something as a class  
 and later want it to be a struct, or vice versa. It almost is actually  
 a local decision. I might want something to be a class in one place,  
 and a struct in another.

virtually never comes up. I have never, in my five years of using D, wanted to change a class to a struct or vice versa, or ever seen anyone else doing that (or complaining about its difficulty). The only people who complain are those who don't use the language ;)

Often I'd wish to statically allocate an object in the current context, like you can do with a struct. scope partially gives me what I want. It would be nice if "scope" could be used in other places: class Bla { int member; } class Foo { scope Bla b; //object constructed here } static assert(Foo.classinfo.init.size == 5*4); Yeah, you'd need a solution for how to call the ctor. Maybe the (very annoying) way of how initialization of final/const members is handled would be useful here.

I belive it could be implemented as a library type, using Scope(T) template: class Foo { Scope!(Bar) _bar; } Perphaps, Phobos could provide that functionality, then we could deprecate "scope Foo foo = new Foo(args);" in favor of "auto foo = Scope!(Foo)(args);" and eventually remove from language.
Apr 28 2009
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Tue, Apr 28, 2009 at 6:07 PM, MLT <none anon.com> wrote:
 2. char[] vs. int[]
 I think it is strange that
 char[] x = "1234" ;
 x[0] = '4' ;

 Produces a run time error, but
 int[] x = [1,2,3,4] ;
 x[0] = 4 ;
 Doesn't. I think that they both should, or both shouldn't - to be consistent
(and it would be better if they both didn't). Best would be again, to allow the
programmer to specify where the array (or other stuff) should be stored.

It pretty much boils down to this (mostly said in other replies) * string literals are special, they are allocated in a static data segment, readonly if the platform allows it. * arrayliterals as non-static expressions are always heap allocated. even when there's absolute no need for it... (see http://d.puremagic.com/issues/show_bug.cgi?id=2356 ) -Tomas
Apr 28 2009
parent reply grauzone <none example.net> writes:
Denis Koroskin wrote:
 On Tue, 28 Apr 2009 22:13:50 +0400, Tomas Lindquist Olsen
<tomas.l.olsen gmail.com> wrote:
 
 On Tue, Apr 28, 2009 at 6:07 PM, MLT <none anon.com> wrote:
 2. char[] vs. int[]
 I think it is strange that
 char[] x = "1234" ;
 x[0] = '4' ;

 Produces a run time error, but
 int[] x = [1,2,3,4] ;
 x[0] = 4 ;
 Doesn't. I think that they both should, or both shouldn't - to be  
 consistent (and it would be better if they both didn't). Best would be  
 again, to allow the programmer to specify where the array (or other  
 stuff) should be stored.

* string literals are special, they are allocated in a static data segment, readonly if the platform allows it. * arrayliterals as non-static expressions are always heap allocated. even when there's absolute no need for it... (see http://d.puremagic.com/issues/show_bug.cgi?id=2356 ) -Tomas

Someone ought to post a feature request to make arrayliterals immutable by default (D2 only, I don't think this change will go to D1 anyway) and don't heap-allocate them every time they're used: int[] x1 = [1,2,3,4]; // error: can't assign immutable(int)[] to int[]

Why not auto-allocate? Writing that .dup all the time is going to be annoying. Just implicitly convert it from immutable to mutable by copying.
 int[] x2 = [1,2,3,4].dup; // okay, allocates
 
 int[4] x3 = [1,2,3,4]; // okay, doesn't allocate
 
 foreach (int i; [1,2,3,4]) { // okay, doesn't allocate
     // ...
 }

Apr 28 2009
parent reply Don <nospam nospam.com> writes:
grauzone wrote:
 Denis Koroskin wrote:
 On Tue, 28 Apr 2009 22:13:50 +0400, Tomas Lindquist Olsen 
 <tomas.l.olsen gmail.com> wrote:

 On Tue, Apr 28, 2009 at 6:07 PM, MLT <none anon.com> wrote:
 2. char[] vs. int[]
 I think it is strange that
 char[] x = "1234" ;
 x[0] = '4' ;

 Produces a run time error, but
 int[] x = [1,2,3,4] ;
 x[0] = 4 ;
 Doesn't. I think that they both should, or both shouldn't - to be  
 consistent (and it would be better if they both didn't). Best would 
 be  again, to allow the programmer to specify where the array (or 
 other  stuff) should be stored.

* string literals are special, they are allocated in a static data segment, readonly if the platform allows it. * arrayliterals as non-static expressions are always heap allocated. even when there's absolute no need for it... (see http://d.puremagic.com/issues/show_bug.cgi?id=2356 ) -Tomas

Someone ought to post a feature request to make arrayliterals immutable by default (D2 only, I don't think this change will go to D1 anyway) and don't heap-allocate them every time they're used:


Definitely. They should go into the initialized data segment.
 int[] x1 = [1,2,3,4]; // error: can't assign immutable(int)[] to int[]

Why not auto-allocate? Writing that .dup all the time is going to be annoying. Just implicitly convert it from immutable to mutable by copying.

I think it's pretty unlikely that you'd want to do that. It's far more likely that it's a bug, and you meant it to be an immutable(int)[]. Except in the case where the array is empty. (Likewise, it'd be nice if char [] s=""; were legal in D2. Since a mutable "" string has nothing that can be changed anyway, "" can be treated in the same way that 'null' is).
 
 int[] x2 = [1,2,3,4].dup; // okay, allocates

 int[4] x3 = [1,2,3,4]; // okay, doesn't allocate

 foreach (int i; [1,2,3,4]) { // okay, doesn't allocate
     // ...
 }


Apr 29 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Don wrote:
 (Likewise, it'd be nice if char [] s=""; were legal in D2. Since a 
 mutable "" string has nothing that can be changed anyway, "" can be 
 treated in the same way that 'null' is).

There was a huge discussion about null strings a few years ago. (Probably it was before Andrei, and possibly before your time.) IIRC, most of the discussion was about detecting the "nullness" of a string, and what we should define the Null string to be, there were a few good thoughts around the subject in general.
Apr 29 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 28 Apr 2009 22:13:50 +0400, Tomas Lindquist Olsen
<tomas.l.olsen gmail.com> wrote:

 On Tue, Apr 28, 2009 at 6:07 PM, MLT <none anon.com> wrote:
 2. char[] vs. int[]
 I think it is strange that
 char[] x = "1234" ;
 x[0] = '4' ;

 Produces a run time error, but
 int[] x = [1,2,3,4] ;
 x[0] = 4 ;
 Doesn't. I think that they both should, or both shouldn't - to be  
 consistent (and it would be better if they both didn't). Best would be  
 again, to allow the programmer to specify where the array (or other  
 stuff) should be stored.

It pretty much boils down to this (mostly said in other replies) * string literals are special, they are allocated in a static data segment, readonly if the platform allows it. * arrayliterals as non-static expressions are always heap allocated. even when there's absolute no need for it... (see http://d.puremagic.com/issues/show_bug.cgi?id=2356 ) -Tomas

Someone ought to post a feature request to make arrayliterals immutable by default (D2 only, I don't think this change will go to D1 anyway) and don't heap-allocate them every time they're used: int[] x1 = [1,2,3,4]; // error: can't assign immutable(int)[] to int[] int[] x2 = [1,2,3,4].dup; // okay, allocates int[4] x3 = [1,2,3,4]; // okay, doesn't allocate foreach (int i; [1,2,3,4]) { // okay, doesn't allocate // ... }
Apr 28 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 28 Apr 2009 22:50:28 +0400, grauzone <none example.net> wrote:

 I belive it could be implemented as a library type, using Scope(T)  
 template:

I don't like that approach to replace random language features by templates at all. And in this case, you really have to ask WHY? It's nice that it's possible, but there are some reasons that speak against this approach: 1. it's harder to understand in general (even if the language definition becomes smaller) 2. error messages turn into an incomprehensible mess 3. puts more stress on the compiler and it gets slower (you will understand when you have to _wait_ for your project to finish compilation, even if you use the superfast dmd)
 class Foo
 {
     Scope!(Bar) _bar;
 }

Would typeof(_bar) == Bar?

No way! But Scope!(Bar) would be implicitly castable to Bar (just not vice-versa): Bar b = _bar; // allowed _bar = b; // disallowed In fact, I don't like scope as it is: scope Foo foo = ...; // is foo scope allocated or not? It depends: scope Foo foo = new Foo(); // scope-allocated Foo getFoo() { return new Foo(); } scope Foo foo = getFoo(); // ???? In last example, DMD may inline and make it scope-allocated, but may not inline and make it heap-allocated. Scope!(Foo) foo = ...; gives you better control over allocation. For example, Scope!(Foo) foo = getFoo(); won't even compile.
Apr 28 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 29 Apr 2009 06:09:49 +0400, Daniel Keep <daniel.keep.lists gmail.com>
wrote:

 Denis Koroskin wrote:
 ...

Scope stack-allocating is an optimisation. It doesn't guarantee it because that it's the point of scope. Given that you're hung-up about stack allocation, I can't imagine how you'd implement scope as a template. Hell, I can't imagine how you'd implement Scope as a template for *any* of its behaviours. class Foo { Scope!(Bar) _bar; } How do you guarantee deterministic destruction when it's inside a non-deterministic construct? -- Daniel

Is that a challenge? import std.stdio; class Foo { this(int i, int j, int k) { writeln("Foo.this(): ", i, j, k); } ~this() { writeln("Foo.~this()"); } } struct Scope(T) { this(Args...)(Args args) { _data[] = T.classinfo.init[]; // shouldn't be needed __get.__ctor(args); } ~this() { __get.__dtor(); } alias __get this; T __get() { return cast(T)_data.ptr; } static assert(is(T == class)); private byte[__traits(classInstanceSize, T)] _data; //private byte[__traits(classInstanceSize, T)] _data = T.classinfo.init; // bug: doesn't work } void main() { auto foo = Scope!(Foo)(1, 2, 3); } One more bug-o-feature is that Scope.ctor is not called when args set is empty: auto foo = Scope!(Foo)(); // no Scope.__ctor is called and thus underlying Foo instance is left uninitialized. I never understood a rationale behind this "feature". I believe it's a hole.
Apr 29 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
Here is another example:

import std.stdio;
import Scope;

class Foo
{
    this(int i, int j, int k) {
        writeln("Foo.this(): ", i, j, k);
    }
    
    ~this() {
        writeln("Foo.~this()");
    }
}

class Bar
{
    this(int i, int j, int k)
    {
        writeln("Bar.this(): ", i, j, k);
        foo = Scope!(Foo)(i, j, k);
    }
    
    ~this()
    {
        writeln("Bar.~this()");
    }

    Scope!(Foo) foo;
}

// Just for comparison - note that they are almost the same
class NoScopeBar
{
    this(int i, int j, int k)
    {
        writeln("NoScopeBar.this()");
        foo = new Foo(i, j, k);
    }

    ~this()
    {
        writeln("NoScopeBar.~this()");
    }

    Foo foo;
}

void main()
{
    auto bar = Scope!(Bar)(1, 2, 3);
}

Expected output:

Bar.this(): 123
Foo.this(): 123
Bar.~this()
Foo.~this()

Output:
Bar.this(): 123
Foo.this(): 123
Bar.~this()

It is a DMD bug: calling an object's dtor should call dtors on all its fields.
Apr 29 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 29 Apr 2009 13:06:18 +0400, Denis Koroskin <2korden gmail.com> wrote:

 It is a DMD bug: calling an object's dtor should call dtors on all its  
 fields.

This could be temporarily worked around by little template magic: foreach(field; filterFields(__traits(allMembers,T))) { field.dtor(); }
Apr 29 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 29 Apr 2009 05:44:07 -0400, Don <nospam nospam.com> wrote:


 Except in the case where the array is empty.
 (Likewise, it'd be nice if char [] s=""; were legal in D2. Since a  
 mutable "" string has nothing that can be changed anyway, "" can be  
 treated in the same way that 'null' is).

Why is this more desirable than just: char[] s; int[] i; Which works now. -Steve
Apr 29 2009