32 bits

Le mode 32 bits permet d'accéder à jusqu'à ±4 Go de mémoire (bien que le système Windows s'en réserve au mois 1/4 pour le noyau) et de pouvoir traiter, nativement, des nombres entiers pouvant aller jusqu'à 4.294.967.295.

L'avantage est ... ? L'inconvénient est ... ? (à vous de choisir, faites vos propres expériences).

Sachez, toutefois, qu'un système 64 bits peut faire fonctionner un programme 32 bits mais qu'un système 32 bits ne peut pas faire fonctionner de programme 64 bits.

La version de la librairie est identifiable par les chiffres 32, ex : e_memory_[?][?][?]32(.lib)/(.dll).

S'oppose à 64 bits.

64 bits

Le mode 64 bits permet d'accéder à jusqu'à ±18 milliards de Go de mémoire et de pouvoir traiter, nativement, des nombres entiers pouvant aller jusqu'à 18.446.744.073.709.551.615.

L'avantage est pouvoir accéder à plus de mémoire et c'est le système pour les années à venir. L'inconvénient est qu'il consomme plus de mémoire car les mécanismes de stockage des nombres, des adresses et des alignements doublent. Cela ne veux pas dire qu'un programme 64 bits consommera deux fois plus de mémoire qu'un programme 32 bits; il consommera plus mais pas le double.

La version de la librairie est identifiable par les chiffres 64, ex : e_memory_[?][?][?]64(.lib)/(.dll).

S'oppose à 32 bits.

Ascii

Le mode ASCII est le format original permettant de stocker les caractères de l'alphabet latin, les nombres, la ponctuation ainsi que les lettres particulières aux états européens (lettres accentuées, trémas, cédille, ß, ...).

L'avantage du format ASCII est qu'il n'a besoin que d'un octet pour stocker un caractère. L'inconvénient est que les alphabets utilisables sont limités aux alphabets d'essences latines.

Par exemple pour stocker la chaîne de caractères "Hello world!" on a besoin de 13 octets, soit 0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x20, 0x57, 0x6F, 0x72, 0x6C, 0x64, 0x21 et 0x00.

La version de la librairie est identifiable par la lettre a, ex : e_memory_a[?][?][?](.lib)/(.dll).

S'oppose à Unicode.

Debug

Le mode debug est essentiellement utilisé lors du développement. Dans ce mode, le compilateur injecte du code supplémentaire afin de détecter plus facilement les éventuelles erreurs et de naviguer très facilement dans la structure et la pile d'appel du programme.

L'avantage est une mise au point du programme beaucoup plus aisée. L'inconvénient est que l'exécutable créé par le compilateur est volumineux, pas optimisable, lent (perte de ± 50% de puissance) et décompilable par une personne tièrce.

La version de la librairie est identifiable par la lettre d, ex : e_memory_[?]d[?][?](.lib)/(.dll).

S'oppose à Release.

Dynamique

Le mode permet d'utiliser les fonctions d'une librairie sans avoir à les injecter dans le programme final. Les appels de ces fonctions se font en ouvrant le fichier librairie.

L'avantage est que le programme est plus petit, que la librairie peut être mise à jour facilement (si la structure de celle-ci n'est pas différente) et qu'elle peut être utilisée par plusieurs programmes en simultané (partagée). L'inconvénient est que l'on doit distribuer la librairie avec le programme et que celle-ci doit être accessible (voir configurer l'accès aux fichiers de liaison dynamique (*.dll)).

La version de la librairie est identifiable par la lettre d, ex : e_memory_[?][?]d[?](.lib)/(.dll).

S'oppose à Statique.

Inter-connexion d'objets

L'intérêt de la librairie EclatLib est qu'elle dispose d'objets pouvant être connectés entre eux pour assouplir et simplifier la programmation d'une application. Cela n'est pas une obligation mais une option. Vous pouvez vous contenter des fonctionnalités propres à chaque objet ou étendre ses possibilités.

