Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-23 16:32:53


--- In boost_at_y..., "Fernando Cacciola" <fcacciola_at_g...> wrote:
>
> ----- Original Message -----
> From: <larsbj_at_l...>
> To: <boost_at_y...>
> Sent: Wednesday, January 23, 2002 5:50 PM
> Subject: Re: [boost] environment variable access
>
>
> > "Fernando Cacciola" <fcacciola_at_g...> writes:
> >
> > | You can use find(), but then "environment" would have to define
> iterators,
> > | at least '.end()' to compare against, thus
> > | it would look too much like a finite-size sequence while it
might be
> not.
> >
> > I can't think of one case where it won't be finite-size.
> >
> > (at least not in a case that is environment specific)
> >
>
> The source of variables, itself, such as the enviroment, can be of
finite
> size.
> But does it mean that this must be reflected into the data
structure?
>
> If the external source, such as 'enviroment', is designed to
reflect this,
> it allows the users to know
> in advance how many variables are in the source, even to iterate
through
> them all, but at the same time requires the source manager load, or
at least
> count, all variables.

There is a big difference between "knowing in advance how many
variables are in the source" and "iterating through them all". You
can iterate over all of them with out knowing the size.
A "restricted map" interface that didn't provide size
request/manipulation methods should work quite nicely for not only
the environment, but also the registry you mention below.

> For small sized sources, such as the enviroment or the command line
options,
> this is no problem since you can
> actually load all of them into a real sequence. It's trivial to
provide
> iterators for this cases.
>
> But I don't think that a typical usage of this would require
iterators or a
> known-in-advance size, so the price to provide it might scale very
bad to
> other sources, such as the windows registry

The Windows registry already provides iteration through the RegEnum*
functions, so obviously I disagree here. It's even possible (though
not desirable) to include the ability to query the size with out too
much impact... after all the registry is as finite as the environment.
 
> I think that the basic requirements for this framework is that it
allows to
> access a extrenal variable by name, and that allows you to tell if
that
> variable actually exist efficiently. Nothing more.
>
> A map interface does provide this, but it also provides many other
things
> that would require the whole source to be loaded in memory to
support either
> a efficient performance or a simple implementation.

size(), max_size(), possibly empty() are the only ones I see that
won't play nice unless you load the full environment. I suppose the
reverse iteration methods like rbegin() would also not work here. I'd
also have to question the need for count(), lower_bound(), upper_bound
(), equal_range(), swap() and all other copy methods, though they
could be retained. Removal of these would leave you with a very nice
interface for environment variable access.

Bill Kempf


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