const_cast operators

If you want an expression to being const, just use the const_cast operator. For example if a legacy function written in C requires of a const argument, just pass a non-const argument by using the const_cast operator:

extern "C" {
    void my_function(const char *p);
};

std::string s = std::string("hello world");
my_function(const_cast<char *>(s.c_str()));

static_cast operator

The static_cast operator performs the conversion unconditionally, without verifying data types at compile time. This makes this operator quite dangerous, so, you need to verify data types before you use variables in this kind of type casting.

if (typeid(*ptr_a) == typeid(MyClass)) {
    ptr_b = static_cast<MyClass>(ptr_a);
    ptr_b->applySomeMethod();
}

You can use the typeid C++ builtin to verify the data type. Also, you must consider that this operator is valid only if the conversion is explicit. Suppose Parent is a base class to Child and that Unrelated is an unrelated class. Then conversions from Child to Parent are valid, but a conversion from Child to Unrelated is disallowed:

Parent a;
Child b;
Parent *a_1 = static_cast<Parent *>(&b); // valid upcast
Unrelated *c_1 = static_cast<Unrelated *>(&b_1); // invalid, Unrelated

The best usage for the static_cast opertaor, are numerical conversions, so you can cast from int, double, float and others of similar type to another int, double, float and similar types, including enum types. Some compilers does this kind of conversion explicit, but more strict compilers usually throw the proper warning on this kinds of assignment, without the proper type casting operation (line 4).

float a;
int b;
a = static_cast<float>(b);
a = b;

dynamic_cast operator

The dynamic_cast operator, among other things, does a runtime check over types applied on the cast operation. As the above example of static_cast operator, dynamic cast does the typeid() checking. Then, if you have a pointer or reference to an object whose declared type is a base class, but you need to obtain a derived class pointer or reference, you should use dynamic_cast, since the dynamic_cast operator is another RTTI (Run-time type information) operator. The use of dynamic_cast derives into more overhead of your program, so you must use it with moderation.

if (ptr_b == static_cast<MyClass>(ptr_a);) {
    ptr_b->applySomeMethod();
}

If the type checking and conversion fails, the operator returns a non-null reference, else it will return a null reference (zero). Also, some compilers will advice on the proper usage of the dynamic_cast operator, the more strict ones, will throw an error.

Parent a;
Child b;
Parent *a_1 = dynamic_cast<Parent *>(&b); // valid upcast
Unrelated *c_1 = dynamic_cast<Unrelated *>(&b_1); // invalid, returns NULL

reinterpret_cast operator

This — possibly — is the most risky to use type casting operator. It completely transforms a pointer to very different types. For example:

some_struct_s {
    short a;
    short b;
};
typedef struct some_struct_s some_struct_t;
some_struct_t *s;
unsigned long v = 0xd34db33f;
s = reinterpret_cast<some_struct_t *>(&v);
std::cout << s->a; // display first 2 bytes of value

As the example above, the pointer was completely transformed to different kind, with the dangerous assumption that the platform has a byte alignment that make possible to access the first to bytes of some address using this kind of operation. This cast is not portable, some compilers should throw some error about it.

The fact is that the reinterpret_cast operator overrides the initial declaration of the given variable, and makes possible to that variable to being reinterpreted as a different one. The usage of the reinterpret_cast must be done careful, for example for derived to base class reinterpretation.

BaseClass a;
DerivedClass *c = reinterpret_cast<DerivedClass *>(&a);

Since many of this kind of conversions are not possible in all compilers, you must try to setup your compiler to the most pedantic flags that it can allow. For example on GCC, you should use -Wall -Wextra -Wshadow -pedantic -std=c++98 as compiler flags. It will keep your code portable and will allow you to create more standarized programs.

Here is a full compiling example of the core ideas in this post:

class A {
public:
	A();
	~A();
};

class B : public A {
public:
	B();
	~B();
};

A::A() {
}

A::~A() {
}

B::B() : A() {
}

B::~B() {
}

int
main(int argc, char **argv)
{

	A *ptr_a = new A();
	B *ptr_b = new B();

	A *a_1 = static_cast<A *>(ptr_b);
	B *b_1 = static_cast<B *>(ptr_a);

	A *a_2 = dynamic_cast<A *>(ptr_b);

	A *a_3 = reinterpret_cast<A *>(ptr_b);
	B *b_3 = reinterpret_cast<B *>(ptr_a);

	const A *a_4 = const_cast<A *>(ptr_a);
	const B *b_4 = const_cast<B *>(ptr_b);

	delete ptr_a;
	delete ptr_b;

	return 0;

}

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

