Boost logo

Boost :

From: joel de guzman (djowel_at_[hidden])
Date: 2002-05-06 10:52:39


----- Original Message -----
From: "Beman Dawes" :

> At 01:49 AM 5/6/2002, Mika Heiskanen wrote:
> >
> >Joel de Guzman wrote:
> >
> >> 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.
> >
> >There has probably been poor wording by me. I am specifically opposed to
> a
> >standard library which would may line, polygon etc rendering requests to
> >some platform specific API, whether it is hardware or software. All
> >rendering should by done by the library itself. It is the users
> >responsibility to then copy the pixel buffer to a display. By allowing
> the
> >user to configure the representation of the pixel buffer the copying may
> >then involve a direct memcpy via some platform specific call.
>
> Please understand that standard library proposals today can't be just "good
> ideas". They have to be shown to work in practical computing environments.
>
> Thus for the standard committee to accept a library that leaves some
> responsibility to the user (like copying the pixel buffer to a display), it
> would have to be shown that this is something a potential user can easily
> and efficiently do, and the best way to demonstrate this is by proving
> demonstration code for actual operating systems and graphics packages.
>
> So even if the core proposal itself is not concerned with interfaces to
> common operating systems or graphics packages, practical examples and tests
> should allow display on common platforms, IMO.

Exactly my point. What I wish to see are pre-canned solutions for
common platforms. These should not be adhoc solutions though
because whether you like it or not, it will be used to guage the
performance and capability of the framework. Without these drivers,
it will be just a concept without a proof. Good ideas need good demos.
If a library preaches cross-platform ability, it must be able to demonstrate
this straight out of the box without requiring passive onlookers to
spend another week coding just to fill in the blanks because believe
me, people won't bother, in particular, typical Joe who only wants to
draw some nice polygons and text.

Regards,
--Joel


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