Prev: Simplester MetaLoop
Next: Announcement: Enhanced search engine for C/C++, with Firefox/IE
From: Keith H Duggar on 3 Nov 2009 06:26
On Nov 3, 7:42 am, "Martin B." <0xCDCDC...(a)gmx.at> wrote:
> Keith H Duggar wrote:
> > On Oct 30, 5:33 pm, Khan <chen...(a)my-deja.com> wrote:
> >> Why is there no variant of pop() in the standard library that returns
> >> the top element? (....)
>
> >> The one reason I can think of (Dont give a way to the user to do
> >> inefficient things) has counterarguments:
> >> - A lot of people are going to write T t = x.pop() anyway. Cant
> >> prevent that.
> >> (....)
>
> > Several have already posted good (and standard) answers. Here
> > is another different take.
>
> > class member interfaces should be 1) complete 2) minimal. In the
> > case of a stack clearly we need the capability to access the top
> > without modification so T & .top() is a must. Second we need the
> > capability to pop as efficiently as possible hence void .pop() .
>
> > At that point the class interface is complete (as far as access
> > and popping go) so adding a top+pop (shift) member variant would
> > violate the "minimal interface" design criterion.
>
> While there are arguments for class *member* interfaces being minimal,
> I'd say that's no reason for the class interface to be minimal. That is,

Then we agree there are reasons for minimalism in "class member
interfaces" (to quote myself). Given that, are you sure you find
"no reason" for minimalism when designing non-member interfaces
as well? Even in balance with other criteria? "no reason" seems
far too extreme to me because I can think of good reasons for
minimalism (to one degree or another) in just about every aspect
of software design.

> if "we" think shift is a useful interface, then it should be
> provided along with the class (as a free function) and "we"
> shouldn't require the user to roll her own.

Personally I don't find the shift interface useful. Usually I'm
going something along the lines of

if ( !s.empty() ) {
foo(s.top()) ;
s.pop() ;
}

so I might want a different gadget. However, I'm sure if the C++
committee as a majority thought of some useful interface then of
course they would consider adding it. That said, they would need
to balance the usefulness with the cost (perhaps extensive) of
making the addition such as debate on the specific interface,
impact analysis, approval, documentation, etc.

> > As a demonstration that it is complete see how simple it is to
> > provide a free function in your own custom library to get the
> > extra shift behavior you want
>
> > template < class T >
> > bool shift (
> > std::stack<T> & s , T & t )
> > {
> > if ( !s.empty() ) {
> > t = s.top() ;
> > s.pop() ;
> > return true ;
> > }
> > return false ;
> > }
>
> Having to provide all[*] these "simple" helper functions does not strike
> me as a sign of completeness.

"complete" in a class interface sense doesn't mean "my program
is written for me" or "covers all conceivable combinations of
user activity" which is of course impossible. Rather it means
that the classes entire (observable) state space is reachable
using the interface.

> [*] With "all" I am referring to the issue that one often heard response
> to questions such as the OP is that it's "easy" or "simple" or "trivial"

Well the word "trivial" is blatantly and wrongly used as a
synonym for "simple" by a huge portion of the population. So
is "easy" to a lesser extent. In this case I said "simple"
and I believe it is appropriate. Neither "trivial" nor "easy"
are appropriate here, in my opinion. But I agree it is very
often wrongly said that a thing is "trivial" or "easy".

> to add said functionality via a free function. The question then is why
> it ain't part of the library already (together with documentation about
> possible issues regarding exceptions etc.).

Because the cost of adding such simple gadgets to the C++
standard is, for the committee, much higher than one might
naively expect and they already have enough to do ;-)

KHD

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jeff Schwab on 3 Nov 2009 18:16
Martin B. wrote:

> Having to provide all[*] these "simple" helper functions does not strike
> me as a sign of completeness.
>
>
> [*] With "all" I am referring to the issue that one often heard response
> to questions such as the OP is that it's "easy" or "simple" or "trivial"
> to add said functionality via a free function. The question then is why
> it ain't part of the library already (together with documentation about
> possible issues regarding exceptions etc.).

Writing the set of utility functions required by a particular user is
simple, especially for the user in question (especially since only s/he
knows exactly what s/he wants). Defining the union of all such sets of
utility functions is not a reasonable expectations of a standards body,
nor of an implementor.

For the record, "trivial" to me has a specific meaning: It is the
absolutely minimal entity that meets a given criterion. For example, a
"trivial" function, as I use the term, has an empty body, or (if a
return value is necessary) a one-line return statement. I got this
definition from an undergraduate course on signal processing, where the
professor used the phrase "trivial value" to mean the origin in a given
state space.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3 4
Prev: Simplester MetaLoop
Next: Announcement: Enhanced search engine for C/C++, with Firefox/IE