openexr-devel
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]