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/

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/

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/

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/

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/

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

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.