AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
September 2004

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2004.09.16 17:04 "libtiff and .net", by Kalonji Kabongo
2004.09.16 17:09 "Re: libtiff and .net", by Bob Friesenhahn
2004.09.16 17:23 "Re: libtiff and .net", by Kalonji Kabongo
2004.09.16 17:35 "Re: libtiff and .net", by Bob Friesenhahn
2004.09.16 17:44 "Re: libtiff and .net", by Kalonji Kabongo
2004.09.16 18:16 "Re: libtiff and .net", by Bob Friesenhahn
2004.09.16 17:59 "Re: libtiff and .net", by Bill Bither
2004.09.20 19:48 "Re: libtiff and .net", by Bob Friesenhahn
2004.09.22 03:52 "Re: libtiff and .net", by Bill Bither
2004.09.22 04:13 "Re: libtiff and .net", by Bob Friesenhahn

2004.09.22 04:13 "Re: libtiff and .net", by Bob Friesenhahn

On Tue, 21 Sep 2004, Bill Bither wrote:

> > This approach does not work for architecture-independent applications
> > which are downloaded via HTTP.   There is likely value in TIFF support
> > code which is architecture-independent.  Since libtiff is portable, it
> > should be feasable to port the portable parts so they work natively in
> > .net.
>
> I agree that there would be some value to this, but there is likely to
> be quite a performance impact with the managed code version.  Would a
> port to .NET be "truly" managed using the managed heap for the image
> data, requiring the GC to free the image data when it feels like it, or
> would it store the image data on the unmanaged heap, where the developer
> can explicitly dispose the data, much like GDI+ in .NET does?

The port would allocate its data on the traditional unmanaged heap. 
To do anything else would be a re-write rather than a port.

> > I am not sure what you mean by this.  The first release of .net
> > supported compiling unmanaged C++ code into a managed assembly.
> > Presumably the 2005 version does something more special?  Maybe it
> > solves the "dual-heap" problem?
>
> Managed Extensions for .NET really didn't make too much sense to me, and
> is difficult to use.  The *new* VC++ is actually quite impressive from
> the Microsoft demonstrations I have seen.  You can compile both
> unmanaged and managed code into the same assembly and into MSIL.  With

The first release of Visual Studio .net supported compiling both 
unmanaged and managed code into the same assembly and into MSIL.  This 
has been released for several years.

I have used Managed C++ for .NET.  It worked fine.  However, the use 
of the term "C++" is a misnomer since all managed object interfaces 
must obey Managed C++ rules, which disables many useful C++ features 
and substitutes something else in their place.

> some syntax additions, you tell the compiler in code to allocate on the
> managed or unmanaged heap.  There has also been more concentration on
> performance and optimizations using managed/unmanaged C++ versus C#.

The "syntax additions" were already part of the first release of 
Managed C++.  However, only managed code was allowed to access managed 
memory in order to assure the safety of the run-time.  Has that 
changed?

> The biggest drawback to us is that it's only available in VS 2005 and
> requires the .NET 2.0 framework.  I'm by far no expert in this, but in
> theory, you could take LibTIFF and compile it entirely into MSIL as an
> unsafe "managed" assembly.

That is just a compiler option.  However, any interfaces other than to 
.net types will result in calls from .net into traditional C 
libraries so using them makes the assembly non-portable.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen