Topic 2 en 1:  
 * tout d'abord je me demande si la sympathique extension typeof() de g++ est reconnue par d'autres compilateurs.
 
 * ensuite je me pose des problèmes de coloration syntaxique: pour l'instant j'utilise xemacs mais je dois dire que je ne trouve pas sa coloration satisfaisante: il ne repère que la moitié des fonctions (celles qui renvoient un type de base genre int ou bool), il choppe pas vraiment les mots-clé du c++ et ne signale encore que les declarations de variables de type int, bool etc..
  J'ai ensuite utilisé le mode cpp-font-lock.el qui ne s'en sort pas mieux pour le reperage des fonctions et des variables mais qui connait tous les mots-clefs du c++ et qui connait quelques types standards en dehors de int et char (genre vector, bitset etc)
  Toujours pas content j'ai chargé le mode ctypes (incompatible avec le précédent), qui est censé repèrer les déclaration de types (mais uniquement typedef, pas les class et les struct ...)
 
  Bref j'ai toujours pas de coloration syntaxique c++ qui fasse mon bonheur. Je me doute bien que c'est extrêmement compliqué de repèrer toutes les declarations de variables et de fonctions en c++ mais ça me manque pas mal (surtout les fonctions, parce qu'une classe dont seule la moitié des fonctions membres sont colorées c'est plus chiant qu'utile ).
 
  D'où la question: quel est selon vous l'éditeur/ide qui gère le mieux la coloration syntaxique du c++ ? (et si c'est un emacs, avec quel conf/modes ?)

non pour typeof, c'est une extension de gcc. en C++ standard, voir <typeinfo>
 
sinon, moi la coloration de emacs me satisfait. tu t'etonnes que vector ne soit pas coloré, pour moi c'est normal: ce n'est ni un mot clef ni un type de base

 
En fait la coloration ou non de vector ça n'est pas ce qui me gene le plus, c'est la reconnaissance des fonctions qui m'embete: pour que font-lock signale une déclaration de fonction, il faut que son type de retour soit un type de base. Donc si elle revoie un vector, elle n'apparait pas comme une déclaration.

Chez moi, ça marche, même si la fonction renvoie un vector<Machin*>&
 
J'utilise le c++-mode, avec un emacs 21.1.1

Ah oui tu as raison, pour une fonction non-membre ça marche pas avec xemacs mais ça marche avec emacs. Par contre pour une fonction membre ça ne marche avec aucun des deux... Un bon point pour emacs, quand même

emacs PAWA!

raaaah mais crotte ! finalement tout le monde est content de la coloration de emacs, y'a pas mieux et je suis le seul à trouver que ça suce ?

Pas pour moi.
Un bon éditeur devrait colorer les types quels qu'ils soient.
(Ça me manque)

visual assist souligne
les types et mots ceux qui ne sont pas definis
(il a parfois des soucis mais c'est un probleme  
complexe)
 
LeGreg

 
Copaing ! surtout que les types base sont souvent renommés, du genre

et du coup on les voit plus   (sauf avec ctypes, certes, mais il reste tous ceux des headers standarts genre size_t etc)

normal!=acceptable

 
 
un multi ?

mon nouvo pseudo, marre de PPC  
 
 
 
 

 
Pourquoi pas un Taz@HFR ?

par ce que je sais que t'es bete, mais j'avais imaginé à quel point  

Pourquoi as-tu choisi la pré-incrémentation ?

plus performante!!!! et puis je vois pas pourquoi une fois avoir incrémenté, j'aurais toujours mon ancienne valeur  

Bon je viens de tomber sur un package qui a l'air pas mal du tout, quoique un peu bourrin sur les regexp (genre sur certains sources la font-lockification peu prendre plusieur minutes):
http://www.esperi.demon.co.uk/nix/ [...] eywords.el
 
voici le commentaire associé au fichier:
 
CC-mode keywords
 
Okay. This is an overkill c/c++ fontification regexp list. It handles
templates, multiple variable declarations, struct/class function
declarations, and more. What it does not handle is specified below or in
the comments for the particular regexps. I try to make things fast by
anchoring expression to the beginning of a line or starting with an
uncommon character wherever possible, and I heavily use the recent
extensions to the regexp syntax. Plus, all regexps are one-liners.
Despite all that, however, I'm sure these regexps require some decent
computing power. But doesn't everyone use lazy-shot by now? :-)
 
Some general comments on the style I support:
 
0. The code makes heavy use of the up-list function, so make sure that
   all blocks are balanced. Throwing in some #ifdefs with hanging braces
   may compile correctly, but it won't highlight correctly.
 
1. Always use braces for if|while|for statements, or things may not
   work. They probably will, though...
 
2. "template <blah>" should be on its own line, although you can have as
   many "template <blah>"s on one line as you want.
 
3. Multi-line template declarations are not guaranteed to work. If
   you're trying to define a type or typedef, it probably won't. If
   you're doing a template <class A, class B, ...> thing, that'll work.
 
4. Templates cannot have whitespace between the name and the "<". For
   example, "pair<T>" works; "pair <T>" doesn't.
 
5. Nested templates must have a space after the first "<". For example,
   "pair<T, T> works; "pair< T, pair<T, T> >" works;
   "pair<T, pair<T, T> >" doesn't.
 
6. You cannot have multiple nested template variable decls on the same
   line. However, you _can_ have a m.n.t. return type, function name,
   and first argument in a function decl (all on one line).
 
7. There is a specific allowed sequence for type qualifirers. See the
   regexp below for exactly what it is.
 
8. The *'s and &'s in types must bind tightly to each other, and also to
   either the type name or the variable, but not both (or neither). For
   example, "foo* bar" works; "foo *bar" works; "foo*bar" doesn't;
   "foo * bar" doesn't. Use the latter two for math expressions.
 
9. There is a maximum of two "::"s per name. How many more than that do
   you need?
 
10. Only the first three variables declared of the same base type in
    a statement are guaranteed to be highlighted correctly.
 
11. The outer parens in a cast must bind tightly to the type they
    contain. For example, "(int*)" works; "( int* )" doesn't. Same thing
    with function arguments. No whitespace between the outer parens are
    supported.
 
12. Only top-level function decls and those declared within a
    class|struct|extern are allowed. To support this, the closest open
    brace is found, and the text before it is examined.
    So, if the braces aren't correctly balanced in the code (because of
    #ifdefs or whatever), it won't work.
 
13. Don't use "(un)signed" to mean "(un)signed int". To see why, look
    at:
 
    unsigned foo = 10?
 
    Is foo a type or a variable? Either one can be legal, unless ? is a
    semicolon. Only in that case can I determine that foo is a variable.
    The default is to treat foo like a type, which won't always be
    correct.
 
14. Function pointer types such as "foo (*)(int bar)" are not supported.
    Use a typedef, or declare the variable "foo (*fp)(int bar)".
 
15. There are two regexps for special comments. These can be highlighted
    differently from normal comments (font-lock-special-comment-face).
 
16. There is a new face for special keywords
    (font-lock-special-keyword-face).
 
Good luck..  
je viens de l'essayer et il roxor !