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). 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"]; Also, common operators become either unclear or confusing on the 'variable' class: variable var1, var2; var1 = var2; // assigns value or both name and value? var1 == var2; // compares value or both name and value? And certainly I don't think it's a good idea to collect algorithms in the 'variable' interface, like it's done in std::string.
Do all variables on the one platform have the same separator?
There are application-specific variables that contain different separators but I don't think you have to support them in your library. You can, however, provide the separator argument to the splitting/joining algorithms, which by default would be the system-specific default. It would be nice if that default could be visible by user (e.g. as a character constant) if he wants to do some string processing himself.