www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - pointers/references again

reply bobef <bobef_member pathlink.com> writes:
Consider this code:

long moveChild(inout XMLnode dest,inout XMLnode source)
{
dest.m_children.length=dest.m_children.length+1;
dest.m_children[dest.m_children.length-1]=source;
..
}

long moveChild(inout XMLnode dest,XMLnode *source)
{
dest.m_children.length=dest.m_children.length+1;
dest.m_children[dest.m_children.length-1]=*source;
..
}

In the first function "source" is not copied. If I delete source later,
dest.m_children[dest.m_children.length-1] becomes unusable. In the second
function source is copied and everything is ok if I delete it. Is this behavior
"normal"? And if it is how to force copying if = does not so?

-bobef
Jan 28 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"bobef" <bobef_member pathlink.com> wrote in message 
news:ctdrkv$o7$1 digitaldaemon.com...
 Consider this code:

 long moveChild(inout XMLnode dest,inout XMLnode source)
 {
 dest.m_children.length=dest.m_children.length+1;
 dest.m_children[dest.m_children.length-1]=source;
 ..
 }

 long moveChild(inout XMLnode dest,XMLnode *source)
 {
 dest.m_children.length=dest.m_children.length+1;
 dest.m_children[dest.m_children.length-1]=*source;
 ..
 }

 In the first function "source" is not copied. If I delete source later,
 dest.m_children[dest.m_children.length-1] becomes unusable. In the second
 function source is copied and everything is ok if I delete it. Is this 
 behavior
 "normal"? And if it is how to force copying if = does not so?

 -bobef

is XMLNode a struct or class? And when you say "delete" do you really mean the D "delete"? Since you probably do then I'm assuming XMLNode is a class. Since class objects are manipulated by reference I wouldn't bother with using either inout or pointers or delete. Realize that D objects are handles more like Java objects than C++ objects. There is no "operator=". If you want to make a copy you write a constructor or member function (called something like "dup") to do the copy.
Jan 28 2005
parent reply bobef <bobef_member pathlink.com> writes:
Then I guess the reason I don't understand it is beacause I believe Java is crap
and I don't know how it treats it's classes (and XMLnode is class)... Maybe then
in my second example the object is not copied but something else happens? Still
when I delete it (with D delete operator) destination remains untouched and
source is deleted. No matter how D treats its classes I think both examples
should do the same thing, because "=" should be the same for both cases and
input for the = operator is the same in both cases. Am I wrong? I'm totaly
confused now...


In article <ctdskb$1sd$1 digitaldaemon.com>, Ben Hinkle says...
"bobef" <bobef_member pathlink.com> wrote in message 
news:ctdrkv$o7$1 digitaldaemon.com...
 Consider this code:

 long moveChild(inout XMLnode dest,inout XMLnode source)
 {
 dest.m_children.length=dest.m_children.length+1;
 dest.m_children[dest.m_children.length-1]=source;
 ..
 }

 long moveChild(inout XMLnode dest,XMLnode *source)
 {
 dest.m_children.length=dest.m_children.length+1;
 dest.m_children[dest.m_children.length-1]=*source;
 ..
 }

 In the first function "source" is not copied. If I delete source later,
 dest.m_children[dest.m_children.length-1] becomes unusable. In the second
 function source is copied and everything is ok if I delete it. Is this 
 behavior
 "normal"? And if it is how to force copying if = does not so?

 -bobef

is XMLNode a struct or class? And when you say "delete" do you really mean the D "delete"? Since you probably do then I'm assuming XMLNode is a class. Since class objects are manipulated by reference I wouldn't bother with using either inout or pointers or delete. Realize that D objects are handles more like Java objects than C++ objects. There is no "operator=". If you want to make a copy you write a constructor or member function (called something like "dup") to do the copy.

Jan 28 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"bobef" <bobef_member pathlink.com> wrote in message 
news:ctdv42$5gt$1 digitaldaemon.com...
 Then I guess the reason I don't understand it is beacause I believe Java 
 is crap
 and I don't know how it treats it's classes (and XMLnode is class)...

I hope you find D less crappy - and not to sound too grandmotherly but keep an open mind :-)
 Maybe then
 in my second example the object is not copied but something else happens?

Class objects are manipulated by reference so the references are copied about. The actual data and properties making up the object are not copied.
 Still
 when I delete it (with D delete operator) destination remains untouched 
 and
 source is deleted.

