John Vincent wrote:
> For some reason I'd missed it ?!?

I think some versions of Adobe Acrobat don't find it when
searching.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Bbcje.39974$vi2.1538760@twister.southeast.rr.com>,
 jgottman@carolina.rr.com ("Joe Gottman") wrote:

>    If the rvalue reference proposal is accepted, then pop_back() might be
> able to use move() to return the top element by rvalue reference.  This
> would be much safer, though not 100% safe, as move constructors and move
> assignment operators will probably be nothrow.  Java stacks return their top
> element with move semantics when they call pop(), and there is no risk of
> them throwing.

The problem is that we should not require that a type be movable (have a
nothrow move constructor) to be put in a stack.  We still need to
support "copyable only" objects, i.e. objects that have no nothrow move
semantics, but do have throwing copy semantics.  Dumping support for
such objects would be a huge backwards compatibility hit.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

I have examined both the first and the second edition of the C++ standard,
and as far as I can see the pop_back() method is not properly defined. I
cannot find anything in the standard that specifies either that it removes
an item from a container, or which item it removes.

Is this an error, or did I miss something?

Thanks
/John Vincent.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Vincent wrote:
>
> I have examined both the first and the second edition of the C++
> standard, and as far as I can see the pop_back() method is not properly
> defined. I cannot find anything in the standard that specifies either
> that it removes an item from a container, or which item it removes.
>
> Is this an error, or did I miss something?

The operational semantics of a.pop_back() is defined as
a.erase(--a.end()), and it is defined for vector, list, and deque.
See Table 68 ("Optional sequence operations") in 23.1.1.

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Vincent wrote:
> Hi,
>
> I have examined both the first and the second edition of the C++
> standard, and as far as I can see the pop_back() method is not properly
> defined. I cannot find anything in the standard that specifies either
> that it removes an item from a container, or which item it removes.
>
> Is this an error, or did I miss something?
>

Have a look to table 68, in 23.1.1.

Alberto

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Vincent" <jpv50@hotmail.com> wrote:
> I have examined both the first and the second edition of the C++
> standard, and as far as I can see the pop_back() method is not
> properly defined.

in fact, it is not defined at all. This is by design - trying to do two
operations at once (copy last element to function result and then remove
it from top of stack) is bad design (especially from exception safety
POV). This has been discussed in literature, e.g. Herb Sutter
"Exceptional C++"


B.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Vincent wrote:

> Hi,
>
> I have examined both the first and the second edition of the C++
> standard, and as far as I can see the pop_back() method is not properly
> defined. I cannot find anything in the standard that specifies either
> that it removes an item from a container, or which item it removes.
>
> Is this an error, or did I miss something?

Table 68 defines the operational semantics of pop_back; were
you looking for additional definitions, or is this sufficient?

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-05-18 22:11:54 -0400, jpv50@hotmail.com ("John Vincent") said:

> Hi,
>
> I have examined both the first and the second edition of the C++
> standard, and as far as I can see the pop_back() method is not properly
> defined. I cannot find anything in the standard that specifies either
> that it removes an item from a container, or which item it removes.
>
> Is this an error, or did I miss something?

>From 23.1.1 [lib.sequence.reqmts]
--------------
12 The operations in Table 68 are provided only for the containers for
which they take constant time:
--------------

And, from said table:
--------------
expression   | return type | operational semantics | container
.          | ...         | ...                   | ...
a.pop_back() | void        | a.erase(--a.end())    | vector, list, deque
--------------


--
Clark S. Cox, III
clarkcox3@gmail.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Vincent" wrote:
> Hi,
>
> I have examined both the first and the second edition of the C++
standard,
> and as far as I can see the pop_back() method is not properly
defined. I
> cannot find anything in the standard that specifies either that it
removes
> an item from a container, or which item it removes.
>
> Is this an error, or did I miss something?

You are correct that the definitions of list<>::pop_back(),
deque::pop_back() and vector<>::pop_back() do not specify those things.
However, what you missed is the implications of the fact that 23.2.1p2,
23.2.2p2 and 23.2.4p2 all specify that those containers satisfy "most
of the optional sequence requirements (23.1.1)".

If you look at 23.1.1p12 you'll find Table 68, which describes the
optional sequence requirements. The requirements are optional, because
the operations they specify are mandotory only when they have constant
complexity. It says that for pop_back() this is the case for list,
deque, and vector. It specifies that a.pop_back() is equivalent to
a.erase(--a.end()).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

brok@rubikon.pl ("Bronek Kozicki") writes:

> "John Vincent" <jpv50@hotmail.com> wrote:
>> I have examined both the first and the second edition of the C++
>> standard, and as far as I can see the pop_back() method is not
>> properly defined.
>
> in fact, it is not defined at all. This is by design - trying to do
> two operations at once (copy last element to function result and
> then remove it from top of stack) is bad design (especially from
> exception safety POV). This has been discussed in literature,
> e.g. Herb Sutter "Exceptional C++"


