[gdal-dev] Bindings for the histogram method of band

[Tamas Szekeres]

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 <hobu.inc at gmail.com>:
>
> 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>