Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
June 20, 2004 Is this dodgy... | ||||
---|---|---|---|---|
| ||||
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/
|
June 20, 2004 Re: Is this dodgy... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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/ |
June 21, 2004 Re: Is this dodgy... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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/ |
June 21, 2004 Re: Is this dodgy... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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/ |
June 21, 2004 Re: Is this dodgy... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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/ |
June 21, 2004 Re: Is this dodgy... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "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. |
June 21, 2004 Re: Is this dodgy... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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.
|
Copyright © 1999-2021 by the D Language Foundation