From: mfdylan (dylan_at_[hidden])
Date: 2002-01-23 17:28:31
--- In boost_at_y..., Jason Stewart <res0054p_at_g...> wrote:
> string location = env::get("LOCATION");
> instead of
> string location;
> env::get("LOCATION", location);
> In this case you have to decide what to do if the variable doesn't
> 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
> in the environment. However, I don't often need it with the
> Unfortunately, this only works well with strings, not with your
> but you might could have both methods.
I think that might be the best option actually (having both). The
default parameter might be worth adding.
> Also, putenv is not portable (as far as I can tell). Under MSVC it
> defined as _putenv. Since it is not portable I took the approach of
> the native Win32 functions on Windows and posix functions elsewhere.
> Windows : GetEnvironmentVariable, SetEnvironmentVariable
> POSIX : getenv, setenv, unsetenv
Nope, putenv is POSIX, and _should_ work the same everywhere (ie the
string is placed as is into the environment, so that further
modifications to the same string modify the environment directly).
Neither setenv and unsetenv are POSIX, although now you mention it
having an explicit "unset" function (as opposed to calling set with
an empty string) is probably a good idea). The problem with using
SetEnviromentVariable directly is that future calls to getenv() won't
pick it up, and the getenv() may be in a library you have no control
over. putenv/getenv under VC (you don't need the underscore btw)
both update the CRT environment and the "OS" environment. I don't
know how well putenv/getenv are supported by other Windows compilers
(or for macintosh - VC's putenv source is commented out for Mac).
> I also added the ability to expand an environment variable, if it
> 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.
Actually variable expansion needs to be offered "standalone" as it
were - you should be able to expand any string, regardless of whether
it comes from the environment or not. It's probably worth having it
support both %...% and $ (parentheses optional) according to certain
flags (that would default to %...% under Win32 and $ elsewhere).
> Someone posted on this list that platform dependencies make it less
> 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
> dependencies. Take fopen, fclose, etc. Those are not implemented
> way for all platforms. I think that for the environment functions
> make sense to use native system calls as well.
I agree totally. The problem is that the C++ standards committee
want to keep C++ suitable for an operating system with as few
requirements as possible - assuming the existence of environment
variables would add an extra requirement. But this isn't really
fair, just because an OS doesn't have native support for environment
variables doens't mean you can't implement 'env' with sensible
Anyway I think boost is a good place for things that rely on OS-
support that the C++ isn't happy about assuming exists (for instance
the dir_it stuff really needs to be finalised. C++ itself doesn't
assume OS's even have directories). All POSIX functionality, in
particular, I think needs to be wrapped up in a recognised C++
library. I've been doing this a bit recently (so far I've done
glob, dlopen/sym/close and getenv/putenv. exec() is probably the
next one on my list, although hiding the difference between fork+exec
() and CreateProcess is going to be the main challenge!).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk