O << 5 vaut 0, donc LevelSensitive est défini comme 0. Si on avait 1<<5, ça vaudrait 32.

En supposant que $(MACHDIR) ne contienne pas de caractères expansifs (comme * ou ?) -intuitivement, on s'attend à un répertoire comme i586/ ou ppc/ qui dépend de la machine- $(wildcard $(MACHDIR)) vaut la chaine vide si le répertoire (ou fichier) $(MACHDIR) n'existe pas, et le répertoire $(MACHDIR), par exemple i586/ s'il existe. L'écriture ifeq ($(MACHDIR),$(wildcard $(MACHDIR))) teste donc l'existence du répertoire $(MACHDIR)


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Friday 10 March 2006 15:30:51

J'ai oublié de préciser que le noyau linux est codé en C, pas en C++, et il y a de bonnes raisons à ça!
Pour votre machine $(MACHDIR) vaut peut-être arm.

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Friday 10 March 2006 15:34:12

Merci,

mais dans ce cas pourquoi ne pas écrire

#define LevelSensitive 0 ??

et il y a plein d'autre #define avec des 5<<7... 6<<8 ... pourquoi ne pas écrire la bonne valeur directement...

et pour le

ifeq ($(MACHDIR),$(wildcard $(MACHDIR)))

blablabla

endif

un ifdef n'aurait-il pas convenu ?

Poste le Friday 10 March 2006 15:49:26

Citation
iostrym
mais dans ce cas pourquoi ne pas écrire

#define LevelSensitive 0 ??

Peut-être parce que ce fichier est généré?, ou sinon pour suggérer que LevelSensitive doit être 0 ou 32.

Citation
iostrym
ifeq ($(MACHDIR),$(wildcard $(MACHDIR)))

blablabla

endif

un ifdef n'aurait-il pas convenu ?

Non, car wildcard fait de l'expansion de nom de fichiers, donc accède à l'arborescence des fichiers. On veut tester si un repertoire existe, pas si une variable de Makefile est définie.



----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Friday 10 March 2006 15:54:48

Citation
Basile STARYNKEVITCH
... O << 5 vaut 0, donc LevelSensitive est défini comme 0. Si on avait 1<<5, ça vaudrait 32. ...

Puis-je me permettre d'apporter une petite précision:

Le précompilateur C fait un remplacement syntaxique et purement syntaxique. Donc lors de la phase de précompilation, LevelSensitive va prendre la valeur 0 << 5, c'est-à-dire que toute les occurences de LevelSensitive seront syntaxiquement remplacée par 0 << 5.

C'est lors de la phase de compilation que 0 << 5 sera évalué comme 0.

Le résultat final est, bien sûr, le même que celui que tu donnes, mais il me paraît important de rendre au précompilateur ce qui lui appartient et au compilateur ce qui lui appartient.

Poste le Friday 10 March 2006 16:08:09

Errare humanum est.

Dans le message précédent, il faut lire (0 << 5) partout ou 0 << 5 apparaît !

Navré du double post, mais comme on ne peut pas éditer ...

Poste le Friday 10 March 2006 16:10:18

Citation
abgech
Le précompilateur C fait un remplacement syntaxique et purement syntaxique.

Un grand merci pour cette précision, que je savais et que je supposais connue du locuteur initial, c'est pour ça que je n'ai pas expliqué les parenthèses.

d'ailleurs je trouve le préprocesseur de C mal foutu, même dans son genre. Par exemple, on ne peut pas écrire yacc ou lex en macros C et je trouve qu'on devrait. Les templates de C++ sont assez idiomatiques, et à peine meilleures. Il y a beaucoup de tâches qui relèvent d'un préprocesseur assez syntaxique et qu'on ne peut pas faire ni en C (avec cpp) ni en C++ (avec les templates): par exemple générer des serialiseurs XML à partir des déclarations de types C, générer des analyseurs à partir des grammaires (comme yacc), etc....

Le préprocesseur m4 est plus puissant, mais sa syntaxe est abominable. Il y a aussi Gpp et Chpp.

Pour ceux qui cherchent un langage avec un précompilateur bien pensé, regardez CommonLisp ou bien Scheme, avec ses macros hygièniques. [fr.wikipedia.org]

Et d'ailleurs, si j'aime bien Ocaml, son préprocesseur Camlp4 -bien meilleur que cpp- est aussi à mes yeux insuffisant et peu intégré au langage. Voir [www.metaocaml.org] pour avoir mieux.

Ceux qui veulent développer des préprocesseurs ou analyseurs de C en Ocaml le peuvent grâce à Cil. [manju.cs.berkeley.edu] et de façon générale, c'est un bon outil pour analyser et/ou générer du C.



