www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is this dodgy...

reply Regan Heath <regan netwin.co.nz> writes:
Not having much experience in a garbage collected language I was wondering 
if this code..

{
	ubyte[] p = input;

	version (BigEndian) {
		ubyte[64] temp;
		..convert input into correct format in temp..
		p = temp;
	}

	..do stuff using p..
}

only works (in the BigEndian case) so long as the garbage collector does 
not collect on 'temp' before it is finished doing stuff with p? Or does p 
= temp stop the GC from collecting temp till p leaves scope?

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 20 2004
parent reply "Walter" <newshound digitalmars.com> writes:
It's dodgy. For the gc to work right, do not hide pointer values in
locations that are typed as non-pointers. This, of course, only applies to
pointer values into the gc heap. If you have a pointer into malloc'd data,
for example, you can hide it however you please since the gc is not going to
collect malloc'd data anyway.

"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9w1bnt15a2sq9 digitalmars.com...

 Not having much experience in a garbage collected language I was wondering
 if this code..

 {
 ubyte[] p = input;

 version (BigEndian) {
 ubyte[64] temp;
 ..convert input into correct format in temp..
 p = temp;
 }

 ..do stuff using p..
 }

 only works (in the BigEndian case) so long as the garbage collector does
 not collect on 'temp' before it is finished doing stuff with p? Or does p
 = temp stop the GC from collecting temp till p leaves scope?

 Regan.

 -- 
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 20 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 20 Jun 2004 16:29:37 -0700, Walter <newshound digitalmars.com> 
wrote:

 It's dodgy. For the gc to work right, do not hide pointer values in
 locations that are typed as non-pointers. This, of course, only applies 
 to
 pointer values into the gc heap. If you have a pointer into malloc'd 
 data,
 for example, you can hide it however you please since the gc is not 
 going to
 collect malloc'd data anyway.


Ok, so will calling .dup on the assign i.e.
   p = temp.dup;

fix the problem?
eg.
{
	ubyte[] p = input;

	version (BigEndian) {
		ubyte[64] temp;
		..convert input into correct format in temp..
		p = temp.dup;
	}

	..do stuff using p..
}


 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9w1bnt15a2sq9 digitalmars.com...

 Not having much experience in a garbage collected language I was 
 wondering
 if this code..

 {
 ubyte[] p = input;

 version (BigEndian) {
 ubyte[64] temp;
 ..convert input into correct format in temp..
 p = temp;
 }

 ..do stuff using p..
 }

 only works (in the BigEndian case) so long as the garbage collector does
 not collect on 'temp' before it is finished doing stuff with p? Or does 
 p
 = temp stop the GC from collecting temp till p leaves scope?

 Regan.

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/






-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 20 2004
parent reply "Walter" <newshound digitalmars.com> writes:
I really don't know what you're trying to do. Are you trying to manipulate a
pointer, or the data it points to?

"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9w4cjbm5a2sq9 digitalmars.com...

 On Sun, 20 Jun 2004 16:29:37 -0700, Walter <newshound digitalmars.com>
 wrote:

 It's dodgy. For the gc to work right, do not hide pointer values in
 locations that are typed as non-pointers. This, of course, only applies
 to
 pointer values into the gc heap. If you have a pointer into malloc'd
 data,
 for example, you can hide it however you please since the gc is not
 going to
 collect malloc'd data anyway.


 Ok, so will calling .dup on the assign i.e.
    p = temp.dup;

 fix the problem?
 eg.
 {
 ubyte[] p = input;

 version (BigEndian) {
 ubyte[64] temp;
 ..convert input into correct format in temp..
 p = temp.dup;
 }

 ..do stuff using p..
 }


 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9w1bnt15a2sq9 digitalmars.com...

 Not having much experience in a garbage collected language I was
 wondering
 if this code..

 {
 ubyte[] p = input;

 version (BigEndian) {
 ubyte[64] temp;
 ..convert input into correct format in temp..
 p = temp;
 }

 ..do stuff using p..
 }

 only works (in the BigEndian case) so long as the garbage collector






does

 not collect on 'temp' before it is finished doing stuff with p? Or does
 p
 = temp stop the GC from collecting temp till p leaves scope?

 Regan.

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/






 -- 
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 20 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 20 Jun 2004 17:49:58 -0700, Walter <newshound digitalmars.com> 
wrote:

 I really don't know what you're trying to do. Are you trying to 
 manipulate a
 pointer, or the data it points to?


the data.

'input' contains some data. I need to convert it on bigendian systems. 
below I use a temp array for the conversion. basically I want to perform 
the same operation on input or temp depending on the endian-ness of the 
system.


 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9w4cjbm5a2sq9 digitalmars.com...

 On Sun, 20 Jun 2004 16:29:37 -0700, Walter <newshound digitalmars.com>
 wrote:

 It's dodgy. For the gc to work right, do not hide pointer values in
 locations that are typed as non-pointers. This, of course, only 


 applies

 to
 pointer values into the gc heap. If you have a pointer into malloc'd
 data,
 for example, you can hide it however you please since the gc is not
 going to
 collect malloc'd data anyway.


 Ok, so will calling .dup on the assign i.e.
    p = temp.dup;

 fix the problem?
 eg.
 {
 ubyte[] p = input;

 version (BigEndian) {
 ubyte[64] temp;
 ..convert input into correct format in temp..
 p = temp.dup;
 }

 ..do stuff using p..
 }


 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9w1bnt15a2sq9 digitalmars.com...

 Not having much experience in a garbage collected language I was
 wondering
 if this code..

 {
 ubyte[] p = input;

 version (BigEndian) {
 ubyte[64] temp;
 ..convert input into correct format in temp..
 p = temp;
 }

 ..do stuff using p..
 }

 only works (in the BigEndian case) so long as the garbage collector






 does

 not collect on 'temp' before it is finished doing stuff with p? Or 




 does

 p
 = temp stop the GC from collecting temp till p leaves scope?

 Regan.

 --
 Using M2, Opera's revolutionary e-mail client: 




 http://www.opera.com/m2/




 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/






-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



 Jun 20 2004



  parent  "Walter" <newshound digitalmars.com>  writes:


"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9w606h35a2sq9 digitalmars.com...

 On Sun, 20 Jun 2004 17:49:58 -0700, Walter <newshound digitalmars.com>
 wrote:

 I really don't know what you're trying to do. Are you trying to
 manipulate a
 pointer, or the data it points to?


 the data.

 'input' contains some data. I need to convert it on bigendian systems.
 below I use a temp array for the conversion. basically I want to perform
 the same operation on input or temp depending on the endian-ness of the
 system.


You can modify the data all you need to, without worrying about the gc.



 Jun 20 2004



prev sibling  parent  Norbert Nemec <Norbert.Nemec gmx.de>  writes:


Walter wrote:


 It's dodgy. For the gc to work right, do not hide pointer values in
 locations that are typed as non-pointers. This, of course, only applies to
 pointer values into the gc heap. If you have a pointer into malloc'd data,
 for example, you can hide it however you please since the gc is not going
 to collect malloc'd data anyway.


??? Who is hiding a pointer?

The question that arises is a different one: where is the local fixed-length
array is actually allocated? Are fixed-length arrays handled in-place (in
this case on the stack) as in C or are they put on the heap? I would really
prefer the first solution for performance reasons, and my multi-dim array
proposal assumes just that.

If the data of temp is actually stored on the stack, the question remains
what happens on conversion to the variable-length array. If p is just set
to point to the stack, then you indeed have problems.

In any case: the GC is not the problem at all here.



 Jun 21 2004