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.