Par exemple l'objet EFile (bientôt disponible) permet d'ouvrir, de lire et d'écrire dans un fichier. Lorsque l'on désire lire un fichier, il faut allouer suffisemment de mémoire pour pouvoir stocker les données lues à partir de celui-ci et libérer la mémoire allouée lorsque l'on en a plus besoin. Exemple :

EFile eFile
uchar *pucBuffer = (uchar*)malloc( 1024 ); // Allouer de la mémoire

eFile.Open( "C:\MyFile.txt", EFile::Open_Read );
eFile.Read( pucBuffer, 1024 );
...
free( pucBuffer ); // Ne pas oublier de libérer la mémoire allouée sous peine de fuite

Une autre solution existe, utiliser l'objet EFile en corrélation avec l'objet EMemory. Ainsi la fonction qui est chargée de lire les données à partir d'un fichier alloue elle-même la mémoire nécessaire pour stocker les données et la libération de la mémoire allouée est automatiquement effectuée. De plus une fois que les données ont été stockées dans l'objet EMemory, il est possible d'utiliser les fonctionnalités de l'objet EMemory pour manipuler ces données puis de les écrire dans un fichier. Exemple :

EFile eFile
EMemory eMem;

eFile.Open( "C:\MyFile.txt", EFile::Open_Read );
eFile.Read( &eMem, 1024 ); // La fonction Read alloue la mémoire nécessaire
...
// L'objet eMem libère automatiquement sa mémoire allouée

Lorsqu'un objet est inter-connectable à un autre objet, il est spécifié dans la colonne Objet connectable.

Inter-dépendance d'objets

Il existe deux sortes d'objets, les objets primaires et secondaires.

Les objets primaires sont autonomes car ils effectuent des tâches de bas niveau, c'est le cas des objets EMemory (gestion de la mémoire) et EFile (gestion de fichiers). Ils peuvent fonctionner en autarcie mais peuvent aussi être inter-connectés avec d'autres objets pour faciliter et étendre ses possibilités.

Les objets secondaires ne sont pas aussi autonomes que les objets primaires car ils gèrent une couche supérieure. Ainsi l'objet EString (bientôt disponible) se base sur l'objet EMemory pour pouvoir stocker une chaîne de caractères. On parle alors d'interdépendance d'objets. Contrairement aux objets primaires dont l'utilisation d'un autre objet tiers est facultative, pour les objets secondaires l'utilisation d'objets tiers est une nécessité. Lorsqu'un objet est nécessaire à un objet secondaire, il est spécifié dans la colonne Objet dépendant.

Librairie

Une librairie est un fichier (jusqu'à aujourd'hui) qui rassemble en son sein des variables et des fonctions. C'est une sorte de boîte où un programme va venir piocher pour effectuer des tâches particulières.

Dans la plupart des cas une librairie est dédiée à un sujet précis. Par exemple DirectX, OpenGL ou SDL sont des librairies graphiques gérant la 2D/3D.

L'intérêt de la librairie est de mettre à disposition des fonctions que l'utilisateur final n'a pas a écrire. Il se sert de l'existant et n'a pas a réinventer la roue. Avant l'apparition des librairies graphiques, les programmeurs devaient écrire eux-même les routines, ce qui était plutôt difficile car la gestion de la 3D est complexe. Avec l'avènement des librairies graphiques, même le programmeur novice peut mettre en place une gestion 3D sans problèmes particuliers. Bref, il peut faire ce que faisait l'expert 3D sans avoir à acquérir ses connaissances.

L'autre intérêt de la librairie est que l'on peut y rassembler toutes ses fonctions déjà écrites. Si l'on utilise pas de librairie, à chaque fois que l'on désire utiliser des fonctions déjà écrites dans un autre projet, on doit insérer le code source ou le fichier source pour qu'ils soient compilés avec le programme. L'inconvénient de cette méthode est que les fichiers contenant le code source peuvent être importants (il ne faut pas en oublier) et surtout le temps de compilation est beaucoup plus lent car chaque fonction doit être analysée, compilée et linkée. Avec une librairie, on n'a besoin que d'injecter le(s) fichier(s) Include général(aux), il n'y a plus de phase de compilation et le temps de linkage est dérisoire.

