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.
> > > For example, LS_COLORS contains a list of color specifications for
> > > 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
> > > 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).
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"];
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk