Bon choix de format, j'aime pas le format *.epub mais bon.
Les variables globales sont a éviter mais si l'on divise son code en plusieurs fichier sources et il est bien difficile de toujours passer en référence un pointeur (Dès fois il faut passer par une structure globale a un fichiers si l'on désire passer plusieurs variables) selon la sémantique des fichiers.
Les variables globale ne sont pas le diable je pense qu'ils existent pour une bonne raison.
En faire le moins possible est le mieux que je puisse faire.
Malgré que ce programme en contiennent pas mal, c'est a cause de son histoire: je me répète ce fût mon premier programme en C++ parallèlement a Edip.
Donc en version 3.0 après 4 versions, j'en ai eliminés et sérieusement améliorer le code mixture C/C++ et rendus le code compatible Mac, Windows, Linux grâce au préprocesseur.
Si ça change beaucoup, le code est moins bien organisé, donc plus difficile à comprendre, donc moins maintenable sur le long terme, et donc contiendra potentiellement plus de bugs.
Concernant un relativement gros fichier includes.h je ne pense pas.
Concernant un gros fichiers defines.h a voir, cela me dérange pas.
Concernant un gros fichiers globals_vars.h et .c tu a sûrement raison.
Car l'on peut très bien référencé les variables externes en les déclarant comme externe là ou l'on en a besoin.
Bref cela est un problème d'organisation.
Donc personnel pour moi.
it-edit-3.0 contiendra les même sortes de fichiers, mais sera beaucoup mieux que les version précédentes.
Je me suis mis en tête après après lu l'ouvrage d'un Unknow head nommer Jonas Skeppstedt (auteur d'un compilateur open-source c99-c11, nommé lmpcc, agréer ISO ce que gcc n'est pas):
A écrire du code pour le compilateur mais je balance entre
l'organisation du code
La présentation au lecteurs.
Et écrire pour le compilateur.
Je te recommande chaudement ce livre: nullement besoin de connaître le Java, plutôt savoir un minimum comment fonctionne un ordinateur et l'assembleur malgré la syntaxe power utilisé dans le bouquin.
Merci Sébastien.
Merci a tous le monde pour vos réponses.
PS: A part une analyse approfondie du code machine connais tu un autre indicateur que la taille de l'exécutable de la qualité du code, comme le rapprochement dans l'utilisation de certaines variables afin d'optimiser l'accès au cache (cache hit !) ?
[^] # Re: Bonne tête, sauf le code source
Posté par Linuxator . En réponse à la dépêche Micro Music Player (mmp), le lecteur musical minimaliste, sort en version 3.0. Évalué à 1.
Salut sébastien,
Linuxtaor == author of it-edit.
J'ai mis ton blog sur https://people.gnome.org comme marque page et j'ai télécharger le *.PDF,
Bon choix de format, j'aime pas le format *.epub mais bon.
Les variables globales sont a éviter mais si l'on divise son code en plusieurs fichier sources et il est bien difficile de toujours passer en référence un pointeur (Dès fois il faut passer par une structure globale a un fichiers si l'on désire passer plusieurs variables) selon la sémantique des fichiers.
Les variables globale ne sont pas le diable je pense qu'ils existent pour une bonne raison.
En faire le moins possible est le mieux que je puisse faire.
Malgré que ce programme en contiennent pas mal, c'est a cause de son histoire: je me répète ce fût mon premier programme en C++ parallèlement a Edip.
Donc en version 3.0 après 4 versions, j'en ai eliminés et sérieusement améliorer le code mixture C/C++ et rendus le code compatible Mac, Windows, Linux grâce au préprocesseur.
Concernant un relativement gros fichier includes.h je ne pense pas.
Concernant un gros fichiers defines.h a voir, cela me dérange pas.
Concernant un gros fichiers globals_vars.h et .c tu a sûrement raison.
Car l'on peut très bien référencé les variables externes en les déclarant comme externe là ou l'on en a besoin.
Bref cela est un problème d'organisation.
Donc personnel pour moi.
it-edit-3.0 contiendra les même sortes de fichiers, mais sera beaucoup mieux que les version précédentes.
Je me suis mis en tête après après lu l'ouvrage d'un
Unknow headnommer Jonas Skeppstedt (auteur d'un compilateur open-source c99-c11, nommé lmpcc, agréer ISO ce que gcc n'est pas):Writing Efficient C Code: A Thorough Introduction
A écrire du code pour le compilateur mais je balance entre
l'organisation du code
La présentation au lecteurs.
Et écrire pour le compilateur.
Je te recommande chaudement ce livre: nullement besoin de connaître le Java, plutôt savoir un minimum comment fonctionne un ordinateur et l'assembleur malgré la syntaxe power utilisé dans le bouquin.
Merci Sébastien.
Merci a tous le monde pour vos réponses.
PS: A part une analyse approfondie du code machine connais tu un autre indicateur que la taille de l'exécutable de la qualité du code, comme le rapprochement dans l'utilisation de certaines variables afin d'optimiser l'accès au cache (cache hit !) ?