Tag Archives: gotcha

Function Chaining in C++

Function chaining is a construct in  C++. It constructs a chain of function calls in one statement. Return value of the previous function call is used to call the next function and hence a chain of function calls is created. Following is an example of it:

obj.func1().func2().func3();

obj.fun1() is an expression which evaluates to the return-value of func1(). On this returned-value func2() is called which again evaluates to its return value. Similarly func3().

Function chaining is good as well as bad. It may make the code look compact and nice but excessive use may end up with readability and maintenance issues. The code may be difficult to debug also. One can’t see the intermediate return values of the function calls.

Apart for the readability and debugging issues, it can also result into a serious memory issue. Lately, I faced it while converting from a QString to a char* C string. Here is the code:

// function QString::toLocal8Bit() returns QByteArray
// QByteArray::data() returns pointer to internal data

QString str("manjeet");
const char *c_str = str.toLocal8Bit().data();
// c_str is now a dangling pointer referring to an invalid memory

In the above code c_str points to an invalid memory.

It happens because the function chaining involves unnamed temporary objects. These unnamed temporary objects are returned by the function calls. And these are again used to call the next function call. But in this case the last temporary object is not stored and is deleted after the statement is complete.

This code can be fixed by avoiding the function chaining and storing the intermediate object.

QString str("manjeet");
QByteArray ba = str.toLocal8Bit();
const char *c_str = ba.data();

Here the problem is fixed as the byte array is now being stored the ba variable.

[1] http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr382.htm

[2] http://stackoverflow.com/questions/154864/function-chaining-how-many-is-too-many

Use QRegExp Carefully

Lately, I found a silly mistake which I have repeated at a couple of places in my Qt code. I thought of noting it down.

Example Case

I have a QStringList (list) and I want to find the index of a string (str) in it.

// list     -  QStringList
// str      -  QString

int index = list.indexOf(QRegExp(str));
// this function accepts QRegExp only, though
// in the new releases of Qt an overload
// accepting QString is also available

Nothing wrong with this, it has been working great for me and I have used it at many places. But, this works as long as str doesn’t contain any RegExp special characters. If the str contains special characters, its meaning changes. For instance dealing with filePaths, filepaths may have special characters in it like the character +.

The meaning of QRegExp(str) changes if str has the character +:

  • str
    /home/dahiya/test+examples/newFile
  • QRegExp(str)
    /home/dahiya/testexamples/newFile
    /home/dahiya/testtexamples/newFile
    /home/dahiya/testttexamples/newFile
    /home/dahiya/testtttexamples/newFile
    /home/dahiya/testttttexamples/newFile

It will never match the original string (str). The index returned will be not be the valid one.

Solution

Escape all the RegExp special characters. On escaping the special characters, they will be treated normal and the code will behave correctly. Qt provides a utility function also.

QString QRegExp::escape(const QString&)

This function returns the escaped string (str).

  • str
    /home/dahiya/test+examples/newFile
  • escape(str)
    /home/dahiya/test\\+examples/newFile

So one can write the correct code like:

int index = list.indexOf(QRegExp(QRegExp::escape(str)));

Conclusion

In future, use QRegExp carefully if you just want to match a string.

C++ Surprise: switch-case declaration-without-initialization

I have been programming in C++ for a long time and it keeps surprising me. C++ Programming Language is full of surprises. Lately, I found an interesting one.

The Surprise!

I never declare new variables/objects in the case statements. To me, it is not allowed. If I ever need new variables/objects in a case statement, I use braces. Braces define a valid scope for the new variables, the new variables are not valid outside the braces. Without using the braces, variables declared in a case statement are visible in the succeeding cases as well. And these declarations can be skipped if the switch jumps to those cases.

The surprise is that declaration is possible! But only for a very specific case, the declaration without initialization. int var; is such example.

The declaration without initialization is possible only for POD types (plain old data, collection of basic types, C structs based on basic types, pointers, enums etc.). Therefore, to be precise, the declaration in a case statement is possible only for POD types and without initialization.

Declaration without initialization [Allowed, Surprise!]

  • int count;
  • float length;
  • int* ptr;

Declaration with initialization [Not allowed as expected]

  • int count = 20;
  • float length = 6.7;
  • int* ptr = 0;
  • std::string str;       // involves call to default constructor (initialization)
  • std::string str2(“manjeet”);

Example

In the following code. I have marked the statements Valid/Invalid as per g++ and MSVC. Let us look at the unexpected and expected statements.

std:string str1("test");

switch(i)
{
case 0:
 int var1;                  // VALID

 int var2 = 22;             // INVALID

 int var2;                  // VALID
 var2 = 22;                 // VALID

 str1 = "test";             // VALID, defined before switch statement
 std::string str2("test");  // INVALID
 break;
case 1:
 break;
case 2:
 break;
default:
 break;
}

Surprise:

  • Line#6: Valid, int var1;
  • Line#8: Invalid, int var2 = 22; if Line#6 is valid then this should also be valid.

Expected:

  • Line#11 & 13: Valid, usual assignments.
  • Line#14: Invalid, declaration of an object. It is not allowed, very much expected.

Explanation

As per the C++ Standard ISO/IEC-14882-2003 section 6.7.3

It is possible to transfer into a block, but not in a way that bypasses declarations with initialization. A program that jumps from a point where a local variable with automatic storage duration is not in scope to a point where it is in scope is ill-formed unless the variable has POD type (3.9) and is declared without an initializer (8.5).

Therefore according to the above rule, jumping past a declaration with initialization is not allowed. And the only exception to this rule could be a declaration of a POD types. Because POD types can be declared without initialization.

int a;  // declaration without initialization

And for non-POD types declaration-without-initialition is never possible. The object can’t be declared without initializing because the constructor will always be called.

std::string str;    // declaration that includes initialization, constructor is called

Rationale Behind the Rule

The question pops up to the mind.

Why is jumping past a declaration-without-initialization allowed?

I don’t have the answer. But it might have something to do with followings:

  • All the initializations of the variables and objects are done at the compile time. Whereas assignments during the runtime of the program.
  • If initialization doesn’t takes place the destructor should not be called. But the destruction always takes place when the object goes out of scope. Destruction without construction doesn’t sound good. Therefore the execution should not jump an initialization.

Conclusion

  • Declaration of POD types without initialization is allowed in a case statement.
  • Declaration of non-Pod types can only be done in the braces only.
  • In a switch-case, all the case statements are in the same scope.
  • The switch-case is nothing but a collection of goto and labels.
  • goto-label jump is not allowed if jump skips declaration with initialization.
  • Good practice would be to always use braces after case statements if declarations are involved.

References

  • C++ Standard ISO/IEC-14882-2003
  • http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=171
  • http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/ISOcxx/doc/POD.html
  • http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.7