Quick Q: Do smart pointers help replace raw pointers? -- StackOverflow

Quick A: Yes, smart pointers replace owning raw pointers, and you should prefer smart pointers in new code. Raw pointers and references are still appropriate to pass parameters down a stack.

Recently on SO:

C++ 11 Smart Pointer usage

I have a question about smart pointers in c++ 11. I've started to have a look at C++ 11 (I usualy program in c#) and read some thing about smart pointers. Now i have the question, does smart pointers completely replace the "old" style of pointers, should i always use them?

18 C++ User Group Meetings in October

The monthly overview on upcoming C++ User Group Meetings:

C++ User Group Meetings in October

by Jens Weller

From the article:

The monthly overview on the meetings of C++ User Groups world wide:

1.10 C++ UG Austin - Understanding and Using Generic Libraries in C++
2.10 C++ UG Paris - C++ FRUG #4 - C++ & Python
2.10 C++ UG New York - An Evening with Bjarne Stroustrup
2.10 C++ UG Madrid - De 0 a 100 (Taller)
2.10 C++ UG Istanbul - R-value references and Move Semantics
8.10 C++ UG San Francisco/ Bay area - Presentation and Q&A
9.10 C++ UG Dresden - Build Systems
11.10 C++ UG Pune, India - A hands-on introduction to the Boost Libraries
15.10 C++ UG Montpellier - Rencontre C++
15.10 C++ UG Düsseldorf - Coding Dojo
15.10 C++ UG Santa Barbara - Kickoff meeting
16.10 C++ UG Seattle/North West - Compiler Technologies
20.10 C++ UG Denver - Coding Dojo
21.10 C++ UG Berlin - No topic yet.
22.10 C++ UG Hamburg - Einführung in MPI
22.10 C++ UG San Francisco/ Bay area - Workshop and Discussion Group
23.10 C++ UG Bristol - "Lessons From Test Code" with Jon Jagger
25.10 C++ UG Saratov, Russia
29.10 C++ UG London - No topic yet.

And In the Beginning... -- Tony DaSilva

We don't normally link to pleas to spam mass-email anyone, never mind Bjarne Stroustrup, but we just had to share this heartfelt plea because it would be Good for the World. (Sorry, Dr. Stroustrup!)

But even if you don't email him, read or re-read D&E. It's still quite current.

And In the Beginning...

by Tony DaSilva

From the article:

I’m on my second pass through Bjarne Stroustrup’s "The Design And Evolution Of C++". In the book...

CppCon 2014 videos online

From the CppCon blog:

2014 Videos Online

We are announcing the CppCon Channel on YouTube with the first uploads of our video from CppCon 2014.

Our first videos feature our three keynote presentations from Bjarne Stroustrup, Mark Maimone, and Mike Acton; as well as our opening and closing plenary sessions from Scott Meyers and Herb Sutter. 

Over the next few weeks we’ll be uploading videos of most of the conference sessions including panels, lightning talks, and over one hundred sessions from the six tracks that made up the core of our conference program. The first two of our regular session uploads are from Michael Caisse and Thomas Rodgers.

We’d like to thank the speakers for allowing these sessions to be recorded and shared and Bash Films for the production of these videos.

Quick Q: Why can noexcept generate faster code than throw()? -- StackOverflow

Quick A: Because noexcept doesn't have to keep track of stack unwinding.

noexcept, stack unwinding, and performance

The following draft from Scott Meyers new C++11 book says (page 2, lines 7-21)

The difference between unwinding the call stack and possibly unwinding it has a surprisingly large impact on code generation. In a noexcept function, optimizers need not keep the runtime stack in an unwindable state if an exception would propagate out of the function, nor must they ensure that objects in a noexcept function are destroyed in the inverse order of construction should an exception leave the function. The result is more opportunities for optimization, not only within the body of a noexcept function, but also at sites where the function is called. Such flexibility is present only for noexcept functions. Functions with “throw()” exception specifications lack it, as do functions with no exception specification at all.

In contrast, section 5.4 of "Technical Report on C++ Performance" describes the "code" and "table" ways of implementing exception handling. In particular, the "table" method is shown to have no time overhead when no exceptions are thrown and only has a space overhead.

My question is this - what optimizations is Scott Meyers talking about when he talks of unwinding vs possibly unwinding? Why don't these optimizations apply for throw()? Do his comments apply only to the "code" method mentioned in the 2006 TR?

Fun with C++14 Lambdas at Silicon Valley Code Camp -- Sumant Tambe

If you're going to SVCC'14, check out the C++ sessions:

Fun with C++14 Lambdas at Silicon Valley Code Camp

by Sumant Tambe

From the article:

Believe it or not, but the 9th Silicon Valley Code Camp is less than 2 weeks away and I can't wait to be at the largest software technology conference setup by developers for developers -- and here is the best part -- at no cost to the attendees. So far, there are 234 registered sessions, 7 technical tracks, and over 3100 registrations. So mark your calendar -- it's October 11th and 12th, Saturday and Sunday, as always.

C++ is hot again at SVCC and third year in a row there is a dedicated track for modern C++...

Variadic Templates -- Feabhas

variadic-templates.PNGRecently on StickyBits, a nice primer on variadics:

Variadic Templates

by feabhas

From the article:

In this article we’re going to look at a new feature of templates in C++11 -- the concept of the variadic template.

Variadic templates allow us to create functions and classes, not only with generic types, but also a variable number of generic types.

If you haven’t been following along with the template articles, I’d suggest you read this article first before continuing.

A Grand Introduction: Stepanov introduces Stroustrup at CppCon -- Tony DaSilva

Bulldozer00's appreciation for Alex Stepanov's introduction for Bjarne Stroustrup at CppCon. We already linked to the video last week -- but if you didn't watch it then, do yourself a favor and spend 6 minutes now getting your workweek off to a great start.

A Grand Introduction

by Tony DaSilva

From the article:

"We should not be ashamed of bits. We should be proud of them." -- Alex Stepanov

You may not interpret it in the same way as I did, but I found this cppcon conference introduction of Bjarne Stroustrup by programming scholar Alex Stepanov very moving...

N4149: Categorically qualified classes -- David Krauss

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: N4149

Date: 2014-09-25

Categorically qualified classes

by David Krauss

Excerpt:

Some classes only work in certain contexts: scope guards are usually useless as subexpressions, and expression template placeholders malfunction as local variables. An unused function result may signal that the caller intends to follow a different protocol, such as with std::async. This proposal extends class definitions to prevent such errors, and adds a mechanism to automatically resolve them by type substitution, such as a value type for an expression template. Additionally, generation of non-movable objects becomes more tractable.

The added functionality includes that of the “auto evaluation” proposals [1]. This proposal intends to be more expressive, more broadly applicable, and easier to adopt and use.

N4148: Disallowing Inaccessible Operators From Trivially Copyable -- Matheus Izvekov

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: N4148

Date: 2014-09-24

Disallowing Inaccessible Operators From Trivially Copyable

by Matheus Izvekov

Excerpt:

This proposal aims to solve a serious flaw in the definition of the trivially copyable concept. Presently, classes with deleted or inaccessible copy/move constructors, copy/move assignment operators and destructor are allowed to be trivially copyable, which might seem counterintuitive.