Re: Newbie: copy, assignment of class instances
Thank you, I had no idea that scope was doing this. I thought that when the docs said that it was being allocated on the stack that I was getting struct like behavior. Simen kjaeraas simen.kja...@gmail.com wrote in message news:op.vc0qlpjovxi...@biotronic-pc.home... | Larry Luther larry.lut...@dolby.com wrote: | | |scope B | alpha = new B; | | | 'scope B alpha;' allocates stack space for a reference to a B, and | space for an instance of B. If the pointer changes, it is simply no longer | referencing the instance on the stack. | | -- | Simen
Re: Newbie: copy, assignment of class instances
bearophile bearophileh...@lycos.com wrote in message
news:ht4g3r$vu...@digitalmars.com...
| Larry Luther:
|
| I did not get an error when building and running with DMD 2.042:
|
| I am using dmd v2.046, and I have taken the good habit of compiling
with -w (warnings on).
| It seems this error I see is a blocking warning. It's a warning badly
written, but do you agree it is saying something important? I presume your
code can lead to bugs. I don't know why this is a warning instead of a true
error...
|
| On your code it also complains for a missed override that is a good
thing that eventually will become obligatory even without -w.
|
| When you post here I suggest you to avoid using HTML and use pure text.
|
| Bye,
| bearophile
Ok, I've added -w to compilation commands and I've switched back to pure
text.
Given:
class A {
int x, y;
void copy (const A a) {
x = a.x;
y = a.y;
}
}
class B : A {
int z;
void copy (const B b) {
super.copy( b);
z = b.z;
}
}
A alpha = new A;
A bravo = new A;
B charlie = new B;
B delta = new B;
---
I don't see the problem with A.copy vs B.copy.
alpha.copy( bravo)-- should execute A.copy
alpha.copy( charlie) -- should execute A.copy
charlie.copy( delta) -- should execute B.copy
charlie.copy( alpha) -- should execute A.copy
What am I missing?
Larry
Re: Newbie: copy, assignment of class instances
Larry Luther: I'm nonplussed. Could you expand on why D class instances don't need to copy their contents and instances of D structs do? While migrating C++ code to D I've had to convert structs to classes because of the need for inheritance. Why would the need to copy an instance's contents to another instance disappear? You are an experienced programmer, so if you think well about this topic you can probably understand the situation and the purposes behind D design as well or better than me. You probably know already what I can tell you about this topic. D is different from C++, it's GC-based, and this changes many things and the way they have to be designed and used. D is designed to be a little simpler than C++, this means in some cases it prefers to do something in a safer way, instead in the most efficient way. D doesn't follow the zero overhead policy of C++, because it can lead to hairy code and because Java and C# have plenty shown it's often a waste of programmers time with no real performance gain. In D structs don't support inheritance because they are designed to avoid the slicing bug, to be simpler, to be Plain Old Data. So D is designed to have different classes and structs because their usage style and purposes are different. When more complexity is needed, classes are there to be used. Even if currently DMD is not very good at optimizing away the class-derived overhead, better future D compilers can solve this. For some situations there's even the scope (that Walter is not so sure to keep, while other people like me have suggested the opposite, that is to extend its purpose to allocate an object inside the memory of another object) that can help performance. In Java the HotSpot is able to perform Escape Analysis on objects to avoid many heap allocations, and LDC is able to detect some simple cases and do the same. By design D has no standard way to copy classes. I have not written very large object oriented D programs, but from what I have seen, I generally don't need to copy objects. I have often the need to move them around, put them in a collection, pull them out and put them in another collection, or create them in single instance, and so on. But I don't remember the last time I've had to copy a class instance in D. I just copy and add and remove class references. When I want I can keep many references to the same object and so on. In C++ programs this has to be done with care, because there is no GC, or you need some kind of smart pointer, while in D (in theory) you can relax and just let the GC do its thing. My experience tells me that when you try to translate a program written in language X to language Y you always find some impedance (unless X and Y are almost the same language). But most times in language Y there are ways to solve the problem in a different way. You, as programmer, have to learn the way Y programs are usually written, its idioms and to avoid to force X idioms in Y and then complain that X idioms are not well represented in Y. D design is far from perfect, and in future some things will probably need to be fixed (I have written enough text to fill two books about D features that can enjoy some change), but behind its design there is also lot of thought. So, you can show us some D code where you think there is a need to copy objects. If such uncommon need arises you can usually write your own copy functions. Bye, bearophile
Re: Newbie: copy, assignment of class instances
Larry Luther:
Ok, I've added -w to compilation commands and I've switched back to pure text.
Good :-)
What am I missing?
I have modified a bit your D code like this, to have something with a main()
that runs:
import std.c.stdio: puts;
class A {
int x, y;
void copy(const A a) {
puts(A copy);
x = a.x;
y = a.y;
}
}
class B : A {
int z;
void copy(const B b) {
puts(B copy);
super.copy(b);
z = b.z;
}
}
void main() {
A a1 = new A;
A a2 = new A;
B b1 = new B;
B b2 = new B;
a1.copy(a2); // should execute A.copy
a1.copy(b1); // should execute A.copy
b1.copy(b2); // should execute B.copy
b1.copy(a1); // should execute A.copy
}
I have also translated your the code to Java, because sometimes Java designers
are more correct thant D designers:
class A {
int x, y;
void mycopy(A a) {
System.out.println(A mycopy);
x = a.x;
y = a.y;
}
}
class B extends A {
int z;
void mycopy(B b) {
System.out.println(B mycopy);
super.mycopy(b);
z = b.z;
}
public static void main(String[] args) {
A a1 = new A();
A a2 = new A();
B b1 = new B();
B b2 = new B();
a1.mycopy(a2); // should execute A.mycopy
a1.mycopy(b1); // should execute A.mycopy
b1.mycopy(b2); // should execute B.mycopy
b1.mycopy(a1); // should execute A.mycopy
}
}
The Java code compiles and runs with no errors, and prints:
A mycopy
A mycopy
B mycopy
A mycopy
A mycopy
But the D version is different. It seems you have found a small difference
between Java and D that I didn't know about.
If I comment out the last line of the main() in the D code (b1.copy(a1);) and I
compile the D code with -w it generates the warning I was talking about:
test.d(13): Error: class test.B test.A.copy(const const(A) a) is hidden by B
If I leave that line uncommented then the compilation stops with a different
error:
test.d(33): Error: function test.B.copy (const const(B) b) is not callable
using argument types (A)
test.d(33): Error: cannot implicitly convert expression (a1) of type test.A to
const(B)
It seems in D the copy() of B replaces (hides) the copy() of A, even if no
override is used. I don't know why D is designed this way, it can even be a
design/implementation bug. But the presence of that warning suggests me this is
expected, so it's probably just a difference between Java and D. If no one
answers to this here then maybe later I will ask about this in the main D group.
Bye,
bearophile
Re: Newbie: copy, assignment of class instances
See: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=110554
Re: Newbie: copy, assignment of class instances
bearophile bearophileh...@lycos.com wrote in message
news:ht4krg$17l...@digitalmars.com...
| On the base of your long experience do you like D so far?
There are many things that I like and I strongly agree with the failings
of C++ mentioned in the docs. I don't like the asymmetry between structs
and classes. I don't see why structs can't have inheritance. I haven't
had a memory leak problem in C++ for many years so the need for a GC seems
minor.
I can only assume that it's needed to support strings and dynamic arrays.
I'm pushing forward on the assumption that I'll discover the paradigm that
will make everything fall into place. It's hard to get the proper picture
from the documentation available on Digital-mars. Tango with D didn't
significantly help either. For example it took a great deal of time to
learn
that private can be used several ways:
private member_function () {)
private {
member_function () {}
}
private:
member_function () {}
I'm anxiously waiting for something of the quality of the Annotated C++
Reference Manual.
Larry
Re: Newbie: copy, assignment of class instances
Larry Luther: There are many things that I like and I strongly agree with the failings of C++ mentioned in the docs. D is designed by people that have a good experience of C++, but while probably D avoids some C++ problems, it surely introduces a number of new issues :-) I don't like the asymmetry between structs and classes. I don't see why structs can't have inheritance. One of the first answers given here is that this D design avoids slicing bugs. See my other answer for more. I haven't had a memory leak problem in C++ for many years so the need for a GC seems minor. I can only assume that it's needed to support strings and dynamic arrays. A GC introduces other kind of leaks when there is a reference alive to an memory block that is supposed to be dead and not used any more. This can even be caused by the not precise nature of the current D GC, it can mismatch something for a pointer to a GC-managed memory zone, keeping it alive. For example in programs that use large associative arrays this seems a problem. If you assume the presence of the GC this changes the way you write code. In theory you can be more relaxed. In practice D GC is not... well, you have to keep your eyes open anyway. I'm pushing forward on the assumption that I'll discover the paradigm that will make everything fall into place. If you have some Java programming experience then you probably have nothing to discover regarding this aspect of D programming (here the main difference is that Oracle Java GC is more precise and quite more efficient). For example it took a great deal of time to learn that private can be used several ways: One of the good things of D design is that it tries to be uniform/consistent, in this case all other attributes can be used in the same ways :-) I'm anxiously waiting for something of the quality of the Annotated C++ Reference Manual. The problem here is that D is not very strictly defined in the first place, so it's harder to write a very strict D reference manual :-) But Andrei book is about to come out, that can be seen as a kind of official D2 reference. Bye, bearophile
Re: Newbie: copy, assignment of class instances
On Thu, 27 May 2010 17:04:35 -0400, Larry Luther larry.lut...@dolby.com
wrote:
bearophile bearophileh...@lycos.com wrote in message
news:ht4krg$17l...@digitalmars.com...
| On the base of your long experience do you like D so far?
There are many things that I like and I strongly agree with the failings
of C++ mentioned in the docs. I don't like the asymmetry between structs
and classes. I don't see why structs can't have inheritance.
Because of the slicing problem. It's basically something like this:
struct A {virtual void foo();};
struct B : A {virtual void foo();};
void bar(A a)
{
a.foo();
}
void baz()
{
B b;
bar(b); // b is sliced down to an A, and bar will now call A.foo
instead of the expected B.foo.
}
The really bad part about this is, b might have set up its private
variables so that to call A.foo would cause an error.
Same thing happens when returning by value. The general issue is that
inheritance and value types don't mix. But reference types (that is,
types that are always passed by reference) never have the slicing
problem. So classes in D (which are reference types) can inherit, while
structs (which *can be* value types) cannot inherit. I have hoped that at
some point, structs can be auto-composed, without a vtable, but you still
have to do this manually. Luckily, it's not so much of a chore now that
alias this is around.
I haven't
had a memory leak problem in C++ for many years so the need for a GC
seems
minor.
I can only assume that it's needed to support strings and dynamic arrays.
I'm pushing forward on the assumption that I'll discover the paradigm
that
will make everything fall into place.
Yes, what it took for me is to write a project in C++ that could really
have used a GC.
Essentially, here was my issue:
I had a protocol implemented with various messages with a function
readMessage, which returned a newly-allocated message (which was a
derivative of some base message type). Then I used RTTI to cast the
message to the right type to deal with the data. However, what sucked is
how I always had to free the message after receiving it. I really just
wanted to process the message and go to the next one. A GC is great for
this because memory management is not strewn throughout your code, you
don't have to remember to free things you should free and leave things you
should not. On top of that, in my case, I had to figure out that I was
responsible for freeing a message via documentation -- the language didn't
really tell me. In D, no matter where it comes from, you just forget
about it, and whoever is responsible (GC or owner) cleans it up later. It
makes for much more readable and less error-prone code.
There are many other designs which work well with GC, and some which don't.
D has some power over the memory management so you can force your will
upon it, but I've found that the best way to write D code is to embrace
the GC.
Note also that memory leaks are not the worst problem with non-GC code.
Freeing memory you weren't supposed to is worse.
I'm anxiously waiting for something of the quality of the Annotated
C++
Reference Manual.
The D Programming Language is hitting bookstores soon, I think it will be
a very good reference and educational book.
-Steve
Re: Newbie: copy, assignment of class instances
Steven Schveighoffer: I have hoped that at some point, structs can be auto-composed, without a vtable, but you still have to do this manually. I don't understand what you mean here :-) Bye, bearophile
Re: Newbie: copy, assignment of class instances
bearophile wrote:
Larry Luther:
Ok, I've added -w to compilation commands and I've switched back to pure text.
Good :-)
What am I missing?
I have modified a bit your D code like this, to have something with a main()
that runs:
import std.c.stdio: puts;
class A {
int x, y;
void copy(const A a) {
puts(A copy);
x = a.x;
y = a.y;
}
}
class B : A {
int z;
void copy(const B b) {
puts(B copy);
super.copy(b);
z = b.z;
}
}
void main() {
A a1 = new A;
A a2 = new A;
B b1 = new B;
B b2 = new B;
a1.copy(a2); // should execute A.copy
a1.copy(b1); // should execute A.copy
b1.copy(b2); // should execute B.copy
b1.copy(a1); // should execute A.copy
}
I have also translated your the code to Java, because sometimes Java designers are more
correct thant D designers:
class A {
int x, y;
void mycopy(A a) {
System.out.println(A mycopy);
x = a.x;
y = a.y;
}
}
class B extends A {
int z;
void mycopy(B b) {
System.out.println(B mycopy);
super.mycopy(b);
z = b.z;
}
public static void main(String[] args) {
A a1 = new A();
A a2 = new A();
B b1 = new B();
B b2 = new B();
a1.mycopy(a2); // should execute A.mycopy
a1.mycopy(b1); // should execute A.mycopy
b1.mycopy(b2); // should execute B.mycopy
b1.mycopy(a1); // should execute A.mycopy
}
}
The Java code compiles and runs with no errors, and prints:
A mycopy
A mycopy
B mycopy
A mycopy
A mycopy
But the D version is different. It seems you have found a small difference
between Java and D that I didn't know about.
If I comment out the last line of the main() in the D code (b1.copy(a1);) and I
compile the D code with -w it generates the warning I was talking about:
test.d(13): Error: class test.B test.A.copy(const const(A) a) is hidden by B
If I leave that line uncommented then the compilation stops with a different
error:
test.d(33): Error: function test.B.copy (const const(B) b) is not callable
using argument types (A)
test.d(33): Error: cannot implicitly convert expression (a1) of type test.A to
const(B)
It seems in D the copy() of B replaces (hides) the copy() of A, even if no
override is used. I don't know why D is designed this way, it can even be a
design/implementation bug. But the presence of that warning suggests me this is
expected, so it's probably just a difference between Java and D. If no one
answers to this here then maybe later I will ask about this in the main D group.
Bye,
bearophile
For what it's worth, here is a code that uses 'dup' instead of 'copy'. I
know this is not the same thing; but I find this more intuitive:
import std.stdio;
import std.string;
class A
{
int x, y;
this(int x, int y)
{
this.x = x;
this.y = y;
}
A dup() const
{
writeln(A copy);
return new A(x, y);
}
override string toString() const
{
return format(A(%s,%s), x, y);
}
}
class B : A
{
int z;
this(int x, int y, int z)
{
super(x, y);
this.z = z;
}
override B dup() const
{
writeln(B copy);
return new B(x, y, z);
}
override string toString() const
{
return format(B(%s,%s,%s), x, y, z);
}
}
void main() {
A a1 = new A(1, 1);
A a2 = new A(2, 2);
B b1 = new B(11, 11, 11);
B b2 = new B(22, 22, 22);
a1 = a2.dup;
assert((a1.x == 2) (a1.y == 2));
a1 = b1.dup;
assert((a1.x == 11) (a1.y == 11));
assert(typeid(a1) == typeid(B)); // -- personality change
b1 = b2.dup;
assert((b1.x == 22) (b1.y == 22) (b1.z == 22));
// b1 = a1.dup; // -- ERROR because not all As are Bs;
// but as we know that a1 is
// actually a B at this point;
// we can down cast:
assert(cast(B)a1 !is null);
b1 = (cast(B)a1).dup;
assert((b1.x == 11) (b1.y == 11) (b1.z == 11));
writeln(a1);
writeln(a2);
writeln(b1);
writeln(b2);
}
Ali
Re: Newbie: copy, assignment of class instances
On Thu, 27 May 2010 17:47:20 -0400, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
I have hoped that at some point, structs can be auto-composed,
without a vtable, but you still have to do this manually.
I don't understand what you mean here :-)
I mean simple inheritance. In C, there has always been manual
inheritance. You can see it with the sockaddr system, and even with the X
toolkit widget system.
essentially, when you derive type B from type A in C++, you get this:
struct B
{
A _a;
}
A is always put first, that way, a pointer to a B can always be used as a
pointer to an A.
The other thing that happens is that function calls on B also use A as
well. This is not so easy in C, but in D it is currently quite trivial:
struct B
{
A _a;
alias _a this;
}
Then a call like b.methodOfA(); gets translated statically to
b._a.methodOfA().
But there are things I don't like about this, such as you can *set* _a.
To get around that, you define a property getter, but not a setter:
struct B
{
private A _a;
@property ref A a() {return _a;}
alias a this;
}
What I would like is a common-sense approach to inheritance for structs
that just does not allow virtual methods or interfaces, and which does not
cast implicitly to the base (explicit cast is OK). I think some designs
would benefit greatly from this simple feature. I think it's more tricky
than I've described, but I think with some diligence it can be done.
-Steve
Re: Newbie: copy, assignment of class instances
On Thu, 27 May 2010 18:41:19 -0400, bearophile bearophileh...@lycos.com wrote: Thank you Steven for your explanations, I have done similar things in C and D, but I didn't understand what you meant. A is always put first, that way, a pointer to a B can always be used as a pointer to an A. Are you sure C specs say doing this leads to defined behaviour? (Recently from a discussion with Walter I have learnt that D follows exactly C specs regarding such defined/undefined things.) Xt and the Berkeley sockets library relies on it. If it's not in the spec, then it's a de-facto standard. I think the defined behavior is that the first member of a struct is positioned at the same address as the struct itself. What I would like is a common-sense approach to inheritance for structs that just does not allow virtual methods or interfaces, and which does not cast implicitly to the base (explicit cast is OK). I think some designs would benefit greatly from this simple feature. I think it's more tricky than I've described, but I think with some diligence it can be done. I have desired some form of inheritance in D structs (before the creation of alias this, that so far I have not used much). I think Walter will not love this idea, but you can think more about its details, and then you can post it in the main D newsgroup. Sadly, I think it is not much more than a wish. I don't think Walter's mind can be changed on this. -Steve
Newbie: copy, assignment of class instances
Given:
class A {
int x, y;
}
class B : A {
int z;
}
B
foo = new B,
bar = new B;
scope B
alpha = new B;
Q1: How do I copy the member variables contributed by base class A
from foo to bar?
In C++: (A ) bar = foo;
Q2: How do I do a deepcopy of foo to bar?
In C++: bar = foo;
Q3: Is the object alpha on the stack (per documentation)?
Q4: What happens when I do alpha = foo;?
printf( %p\n, alpha); indicates that the address of alpha has
changed.
Thanks, Larry
Re: Newbie: copy, assignment of class instances
Larry Luther larry.lut...@dolby.com wrote:
Given:
class A {
int x, y;
}
class B : A {
int z;
}
B
foo = new B,
bar = new B;
scope B
alpha = new B;
Q1: How do I copy the member variables contributed by base class A
from foo to bar?
In C++: (A ) bar = foo;
You can't. If you need this functionality, use a specialized function.
Q2: How do I do a deepcopy of foo to bar?
In C++: bar = foo;
You don't. If you need this functionality, use a specialized function.
This should, to keep symmetry with other D features, probably be
called dup. Possibly deepdup, as the other dups don't do deep copy.
It is also worth noting that 'bar = foo;' does not perform deep copying
in C++, it only copies the immediate members, whereas deep copy would
follow pointers and deep copy those, too.
btw, if what you're referring to is not the deep copy explained above,
but merely a shallow copy (of the instance, not the reference), the
function should be called dup.
Q3: Is the object alpha on the stack (per documentation)?
Yes. Proof:
void main( ) {
A a = new A( );
scope A b = new A( );
writefln( %p, %p, %p, cast(void*)a, cast(void*)b, cast(void*)a );
}
Q4: What happens when I do alpha = foo;?
printf( %p\n, alpha); indicates that the address of alpha has
changed.
'scope B alpha;' allocates stack space for a reference to a B, and
space for an instance of B. If the pointer changes, it is simply no longer
referencing the instance on the stack.
--
Simen
Re: Newbie: copy, assignment of class instances
Larry Luther:
class A {
int x, y;
}
class B : A {
int z;
}
B
foo = new B,
bar = new B;
scope B
alpha = new B;
Don't write code like this, it's not easy to write:
B
foo = new B,
bar = new B;
Write it this way:
B foo = new B,
B bar = new B;
Or this way:
auto foo = new B,
auto bar = new B;
Q1: How do I copy the member variables contributed by base class A
from foo to bar?
In C++: (A ) bar = foo;
There is no standard way to do this. In general you don't need to copy classes
or their contents, because they are on the heap and managed by the GC. If you
want to copy their contents you have to add methods written by you that perform
the copy you need.
Q2: How do I do a deepcopy of foo to bar?
In C++: bar = foo;
In general you don't do it. There is no standard way to perform a deep copy.
You can write your code to do it, but it's not easy to write. So far I have
never had to perform a deep copy on D classes.
For structs take a look at postblit too:
http://www.digitalmars.com/d/2.0/struct.html#StructPostblit
Q3: Is the object alpha on the stack (per documentation)?
In this case with ldc and dmd alpha is on the stack, you can see also reading
the produced asm. On the docs you can read the rules that must be satisfied for
scoped classes to be really allocated on the stack.
Q4: What happens when I do alpha = foo;?
printf( %p\n, alpha); indicates that the address of alpha has
changed.
alpha is on the stack, but beside alpha on the stack there is also the
reference to alpha. So such reference gets rewritten.
Generally in D it's not a good idea to reassign the reference to a scoped class
(some months ago I have even suggested to turn this operation into a syntax
error) because when the scope ends, the class referenced by the reference to
alpha gets collected, so if you change such reference to something else, it is
such something else that gets collected. I am not sure what happens here, but
this can be a source of bad troubles. This is probably why Walter was thinking
of removing the scope attribute for classes.
Bye,
bearophile
Re: Newbie: copy, assignment of class instances
Generally in D it's not a good idea to reassign the reference to a scoped
class
You can see it with this little D2 program:
import std.stdio: printf;
class Foo {
int x;
this(int xx) { this.x = xx; }
~this() { printf(Foo(%d) destructor\n, this.x); }
}
void main() {
scope Foo f1 = new Foo(1);
Foo f2 = new Foo(2);
f1 = f2;
}
It prints just:
Foo(2) destructor
In general this is not good.
Bye,
bearophile
Re: Newbie: copy, assignment of class instances
Thank you for the clarifications.
I'm trying to do a shallow copy.
After reading Simen bearophile, I would add a copy member function:
class A {
int x, y;
void copy (in A a) {
x = a.x;
y = a.y;
}
}
class B : A {
int z;
void copy (in B b) {
super.copy( b);
z = b.z;
}
}
B foo = new B,
B bar = new B;
Q: Do I copy the member variables contributed by class A
from foo to bar, this way: (cast(A) bar).copy( foo);?
Or maybe bar.A.copy( foo);?
Larry
Re: Newbie: copy, assignment of class instances
I did not get an error when building and running with DMD 2.042:
import std.stdio;
class A {
int x, y;
void copy (in A a) {
x = a.x;
y = a.y;
}
void dump (string s) {
writefln( %s.A = { %s, %s }, s, x, y);
}
}
class B : A {
int z;
void copy (in B b) {
super.copy( b);
z = b.z;
}
void dump (string s) {
super.dump( s);
writefln( %s.B = { %s }, s, z);
}
}
void main () {
B foo = new B;
B bar = new B;
foo.x = 3;
foo.y = 5;
foo.z = 17;
bar.x = 7;
bar.y = 11;
bar.z = 13;
foo.dump( foo);
bar.dump( bar);
bar.copy( foo);
bar.dump( bar#2);
}
Which prints:
foo.A = { 3, 5 }
foo.B = { 17 }
bar.A = { 7, 11 }
bar.B = { 13 }
bar#2.A = { 3, 5 }
bar#2.B = { 17 }
Re: Newbie: copy, assignment of class instances
On 05/20/2010 06:23 PM, bearophile wrote: You are a newbie, so let me point the little flaws in your D code, this is the D style guide: http://www.digitalmars.com/d/2.0/dstyle.html Regarding white space it says: * Use spaces instead of hardware tabs. * Each indentation level will be four columns. Bye, bearophile Says the python nazi g
Re: Newbie: copy, assignment of class instances
bearophile bearophileh...@lycos.com wrote:
Generally in D it's not a good idea to reassign the reference to a
scoped class
You can see it with this little D2 program:
import std.stdio: printf;
class Foo {
int x;
this(int xx) { this.x = xx; }
~this() { printf(Foo(%d) destructor\n, this.x); }
}
void main() {
scope Foo f1 = new Foo(1);
Foo f2 = new Foo(2);
f1 = f2;
}
It prints just:
Foo(2) destructor
In general this is not good.
Bye,
bearophile
It is indeed not. However, there are two bugs here - first, the
wrong instance's destructor is called. Second, f1's destructor
is never called. Surely this has roots in the same code, but
they're two separate issues.
Basically, with the current system, it must not be the
reference's task to destroy an instance at end of scope, but
the instance itself. The simplest way to fix this is, as you
say, to disallow reassignment of a scope class reference.
--
Simen
Re: Newbie: copy, assignment of class instances
Ellery Newcomer: Says the python nazi g I admit that I am more indentation-nazi after using Python for few years, but I was strict on indentation even before hearing of Python :-) (In past I used 2 spaces, for older monitors). I have not written that html page was written by Walter before seeing me in the D newsgroups :-) Having a well chosen and uniform style in a language is useful, it helps readability between different programmers of the D community of programmers. You can also take a look at the quite strict C++ style guide (they forbid tabs, but use 2 spaces). 4 spaces is better than 2 in D today because monitors are wider, and because too many indentations in the code (more than five or six) is probably a sign of badly written code (here I am talking about production code, not toy programs). Bye, bearophile
Re: Newbie: copy, assignment of class instances
Another bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4216
Re: Newbie: copy, assignment of class instances
Larry Luther: I'm a newbie to D, not to programming. The first computer I got to program was a Digital PDP-8L. Wow :-) On the base of your long experience do you like D so far? I'm learning D. And I am listing what I think can be improved in your D code :-) You are free to not follow my advice... The IT guy said use HTML and that worked, but you don't like it, It's the Web interface of the D groups that doesn't seem to like HTML :-) The OutlookExpress editor must be replacing my spaces with tabs. I have seen 2 spaces in your code. The Association of Computing Machinery did a study of indentation a long time ago and found that indentations of 2 or 3 were best. I picked 2. I have shown you the D style guide written by the Walter, the D main designer. Some people don't follow that style guide, but I like it and I think a language-community-wide style guide is important for a modern language. I too used to use 2 spaces religiously, but today monitors have 120+ columns, not 80 as (probably) when that ACM study was carried out. Things change as time goes on. If you use 2 columns it's a bit harder to see indentations and you can be more tempted to use many indentation levels in your code. Keeping four is a way to discourage the usage of too many indentation levels. In the end you are free to use the number of indentations you like in D snippets :-) Don't get upset, we are all learning :-) There are many things in D that I have yet to understand. Bye, bearophile
