Home » Blog » Tags » intermediate

intermediate

Using Parallel Without a Clue: 90x Performance Loss Instead of 8x Gain--"No Bugs" Hare

By Adrien Hamelin | Apr 3, 2018 02:01 PM | Tags: performance intermediate c++17

Be careful.

Using Parallel <algorithm> Without a Clue: 90x Performance Loss Instead of 8x Gain

by "No Bugs" Hare

From the article:

With C++17 supporting1 parallel versions of the std:: algorithms, there are quite a few people saying “hey, it became really simple to write parallel code!”.

Just as one example, [MSDN] wrote: “Only a few years ago, writing parallel code in C++ was a domain of the experts.” (implying that these days, to write parallel code, you don’t need to be an expert anymore).

Inquisitive hare:
“I made an experiment which demonstrates Big Fat Dangers(tm) of implying that parallelization can be made as simple as just adding a policy parameter to your std:: call.
I always had my extremely strong suspicions about this position being deadly wrong, but recently I made an experiment which demonstrates Big Fat Dangers(tm) of implying that parallelization can be made as simple as just adding a policy parameter to your std:: call...

String’s competing constructors--Andrzej Krzemieński

By Adrien Hamelin | Mar 14, 2018 12:13 PM | Tags: intermediate

A tough problem.

String’s competing constructors

by Andrzej Krzemieński

From the article:

Let’s start with the problem. I want to check whether a program received a text message that consists of four consecutive zeroes. Not '0', but the numeric zero. I will create a constant std::string representing the special sequence and compare the messages (also stored as std::strings) I receive...

A Foolish Consistency--Jon Kalb

By Adrien Hamelin | Mar 12, 2018 12:23 PM | Tags: intermediate community

A very interesting article that we should all read.

A Foolish Consistency

by Jon Kalb

From the article:

Ralph Waldo Emerson famously said, “A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.” I don’t think he was talking about code, but that statement couldn’t be more relevant to software engineers.

I’ve experienced a scenario like this a number of time in my career:

I’m sharing a new approach to writing code that offers some clear improvements to what we’ve been doing. Perhaps it is more readable, more efficient, or safer. But the response that I hear from colleagues is, “But we can’t do that here. We have <some large number> lines of code where we didn’t do it that way, so it wouldn’t be consistent.”

Quick Q: In C++ are static member functions inherited? If yes why ambiguity error does not arise?

By Adrien Hamelin | Feb 20, 2018 08:44 AM | Tags: intermediate

Quick A: Yes, and there are no ambiguity with static members.

Recently on SO:

In C++ are static member functions inherited? If yes why ambiguity error does not arise?

It's fine according to the lookup rules. You see, when you write member access (obj.display();), the member display is looked up not just in the scope of the class and its base classes. Base class sub-objects are taken into consideration as well.

If the member being looked up is not static, since base class sub-objects are part of the consideration, and you have two sub-objects of the same type, there's an ambiguity in the lookup.

But when they are static, there is no ambiguity. And to make it perfectly clear, the C++ standard even has a (non-normative) example when it describes class member lookup (in the section [class.member.lookup])