Mode de compilation

Les modes de compilation sont les directives ordonnées aux compilateurs afin de générer un programme répondant à des attentes précises à un instant donnée.

La librairie EclatLib accèpte quatre groupes de modes de compilations pour répondre aux principales demandes. Au sein de ces groupes, les éléments les composant sont antinomiques, c'est à dire qu'ils ne peuvent être combinés.

1er groupe, Ascii «» Unicode
2ème groupe, Debug «» Release
3ème groupe, Dynamic «» Static
4ème groupe, 32 bits «» 64 bits

Chaque élément d'un groupe peut être combiné avec l'élément d'un autre groupe pour obtenir une configuration particulière. Ainsi pour chaque objet de la librairie EclatLib, il existe 16 configurations possibles :

(U)nicode, (A)scii, (D)ebug, (R)elease, (D)ynamique, (S)tatique, (32) bits, (64) bits

Note : vous n'avez pas spécifier le mode que vous désirez utiliser, chaque objet est livré avec un fichier <objet>_mode.h qui va déterminer automatiquement (en scrutant le projet) les bons modes à utiliser et guider le compilateur vers le(s) fichier(s) de liaison à utiliser.

Release

Le mode release est utilisé lorsque le programme est finalisé et près à être distribué. Dans ce mode, le compilateur n'injecte pas de code supplémentaire contrairement au mode Debug.

L'avantage est que le programme est plus petit, plus compact, plus rapide, optimisable et plus difficilement décompilable par une personne tièrce. L'inconvénient est que n'ayant pas de code de débugage il n'est pas facilement analysable.

La version de la librairie est identifiable par la lettre r, ex : e_memory_[?]r[?][?](.lib)/(.dll).

S'oppose à Debug.

Statique

Le mode static permet d'injecter directement les fonctions utilisées de la librairie d'un objet dans le programme final, le programme et la librairie ne font qu'un; c'est le top du top à mon avis.

L'avantage est que l'on a pas besoin de distribuer le(s) fichier(s) *.dll correspondant(s) à la(aux) librairie(s) utilisée(s). L'inconvénient est que l'exécutable créé par le compilateur est plus volumineux.

Note : lorsque l'on linke une librairie statique à un programme, ce ne sont que les fonctions de la librairie utilisées dans le programme qui sont injectés. Les fonctions n'étant jamais appelées par le programme ne sont jamais injectées dans le programme final (il ne faut pas faire l'addition "Programme final = Programme + *.lib + *.dll).

La version de la librairie est identifiable par la lettre s, ex : e_memory_[?][?]s[?](.lib).

S'oppose à Dynamique.

Unicode

Le mode unicode est un évolution du format ASCII à l'occasion de l'internationalisation de l'outil informatique. Il permet de représenter les alphabets ne reposant pas sur l'aphabet latin.

L'avantage du format unicode est de pouvoir stocker tous les caractères de tous les alphabets de la planète (et ceux à venir). De plus selon la documentation de Microsoft, le mode unicode est plus rapide que le mode ASCII. L'inconvénient est qu'il faut deux octets pour stocker un caractère.

Par exemple pour stocker la chaîne de caractères "Hello world!" on a besoin de 26 octets, soit 0x48, 0x00, 0x65, 0x00, 0x6C, 0x00, 0x6C, 0x00, 0x6F, 0x00, 0x20, 0x00, 0x57, 0x00, 0x6F, 0x00, 0x72, 0x00, 0x6C, 0x00, 0x64, 0x00, 0x21, 0x00, 0x00 et 0x00.

La version de la librairie est identifiable par la lettre u, ex : e_memory_u[?][?][?](.lib)/(.dll).

S'oppose à Ascii.