On Fri, 2005-01-14 at 16:07 +0000, J. Ali Harlow wrote:
> On 13/01/05 22:06:46, J. Ali Harlow wrote:
> > On 13/01/05 20:27:43, Owen Taylor wrote:
> >
> > > I think that the claim is that the flat API is C++ based too...
> >
> > Concern, at least, yes.
> >
> > > GpPath *is* defined as a class, but only in the most trivial way.
> > > As far as I can see, it's really just an opaque pointer and you
> > > could use a C definition like:
> > >
> > > typedef struct GpPath_ GpPath;
> > >
> > > and it should work fine.
> >
> > Let's hope you're right. I'll try and have a play tomorrow and see if
> > I can put together a gdiplusflat.h which uses opaque pointers or
> > drops functions that take classes that appear to be wrappers
> > themselves (eg., GdipAddPathRectanglesI which probably just wraps
> > GdipAddPathRectangleI).
>
> Okay, I've had a quick play. It's possible to produce header files
> which will compile with a C compiler as long as you avoid certain
> functions which use the C++ '&' operator. Mine are pretty raw, but if
> anybody wants them, please shout.
>
> However, in trying to use these headers to compile a test program[1], I
> ran into trouble with trying to lock a bitmap. It seems as though you
> have to have a Rect (which is a class) to lock a bitmap and there is no
> way to create one in C.
>
> Some half-baked ideas for how to proceed:
>
> - It's possible that you could try and hack one up using a structure if
> you assumed that the public members came at the start but I've no idea
> if this would work and in any case it doesn't sound like a sensible way
> to proceed to me.
I have some belief that a C++ class is required to have the same
in-memory layout as a C structure with the same members in the same
order.
I'd be suprised if the Rect class didn't have the memory layout:
struct Rect_ {
int x, y, width, height;
}
having private members would just be weird for that.
> - We could set aside a hopefully-large-enough block of memory and then
> set and get the clip rect as another gross hack.
>
> - Another possibility would be to try and see if we could pass NULL
> into the locking function. We'd loose the ability to lock a portion of
> a bitmap, but that might be acceptable if it happens to work. It's
> still breaking the published API of course.
>
> - There may be a method of creating a Rect using one of the functions
> which I have excluded because they use the C++ '&' operator. Somebody
> who understands C++ rather more than me (ie., at all) will need to
> advise here.
>
> - Assume we don't need this functionality for cairo and soldier on.
Note there is no reason we can't use C++ in the implementation
of Cairo. I've never heard of anybody compiling GTK+ for Windows
with anything other than MSVC or GCC (cross or native).
The question to me is header file creation... can we create
redistributable header files that are compatible with the SDK header
files; the C++ interface is problematical for that because it's
a lot of inline functions. (Not impossible, just a fair bit of
work
The flat interface should be easier.
Right now I'm thinking straight-GDI rather than GDI+ anyways... it
doesn't sound like there is a big performance advantage to GDI+
on current Windows,and for acceleration, going to lower levels
will likely be easier, rather than using the not-quite-a-match
GDI+.
Regards,
Owen
Attachment:
signature.asc
Description: This is a digitally signed message part