Monday, January 11, 2016

Digest for comp.lang.c++@googlegroups.com - 12 updates in 6 topics

Paul <pepstein5@gmail.com>: Jan 11 06:38AM -0800

Suppose C is a random access container. I seem to remember reading that adding positive integers to iterators works fine so long as we don't travel more than 1 unit past the off-the-end iterator.
 
For example, if vec is a vector, auto z = vec.end() + 1; is fine (of course we can't dereference z, though).
 
However, auto z = vec.end() + 2; has undefined behaviour. Is this correct? I can't see a reference anywhere.
 
Thanks.
 
Paul
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 11 04:42PM +0100

On 1/11/2016 3:38 PM, Paul wrote:
> course we can't dereference z, though).
 
> However, auto z = vec.end() + 2; has undefined behaviour. Is this
> correct? I can't see a reference anywhere.
 
The end() iterator is already one past the end of the sequence. It's an
"after" the sequence iterator. I think that's what you probably read.
 
 
Cheers & hth.,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Jan 11 08:09AM -0800

On Monday, 11 January 2016 16:38:37 UTC+2, Paul wrote:
> Suppose C is a random access container. I seem to remember reading that
> adding positive integers to iterators works fine so long as we don't travel
> more than 1 unit past the off-the-end iterator.
 
It was incorrect or you misread it or you misremember it. Traveling one unit
further than the "one past end" iterator is undefined behavior.

> For example, if vec is a vector, auto z = vec.end() + 1; is fine (of course
> we can't dereference z, though).
 
No. Dereferencing or incrementing past 'vec.end()' is undefined behavior.
 
 
> However, auto z = vec.end() + 2; has undefined behaviour. Is this correct?
> I can't see a reference anywhere.
 
That has also undefined behavior and so has 'vec.end() + 3'. 'vec.end()' *is*
one past end iterator already.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 11 06:33AM +0100

On 1/11/2016 1:05 AM, Stefan Ram wrote:
 
> herbsutter.com/2013/05/09/gotw-1-solution/
 
> Why is there a reference in »const int& value« instead of
> just »const int value«?
 
Because `std::vector` is a class template, where this argument type is
specified in terms of a template parameter.
 
It's not practical to define a type-dependent choice of a formal
argument type in a template, because that would foil ordinary template
argument type deduction. So that's not done. So there's just a single
argument form for this argument, namely `T const&`, regardless of
whether that's maximally efficient or not for a given type `T`.
 
Cheers & hth.,
 
- Alf
SG <s.gesemann@gmail.com>: Jan 11 06:39AM -0800

On Monday, January 11, 2016 at 6:33:52 AM UTC+1, Alf P. Steinbach wrote:
 
> It's not practical to define a type-dependent choice of a formal
> argument type in a template, because that would foil ordinary template
> argument type deduction.
 
Well, it is possible to do something type-dependent and template
argument deduction is of no concern in this case. But I would claim
that something like this...
 
template<class T> // intentionally ignoring allocators
class vector {
...
vector(size_type n,
typename boost::call_traits<T>::param_type value = T());
...
};
 
...is not worth the effort at all. But this would pick pass-by-value
for small trivial types and pass-by-const-ref otherwise. So,
technically, it is possible.
 
Cheers!
SG
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 11 04:56PM +0100

On 1/11/2016 3:39 PM, SG wrote:
 
> ...is not worth the effort at all. But this would pick pass-by-value
> for small trivial types and pass-by-const-ref otherwise. So,
> technically, it is possible.
 
Hm. I was thinking about a dependent-on-actual-argument-type, and that
was wrong. Thanks.
 
The above is also a bit wrong, for C++11 and later, in that it limits
the item type T to types that can be default-initialized: in C++11 the
declaration of this constructor simply drops the default.
 
I think this means that the issue is not completely trivial. ;-)
 
 
Cheers,
 
- Alf
scott@slp53.sl.home (Scott Lurndal): Jan 11 02:42PM


>In portable C++ that would be:
 
> std::bitset<32> variable{0xaaaa5555};
> auto number_of_bits_1 = variable.count();
 
It would be interesting to see if this devolves to a single
POPCOUNT instruction on architectures that have one (e.g. Intel,
ARM64, et. al).
"R. Schubert" <raphael.schubert@gmx.de>: Jan 11 05:17AM -0800

On Friday, January 8, 2016 at 7:43:38 PM UTC+1, Richard wrote:
> The Computer Graphics Museum <http://computergraphicsmuseum.org>
> The Terminals Wiki <http://terminals.classiccmp.org>
> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
 
I see. I thought that only (T)value denoted the C-style cast,
while T(value) would always create a temporary directly initialized
from value and thus require value to be convertible to T, but
apparently I was mistaken. §5.2.3 (Explicit type conversion) of
N3797 even says so, I just didn't find it before. Thanks.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 11 06:52AM +0100

On 1/11/2016 1:37 AM, Stefan Ram wrote:
> and »Algorithms library«.
 
> So we might say, »the container library and the iterators
> library and the algorithms library«.
 
Depending on the context the "STL" might refer to the Standard Template
Library developed by Stepanov and largely incorporated into the C++
standard library (but it's only a part of the standard C++ library), or
it might refer to Stephan T. Lavavej, who maintains the STL
implementation at Microsoft, and who also maintains a MinGW g++ distro
at <url: http://nuwen.net/stl.html>.
 
So, this "other person" who apparently denies the existence of the STL
would, if that were the case, be badly uninformed.
 
But there is a chance that he or she just reacted to an inappropriate
use of the term "STL" to refer to the whole of the C++ standard library.
 
• • •
 
Regarding Bjarne, he was clearly referring to the STL subset of the
standard library.
 
It's worth knowing that it was Bjarne and Stepanov, working together,
who made the STL proposal for the 1998 C++ standardization.
 
So there's zero chance that he didn't know what he was talking about.
 
• • •
 
On a more general note, regarding terminology, I think one should just
be flexible and understanding in what one accepts from others, and more
precise, if possible, in one's own speech and writings.
 
Those who focus too much on "correct" terminology fail to understand
that there's usually many meanings of a term, some archaic and some more
current, and conversely, that a single concept can be referred to by
many different terms. Even descriptive ones made up at the moment. For
example, at one time the Politically Correct Terminologists™ were
focused on "character code", which they denied could mean what it means
in e.g. "American Standard Code for Information Interchange". To any
reasonable intelligent person that's an absurd position, and I guess my
point here is that the Politically Correct Terminologists™ are seldom
reasonably intelligent, or at least they don't act like it.
 
Thus, if it's clear from context that someone uses "STL" to refer to the
whole C++ standard library, then one should in my opinion accept that.
But also, if there's room for it, one should try to educate the person a
little. E.g., responding "You mean, the C++ standard library, not just
the STL part of it?"
 
 
Cheers & hth.,
 
- Alf
Gareth Owen <gwowen@gmail.com>: Jan 11 07:16AM


> So we might say, »the container library and the iterators
> library and the algorithms library«.
 
Or we could say "STL" - and have everyone know what we mean - then
acknowledge that as sentient humans our use of language need not
constrained by ISO documents, and go about our day.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 11 12:05AM

»Ignoring defaulted optional allocator parameters for
simplicity, the two constructors are: vector( size_t n,
const int& value ); // A: n copies of value«
 
herbsutter.com/2013/05/09/gotw-1-solution/
 
Why is there a reference in »const int& value« instead of
just »const int value«?
ram@zedat.fu-berlin.de (Stefan Ram): Jan 11 12:37AM

Maybe you have made this experience:
 
You: STL
Other person: There is no STL.
You: What?
Other person: Nowhere does ISO 14882 use »STL«!
 
Now, what's the correct name?
 
Bjarne Stroustrup wrote in around 2007:
 
»As adopted as the containers and algorithms framework
of the ISO C++ standard library, the STL consists of a
...«.
 
But I can tell you this: Checked it out,
ISO 14882 does not contain the words
»containers and algorithms framework« either!
 
But it contains, »Containers library«, »Iterators library«,
and »Algorithms library«.
 
So we might say, »the container library and the iterators
library and the algorithms library«.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)