Re: [boost] Environment Variables Library?

Subject: Re: [boost] Environment Variables Library?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-05-21 22:52:30

On 22/05/2015 13:09, Michael Ainsworth wrote:
>> I would recommend against this particular style.  Variables like
>> PATH might be accessed either as a complete string (in which case
>> += should do a normal string append without any separator, and the
>> iterator would be the string's character iterator) or as individual
>> components; it should be obvious which of these is being done.
>
> It sounds like you're assuming the iterator to point to a string. The
> iterator could actually point to a 'variable' type which has
> knowledge of the path separator built in.

To clarify, I was saying that since most environment variables are not 
multi-path format, just simple strings, then the "common" method of 
accessing environment variables should return a simple string, or at 
most a wrapper object that has the simple string as the most easily 
accessible content.  Having that wrapper object also contain an iterator 
that is *not* a char-iterator of that simple string seems confusing at 
best.  (The wrapper object could have a split_path() method that returns 
something else that has iterators though -- the simplest choice being a 
vector.)

Also note that for the environment variables that do contain 
multi-paths, there are two separate delimiters in play -- one is the 
separator between entire paths, and the other is the separator between 
components of a single path.  Both of them are platform-specific.

It seems reasonable (though not essential) for an Environment library to 
take care of the former for you by providing split/rejoin methods that 
hide the difference between platforms.

It seems out of scope for it to do the latter, as this is already 
handled by the Filesystem library, and duplicating it seems wasteful.

Hence the suggestion to have Environment provide split/join methods that 
use Filesystem path objects as a basis (ie. vector<path>), as this 
allows the most platform abstraction.  And as others have already 
pointed out, Filesystem has been standardised already.