JTC1/SC22/WG21 N0729

 
                                        #X3J16-95-0129,WG21-N0729
 
        Bjarne Stroustrup:
 
        A Suggestion for Simplifying the Use of Adaptors
 
 
What's wrong with this piece of code?
 
        list<int> li;
        vector<int> vi;
        queue<int> qi;
        stack<int> si;
 
Nothing at all, but because of the way container adaptors are defined
the last declaration is an error. We must write
 
        stack<queue<int> > si;
 
or something equally non-obvious (to a novice).
 
I'd rather not have to try to explain that when teaching C++.
Unless we change the definition of adapters, this will become
an embarrasement. It will also be a source of (detected) bugs
and confusion. There is no way we will be able to avoid the style
of adaptor definition to be copied. Problems with adaptors in
the standard will be repreated thousands of times by programmers
trusting our judgement.
 
I conjecture that most users initially will not know the difference
between a container and a container adaptor, and will (reasonably
enough) prefer not to know that difference until that knowledge will
be of practical use to them. It is a difference that we generally
prefer to ignore as an "implementation detail." Quick: do you really
remember which containers are really containers, and which are
adaptors? stack? queue? dequeue? set?
 
I don't care greatly how `stack' is defined, but I do think that
it is important that
 
        stack<int> si;
 
is a legal definition of a stack of integers.
 
The obvious alternative style of adapter definition is:
 
        template<class T, class container = deque<T> >
                class stack { ... };
 
This definition will have essentially no impact on the definition
of stack; no time or space penalties apply compared to the current
definition. There is a small burden placed on people who actually
use non-default representations of a stack. Instead of writing
 
        stack<array<int> > sai;
 
they must write
 
        stack< int, array<int> > sai;
 
To me, that seems a minor burden, and placing a minor burden on
relative experts seems far preferable to placing a slightly larger
burden on novices.
 
In the WP, the change is localized to section 23.2.4
[lib.container.adapters].
 
I see only four possible objections:
 
        (1) Any change takes time to execute.
 
        (2) A new kind of error becomes possible: queue<char,list<int>>.
 
        [3] Existing code using adapters break.
 
        [4] Existing tutorial material becomes outdated.
 
I conjecture that the change is small and locallized enough
for [1] not to be serious (even in this late stage of the process).
Point [2] is offset by avoiding the more obvious error stack<int>.
It is my belief that the amount of code that will be broken
small enough - and of a sufficiently experimental nature - for
the change to be worth while. I am quite sensitive to [4], but
in this case the amount of existing material is still rather small
and will need updating anyway to take other changes into account.