A template in C++ works like a Java Generic, but it uses different semantics. For example we can use a template to overload a previously declared operator — in Java we can not overload operators — and change its behavior. We can also define templates for functions, classes and methods. How do we play with them, it’s just a design issue. They have a similar behavior to abstract methods, but with more powerful semantics, allowing us to work directly with named types.

/* example template function */
#include <iostream>
#include <vector>

template <class T>
const T& smaller_v(const T& a, const T& b)
{
    if (a.size() > b.size()) {
        return b;
    } else {
        return a;
    }
}

int main(void)
{
    // we play around with three vectors
    std::vector<int> a = std::vector<int>();
    std::vector<int> b = std::vector<int>();
    std::vector<int> c;
    // we put two elements in a vector
    a.push_back(1);
    a.push_back(2);
    // we put three elements in b vector
    b.push_back(3);
    b.push_back(4);
    b.push_back(5);
    // so we compare each vector size
    c = smaller_v<std::vector<int> >(a, b);
    // after we get the smaller vector
    // through our template, we output its size
    std::cout << c.size() << std::endl;
    return 0;
}

We have above an example of template function. It plays around the same namespace and linkage of main(), so we don’t need to export it. But what happens to foreign templates, where we need to import them into the working namespace, at the time they are declared in external linkage. We use the export keyword. How were affected the template declarations before they were removed from the C++0x standard?

A template-declaration may be preceded by the export keyword. Such a template is said to be exported. Declaring exported a class template is equivalent to declaring exported all of its non-inline member functions, static data members, member classes, member class templates, and non-inline member function templates.

Then, templates were exported if we use the export keyword on them, extending the export to its members and the template kind.

If a template is exported in one translation unit, it shall be exported in all translation units in which it appears; no diagnostic is required. A declaration of an exported template shall appear with the export keyword before any point of instantiation (14.7.4.1) of that template in that translation unit. In addition, the first declaration of an exported template containing the export keyword shall not follow the definition of that template. The export keyword shall not be used in a friend declaration.

The template shall be exported in all translation units of its linkage, regarding its declared namespace, preventing the use of any instantiation related usage of the export keyword including the implicit restriction on exporting friends — but explicitly exposed in the working draft. Also the standard refers to templates contained in unnamed namespaces to not be exported outside of its linkage. You may ask what is a translation unit in C++?

The text of the program is kept in units called source files in this International Standard. A source file together with all the headers (17.6.1.2) and source files included (16.2) via the preprocessing directive #include, less any source lines skipped by any of the conditional inclusion (16.1) preprocessing directives, is called a translation unit. [ Note: a C++ program need not all be translated at the same time. — end note ]

conclusion

The explicit export of a template, by using the exported templates feature, is restricted on the implementation definition, so the deprecation of the explicit export and any implementation must regard at least the deprecated standard recommendation. So, it lefts to implementation specific or undefined behavior for exported templates in future standards, since they are thinking to remove it completely. In some way I personally feel that they are decapitating the original design of C++0x, which was very powerful at his original specification. Such as the removed specification for Concepts for C++ and nice formal designs.

Copyright © 2009 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2009. | Permalink | No comment
Post tags:

I know a little about functional programming. Certainly, It have interesting features, such as Lambda Expressions and Closures. It seems that C++0x, the new C++ standard will support both of them. Closures, known as nested functions and Lambda Expressions, known as anonymous functions are neat tools on developing fast code with small pieces of them. Lambda expressions can be used as arguments. They allow certain kind of abstractions, allowing the implementation of computational structures like Monads and Monoids.

Lambda expressions are seen in functional languages like Lisp. Also multiparadigm languages, like Python and Ruby. We can review both of them from its origins, such as Lisp implementations.

Closures

From the Wikipedia article on closures:

In computer science, a closure is a first-class function with free variables that are bound by the lexical environment. Such a function is said to be “closed over” its free variables. A closure is defined within the scope of its free variables, and the extent of those variables is at least as long as the lifetime of the closure itself. The explicit use of closures are associated with functional programming and with languages such as ML and Lisp. Closures are used to implement continuation passing style, and in this manner, hide state. Constructs such as objects and control structures can thus be implemented with closures.

A closure is bound to nested functions. The scope of a nested function allows the reuse of variables which are local to the container function. In this case, a closure has the next form — if we review from the Lisp perspective:

;;; we have this file as test.l
(defun test-container (x)
  (defun test-closure (y)
    (format t "~10A" y))
  (test-closure x))

(test-container "hola")

From the Lisp interpreter:

>(load "test.l")

Loading test.l
hola
Finished loading test.l
T

If you look at the code, you have the test-closure nested function, or as it’s called closure. The C++0x standard allows the use of closures in the code, you can define nested functions.

### sample Python closure...
def test_container(x):
    def test_closure(y):
        print y
    test_closure(x)

test_container("hola")

The C++0x standard and the current working draft do not allow the direct declaration of nested functions or closures, but as is read in the current working draft: “The type of the closure object is a class with a unique name, call it F, considered to be defined at the point where the lambda expression occurs” [C++0x Working Draft, Sec. 5.1.2, P7]. Under this definition, and by using lambda expressions, we can define closures as follows:

#include <iostream>
#include <string>

class TestClass {
public:
    TestClass();
    int csum(int a, int b);
};

int
TestClass::csum(int a, int b) {
    // do you know what clos is? xD
    auto clos = [](int x, int y) -> int { int z = x * y; return y + z; };
    return clos(a, b);
}

int
main (int argc, char **argv) {
    TestClass *p = new TestClass();
    std::cout << p->csum(10, 13) << std::endl;
    return 0;
}

We have the magic keyword auto to define the anonymous class or anonymous closure object, then we can use the closure in our code. The closure itself is a Lambda Expression. So, let’s review what is a Lambda Expression.

Lambda Expressions

Lisp supports Lambda Expressions from its origins. A common example is the list and sequence processing statements where lambda expressions pass each element on sequences and lists to the anonymous functions. Let’s see an example.

The Wikipedia example on Lisp Lambda Expressions only shows an anonymous function:

(lambda (x) (* x x))

If I run GCL or SBCL, I can do a little bit more applied example:

