Home » Blog » Tags » basics

basics

Quick Q: What do braces mean as a function argument? -- StackOverflow

By Blog Staff | Feb 5, 2014 03:12 AM | Tags: basics

Quick A: Something cool and convenient -- you can construct a temporary variable of the parameter type without having to repeat the type.

From SO:

C++ 11 Curly Braces

I haven't used C++ for a good few years, and have just come across this:

program.build({ default_device })

The definition is:

cl_int build(
    const VECTOR_CLASS<Device>& devices,
    const char* options = NULL,
    void (CL_CALLBACK * notifyFptr)(cl_program, void *) = NULL,
    void* data = NULL) const

What are the curly braces there for? I have never seen them used in a function call like this before. I assume it has something to do with the function pointer, but that seems optional?

C++ User Group Meetings in February

By Meeting C++ | Jan 31, 2014 04:34 AM | Tags: community basics

February will be a month full of C++ user group meetings:

C++ User Group Meetings in February

by Jens Weller

From the article:

There are a few new user groups, some of them even will meet in February for the first time. There is now a russian C++ users group organizing Meetings in St. Peterburg and Moscow. In Germany, the C++ user group Munich has met in January for the first time, with over 50 people attending the first meeting. In February the user groups of Aachen and Dortmund will meet for the first time. And, already meeting last year for the first time, there is now a dutch C++ user group!

Quick Q: Is pass-by-value-and-then-move a bad idiom? -- StackOverflow

By Blog Staff | Jan 13, 2014 01:47 AM | Tags: basics

Quick A: It's a good style by default when you know you'll keep a copy of the parameter anyway. If you have an expensive-to-move type or otherwise want additional control, you can overload on &/&& or else perfect-forward.

Recently on SO:

Is the pass-by-value-and-then-move construct a bad idiom?

Since we have move semantincs in C++, nowadays it is usual to do

void set_a(A a) { _a = std::move(a); }

The reasoning is that if a is an rvalue, the copy will be elided and there will be just one move.

But what happens if a is an lvalue? It seems there will be a copy construction and then a move assignment (assuming A has a proper move assignment operator). Move assignments can be costly if the object has too many member variables.

On the other hand, if we do

void set_a(const A& a) { _a = a; }

There will be just one copy assignment. Can we say this way is preferred over the pass-by-value idiom if we will pass lvalues?

Quick Q: Why prefer making shared_ptrs via make_shared? -- StackOverflow

By Blog Staff | Jan 10, 2014 12:47 PM | Tags: basics

Quick A: Because it's more efficient, since it can eliminate an additional allocation.

Recently on SO:

Difference in make_shared and normal shared_ptr in C++

std::shared_ptr<Object> p1 = std::make_shared<Object>("foo");
std::shared_ptr<Object> p2(new Object("foo"));

Many google and stackoverflow posts are there on this, but I am not able to understand why make_shared is more efficient than directly using shared_ptr. Can someone explain me step by step sequence of objects created and operations done by both so that I will be able to understand how make_shared is efficient. I have given one example above for reference.

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.

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.

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.