[Mono-dev] MonoListWrapper WIP - code review/feedback

[Robert Jordan]

Hi,

On 18.07.2013 19:16, rfine at tbrf.net wrote:
> I've been working on a little wrapper library for working with
> System.Collections.Generic.List<T> instances from native code. The
> motivation is to provide a way for Mono embedders to easily design APIs
> that use List<T> instances as output buffers, whilst running as quickly
> as possible and with minimal allocations. Presently I'm getting around a
> 30x speedup for bulk loading a chunk of data, compared to allocating a
> new array to return that data in. Particular users I envision for this
> are game engines like Unity3D.
>
> Any chance I could get a review of what I've done so far? It's just a
> couple of files, plus a short readme:
>
> https://github.com/richard-fine/mono/tree/MonoListWrapper/contrib/MonoListWrapper
>
>
> I'm interested in any "there's a better way to do this" observations,
> suggestions for things I should add, ways to speed up the new-array
> cases, bugs you can spot, or any generally "un-Mono" things about it.

Although I understand your motivation, I find that you're
exposing/using too much internals to make this wrapper
ready for public consumption with an unchanged Mono runtime.

You seem to have exposed mono/class-internals.h, which is
a no-go. Also, poking into List<T> internals isn't quite
safe, as there is no "written" contract between runtime and BCL
regarding List<T>.

It would be safer if you'd copy and rename List<T> and provide
it together with your MonoListWrapper implementation.

Also, there are public mono_array_* macros that
you can use for accessing MonoArray* elements. You can still
use them unsafely (like taking the address of the first element
and access elements using pointer arithmetic) but at least
it won't poke into too much internals.

Robert