[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Openexr-devel] Exr.NET
From: |
n! |
Subject: |
[Openexr-devel] Exr.NET |
Date: |
Sun, 14 Mar 2004 17:18:14 -0000 |
(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