Boost logo

Boost :

From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2004-02-17 09:56:22

"Andy Little" <andy_at_[hidden]> writes:

| > I'm sorry, I cannot undersand what you mean here.
| The reference is in D&E 3.12 2/3rd way in (example struct outer{struct inner
| ... ) C had(has?) a different take on nested scopes.
| My point is more general. As laid out in the standard scope rules are
| dependent on context, however there is no overall vision of the concept
| behind why certain rules apply in a given context. What you have is a large
| number of bits and pieces hinting at the greater picture. As it stands you

I usually describe that as "a long list of special cases", but I would
not go that far saying that there is no overall vision of the concept
behind why certain rules apply in a given context. Each time I've
asked why certain rules don't apply, I think I've got an answer as to
But, there are situations where general rules are prevalent.
It looks to me that this issue of members hide enclosing
template-parameters is one where a general rule applies.

| just have to know All the rules... nobody really does... hence confusion. In
| order to provide concepts rather than intuition as a guide to what rules to
| apply in a given situation, there should be some hierarchy of entities. I
| would put the first branch off the root of the tree at template versus non
| template. What that means is that on the template branch Dont expect the
| same rules as on the non template branch. From there function/class giving
| 4 contexts each again with its own rules. There is no crossover of rules
| from one context to another. However travelling down from the root there
| should be consistency of rules. One rule at top of the template branch
| Might be that 'new' template parameters should hide names from 'older'
| scopes. The rationale being that the template parameters are the most
| prominent part of a template definition.
| Whatever... template 'space' just aint the same as non template 'space'...
| so there should be no crossover of rules between different contexts. e.g you
| cant apply rules from a non-template function to a function template etc.
| This sounds like a recipe for an explosion of rules, but in fact many rules
| that apply in one context would *look very similar* to rules that applied in
| other contexts. However there is no Requirement that that must be the case.
| The tree models language syntax
| Template branch.: template<..> T ---> {function template}
| template<..> class -->{ class template}
| Non-template branch T --->{function} class ---> {class};
| (Next branch from root to be 'concept' ...) ;-)
| All these entities are entirely different animals.
| Hope the above makes some sense. It does to me anyways :-)

I see now what you meant. Thanks for taking the time to clarify.
Your picture leave out whether you consider nesting of scopes or not.

-- Gaby

Boost list run by bdawes at, gregod at, cpdaniel at, john at