From: Maxim Shemanarev (mcseem_at_[hidden])
Date: 2002-05-04 13:15:11
> 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.
Agree, but the devil is in the details.
> If I write cout << 123, I expect it to work straight out of the box.
Not quite. For example, you still have to worry about byte ordering
and the representation of, say, floating point values if you use
compatible binary streams. And it's also completely your
responsibility. STL afaik does not proivide any marshalling
> The current state of affairs with AGG
> is that I still have to fill in the missing components. In effect, it's
> an iostream library where the output is thrown into a memory buffer
> somewhere and it is the client's resposibility to print that out
Yes. It's because file I/O is much simplier and much more
developed than graphical I/O. After all there's simple C fread/fwrite
interface is underlying in std::streams. And this interface is already
platform independent (except byte ordering).
The only thing AGG provides is a number of supported pixel
> 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.
It would be just perfect if somebody offered a uniform C++ and
STL-like interface how to display pixel images, as well as how
to read/write popular graphical formats. I alone cannot handle
all of it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk