From: Jason Stewart (res0054p_at_[hidden])
Date: 2002-01-23 10:21:12
I have written a similar set of functions for environment access and I
wanted to make some comments. I personally like to have a get function that
returns a string instead of taking one as a reference. I pefer to type
string location = env::get("LOCATION");
In this case you have to decide what to do if the variable doesn't exists.
I provided a default value that gets returned in that case, i.e.
string location = env::get("LOCATION", "c:/");
I also provided an Exists function that returns true if the variable exists
in the environment. However, I don't often need it with the defaults.
Unfortunately, this only works well with strings, not with your other types
but you might could have both methods.
Also, putenv is not portable (as far as I can tell). Under MSVC it is
defined as _putenv. Since it is not portable I took the approach of using
the native Win32 functions on Windows and posix functions elsewhere.
Windows : GetEnvironmentVariable, SetEnvironmentVariable
POSIX : getenv, setenv, unsetenv
The setenv function does not seem to have the behavior of putenv. If I read
the man pages correctly it makes a copy of the string instead of storing
the exact pointer that you pass it.
I also added the ability to expand an environment variable, if it refers to
another variable. For instance:
LOCATION = %SYSTEM%/drivers
SYSTEM = c:/winnt
then env::get("LOCATION", "", true) would return "c:/winnt/drivers". Of
course on non-windows platforms I used $(VARIABLE) syntax.
Someone posted on this list that platform dependencies make it less likely
for something to be accepted by the Standards committee but it seems to me
that the standard library is the best place to hide some of these platform
dependencies. Take fopen, fclose, etc. Those are not implemented the same
way for all platforms. I think that for the environment functions it might
make sense to use native system calls as well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk