Home » Blog » Categories »

An overview of smart pointers -- Jens Weller

By Blog Staff | Jan 10, 2014 10:30 AM | Tags: basics

Jens's latest, following up on his pointers post:

An overview on smart pointers

by Jens Weller

From the article:

So, a smart pointer is only needed, when you use new or other means of dynamic memory allocation. In my opinion, you should prefer to allocate variables on the stack, so when refactoring code (to C++11), you should always ask yourself, if this new is needed, or could be replaced with an object on the stack. When you need to use new, you should always use a smart pointer in my opinion. Also some smart pointers offer a custom deleter, which is handy if you have an object that is either not allocated by new and/or needs to be freed by calling a special function.

N3828: C++ Standards Committee Meeting, Nov 3-8, 2014, Urbana-Champaign

By Blog Staff | Jan 9, 2014 11:01 AM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3828

Date: 2014-01-07

C++ Standards Committee Meeting November 3-8, 2014 University of Illinois at Urbana-Champaign

by Jill Peckham

Excerpt:

The Fall 2014 C++ Standards Committee Meeting will be held on the
campus of the University of Illinois at Urbana-Champaign. Hosts for the
meeting are the U of I Department of Computer Science and the Parallel
Computing Institute.

Meetings will be held in the Thomas M. Siebel Center for Computer Science
and the Coordinated Science Laboratory, both conveniently located just a
few blocks from either conference hotel and across the street from each
other.

Registration for C++Now 2014 is now open

By marshall | Jan 7, 2014 09:06 AM | Tags: None

Registration for C++Now 2014 is now open.

The Eighth annual C++Now Conference (formerly BoostCon) will be held at the Aspen Center for Physics in Aspen, Colorado, May 12th to 17th, 2014.

Conference website: http://www.cppnow.org

 

Dive into C++11 (#4) — Smart pointers

By Vittorio Romeo | Jan 6, 2014 02:48 AM | Tags: intermediate

Hello once more isocpp users, I’m Vittorio Romeo, a computer science student, hobbyist game developer and C++ enthusiast.

I’ve uploaded the fourth episode of “Dive into C++11” on my YouTube channel.

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!

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.