Assert Statique

L’utilisation d’un assert statique peut être utile dans le cas ou une condition doit être testée au moment de la compilation. Par exemple la taille d’un tableau. Le principe est d’utiliser une macro pour définir une expression. Si le test est valide alors l’expression générée l’est aussi, sinon elle résulte en une erreur de compilation.

#define STATIC_ASSERT(cond)    typedef int ERROR_##__LINE__[(cond) ? 1 : -1]

Ici, on utilise typedef pour définir un type tableau. Si la condition est valide alors la taille du tableau est positive. Sinon elle est négative ce qui résulte en une erreur de compilation.

Exemple d’utilisation :

STATIC_ASSERT(sizeof(object1) == sizeof(object2));

Protéger les classes contre la copie ou l’assignation en C++

Pour protéger les classes contre la copie, il suffit de déclarer le constructeurs de copie en private. Une macro peut être définie car le principe est le même pour toutes les classes.

#define DECLARE_NO_COPY_CLASS(classname)  \
    private:                              \
        classname(const classname&);
#endif

De même pour les protéger contre l’assignation, on peut déclarer la surcharge de l’opérateur « = » comme étant private.

#define DECLARE_NO_ASSIGN_CLASS(classname)  \
    private:                                \
        classname& operator=(const classname&);
#endif

Mutex Locker

Préambule

Le mutex locker fait partie du concept de RAII. Cette acronyme vient de l’anglais Resource Acquisition Is Initialization. C’est une technique de programmation qui permet de s’assurer que la ressource acquise sera bien libérée à la fin de la vie d’un objet.

Principe

Appliqué au mutex, ce principe consiste à bloquer un mutex lors de la création d’un objet et de le libérer lors de sa destruction. On peut imaginer la création d’un objet spécifique : le MutexLocker.  Il faudrait qu’il puisse prendre un mutex lors de sa création et le libérer lors de sa destruction. Son constructeur va donc prendre le mutex et son destructeur le détruire.

class MutexLocker {
    public :
        MutexLocker(Mutex& mutex): m_mutex(mutex) {
            m_mutex.Lock();
        }
        virtual ~MutexLocker(){
            m_mutex.Unlock();
        }

    private:
        Mutex& m_mutex;
};

Son utilisation procède comme suit :

{
    Mutex mutex;

    MutexLocker locker(mutex);

    /* Maintenant le mutex est pris. Le code critique peut être exécuté. */
}

Conclusion

Son utilisation est justifié quand des exceptions peuvent arriver à tout moment. A ce moment, le mutex est assuré d’être libéré à la fin de la portée du code lorsque le locker est détruit. D’une manière générale, il est bon de l’utiliser tout le temps pour éviter de tomber dans des cas d’erreur difficiles à détecter.

Singleton

Présentation

Le singleton est un patron de conception (design pattern) dont le but est de restreindre l’instanciation  d’une classe à un nombre défini d’objets. Il est utilisé lorsque l’on a besoin que d’un seul objet pour coordonner des actions dans un système. Par exemple, le singleton va être utilisé comme gestionnaire de fenêtre, gestionnaire de systèmes de fichiers ou d’imprimantes. Le singleton va être disponible de manière globale dans un package et sera utilisé comme étant un point d’accès.

Le singleton est une classe qui va s’instancier elle-même. Ses constructeurs seront donc définis comme étant privés. Elle met à disposition une méthode statique pour récupérer son instance. Cette méthode vérifie qu’une seule instance existe ou en crée une si elle n’existe pas encore.

Une attention particulière sera donnée dans les environnements multi-threadés. Si deux thread essaient d’accéder à l’objet, un seul devra l’instancier tandis que le deuxième obtiendra une référence sur l’objet nouvellement créé.

Implémentation en C++

template <typename T> class Singleton
{
    public:
        static T* Get() {
            if(null == m_intance) {
                m_instance = new T;
            }
            return m_instance;
        }

    protected:
        Singleton(){};
        virtual ~Singleton(){};

    private :
        static T* m_instance;
};

Les classes peuvent ensuite hériter de Singleton. Elles seront instanciées par la méthode héritée Get().

class Eur : public Singleton<Eur>
{
    friend class Singleton<Eur>;
};

func(){
    Eur* obj = Eur::Get();
};

Multi-Threading

Dans un environnement multi-tâche,  il est important de protéger le code d’instanciation pour éviter d’avoir plusieurs références vers le Singleton lorsque celui-ci est appelé depuis plusieurs threads différents.

La solution peut être comme suit :

template <typename T> class Singleton
{
    public:
        static T* Get() {
            m_mutex.Lock();
            if(null == m_intance) {
                m_instance = new T;
            }
            m_mutex.unlock();
            return m_instance;
        }

    protected:
        Singleton(){};
        virtual ~Singleton(){};

    private :
        static T* m_instance;
        static Mutex m_mutex;
};

Ici Mutex est une classe qui initialise le mutex dans son constructeur par défaut et présente les méthodes Lock() et Unlock() pour locker et délocker le mutex.

Le problème de cette solution est que le mutex est locké à chaque appel de Get(). Ceci peut être coûteux en nombre d’instruction en comparaison avec un simple test pour savoir si m_instance existe. D’autant plus que le Singleton n’est instancié qu’une seule fois pendant la durée de vie du programme.

Une proposition d’optimisation serait de tester une première fois si l’instance existe sans locker le mutex puis de tester une seconde fois sous protection dans le cas ou l’instance n’existe pas. Ceci ajoute un test dans le cas ou l’instance n’existe pas, mais enlève tout appel au mutex dans le cas ou elle existe.

