Compilation et taille des fichiers - Page 1

J'ai un soucis avec GTC concernant les la compilation de projets important en taille.

J'ai plusieur fichier dans mon projet dont la taille de certains atteind 5 Ko( Maxi).

A la compilation j'ai Error not enough memory

Quelle est la strategie optimal pour la compilation sous GTC ?

La taille des fichiers a peu d'importance, ce qui compte c'est de ne pas avoir de fonctions gigantesques : si une fonction devient trop grosse il faut la réorganiser en sous-fonctions.

ok merci, c'est exactement le probleme que j'ai.
Mon Interface Graphique contient une fonction qui fait plus de 4Ko

Ce n'est pas bon du tout ! Dans une grosse fonction, on ne s'y retrouve pas. Tu as certainement plusieurs gros blocs d'instructions imbriqués (un if dans un else dans un case, etc). Quand tu voudras relire ça dans 3 mois, tu n'y comprendras plus rien. Découpe les étapes de ton algorithme en sous-étapes, c'est à dire en fonctions.

Peut être qu'il commente beaucoup

Découper à l'extrême comme semble le suggérer ./4 c'est pas forcément bon non plus (enfin sauf si c'est pour passer à travers les limitations techniques de GTC), lire un code source ou une ligne sur 2 est un appel à une fonction définie ailleurs c'est assez vite pénible ^^

Je ne suis pas d'accord. Si le nom de la fonction est explicite, on comprend très bien ce qu'elle fait, le code est beaucoup plus clair : il se lit comme un roman. S'il est difficile d'exprimer l'action juste avec le nom, on écrit un petit commentaire au-dessus de l'appel. C'est bien plus clair que devoir décrypter l'action réalisée par un algo de 50 lignes, et chercher où il commence et où il se termine quand il est composé de plusieurs {} imbriqués.

Si on veut savoir ce qui se cache derrière chaque action, on peut ensuite aller consulter les fonctions. Le fonctionnement interne des fonctions n'est pas nécessaire à la compréhension. Exemple : on s'en tape un peu du fonctionnement de printf() ou de pow() quand on lit un code. On devine leur utilité, ce que ça fait. On comprend bien ce que fait le programme.

Bien sûr, il y a un juste milieu à trouver entre décomposition extrême et ramassis d'instructions, pour ne pas dégrader trop les performances.

On ne doit pas lire les romans de la même façon ? Les miens sont rarement blindés de renvois d'une page à l'autre dans tous les sens

Et il ne s'agit bien sûr pas de mixer n'importe quoi, mais un "bloc logique" de code peut tout à fait atteindre les 50 lignes sans nécessiter un découpage qui n'apporterait pas grand chose à la lisibilité et ne ferait finalement que couter un appel supplémentaire à l'exécution (en plus d'obliger un éventuel lecteur à arrêter sa lecture continue pour sauter à un autre bout de code, alors qu'il est la suite logique de ce à quoi il s'intéressait juste avant).

Oui enfin GTC n'a aucun problème à compiler des fonctions de 50 lignes ou même 150 lignes, après ça va dépendre de ce que font les lignes : si elles contiennent toutes des appels de macro compliqués ça va forcément être plus gourmand que de simples if() ou des appels de fonctions...

Zephyr : Je crois plutôt qu'on n'a pas la même manière de découper les problèmes. Je parle de faire une analyse "descendante" du problème (je sais pas si c'est le mot). On sait que, globalement, on doit faire telle chose, puis telle chose. On dédie une fonction à chacune des choses. Dans ces fonctions, on fait le même raisonnement : "pour arriver au terme du travail demandé, il faut faire, grossièrement, telles actions". On dédie des fonctions à ces actions et on les appelle. Puis on refait ça dans chacune...

On part donc d'un point de vue très global sur le travail à effectuer, puis on détaille, puis on détaille les détails, etc... Je n'ai pourtant pas l'impression d'inventer la roue puisque nos profs nous ont toujours dit ça. Une fonction trop grosse, c'est certainement une fonction qui peut être découpée en blocs d'actions, qu'on codera dans des fonctions. Le travail se résumera alors à appeler ces fonctions.

Et je te garantis que ça se lit comme un roman. C'est plus clair, on comprend tout de suite ce que fait le code. Après, on rentre dans les détails qui nous intéressent en allant consulter les fonctions correspondantes.

Comme dit, il y a un juste milieu à trouver !

Je suis passé par un bon paquet de normes, depuis les très souples qui ne t'interdisent quasiment rien jusqu'à l'horrible norme EPITA et ses contraintes à la "vos fonctions ne doivent pas dépasser 20 lignes", et dans ce deuxième cas on se rend vite compte que ça donne parfois n'importe quoi.

Oui, bien sûr qu'en règle générale on peut découper assez facilement, mais il reste encore bien d'occasions où vouloir à tout prix découper à l'extrême ne va rien faire d'autre qu'une décomposition inutile du code qui va juste compliquer la lecture. C'est dans ce sens que je trouve l'affirmation du ./4 incomplète, et fausse si tu considères qu'elle s'applique toujours.

(le bon sens, ça fonctionne très bien en toutes circonstances, hein )

Pas chez EPITA. Du moins si ce que je lis est vrai. (Je n'ai heureusement pas eu la malchance de passer par là. )

(pourtant je pense que ça n'aurait pu te faire que du bien, mais bon c'est un autre problème )

Meme si je trouve ce genre de regles assez débiles, quelque part je trouve ça bien. Quand je vois du code de quelqu'un de pas discipliné du tout, on voit qu'il a laissé parler son imagination. Pour ces gens là un peu de discipline militaire ne ferait pas de mal.

Maintenant le mieux c'est effectivement de ne pas se tirer une balle dans le pied et trouver un juste milieu: être conscient des approximations qu'on fait au détriment d'un développement plus "souple".