----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Friday 10 March 2006 16:30:25

merci pour toutes ces precisions :-)

je compile mon petit uclinux pour ARM7TDMI et promis, après je vous prépare un petit préprocesseur analyseur de C.

Linux est developpé en C mais la notion de pointeur n'est-elle pas propre au C++ ?

Poste le Friday 10 March 2006 16:48:24

Non, le C connait les pointeurs depuis toujours, et même son ancêtre le BCPL l'avait!


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Friday 10 March 2006 16:57:17

Citation
iostrym
... Linux est developpé en C mais la notion de pointeur n'est-elle pas propre au C++ ? ...

En fait la notion de pointeur est intrinséque aux ordinateurs conçu selon l'architecture de Von Neumann, c'est à dire l'écrasante majorité des ordinateurs actuels, pour ne pas dire la totalité de ceux mis sur le marché, les autres étant expérimentaux. C'est tout simplement une adresse mémoire, telle qu'elle apparaît dans les instructions machines. La plupart des langages implémentent une forme ou un autre de pointeur, même COBOL (ALTER xyz TO PROCEED TO abc) mais dans ce cas c'est une véritable horreur ).

On ne peut tout simplement pas programmer en C sans utiliser de pointeur, pensons simplement à scanf(...), sans oublier les passages de paramètre par référence, ou plus précisément par adresse (c'est à dire par pointeurs).

Avec les langages dits "évolué", le pointeur acquiert un peu de sémantique: il ne représente plus obligatoirement l'adresse du plus petit élément adressable de la machine, mais l'adresse d'une structure de donnée qui peut être plus grande et plus complexe. La mode actuelle étant d'ailleurs de se passer de pointeurs (Java), mais en fait les pointeurs existent en Java, mais de façon implicite.

Poste le Friday 10 March 2006 17:27:33

aaaa ouiiiii j'ai confondu. la différence en c++ et c c'est la notion de classe...

Poste le Friday 10 March 2006 17:29:49

Citation
iostrym
aaaa ouiiiii j'ai confondu. la différence en c++
et c c'est la notion de classe...

Pas tout à fait. La grande différence, c'est la notion d'objet. Parce que les classes en C se nomment des structures (d'ailleurs il est généralement possible de porter un pgm de C++ vers C en remplaçant toutes les classes par des structures et toutes les méthodes par des fonctions prenant en paramètre un pointeur vers la structure à laquelle elle était liée en C++)
Il reste d'autres différences comme les template, les fonctions inline, les références, les espaces de nommage mais grosso-modo, tout est dit quand on dit "objet"...

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Friday 10 March 2006 19:17:01

Citation
Sve@r
La grande différence, c'est la
notion d'objet.

Effectivement, les autres différences n'étant que des détails qui facilitent la vie du programmeur, comme le commentaire de fin de ligne ou le type booléen. La gestion des pointeurs et de la mémoire est tout de même différente, avec les fonctions new et delete, mais le principe reste le même.

Poste le Friday 10 March 2006 20:35:05

On peut, en C comme en C++, ne pas explicitement gérer la mémoire (c'est la plaie) en utilisant un ramasse-miettes.

Il y évidemment le ramasse-miettes conservatif de Boehm, qui est présent dans toutes les distributions récentes de linux comme libgc.so ou libgc.a (et #include <gc.h>). Dans son usage le plus simple, on remplace malloc par GC_malloc ou new par new(GC) et on peut oublier les free ou delete - l'application va libérer (presque toute) la mémoire inutile pour la réutiliser.


Il y a d'autres ramasse-miettes (notamment précis, ie non conservatifs). Ils sont plus désagréables d'utilisation mais permettent aussi de coder en C ou C++ [v](j'ai même écrit un tel ramasse-miettes, Qish, en LGPL, sur ma page)[/v].

Je veux dire par là que, même dans une application codée en C ou C++, on peut ne pas gérer la mémoire à la main (en mettant, et c'est horrible, les free ou delete à la main dans le code).

Dans un noyau, les choses sont un peu différentes, car le noyau est tenu de gérer la mémoire (y compris la sienne) mais pourrait utiliser un ramasse-miettes pour ça.

Le comptage de références, chers aux programmeurs C++, est une (très mauvaise) technique de ramassage de miettes (ou garbage collector, ou glâneur de cellules).

L'un des nombreux intérêts du langage Ocaml (de son implantation dans son compilateur) est son ramasse-miettes très efficace (souvent plus efficace que le malloc & free de C).



----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Saturday 11 March 2006 21:42:18