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.