RE: [boost] Re: environment variable access

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-01-23 17:20:35

From: 	bill_kempf [mailto:williamkempf_at_[hidden]] 

>size(), max_size(), possibly empty() are the only ones I see that 
>won't play nice unless you load the full environment. I suppose the 
>reverse iteration methods like rbegin() would also not work here. I'd 
>also have to question the need for count(), lower_bound(), upper_bound
>(), equal_range(), swap() and all other copy methods, though they 
>could be retained. Removal of these would leave you with a very nice 
>interface for environment variable access.

This appears to be yet another area where policies can come in handy.  Take
as a starting point a std::map interface and a platform which allows that
interface to be fully met (including complexity guarantees).  For example,
env["foo"] would insert a default constructed (i.e. empty-valued)
environment value "foo".

The stickiness comes when a platform doesn't allow full support of the
std::map interface.  In this case, the implementation can do one of three
things:
1. Not support the associated function.
2. Throw an exception when the associated function is called.
3. Perform the function, with degraded performance.

Which option is best depends on what the user is trying to do.  In user code
targeting a specific platform, it is probably best to get a compiler error
and rework the code to avoid the missing functionality.  In code targeting
multiple platforms, the author may programmatically deal with limitations of
certain platforms, with the exception being a low-cost safety net. This is
similar to Python's os.path module.

Option 3 is really orthogonal to the first two options.  It's basically a
way to make obvious a platform speed problem, rather than have it silently
cause slow execution.

More formally, there would be two orthogonal policies:
P1: handle_platform_unsupported: either compile_error or exception
P2: handle_platform_slow: either treat_at_supported or treat_as_unsupported

For example, if handle_platform_unsupported == compile_error and
handle_platform_slow == treat_as_unsupported, and the platform could support
provide size(), but not in constant time, size() would trigger a compiler
error.

Finally, given what can be done.  The next question is: How much of this is
worth the complexity.  The answer depends on differences between platforms,
and how important are the features that supported only in a subset of
platforms.  A feature support map of the more popular platforms would be
helpful.