Re: environment variable access

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