Using the same approach for the csharp bindings seems much more complicated than the current method. Currently the caller (at the csharp side) allocates a fixed length int array and the default marshaler takes care of passing the array to the unmanaged (C) part of the code. There's no need to do extra memory allocations inside the wrapper code and using the existing 'int argin[ANY]' typemap does the right thing when mapping this type.
Since I continue to think about a different implementation for c# I leave the decision about this topic to the other bindings maintainers. Best regards, Tamas 2008/7/22 Howard Butler <[EMAIL PROTECTED]>: > > On Jul 22, 2008, at 9:48 AM, Ari Jolma wrote: > >> The trac.osgeo.org does not answer so I'll put this here. >> >> Hobu, would it be ok to have (int len, int *output) typemap. They can be >> used in GetHistogram method like this (note that the API is same for C# but >> it must use different typemaps. From Band.i: >> >> %typemap(check) (int len, int *output) >> { >> /* %typemap(check) (int len, int *output) */ >> if ($1 < 1) $1 = 1; /* stop idiocy */ >> $2 = (int *)CPLMalloc( $1 * sizeof(int) ); >> } > > > Ari, > > This isn't too different from what I proposed except for I think that > abusing the check typemap like that (malloc'ing the integer array) is a > recipe for disaster. The check typemap could possibly be run multiple > times, right? Otherwise, it looks pretty close to what I had for a proposal > http://trac.osgeo.org/gdal/changeset/14941 . > > I'm open to changing the GetHistogram function signature within Band.i > however you guys wish (ideally to support just using (int len, int *output) > and not having a special typemap for just this function), and while it would > be nice that we wouldn't need the #ifdefs for every possible language we > might ever support ;), it's not the end of the world either... > > Howard > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev