Re: [boost] Environment Variables Library?

Subject: Re: [boost] Environment Variables Library?
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-05-23 09:30:23

On May 22, 2015 4:59:13 AM EDT, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> On Friday 22 May 2015 18:35:09 Michael Ainsworth wrote:
> > > Note that not only paths can be present in multi-element env.
> variables.
> > > For example, LS_COLORS contains a list of color specifications for
> ls
> > > command. I think, it's better for the environment library to
> perform a
> > > split to a sequence of strings and let the user interpret those
> strings
> > > as filesystem paths or something else.
> >
> > Exactly. $PATH isn't the only "array-like" variable, hence my
> reasoning for
> > encapsulating the raw name/value string pair in a 'variable' class
> that can
> > iterate over the substrings in the value string. It may be confusing
> > though. Will think more on it.
> 
> I think it's better to have a separate interface for splitting/joining
> - 
> preferably, an algorithm (a free function).

+1

I was going to say the same.

> I'm not sure a 'variable' class which contains both name and value is
> a good 
> thing, at least as the main interface. When I get a variable, I expect
> to have 
> to pass only its name and receive only its value, like:
> 
>   std::string value = env["FOO"];

+1

___
Rob

(Sent from my portable computation engine)