N4146: Disposition of Comments, ISO/IEC DIS 14882, C++ 2014 -- Barry Hedquist

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4146

Date: 2014-09-23

Disposition of Comments, ISO/IEC DIS 14882, C++ 2014

by Barry Hedquist

Excerpt:

Attached is WG21 N4146, the Disposition of Comments for ISO/IEC DIS 14882, Draft Information Standard ISO/IEC 14882:2014.

Document numbers referenced in the ballot comments are WG21 documents unless otherwise stated.

N4133: Cleanup for exception-specification and throw-expression -- Jens Maurer

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4133

Date: 2014-09-10

Cleanup for exception-specification and throw-expression

by Jens Maurer

Excerpt:

This paper proposes to adjust the wording for exceptions to achieve the following goals:

  • Exception specifications as a semantic concept are separated from the grammar term exception-specification
  • The description of throw-expression is integrated into clause 5.

The changes are intended to be editorial only, not changing semantics. Due to the size of the changes, it seems prudent to have a full CWG review for these instead of leaving the issue to the project editor alone.
 

N4132: Contiguous Iterators -- Jens Maurer

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4132

Date: 2014-09-10

Contiguous Iterators

by Jens Maurer

Excerpt:

There are four containers in the standard library that guarantee contiguous storage: vector, string, valarray, and array. In the Library Fundamentals TS, there is also string_view. This paper introduces the term "contiguous iterator" as a refinement of random-access iterator, without introducing a corresponding contiguous_iterator_tag, which was found to break code during the Issaquah discussions of Nevin Liber's paper N3884 "Contiguous Iterators: A Refinement of Random Access Iterators". 

Rapid prototyping and teaching ZeroMQ in C++ with biicode -- Diego Rodriguez-Losada

From the biicode beta product blog:

Rapid prototyping and teaching ZeroMQ in C++ with biicode

by Diego Rodriguez-Losada

From the article:

Today, if you try to build the basic C++ client-server example that ZeroMQ provides in their site, you might encounter some problems. You have to guess that the C++ binding is not in the library, instead, it’s inside another repo (zmqcpp). I had to google it myself to find it. You have to get, configure and build the library, then setup your own project to use it.

The question is: Given some example source code snippets that use zmq, can anyone, even unexperienced developers build them quickly and easily, even without writing a single line of configuration, in any of the major OS? We think that it can be done, in a few simple steps...

Quick Q: Can computing the length of a C string really be compile-time constexpr? -- StackOverflow

Quick A: Yes, when the string being traversed is itself a constant expression, such as a string literal.

Recently on StackOverflow:

Computing length of a C string at compile time. Is this really a constexpr?

I'm trying to compute the length of a string literal at compile time. To do so I'm using following code:

#include <cstdio>

int constexpr length(const char* str)
{
    return *str ? 1 + length(str + 1) : 0;
}

int main()
{
    printf("%d %d", length("abcd"), length("abcdefgh"));
}

Everything works as expected, the program prints 4 and 8. The assembly code generated by clang shows that the results are computed at compile time:

0x100000f5e:  leaq   0x35(%rip), %rdi          ; "%d %d"
0x100000f65:  movl   $0x4, %esi
0x100000f6a:  movl   $0x8, %edx
0x100000f6f:  xorl   %eax, %eax
0x100000f71:  callq  0x100000f7a               ; symbol stub for: printf

My question: is it guaranteed by the standard that length function will be evaluated compile time?

If this is true the door for compile time string literals computations just opened for me... for example I can compute hashes at compile time and many more...

A Conversation with Bjarne Stroustrup, Carl Hewitt, and Dave Ungar -- Charles Torre

stroustrup-hewitt-ungar.PNGAn appetizer while the CppCon videos are being processed, we are pleased to link to this interview on Channel 9:

A Conversation with Bjarne Stroustrup, Carl Hewitt, and Dave Ungar

by Charles Torre

What happens when you put three titans of programming language design and computing in a room and turn a camera on to capture what takes place?

That's the thought experiment that led to this conversation with C++ language creator Bjarne Stroustrup, Self language creator Dave Ungar, and actor model creator Carl Hewitt. Thank goodness all three of them were present at Lang.NEXT 2014. Many topics are covered, as you can imagine. It's best that you find some quality time to watch, listen, and learn from some true masters. This is a long conversation and there is great programming history herein!

This is a rare (and very candid) gathering of some of the best minds in the programming world today.

Huge thanks to Bjarne, Carl, and Dave for spending over an hour to make conversation in real time. The topics naturally evolved out of the random and it was an honor to be in the room with such wonderful people who've had such a huge impact on programming.

Tune in. Enjoy.

Quick Q: Why can I return a unique_ptr by value? -- StackOverflow

Quick A: Because return local_obj; automatically treats it as an rvalue. After all, you won't be using it any more.

When this FAQ came up again recently on SO, the answer was to refer to this previous Q&A:

Returning unique_ptr from functions

unique_ptr<T> does not allow copy construction, instead it supports move semantics. Yet, I can return a unique_ptr<T> from a function and assign the returned value to a variable...

unique_ptr<int> foo()
{
  unique_ptr<int> p( new int(10) );

  return p;                   // 1
  //return move( p );         // 2
}

The code above compiles and works as intended. So how is it that line 1 doesn't invoke the copy constructor and result in compiler errors? If I had to use line 2 instead it'd make sense (using line 2 works as well, but we're not required to do so)....

Destructors: Two Use Cases -- Andrzej KrzemieĊ„ski

Freshly pressed from Andrzej:

Destructors: Two Use Cases

by Andrzej Krzemieński

From the article:

In this post I want to describe an interesting observation: programmers generally use destructors for two purposes. One is fairly obvious: releasing resources; the other — not necessarily so...