>(defvar test '("piwidi" "yopuz" "gon"))
TEST
>(defvar test2 (map 'list #'(lambda (x) (concatenate 'string x " cheat chat")) test))
TEST2
>test2
("piwidi cheat chat" "yopuz cheat chat" "gon cheat chat")

The example above uses an anonymous function to concatenate each string on the test list with the suffix string ” cheat chat”, and uses the map call output to create the test2 variable. With a behavior pretty similar to what a monad does, since we can use anonymous functions as variables, in example as list members:

>(defvar test3 #'(lambda (x) (concatenate 'string x " cheat chat")))
TEST3
>test3
(LAMBDA-CLOSURE () () () (X) (CONCATENATE 'STRING X " cheat chat"))
;;; And then to use test3 as part of a list:
>(defvar test3 #'(lambda (x) (concatenate 'string x " cheat chat")))
TEST3
>(defvar test4 '(("gon" test3) ("yopuz" test3) ("piwidi" test3)))
TEST4
>test3
(LAMBDA-CLOSURE () () () (X) (CONCATENATE 'STRING X " cheat chat"))
>test4
(("gon" TEST3) ("yopuz" TEST3) ("piwidi" TEST3))

Other languages are also implementing lambda expressions. Python have the lambda keyword to allow the declaration of anonymous functions and there are interesting articles on Functional Programming under Python. And surely you can be impressed by viewing that many languages allow the use of code as argument, directly as functional paradigm does or indirectly as the imperative paradigm does by using callbacks.

The C++0x will allow the use of Lambda Expressions. If we look at the Wikipedia examples, the next statement:

[](int x, int y) -> int { int z = x + y; return z + y; }

Is a lambda expression. The first part [](int x, int y) -> int { have a semantic equivalence with #’(lambda (x, y), where x and y are both arguments to the anonymous function. Since Lisp is not strict with data typing, the C++0x expression allows to define the return type of the anonymous function with the statement -> int. The anonymous function body is { int z = x + y; return z + y; }, that is semantically equivalent to the let or progn body of the Lisp expression.

We considered the possibility of supporting polymorphic lambda functions, whose parameter types need not be specified. Such a lambda function would implicitly be an unconstrained template, accepting any argument types; the body would be checked against the particular argument types used when the call to the lambda function is instantiated. Such functions would not create significant difficulties for the proposed translation model. A lambda expression whose parameter types were not specified would simply be translated to a function object whose function call operator is a template. Such lambda functions would, however, clash with the modular type-checking which we attempt to introduce to C++ via concepts [SD05, GSW+ 05].
“Lambda expressions and closures for C++”

This is an interesting paragraph. Since anonymous functions are not templates, they will allow polymorphism with anonymous typing of their arguments, whereas those arguments will have typing constraints in the function implementation body and checked in run-time and driven by the use of standard C++ templates: A lambda expression whose parameter types were not specified would simply be translated to a function object whose function call operator is a template. Well, this paper is a quiet old, since C++0x Concepts were recently removed from the standard by the C++0x working committee. The proposal does not refers to implementation issues, but leads to implementation strategies, like the expensive compile time performance which requires those lambda expressions and closures, since the leading strategy sets both of them become as a new local class, meaning that those classes must be instantiated to allow the use of their behavior.

Now, why are closure objects important to the C++0x Lambda Expressions:

The evaluation of a lambda-expression results in a closure object, which is an rvalue. Invoking the closure object executes the statements specified in the lambda-expression’s compound-statement. Each lambda expression has a unique type. Except as specified below, the type of the closure object is unspecified. [Note: A closure object behaves as a function object (20.7) whose function call operator, constructors, and data members are defined by the lambda-expression and its context. — end note]

Then, closure objects are the core type of lambda expressions, since C++0x supports function objects, and C++0x comes with the <functional> header, to allow you to work with function objects and their declaring types and core operators:

Function objects are objects with an operator() defined. In the places where one would expect to pass a pointer to a function to an algorithmic template (clause 25), the interface is specified to accept an object with an operator() defined. This not only makes algorithmic templates work with pointers to functions, but also enables them to work with arbitrary function objects.

The interesting declaration on the <functional> header for closures is the function class: template<FunctionType> class function;, which keeps the class undefined to allow your custom definition and type hierarchy.

Take a look on the current working draft of the C++0x, it comes interesting

Copyright © 2009 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2009. | Permalink | No comment
Post tags:

In other posts I’ve presented you some ways to detect memory leaks, conceptually rather than practically, but enough to understand them and solve those programming issues. Normally, valgrind messages. There are some posts about valgrind and well documented user guides, such as the guide written by Alex Ott. This article is about on how to interpret valgrind messages while you are using it as memory allocation debugger.

First of all, I want to share a small script with the flags that I’m using with valgrind. Here is a small script which runs valgrind on the given program and creates a log with the valgrind output. You can find the explanation on the flags in the Alex’s article and the valgrind documentation.

#!/bin/bash

if test "$#" "<" "1"; then
    echo "$0: too few arguments"
    exit 1
fi

VLG=`which valgrind`
VLG_LOG=`basename $PWD`
VLG_LOG="log.$VLG_LOG"
VLG_OPTS="$VLG_OPTS --verbose"
VLG_OPTS="$VLG_OPTS --trace-children=yes"
VLG_OPTS="$VLG_OPTS --track-fds=yes"
VLG_OPTS="$VLG_OPTS --run-libc-freeres=yes"
VLG_OPTS="$VLG_OPTS --logfile-fd=1"
VLG_OPTS="$VLG_OPTS --num-callers=100"
VLG_OPTS="$VLG_OPTS --error-limit=no"
VLG_OPTS="$VLG_OPTS --show-below-main=yes"
VLG_OPTS="$VLG_OPTS --pointercheck=yes"
VLG_OPTS="$VLG_OPTS --demangle=yes"
VLG_OPTS="$VLG_OPTS --leak-check=yes"

export VLG VLG_LOG VALGRIND_OPTS

if test -r "$VLG_LOG"; then
        echo "$0: removing $VLG_LOG"
        rm -f -v "$VLG_LOG"
fi
$VLG $VLG_OPTS $* 2>&1 | tee "$VLG_LOG"

This shell script the call to valgrind — IMO — with the best options that some programs can have to debug them. This command line will generate a large trace on your command and as I’ve posted in a previous topic, valgrind replaces the allocation system calls with his own group of system calls, wrapping the original ones, just track those calls.

invalid read of size nnnn

Your pointer arithmetics are bad. Yes, this message means that the program is accessing an invalid address by reading nnnn bytes from it. The code bellow — that seems to be ridiculous, but is not different that the error that you have in your code — would throw this message.

#include <stdio.h>
int
main (int c, char **argv) {
    char test[] = "hola mundo!";
    printf ("%s\n", (char *)(test + 20));
    return 0;
}

The message obtained is as follows.

==22111== 1 errors in context 1 of 1:
==22111== Invalid read of size 1
==22111==    by 0x3010A4E0: vfprintf (in /lib/libc.so.6)
==22111==    by 0x300F6B2F: printf (in /lib/libc.so.6)
==22111==    by 0x8048571: main (test-invalid-read.c:11)

As you, see in the backtrace, the part where it reaches the invalid address is inside the printf(3) function, but the previous step is on the line 11 of the file test-invalid-read.c.

use of uninitialised value of size nnnn

By default, there is no automatic variable initialization for certain kinds of variables, all depends on the compiler implementation and the C99 standard reveals it as undefined behavior. Since that condition, is required that you initialize all your variables to ensure code portability.

#include <string.h>
#include <stdio.h>

int
main (int c, char **argv) {
    char *tst;
    printf ("%s\n", tst);
    return 0;
}

The code above will produce the next error messages on valgrind.

==22309== 1 errors in context 1 of 6:
==22309== Use of uninitialised value of size 4
==22309==    at 0x30039DC0: memcpy (in /usr/local/lib/valgrind/vgpreload_memcheck.so)
==22309==    by 0x3010A4E0: vfprintf (in /lib/libc.so.6)
==22309==    by 0x300F6B2F: printf (in /lib/libc.so.6)
==22309==    by 0x804854B: main (test-invalid-read.c:8)
==22309==
==22309== 1 errors in context 2 of 6:
==22309== Conditional jump or move depends on uninitialised value(s)
==22309==    at 0x30039DAF: memcpy (in /usr/local/lib/valgrind/vgpreload_memcheck.so)
==22309==    by 0x3010A4E0: vfprintf (in /lib/libc.so.6)
==22309==    by 0x300F6B2F: printf (in /lib/libc.so.6)
==22309==    by 0x804854B: main (test-invalid-read.c:8)

Both errors are pointing to the same programming error. The variable tst was not initialized, and then you operate — and what makes one of the most ugliest errors on programming — using it as address reference. Also, by default gcc has automatic initialization of those pointers to null, and then you get "Null References: The Billion Dollar Mistake" pointed by Tony Hoare. Remember that variable initialization is an undefined behavior according to the current C standard. Reference verification and initialization is an important task, recently was announced a new version of Eiffel — a pure object oriented paradigm based language — that is avoiding null deferencing.

process terminating with default action of signal nn (SIGNAME): dumping core

Here the valgrind execution stops. Why? the program receives a signal and is terminated by the operating system. Take a look on the signal(3) manual page for more details.

The operating system generates a core file, from where you can get the proper information about the crashing instruction. All depends on the signal that the program was catching, a SIGBUS or bus error, means that you are writing bytes to wrong address. The code bellow shows that bug.

#include <string.h>
#include <stdio.h>

int
main (int c, char **argv) {
    char tst[10];
    const char hl[] = "hola mundo!";
    memset (tst, 0, sizeof(tst));
    memcpy (tst, hl, strlen(hl) + 1);
    return 0;
}

The memset(3) instruction sets the memory buffer pointed by tst to zero and it is OK. The size of tst is known, and since the operator sizeof is a compile time operator, there is no problem. If tst is a pointer instead of an array of bytes — I mean "char *tst" declaration — we can’t use sizeof and using it is like to get sizeof(NULL) — have noticed that every pointer has the same size?. If we extract the backtrace from the core file, we can reach the line of code which have the error. Depending on the signal, we can reach different kinds of errors, you must read your system documentation to know to what specific error refers it.

other valgrind errors

Depending on your operating system implementation, other errors can occur, if there is no proper memory protection. For example, you can have a conditional jump error and then an invalid write error. If you mix both of them and the system is not capable to protect itself of those errors, valgrind will report them. In other case, the proper signal will be thrown to your process and possibly a core file will be generated, then you must use the traditional debugging techniques to reach the bug.

conclusion

You must consider learning assembly language and computer architecture if you want to work at this level. Nowdays, by C programming most people understand a low level programming. By the years that I was studying, C programming was just another high level language, and I got the basics of programming on it, but just before I was introduced to it by reading some books — about 5 to 7 books on C programming — I was capable to build stronger programs.

Everything is important on C programming, from the basic techniques to complex data structures and algorithms. Most operating systems and user interfaces are made with C as the main programming language and also with C++. The applications of this language are not only applied to low level tasks. There are many programs implementing their algorithms in C and assembler to reach optimal performance, just look at ATLAS, BLAS and some other interesting projects.

Copyright © 2009 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2009. | Permalink | No comment
Post tags: