October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 3-8, Kona, HI, USA
By Adrien Hamelin | Mar 31, 2015 02:41 PM | Tags: boost basics
Here is an interesting bug:
Bug of the week
by Andrzej Krzemieński
From the article:
Today we are going to see a case study illustrating a bug. Not a very spectacular one: a typical bug one would encounter in everyday work. We will start with the symptoms, identify the root cause, and suggest measures to prevent similar things from happening in the future...
By Mantosh Kumar | Mar 29, 2015 06:46 PM | Tags: None
This article talks about why simple code is more important.
Simple and Clean Code vs. Performance
by Arne Mertz
From the article:
One of C++s strengths is that it is possible to write very performant code. But does that mean we always have to worry about performance and write our everyday code as performant as possible? Should we give up simplicity for performance? Do we have to?
By Felix Petriconi | Mar 18, 2015 01:07 AM | Tags: intermediate concurrency
Max Khiszinsky describes in his recent blog article different approaches to develop concurrent containers.
Lock-Free Data Structures. The Evolution of a Stack
by Max Khiszinsky
From the article
Describing the known algorithms would be quite boring, as there would be a lot of [pseudo-]code, plenty of details that are important but quite specific. After all, you can always find them in the references I provide in articles. What I wanted was to tell you an interesting story about exciting things. I wanted to show the development of approaches to designing concurrent containers.
By Blog Staff | Mar 17, 2015 05:10 PM | Tags: None
Quick A: Because shared_ptr is awesome and remembers the correct deleter to call.
Recently on SO:
Why does incomplete type of smart pointer data member and raw pointer data member have different behavior when their parent destruct?
In the following code:
smart pointer data member pImpl(class Impl) and raw pointer pc(class CAT) all are incomplete data type, there is no definition of these two classes in Widget.h ...
... For the raw pointer data member, its destuctor is not called when widget object is destructed.
While the
... Why doshared_ptrdata member, its destructor has been correctly called.shared_ptrdata member and raw data member have different behavior when the widget gets destructed?
By Blog Staff | Mar 17, 2015 04:53 PM | Tags: None
In case you missed the transcript a few days ago on Reddit:
Interview with Scott Meyers at Yandex
by Coder_CPP
From the interview:
... So I don’t think that in ten years everyone will be using managed languages. I think that C++ is going to remain an extremely important language for production use. Simply because if your goal is to get the maximum of performance out of the machine. If that is what is most important to you. I think that even these days the primary competitors are C and C++. Those are pretty much your choices. And C++ is just a much more expressive language. I have to say that I’m not a C programmer. I've never really been a C programmer. But I think that just a simple notion of destructors is so unbelievably powerful, that as a C programmer I would consider moving to C++ just so I could compile and get destructors. And, obviously, there is a lot more? to it than that...
By Jeremy Wright | Mar 16, 2015 06:53 AM | Tags: basics assembly
Leveraging the elegance of recursion:
C++ Tail Recursion Using 64-bit variables
by Giovanni Campo
From the article:
Main disadvantage of Recursion in imperative languages is the fact that not always is possible to have tail calls, which means an allocation of the function address (and relative variables, like structs for instance) onto the stack at each call. For deep recursive function this can cause a stack-overflow exception because of a limit to the maximum size of the stack, which is typically less than the size of RAM by quite a few orders of magnitude.
By Razvan Pascalau | Mar 16, 2015 05:22 AM | Tags: multithreading intermediate c++11 atomic
An interesting approach on how semaphores could be used in Modern C++ multithreaded programming:
Semaphores are Surprisingly Versatile
From the article:
In multithreaded programming, it’s important to make threads wait. They must wait for exclusive access to a resource. They must wait when there’s no work available. One way to make threads wait – and put them to sleep inside the kernel, so that they no longer take any CPU time – is with a semaphore.
I used to think semaphores were strange and old-fashioned. They were invented by Edsger Dijkstra back in the early 1960s, before anyone had done much multithreaded programming, or much programming at all, for that matter. I knew that a semaphore could keep track of available units of a resource, or function as a clunky kind of mutex, but that seemed to be about it.
My opinion changed once I realized that, using only semaphores and atomic operations, it’s possible to implement all of the following primitives:
- A Lightweight Mutex
- A Lightweight Auto-Reset Event Object
- A Lightweight Read-Write Lock
- Another Solution to the Dining Philosophers Problem
- A Lightweight Semaphore With Partial Spinning ...
By Meeting C++ | Mar 15, 2015 06:04 AM | Tags: qt intermediate c++11 basics
I spend some time on refactoring my database code in Qt:
Refactoring my Qt database code
by Jens Weller
From the article:
For two days I had the chance to clean up my code and do a little refactoring. One of the results is, that my database code now also uses variadic templates. For some time now, I use Qt as the UI and Database frontend of my applications...
By Mantosh Kumar | Mar 11, 2015 06:33 PM | Tags: None
This article talks about how modern C++ unique_ptr tool can be used to achieve exception safety.
Simplifying code and achieving exception safety using unique_ptr
by Marshall Clow
From the article:
The general pattern for this is:
unique_ptr<T> holder(new T{/* params */});
// set up some stuff that uses holder.get()
holder.release();
By Adrien Hamelin | Mar 11, 2015 01:54 PM | Tags: c++11 basics
Quick A: Wrong!
Recently on SO:
Return a local object rvalue reference,right or wrong?
I see once return a local object,the compiler will take the return value optimization.(RVO,NRVO).
The part of the Standard blessing the RVO goes on to say that if the conditions for the RVO are met, but compilers choose not to perform copy elision, the object being returned must be treated as an rvalue.
So we just write code like this:Widget makeWidget() { Widget w; … return w;//never use std::move(w); }I never see somebody write code like this:
Widget&& makeWidget() { Widget w; … return std::move(w); }I know that returns an lvalue reference of local object is always wrong. So, returns an rvalue reference of local object is also wrong?