template <typename T> class Singleton
{
    public:
        static T* Get() {
            if(null == instance)
            {
                m_mutex.Lock();
                if(null == m_intance) {
                    m_instance = new T;
                }
                m_mutex.unlock();
            }
            return m_instance;
        }

    protected:
        Singleton(){};
        virtual ~Singleton(){};

    private :
        static T* m_instance;
        static Mutex m_mutex;
};

Cette solution est valide car les accès concurrents en lecture ne sont pas pénalisant. En effet, le Singleton est le même pour tous les threads.

The TUN/TAP interface on Linux

Recently, I had to work with the tun interface on Linux. There is not a lot of documentation on this subject so here is a little presentation.

TUN/TAP is like a physical Ethernet port but for user space program. Instead of receiving data from a physical device, it receives it from a user space program and instead of sending data through a wire, sends it to a user space program.

This interface corresponds to a file situated in /dev/net/tun or /dev/tun. When a program opens this file, an interface is created. The name of this interface can be set by the program or automatically set by the tun driver as tunXX, tapXX or bnepXX where XX can be 0, 1, 2… This interface can be manipulated by ifconfig such as eth0.

More information can be found here

Now, i describe in the following some steps to open and use a tun interface.

Opening the file :

int tap = open(tunname[i], O_RDWR);
if (tap < 0) {
fprintf(stderr, "TAP: failed to open TUN interface\n");
return -1;
}

Configuring the interface :


struct ifreq ifr;

memset(&ifr, 0, sizeof(ifr));

/* Flags: IFF_TUN - TUN device (no Ethernet headers)
* IFF_TAP - TAP device
*
* IFF_NO_PI - Do not provide packet information
*/
ifr.ifr_flags = IFF_TAP|IFF_NO_PI;
strcpy(ifr.ifr_name, "bnep");

if( ioctl(tap, TUNSETIFF, (void *) &ifr) < 0 ) {
fprintf(stderr, "TAP: failed to set BNEP name\n");
close(tap);
tap = -1;
return -1;
}

Then we are setting the mac address :

struct sockaddr sap;
sap.sa_family = ARPHRD_ETHER;
((char*)sap.sa_data)[0]=0x00;
((char*)sap.sa_data)[1]=0x11;
((char*)sap.sa_data)[2]=0x22;
((char*)sap.sa_data)[3]=0x33;
((char*)sap.sa_data)[4]=0x44;
((char*)sap.sa_data)[5]=0x55;

memcpy((char *) &ifr.ifr_hwaddr, (char *) &sap, sizeof(struct sockaddr));

if (ioctl(tap, SIOCSIFHWADDR, &ifr) < 0) { fprintf(stderr, "TAP: failed to set MAC address\n"); }

The interface is configured. We can now start to listen :

uint8_t* buffer = (uint8_t *)malloc(1500); //size of an ethernet frame
assert(buffer != NULL);

while (tap >=0) {
struct timeval tv={ 1, 0};
fd_set rfd;
FD_ZERO(&rfd);
FD_SET(tap, &rfd);

// We are waiting for data coming to the file
if (select(tap+1, &rfd, NULL, NULL, &tv)<0) { fprintf(stderr, "bnep_sender: select failed\n"); break; } // If data to be read if (FD_ISSET(tap, &rfd)) { n = read(tap, buffer, BNEP_BUFFER_SIZE); if (n < 0 && errno != EINTR) { printf("\nERROR\n\n, thread killed \n\n"); break; } if (n==0){ printf("We read nothing\n"); } if (n > 0 ) {
//do some stuff with the data
}
}
}
if (buffer != NULL) free(buffer);
if (tap >= 0) close(tap);

return 0;

On the same way, we can write data to the file using 'write'. Don't forget the Ethernet header !

How to disable warnings

When we are using a third party library in software development, we may encounter a lot of warning during the compilation. It is possible to disable warnings using compiler flags. This will disable warnings for all codes, it is thus useless when we want the higher warning level in our code.

I have encountered some « unused variable » warning in adding source code in my project. I have disabled these warnings in adding this line just after the variable declaration : __attribute__ ((unused))

I have found the documentation here.

How to use diff in svn folder

The diff program is used to find differences between files. To know more about diff : http://www.google.com/search?hl=fr&q=man+diff

But, if we use diff in svn folder, it can find a difference between files inside .svn. Here is the line of code I’m using :
cd /where/is/my/svn/folder
diff -r -x .svn /folder/source /folder/dest > file

With these parameters, diff doesn’t look into .svn folder.

Temperature Information in Ubuntu Linux

One day I had some troubles with my computer. Sometimes it crashes both spontaneously and sporadically. I thought it was because the CPU’s temperature was to hight. So here is a command line to know more about the CPU’s temperature on linux (I’m using Ubuntu 9.10)

cat /proc/acpi/thermal_zone/*/*

But this line shows me that the temperature of my CPU was completely normal. I think that my computer has some power problems, but impossible to discover the cause of crashes. Fortunately, it seems to work now…

System pause in linux script

Sometimes, you need to make a pause in your Linux script. For instance, you want to see the result of your script when you’re executing it from the window system. In my case, when I want to open an executable script file from gnome, it asks me if I want to open it in a new bash. If I say yes, it executes it and close the window. I don’t have the time to see any output, so I’m writing this at the end :
read a

The system wait for a keyboard input. The input is finish after pressing the « enter » key. Pressing it, the window closes itself (when executing from the window system)

Unix command to delete .svn folders

I have found on the web a useful command to delete .svn folders in your local svn repository. I found it here.

The command line is as follow :

find ./ -name .svn -exec rm -rf {} \;

The command find will search in the ./ directory each element whose -name is .svn. Don’t forget to go into your svn directory with the cd command. After each successful research, the -exec command will execute rm -rf with the path found by find put into the {} brackets. The result is that each .svn folder found is deleted.