Re: [boost] Environment Variables Library?

Subject: Re: [boost] Environment Variables Library?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-05-19 06:54:54

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Michael Ainsworth
> Sent: 19 May 2015 10:51
> To: boost_at_[hidden]
> Subject: Re: [boost] Environment Variables Library?
> 
> > On 19 May 2015, at 7:18 pm, Klaim - Joël Lamotte <mjklaim_at_[hidden]> wrote:
> 
> >
> > I'm not sure for other devs but my personal guideline so far is:
> >
> > 1. Don't use the register except if you must (mostly because of
> > requirements from the kind of application you are making).
> > 2. Don't use environment variables except if you must (mostly for dev
> > tools helping locating each other).
> > 3. Prefer user-specific or shared directories to put config data in
> > (config files or databases).
> >
> > The reasons for the first two are mainly to avoid issues like "pollution"
> > of the system with montains of unuseful data (in particular with
> > computers used by non-developers).
> > Part of the source of the issue is the lack of common good
> > uninstallation system, part of it is just historical scars itching
> > (from windows98/me era).
> >
> > There is also the cross-platform code issue: if you want to provide
> > data to the whole system in a cross-platform way, the environment
> > variables is the only way to do so, because there is no register on
> > non-windows platforms (that I know of).
> >
> > The environment variables in windows have a limited size which is
> > small enough to be hit very quickly if you abuse it.
> > For example the famous PATH can be filled with paths to tools like
> > git,hg,svn, python, ruby, your favorite C++ compilers and hit the
> > point where you can't add anything anymore. Of course, this can be
> > worked aroudn but it's still an annoying limitation.
> >
> > Finally there is the "it's a public global state" issue, which I kind
> > of like public global non-const variables in a program.
> > It's just problematic.
> >
> > I'm not a specialist of the windows specifics so any of my assumptions
> > might be wrong.
> 
> Your comparison of environment variables in an operating system to global non-const variables in a
> software library is a good one - it's usage appears contrary to encapsulation principles. I can think of two
> generalised uses of environment variables:
> 
> 1. It provides users with the ability to pass configuration information to a process, such the $CXX variable
> used in Makefiles, or $GIT_DIR for Git.
> 2. It provides processes with the ability to communicate with other processes (a rudimentary form of inter
> process communication), such as an HTTP server implementing the CGI specification, or SVN executing
> $EDITOR for commit messages.
> 
> It'd be nice for an alternative that provides a cleaner implementation with less "global namespace
> pollution", but regardless, it appears that in the current situation:
> 
> 1. Windows does not use environmental variables as much as POSIX, but still does use them.
> 2. There is not great support for environmental variables in the curren C++ standard.
> 3. Therefore, there is a need for such a library.
> 
> Would you agree with the above from your background and experience?

Yes.

Bad in theory, useful in practice.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]