1. Of course pop_back is defined -- in fact, it's defined
   for all the containers in the standard.

2. Almost every useful function is a composite of multiple
   sub-operations.  Labelling that "bad design" is not only dogmatic,
   it's silly.

3. The issue you're thinking of was raised by Tom Cargill's Article:
   "Exception Handling: A False Sense of Security"
   (http://tinyurl.com/9tnnk) or
   (http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html)
   It was improperly labelled a safety problem.  The interface as
   described is simply unable to provide more than the basic
   guarantee.  There's nothing wrong with that in principle, though
   it's true that in this case it makes sense to also supply a
   separate top() function.  The assumption that every operation must
   give the strong guarantee in order to be exception safe is
   widespread, but incorrect.  In general, the strong guarantee is
   neither sufficient, nor is it always neccessary, for exception
   safety.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bronek Kozicki wrote:
> in fact, it is not defined at all. This is by design - trying to do two
> operations at once (copy last element to function result and then remove
> it from top of stack) is bad design (especially from exception safety
> POV). This has been discussed in literature, e.g. Herb Sutter
> "Exceptional C++"

oooops. I do not know how it happend, but when writing above I was sure
that you are asking about std::stack.


B.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Vincent wrote:

>
> I have examined both the first and the second edition of the C++
> standard, and as far as I can see the pop_back() method is not properly
> defined. I cannot find anything in the standard that specifies either
> that it removes an item from a container, or which item it removes.
>
> Is this an error, or did I miss something?
>

The table entitled "Optional Sequence Operations" (I think it's 68 in
the official ISO versions, but it's 69 in the latest working draft)
gives the specification as { iterator tmp = a.end(); --tmp; a.erase(tmp); }

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <BAY101-F25F93A3613EF628DD56370A6170@phx.gbl>,
 jpv50@hotmail.com ("John Vincent") wrote:

> Hi,
>
> I have examined both the first and the second edition of the C++ standard,
> and as far as I can see the pop_back() method is not properly defined. I
> cannot find anything in the standard that specifies either that it removes
> an item from a container, or which item it removes.
>
> Is this an error, or did I miss something?

The table in 23.1.1p12 says that the operational semantics of
a.pop_back() is a.erase(--a.end()).

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

Thanks to everyone who pointed out Table 68. For some reason I'd missed it
?!?

/John Vincent.

>From: Ray Lischner <rl.news@tempest-sw.com>
>To: John Vincent <jpv50@hotmail.com>
>Subject: Re: problem with definition of pop_back()
>Date: Thu, 19 May 2005 17:15:51 -0400
>
>On Wednesday 18 May 2005 10:11 pm, John Vincent wrote:
>
> > ... as far as I can see the pop_back() method is not
> > properly defined.
>
>Section 23.1.1, Table 68.
>--
>Ray Lischner, author of C++ in a Nutshell
>http://www.tempest-sw.com/cpp


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:u3bsig3nz.fsf@boost-consulting.com...
> brok@rubikon.pl ("Bronek Kozicki") writes:
>
>> "John Vincent" <jpv50@hotmail.com> wrote:
>>> I have examined both the first and the second edition of the C++
>>> standard, and as far as I can see the pop_back() method is not
>>> properly defined.
>>
>> in fact, it is not defined at all. This is by design - trying to do
>> two operations at once (copy last element to function result and
>> then remove it from top of stack) is bad design (especially from
>> exception safety POV). This has been discussed in literature,
>> e.g. Herb Sutter "Exceptional C++"
>
>
> 3. The issue you're thinking of was raised by Tom Cargill's Article:
>   "Exception Handling: A False Sense of Security"
>   (http://tinyurl.com/9tnnk) or
>
> (http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html)
>   It was improperly labelled a safety problem.  The interface as
>   described is simply unable to provide more than the basic
>   guarantee.  There's nothing wrong with that in principle, though
>   it's true that in this case it makes sense to also supply a
>   separate top() function.  The assumption that every operation must
>   give the strong guarantee in order to be exception safe is
>   widespread, but incorrect.  In general, the strong guarantee is
>   neither sufficient, nor is it always neccessary, for exception
>   safety.

   If the rvalue reference proposal is accepted, then pop_back() might be
able to use move() to return the top element by rvalue reference.  This
would be much safer, though not 100% safe, as move constructors and move
assignment operators will probably be nothrow.  Java stacks return their top
element with move semantics when they call pop(), and there is no risk of
them throwing.

Joe Gottman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Bronek Kozicki" wrote:
> "John Vincent" <jpv50@hotmail.com> wrote:
> > I have examined both the first and the second edition of the C++
> > standard, and as far as I can see the pop_back() method is not
> > properly defined.
>
> in fact, it is not defined at all. This is by design - trying to do
two
> operations at once (copy last element to function result and then
remove
> it from top of stack) is bad design (especially from exception safety

> POV). This has been discussed in literature, e.g. Herb Sutter
> "Exceptional C++"

The pop_back() member is specified in Table 68 as having no return
value. What are you talking about?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Joe Gottman wrote:

> "David Abrahams" <dave@boost-consulting.com> wrote in message
> news:u3bsig3nz.fsf@boost-consulting.com...
>
>>brok@rubikon.pl ("Bronek Kozicki") writes:
>>
>>
>>>"John Vincent" <jpv50@hotmail.com> wrote:
>>>
>>>>I have examined both the first and the second edition of the C++
>>>>standard, and as far as I can see the pop_back() method is not
>>>>properly defined.
>>>
>>>in fact, it is not defined at all. This is by design - trying to do
>>>two operations at once (copy last element to function result and
>>>then remove it from top of stack) is bad design (especially from
>>>exception safety POV). This has been discussed in literature,
>>>e.g. Herb Sutter "Exceptional C++"
>>
>>
>>3. The issue you're thinking of was raised by Tom Cargill's Article:
>>  "Exception Handling: A False Sense of Security"
>>  (http://tinyurl.com/9tnnk) or
>>
>>(http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html)
>>  It was improperly labelled a safety problem.  The interface as
>>  described is simply unable to provide more than the basic
>>  guarantee.  There's nothing wrong with that in principle, though
>>  it's true that in this case it makes sense to also supply a
>>  separate top() function.  The assumption that every operation must
>>  give the strong guarantee in order to be exception safe is
>>  widespread, but incorrect.  In general, the strong guarantee is
>>  neither sufficient, nor is it always neccessary, for exception
>>  safety.
>
>
>    If the rvalue reference proposal is accepted, then pop_back() might be
> able to use move() to return the top element by rvalue reference.  This
> would be much safer, though not 100% safe, as move constructors and move
> assignment operators will probably be nothrow.  Java stacks return their top
> element with move semantics when they call pop(), and there is no risk of
> them throwing.

Note that Java stacks don't return things with move semantics;
the object is never part of the stack, but rather is allocated
separately on the heap, and when it is popped it doesn't move,
but rather a pointer (reference, in Java-speak) to it is returned
to the caller and the stack ceases to reference it.  Copying a
pointer (reference) is a no-throw operation, so that's all fine;
you just pay the penalties of another level of indirection
compared to a value-based C++ stack.  The complications in C++
come from allowing values to be stored inside the stack, rather
than having the stack just refer to objects elsewhere.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jgottman@carolina.rr.com ("Joe Gottman") writes:

>>
>> (http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html)
>>   It was improperly labelled a safety problem.  The interface as
>>   described is simply unable to provide more than the basic
>>   guarantee.  There's nothing wrong with that in principle, though
>>   it's true that in this case it makes sense to also supply a
>>   separate top() function.  The assumption that every operation must
>>   give the strong guarantee in order to be exception safe is
>>   widespread, but incorrect.  In general, the strong guarantee is
>>   neither sufficient, nor is it always neccessary, for exception
>>   safety.
>
>    If the rvalue reference proposal is accepted, then pop_back()
> might be able to use move() to return the top element by rvalue
> reference.  This would be much safer, though not 100% safe, as move
> constructors and move assignment operators will probably be nothrow.

You totally miss my point.  My point is that there's nothing unsafe
about an interface that may lose data when an exception is thrown, as
long as it's documented, and all invariants are maintained.  Nobody
thinks std::vector<T>::insert is unsafe (**).

-Dave

(**) Well, if they do, they're wrong ;-)
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:
> "Bronek Kozicki" wrote:
>>"John Vincent" <jpv50@hotmail.com> wrote:
>>>I have examined both the first and the second edition of the C++
>>>standard, and as far as I can see the pop_back() method is not
>>>properly defined.
>>
>>in fact, it is not defined at all. This is by design - trying to do two
>>operations at once (copy last element to function result and then remove
>>it from top of stack) is bad design (especially from exception safety
>>POV). This has been discussed in literature, e.g. Herb Sutter
>>"Exceptional C++"
>
> The pop_back() member is specified in Table 68 as having no return
> value. What are you talking about?

<blush> err.... probably that was not a good time to write. At least
here ;-) Somehow I thought that OP was asking for "remove last element
from stack and return its value". Do not ask why, as I do not know
myself. I think that Dave underestood what I meant and cleared things up
(thanks for that - he knows the subject exceptionally well). Oh, as Joe
Gottman pointed out, after rvalue-reference goes into standard, we could
actually do that quite safely. If there is good reason for it, that is.


B.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]