Re: Clean ways to count remove_if() removals?

From:

Pete Becker <pete@versatilecoding.com>

Newsgroups:

comp.lang.c++

Date:

Thu, 25 Jun 2009 13:03:40 -0400

Message-ID:

<XeqdnQOn37FwMN7XnZ2dnUVZ_uSdnZ2d@giganews.com>

Martin Eisenberg wrote:

Pete Becker wrote:

Martin Eisenberg wrote:

Pete Becker wrote:

One reason for all this handwaving is a desire to not preclude
debugging versions of splice, which sometimes have to root
around in the underlying data in ways that can't be done in
constant time.

Would it raise any technical problem for a standard (be it C++
or something newly drawn up) to give debug implementations of
any facility a waiver up front to do whatever they have to,
leaving reasonableness to QoI, rather than muddy descriptions
of ordinary cases?

For some folks, debugging implementations are "ordinary cases."

The standard doesn't require that implementations conform to it.
It can't. So for the standard to say "debugging implementations
need not conform to this standard" would be vacuous. That's an
issue between you and your vendor.

Thanks, that's logical. But... then it shouldn't leak to the surface
of the splice specification either, right?

It depends on what you want a conforming implementation to do. For a
simpler (although more fraught) example, consider export templates. A
conforming implementation supports the keyword "export" applied to
template definitions. If an implementation doesn't do this, it doesn't
conform to the standard. On the other hand, if the standard said, say,
"implementations for embedded systems do not need to support export"
then implementations for embedded systems that did not support export
would conform to the standard.

To a certain extent this is word play: no implementation conforms
perfectly to the standard. But the implications of the two forms of
expression are clearly different.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)