digitalmars.D.learn - Wrapping a C-style Array (Pointer + Length) in a Range Interface
- "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> (15/15) Jul 07 2015 I'm currently developing a high-level wrapper for FFMPEG at
- Rikki Cattermole (6/20) Jul 07 2015 size_t count;
- "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> (7/11) Jul 07 2015 Thanks.
- Rikki Cattermole (9/21) Jul 07 2015 To my knowledge it should reuse the memory and not inform the GC
- "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> (3/5) Jul 07 2015 I could tag it as @nogc.
- ketmar (11/14) Jul 07 2015 i bet this trick was planned from the moment of introduction of slices i...
- =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (3/5) Jul 14 2015 I believe there's a DIP (involving the scope keyword) related to
- ketmar (2/8) Jul 14 2015 yes, but i never get it.=
- John Colvin (11/23) Jul 07 2015 Slicing never* allocates a new array. The GC is only aware of
- Andrea Fontana (5/20) Jul 09 2015 I think a wrapper is quite easy to do, isn't it?
I'm currently developing a high-level wrapper for FFMPEG at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d My question now becomes how to most easily wrap the iteration over streams at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L150 https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L152 in a nice D-style range interface. Do I have to allocate a new D array and copy the `AVStream*` elements into that or is there a convenience wrapper for constructing a lazy range from a C style Array-pointer plus array-length? Note that the elements of the C array are pointers to structs, in this case instances of `AVStream`. This, of course, complicates the matter with regard to GC-safety. Comments on that please :)
Jul 07 2015
On 8/07/2015 12:26 a.m., "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com>" wrote:I'm currently developing a high-level wrapper for FFMPEG at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d My question now becomes how to most easily wrap the iteration over streams at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L150 https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L152 in a nice D-style range interface. Do I have to allocate a new D array and copy the `AVStream*` elements into that or is there a convenience wrapper for constructing a lazy range from a C style Array-pointer plus array-length? Note that the elements of the C array are pointers to structs, in this case instances of `AVStream`. This, of course, complicates the matter with regard to GC-safety. Comments on that please :)size_t count; AVStream* thePtr; AVStream[] array = thePtr[0 .. count]; That should work.
Jul 07 2015
On Tuesday, 7 July 2015 at 12:29:04 UTC, Rikki Cattermole wrote:size_t count; AVStream* thePtr; AVStream[] array = thePtr[0 .. count]; That should work.Thanks. Will that reuse the existing allocate memory at `thePtr` for internal storage of the D array? If so how is the GC aware of this memory? Is there any tutorials, reference documentation, etc on these matters?
Jul 07 2015
On Tuesday, 7 July 2015 at 12:33:23 UTC, Per Nordlöw wrote:On Tuesday, 7 July 2015 at 12:29:04 UTC, Rikki Cattermole wrote:To my knowledge it should reuse the memory and not inform the GC about it. It basically makes D treat that pointer like a slice. If you need to confirm that it is doing that, just nogc it. If it allocates it'll fail. I'm not aware of much docs regarding these sort of tricks. But I believe it was Adam who originally discovered this little trick. Atleast I'm pretty sure he is how I learnt about it. On D.learn as well.size_t count; AVStream* thePtr; AVStream[] array = thePtr[0 .. count]; That should work.Thanks. Will that reuse the existing allocate memory at `thePtr` for internal storage of the D array? If so how is the GC aware of this memory? Is there any tutorials, reference documentation, etc on these matters?
Jul 07 2015
On Tuesday, 7 July 2015 at 12:36:11 UTC, Rikki Cattermole wrote:If you need to confirm that it is doing that, just nogc it. If it allocates it'll fail.I could tag it as nogc. Thx.
Jul 07 2015
On Tue, 07 Jul 2015 12:36:09 +0000, Rikki Cattermole wrote:I'm not aware of much docs regarding these sort of tricks. But I believe it was Adam who originally discovered this little trick. Atleast I'm pretty sure he is how I learnt about it. On D.learn as well.i bet this trick was planned from the moment of introduction of slices in=20 D. yet there is something that makes it dangerous: user is free to change=20 ".length" of the "slice wrapper". and as GC doesn't manage the memory=20 slite is pointing to, it will copy slice contents. the program definitely=20 will not crash, but if copied data had some pointers to that copied data=20 (sometimes C program does this)... besides, one cannot use ".ptr" to `free ()` memory anymore. so while there is nothing wrong in creating slices from pointers,=20 programmer should be aware of some potential pitfalls.=
Jul 07 2015
On Wednesday, 8 July 2015 at 05:14:48 UTC, ketmar wrote:so while there is nothing wrong in creating slices from pointers, programmer should be aware of some potential pitfalls.I believe there's a DIP (involving the scope keyword) related to this problem, right?
Jul 14 2015
On Tue, 14 Jul 2015 08:33:56 +0000, Nordl=C3=B6w wrote:On Wednesday, 8 July 2015 at 05:14:48 UTC, ketmar wrote:yes, but i never get it.=so while there is nothing wrong in creating slices from pointers, programmer should be aware of some potential pitfalls.=20 I believe there's a DIP (involving the scope keyword) related to this problem, right?
Jul 14 2015
On Tuesday, 7 July 2015 at 12:33:23 UTC, Per Nordlöw wrote:On Tuesday, 7 July 2015 at 12:29:04 UTC, Rikki Cattermole wrote:Slicing never* allocates a new array. The GC is only aware of memory it allocates itself and memory it is explicitly told about (see core.memory) Slicing pointers etc. should all be covered in http://dlang.org/arrays.html, http://dlang.org/d-array-article.html, http://ddili.org/ders/d.en/arrays.html and http://ddili.org/ders/d.en/slices.html *unless you're using operator overloading, in which case it can do anything of coursesize_t count; AVStream* thePtr; AVStream[] array = thePtr[0 .. count]; That should work.Thanks. Will that reuse the existing allocate memory at `thePtr` for internal storage of the D array? If so how is the GC aware of this memory? Is there any tutorials, reference documentation, etc on these matters?
Jul 07 2015
On Tuesday, 7 July 2015 at 12:26:33 UTC, Per Nordlöw wrote:I'm currently developing a high-level wrapper for FFMPEG at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d My question now becomes how to most easily wrap the iteration over streams at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L150 https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L152 in a nice D-style range interface. Do I have to allocate a new D array and copy the `AVStream*` elements into that or is there a convenience wrapper for constructing a lazy range from a C style Array-pointer plus array-length? Note that the elements of the C array are pointers to structs, in this case instances of `AVStream`. This, of course, complicates the matter with regard to GC-safety. Comments on that please :)I think a wrapper is quite easy to do, isn't it? You just need to implement front popFront and empty and you're done. So you avoid slice-related problems...
Jul 09 2015