Olivier Langlois's blog

This is an editorial that I sent out to my LinkedIn C++ group members:
https://www.linkedin.com/groups/2035024/2035024-6089655206256144384

I'm discussing the retirement of of one of my favorite C++ books author: Scott Meyers
I am remembering the context when Scott Meyers books were hot and just out of the printers in the 90s. What other books of the same era that did pass as well the test of time.

I'm telling what he was meaning for me as a C++ developer and I am inviting people to discuss the impact and the causes of Mr. Meyers retirement.

Go read about it. It is very good!

I have posted on my website a small C++ program that I have been asked to write during an interview with Facebook at Fall 2009. One of their interview was related to graph theory and the problem was to find the the shortest distance between to nodes in a graph. The best algorithm to use to solve this problem is the breadth-first traversal algorithm.

You can look at the source code here at:
http://www.olivierlanglois.net/archive/graph_cpp.htm

and you can read more about the breadth-first traversal algorithm in Robert Sedgewick excellent book on algorithms.

I have submitted a patch for the bugzilla bug 3606:

http://bugzilla.dre.vanderbilt.edu/show_bug.cgi?id=3606

Fix function ACE::handle_ready + SOCK_Test modif to test the fix

The patch include the following:

1. Fix for the bug 3606 in function ACE::handle_ready
2. Modif of the unittest SOCK_Test to validate the fix
3. Removal of the define ACE_HAS_LIMITED_SELECT

There has been a very long thread about it last summer on the ACE mailing list and I was arguing that it was dangerous to use select() when poll() is available because if you pass an handle whose value that is higher than FD_SETSIZE (typically 1024), it causes a buffer overflow on the stack which is hard to debug.

At the end, a consensus emerged that ACE_HAS_LIMITED_SELECT should be removed. Actually if some platform would benefit from that, it would be safer to define ACE_HAS_UNLIMITED_SELECT instead.

4. Remove the duplicated code from ACE::handle_ready() at different locations to replace it with the appropriate ACE namespace function call.

For those who do not know what RAII is, you are probably using it without knowing it. One common use of this C++ idiom is to keep code manipulating mutexes exception safe. While I was writing a thread safe getter with a scoped lock like this:

A B::getA() const
{
  ScopedLock sc(m_lock);
  return m_a;
}

A doubt sparkled in my mind about whether or not the object copy performed by the return statement was protected by the lock. It must be since I have seen tons of functions using similar pattern but I could not explain why. I asked to another senior developer and he could not tell neither. By the way, this is what I love about the C++ language. You can have years of experience with it, there are millions of small details and any day, you may stumble on a mind boggling detail that force you to stop and think about it.

So if we come back to the original question, I guess that I could have checked what the standard document says about it but it is boring to do so. I prefer to do small scientific experiments to figure out myself what is the answer. So I wrote this small program:

#include <iostream>

class RAIIObj
{
  public:
  RAIIObj() { std::cout << "RAIIObj()\n"; }
  ~RAIIObj() { std::cout << "~RAIIObj()\n"; }
};

class A
{
  public:
  A() {}
  A( const A & ) { std::cout << "A( const A & )\n"; }
};

class B
{
  public:
  B() {}
  A getSyncAByVal() const;
  private:
  A m_a;
};

A B::getSyncAByVal() const
{
  RAIIObj scopedLock;
  return m_a;
}

int main( int argc, char *argv[] )
{
  B b;
  A retVal = b.getSyncAByVal();
  return 0;
}

and here is the output confirming that the getter code is correct:

RAIIObj()
A( const A & )
~RAIIObj()

Now that I know the answer, I have found another proof confirming that return statement object copies are performed before the local lock goes out of scope. If you were returning by value a local object, it absolutely must be copied before going out of scope.

I have received a comment for this blog post to the effect that using the keyword 'register' was useless and all compilers will ignore it. I do not agree on this. If you search on the Internet, you will find out that a lot of people speculate and have their opinion on the subject but the truth is that unless you are a compiler writer, you have no idea whether a given compiler is doing something with the 'register' keyword or not. Even if you know the answer for a specific compiler, you cannot generalize for the other compilers. Here is what the C++ standard in section 7.1.1:

A register specifier has the same semantics as an auto specifier together with a hint to the implementation that the object so declared will be heavily used. [Note: the hint can be ignored and in most implementations it will be ignored if the address of the object is taken. -end note]

It is true that today compiler optimizers are very clever and can do a decent job at managing a CPU registers alone but lets imagine how the algorithm managing the registers used by the compiler works. Registers are a scarce resource and the compiler must analyze each variable usage and assign to each variable a score based on various criterias. If the compiler needs to swap back a variable to memory to reuse a register, it would choose the variable having the lowest score. What happens if more than one variable have the same low score? In such situation, a compiler could use the 'register' keyword hint to take a decision.

Situations where the 'register' keyword could be used:

• temporary variables used in bitwise logical operations
• loop counters