Boost logo

Boost :

From: joel de guzman (djowel_at_[hidden])
Date: 2002-05-04 07:19:35


----- Original Message -----
From: "Mika Heiskanen" :

> To summarize, any discussion regarding a graphics rendering library in
> a Boost mailing list should focus on things a standard library should
> support, and nothing else. Support for any existing given platform
> specific API is of no concern. Only support for platform independent
> standard APIs like the PNG and JPEG image formats must be considered,
> and even them only in a user configurable way (perhaps a registry).

I agree with most of what you said. However, you are implying that
standard libraries should not use platform specific APIs. This is
certainly not true. As an example, how do you think are standard
files and streams implemented anyway? Ultimately, it should map
to the underlying platform where it is deployed. The key point here
is that these calls are opaque and hidden from the client. The cross-
platform API shields the client from the platform.

User hat on, if I have to plug in all the missing parts before I can use
a library, I will have second thoughts. If I write cout << 123, I expect
it to work straight out of the box. The current state of affairs with AGG
is that I still have to fill in the missing components. In effect, it's like
an iostream library where the output is thrown into a memory buffer
somewhere and it is the client's resposibility to print that out
somewhere.

I believe that support for common platforms (Mac, Windows, Unix)
is necessary. However, I also believe that these 'pre-canned'
OS adapters should be isolated from the library much like plug-
ins. I am sure there are people out there who would be willing
to contribute OS specific adapters. I, for one, would be willing
to contribute a Mac adapter. Yes, I have experience writing such
beasts. This can be done once an OS abstraction layer in the
form of a protocol API is designed and provided. This, by itself,
is not trivial, however.

Regards,
--Joel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk