RE: [boost] environment variable access

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-01-23 16:16:50

----- Original Message -----
From: <larsbj_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, January 23, 2002 5:50 PM
Subject: Re: [boost] environment variable access

> "Fernando Cacciola" <fcacciola_at_[hidden]> 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.

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

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.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com