: Standard C++

After looking at C and C++'s memory and lifetime management in part 3, we'll take a brief look at C++11 smart pointers. We will learn what they are, what problem they solve, their advantages and their uses.

The intended audience for this tutorial/screencast are people who have some experience with C++ in general, and who watched the previous episodes. This episode may be very interesting for those with experience with C++ who want to learn more about variable lifetime and memory management.

I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Feel free to fork/analyze the source code at: https://github.com/SuperV1234/Tutorials

You can find the previous episodes here:

Episode 1
Episode 2
Episode 3
Playlist

Thanks for watching!

C++ User Group Meetings in January

By Meeting C++ | Jan 2, 2014 09:28 AM | Tags: usergroups community

A new great year for C++ has begun and a few C++ User Groups already meet in January for the first time:

C++ User Group Meetings in January

by Jens Weller

From the Article:

A new and awesome year for C++ has begun. And this years starts with at least 2 new C++ User Groups...

Quick Q: Should we really avoid new and delete? -- StackOverflow

By Blog Staff | Jan 2, 2014 01:48 AM | Tags: basics

A: Yes, except possibly encapsulated inside the implementations of low-level data structures.

The more general question on SO was:

About the usage of new and delete, and Stroustrup's advice

About the usage of new and delete, and Stroustrup's advice...

He says something like (but not exactly, this is from my notes of his book):

A rule of thumb is that, new belongs in constructors and similar operations, delete belongs in destructors. In addition, new is often used in arguments to resource handles. Otherwise avoid using new and delete, use resource handles (smart pointers) instead.

I was wondering if the more experienced folks with C++11 have really applied this or not.

My impression of this was, wow this seems like a really cool rule to follow. But then I got suspicious, as for any general rule. At the end of the day you will end up using new and delete wherever necessary. But maybe this rule is a good guideline I don't know.

Interlude: C++’s Strides in 2013 -- K-ballo

By Blog Staff | Jan 1, 2014 10:13 AM | Tags: None

K-ballo's look at the achievements of C++ completed in 2013 and coming up in 2014, with an overview of draft C++14 features.

Interlude

by K-ballo

From the article:

One year down the road, 2013 has gone by but not without modifications to the C++ lands. Two major compilers have reached C++11 conformance ---GCC and Clang---. Shortly after, the Committee Draft (CD) for C++14 was completed, which is now just around the corner...

All things considered, it was an impressive year for C++ conformance. And notably, it looks like for the first time there will be feature complete compilers for a C++ standard on the very same year it is ratified. The following slide from GoingNative's Keynote: Herb Sutter -- One C++ summarizes the situation nicely:

[... lots of discussion of C++14 features ...]

The C++ lands grew bigger during 2013, and we can only expect this trend to intensify during 2014. With the likely ratification of C++14 and at least some of the TS, it will certainly be a good year for C++.

GotW #7b Solution: Minimizing Compile-Time Dependencies, Part 2

By Blog Staff | Jan 1, 2014 07:57 AM | Tags: intermediate basics

The solution to the latest GotW problem is now available.

GotW #7b Solution: Minimizing Compile-Time Dependencies, Part 2

by Herb Sutter

From the article:

Now that the unnecessary headers have been removed, it’s time for Phase 2: How can you limit dependencies on the internals of a class?

...
Guideline: For widely-included classes whose implementations may change, or to provide ABI-safety or binary compatibility, consider using the compiler-firewall idiom (Pimpl Idiom) to hide implementation details. Use an opaque pointer (a pointer to a declared but undefined class) declared as struct impl; std::unique_ptr<impl> pimpl; to store private nonvirtual members.

Quick Q: Does constexpr guarantee compile-time evaluation? -- StackOverflow

By Blog Staff | Dec 31, 2013 10:12 AM | Tags: intermediate

Quick A: constexpr guarantees compile-time evaluation is possible if operating on a compile-time value, and that compile-time evaluation will happen if a compile-time result is needed.

From SO, the originally worded question:

Can C++ constexpr function actually accept non-constant expression as argument?

I have defined a constexpr function as following:
constexpr int foo(int i)
{
    return i*2;
}
And this is what in the main function:
int main()
{
    int i=2;
    cout<<foo(i)<<endl;
    int arr[foo(i)];
    for(int j=0;j<foo(i);j++)
        arr[j]=j;
    for(int j=0;j<foo(i);j++)
        cout<<arr[j]<<" ";
    cout<<endl;
    return 0;
}
The program was compiled under OS X 10.8 with command clang++. I was surprised that the compiler did not produce any error message about foo(i) not being a constant expression, and the compiled program actually worked fine. Why?

Quick Q: How do I use conditional noexcept? -- StackOverflow

By Blog Staff | Dec 31, 2013 02:57 AM | Tags: intermediate

The question also has a lemon-zest touch of "templates in headers" but the basic noexcept question is still the same:

Use of the noexcept specifier in function declaration and definition?

Consider the following function:
// Declaration in the .h file
class MyClass
{
    template <class T> void function(T&& x) const;
};

// Definition in the .cpp file
template <class T> void MyClass::function(T&& x) const;
I want to make this function noexcept if the type T is nothrow constructible.

How to do that? (I mean what is the syntax ?)

Quick Q: Why would I use =default? -- StackOverflow

By Blog Staff | Dec 30, 2013 12:55 PM | Tags: basics

Quick A: Not just for convenience, but sometimes it matters for PODness or optimal performance.

From SO:

The new keyword =default in C++11

I don't understand why would I ever do this:
struct S {
    int a;
    S(int aa) : a(aa) {}
    S() = default;
};
Why not just say:
S() {} // instead of S() = default;
why bring in a new keyword for that?

Quick Q: Does memory layout (including alignment) matter for performance? -- StackOverflow

By Blog Staff | Dec 30, 2013 11:50 AM | Tags: intermediate

Quick A: Oh, yeah.

See the nice three-paragaph "highlights" answer to the question:

Does alignment really matter for performance in C++11?

There is an advice in Stroustrup's book to order the members in a struct beginning from the biggest to the smallest. But I wonder if someone has made measurements to actually see if this makes any difference, and if it is worth it to think about when writing code.