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

"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.

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.
>
>

"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.

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 :-)
>

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".

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

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

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.