Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-06 12:33:16


--- Brock Peabody <brock.peabody_at_[hidden]>
wrote:
> I wonder how much we will have to redo when we add
> in support for say
> Mac Os X or another *nix API. Is it going to be too
> complex to develop
> a single underlying code base that works on all of
> them? Would we be
> better off developing separate implementations for
> each GUI API? Do any
> of you with cross platform development experience
> have any opinions
> about this?

Good question!

>
> Here are the two possibilities as I see:
>
> Method 1 - common underlying representation method
>
> layer 1 - target GUI API
>
> layer 2 - low level GUI API interface wrapper.
> There is one
> implementation of this wrapper that compiles for all
> target platforms,
> using standard cross-platform development methods.
> This layer may be
> private to boost (in namespace detail).
>
> layer 3 - high level boost GUI API. This is the
> public interface to our
> GUI 'domain specific sublanguage'. It is
> implemented on top of layer 2.
>
>
> Method 2 - N implementations
>
> layer 1 - target GUI API
>
> layer 2 - high level boost GUI API. This is
> implemented directly on top
> of the target GUI API, for each target API, except
> for the parts of the
> sublanguage which can be implemented in terms of
> other parts of the
> sublanguage.
>
>
> Method 1 pros
>
> - maintenance can be done in one place
> - possible sharing of code amongst implementations
> - layer 2 might eventually become another part of
> the public interface
> at a lower level (like phase (3) in Beman's first
> post on this topic).

To the method 1 pros list:
- More user friendly. If the user implements the layer
1, she can use the library with her custom GUI
platform.

>
> Method 1 cons
>
> - complexity. This is my main concern. I don't
> know if we can
> implement a low level API that works for all GUI
> APIs.
> - we have to implement all intended targets at once.
> Adding new targets
> affects code referring to existing targets

Sorry why does adding new target affect code referring
to existing targets? Could you give an example?

>
> Method 2 pros
>
> - implementation for each target is relatively
> straightforward and self
> contained
> - we can add support for targets at leisure without
> affecting existing
> targets
>
> Method 2 cons
>
> - if changes need to be made they will have to be
> made across N code
> bases
> - possible redundancy in various implementations

to the the Method 2 cons list:

- The user won't be able to use the library on top of
a custom GUI (like some requested) unless she writes
it from scratch.

Eugene

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


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