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
> > | at least '.end()' to compare against, thus
> > | it would look too much like a finite-size sequence while it
> > 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
> But does it mean that this must be reflected into the data
> If the external source, such as 'enviroment', is designed to
> it allows the users to know
> in advance how many variables are in the source, even to iterate
> them all, but at the same time requires the source manager load, or
> 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
> this is no problem since you can
> actually load all of them into a real sequence. It's trivial to
> 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
> 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
> access a extrenal variable by name, and that allows you to tell if
> variable actually exist efficiently. Nothing more.
> A map interface does provide this, but it also provides many other
> that would require the whole source to be loaded in memory to
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk