Re: [Openexr-devel] Exr.NET

[Drew Hess]

Cool, that sounds like a good approach.  Hopefully this will be much 
easier in the long run :)


-dwh-


 On Sun, 14 Mar 2004, n! wrote:

> (from my home email account)
> 
> > (Drew)
> > I was talking to Florian about this and I think I
> > misinterpreted your intentions.
> 
> Well, you did and you didn't :) I was originally writing a simple wrapper
> for C#, but once it was working a number of issues made me think about
> writing a complete C# version. My fault the confusion occurred!
> 
> After spending a number of hours writing a partial conversion, I have-to
> agree it was a bad decision! And decided that remaining as a wrapper makes
> [much] more sense, so to be clear it's now a simple wrapper... again :)
> 
> > (Drew)
> > p.s. one more thing -- the C# API can (and probably should)
> > diverge from the C++ API when it's appropriate.  For example,
> > if you don't want to pass around pointers to pixels, use the
> > C# idiom that's suited to that sort of thing
> 
> Yes, I intended to present the wrapped API using C# idioms. The problem
> being pointer arithmetic is considered 'unsafe' in C# and means complete
> trust needs to be given to the application. As 'trusted code' is one of the
> reasons someone would write an application in C#, this fact reduces the
> desirability of such a wrapper (one that requires full trust). Saying that,
> I may be able to work around it so that the wrapper won't need full trust,
> but that's completely theoretical at the moment :)
> 
> > (Florian)
> > Most of the concerns you mentioned in your earlier
> > mail can be addressed by using the IlmImf C++ API
> > instead of the rather minimalistic C version.
> 
> Due to the name mangling that occurs in a C++ library when exporting C++
> classes & methods they become unavailable to C# (which isn't an issue for
> methods exported with 'extern "C"'). However, Microsoft claims you can
> compile all C++ code with the managed C++ compiler which would produce a
> library usable from other managed languages. It might make sense for me to
> buy the C++ compiler to try this out (the fact they've just pushed back the
> release date for the next version makes it more appealing to me now!).
> 
> > Your other concern, the pointer arithmetic that is
> > associated with the setFrameBuffer() calls, won't be
> > solved just by porting to C#.
> 
> The original thought was to replace the pointer arithmetic with something
> safer in C#. However this isn't an issue any more as I'll seek an
> alternative to use inside a wrapper.
> 
> FWIW I want to make it open-source as exr is not my idea and besides the
> more people its available to the more useful it becomes.
> 
> Thanks for the replies, I'll continue with my wrapper! :)
> 
> Wayney
> 
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openexr-devel
> 
>