Explicitly calling "delete" I think only calls a destructor if there is one and doesn't guarantee that you'll crash or anything if you keep using the object. So I wouldn't be surprised if the destination is deleted, too, but that it would only show up after a GC run or allocation or something. Remember assignment only copies references around so deleting through one of the references will cause all the other references to become invalid and behave randomly.
 No matter how D treats its classes I think both examples
 should do the same thing, because "=" should be the same for both cases 
 and
 input for the = operator is the same in both cases. Am I wrong? I'm totaly
 confused now...

Is source modified in the code chunk you snipped out? I agree the assignments should do the same thing (copy a reference to the source node to some array). If a variable is declared as inout then any change like source = null; will change the caller's value as well as the local variable's value. If a variable is declared as XMLNode* then source = null; will just change the local value and leave the caller untouched. In general I'd recommend experimenting with small code snippets to figure out what is going on.
Jan 28 2005
parent reply bobef <bobef_member pathlink.com> writes:
Yes I do :) I find D lovely :) In fact few times I give up and decide to go back
to C++ but when I have a rest I can't resist D :)
Anyway I still believe it has to be more like C++ than Java and it needs some
"lower level features" like C++ management of classes and preprocessor. I don't
say it must be C+++. Just sometimes low level features make things powerful and
vice versa. And when we try to be "modern" we result with Java that runs
extremely slow even a single messege box and syntax is a joke with few keywords
for the same thing and nothing useful... No control over things at all...

In article <cte3jr$bbi$1 digitaldaemon.com>, Ben Hinkle says...
I hope you find D less crappy - and not to sound too grandmotherly but keep 
an open mind :-)

Jan 28 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
bobef wrote:

 Anyway I still believe it has to be more like C++ than Java and it needs some
 "lower level features" like C++ management of classes and preprocessor.

D does not need a preprocessor, that's one of the basic design choices: http://www.digitalmars.com/d/pretod.html Java does need one, but that's another discussion altogether... :-) (since it doesn't have the "version", and just got "assert" in 1.5) --anders PS. You can generate your D code however you want. Including "cpp".
Jan 29 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <ctgnj7$604$2 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
bobef wrote:

 Anyway I still believe it has to be more like C++ than Java and it needs some
 "lower level features" like C++ management of classes and preprocessor.

D does not need a preprocessor, that's one of the basic design choices: http://www.digitalmars.com/d/pretod.html Java does need one, but that's another discussion altogether... :-) (since it doesn't have the "version", and just got "assert" in 1.5)

Its actually kind of sad that Java missed the boat so completely; once upon a time, we all had such high hopes for that platform. The closest Java has to D's version is this:
 // declare a 
 class Version{
     public static const boolean useOptionX = true;
 }
 // elsewhere...
 class TestClass{
     public void testMethod(){
         if(Version.useOptionX){
             // only runs if userOptionX = true;
         }
     }
 }

.. and that only works as long as the compiler knows to optimise away the bits that are branching on a constant value. D's version() and debug() statements are far more versatile. - EricAnderton at yahoo
Jan 29 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
pragma wrote:

 Its actually kind of sad that Java missed the boat so completely;
 once upon a time, we all had such high hopes for that platform.  

I'm not sure that the "Java platform" can be blamed for any short-comings in the Java language itself - or vice versa. There are several languages besides Java that compile to byte-code, and you can also compile Java to native using something like GCJ... Then again, Sun have only themselves to blame for the dilution of the Java name and what is stands for. (Java Desktop? <sigh>)
 .. and that only works as long as the compiler knows to optimise away the bits
 that are branching on a constant value.  D's version() and debug() statements
 are far more versatile.

Java does have Log4J, which is better, but Kris ported that to D in the Mango project already... http://logging.apache.org/log4j/docs/ Java isn't concerned with lowlevel optimization, such as optimizing out a boolean check-and-branch. (even if it could lead to severe code bloat if the debugging code makes it into the release version) --anders
Jan 29 2005
prev sibling parent Brian Chapman <nospam-for-brian see-post-for-address.net> writes:
On 2005-01-29 13:19:03 -0600, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= 
<afb algonet.se> said:

 
 PS. You can generate your D code however you want. Including "cpp".

Yeah, I was using gpp ( http://www.nothingisreal.com/gpp/ ) for awhile in my Makefile. Then I tried m4, then I went back. ;-) Now I'm not using a preprocessor at all in my current project. Even though D goes a long way into making it less needed, there still are a few circumstances where a preprocessor can be quite helpful.
Jan 29 2005