Re: [boost] [Boost.utility]

Subject: Re: [boost] [Boost.utility]
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-01-26 12:43:03

----- Original Message ----- 
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, January 26, 2010 5:46 PM
Subject: Re: [boost] [Boost.utility]

> 
> Jeff Flinn wrote:
> 
>> I fail to see the analogy between global-state-coupling and
>> exceptions.  In the former, you've got a function with
>> dependency upon global state, and any function that calls
>> that function is now dependent upon global state. The only
>> way I can tell that dependency is I have to hunt that down
>> by looking at the source code, or trying to link and getting
>> an unresolved ref liner error. How are exceptions similar?
> 
> Let me try another way to explain my point.
> 
> In the case of return codes, you must litter every function in the call chain with the appropriate return type.  Each function in the chain must examine the returned value to determine whether to proceed or return an error.  With exceptions, intermediate functions are ignorant of the exceptions thrown or the code that handles them.
> 
> With Singletons, code that needs access to global state accesses a Singleton.  Without that, all intermediate functions must be littered with argument(s) for the state needed by the inner function.  If the inner function needs access to global state it didn't need before, or no longer needs access to global state it once did, all functions in the call stack must be changed to pass or not pass along that state.
> 
> I was never discussing determining whether a function is dependent upon global state.
> 
>> What use cases do you see where global state access is required?
> 
> Consider an environment with a single configuration state object.  All code requiring access to that configuration state can either access it as global state, which it is, or that object can be passed to all functions that require it.  The latter leads to polluting myriad other functions with arguments they need only to satisfy the functions they call.
> 

What about defining all the functions of the singleton at a namespace level. So rather than doing 

struct S : singleton<S> {
    void f1();
    int f2(char);
};

and use it as 

S::instance().f1();

doing in this way

namespace S {
    void f1();
    int f2(char);
};

and use it as 

S::f1();

Of course, nothing forbids the implementation of the functions at the namespace level to use a singleton, but this is an internal detail, not shown at the user level.
 
What use cases do you see where the class interface is more convenient than the namespace interface?

Best,
Vicente