Reprise du message précédent :
Perso, préfère le  
if ( ) {
   ...
} else {
   ...
}

Je preferre aussi, mais il parait que c'est moins efficace.
A+,

 
une petite explication ?

Juste ce que j'ai dit: des tests mesurés par des psychologues a ce sujet.
Le rapport de leur etude a ete publie il y a un bail.
A+,

 
+1

Moi j'aime pas les accolades pour marques les blocs, les begin/end c'est plus clair

pascal/delphi, sappuduku

#define BEGIN {
#define END }
 
si ya que ca pour te faire plaisir  

plutôt en minuscule
puis moi mon environnement de dev il me les met en gras les begin/end

pareil en python : les accolades vous manquents ?
 
if bidule:
    #{
    dawa
    #}
 
je vous fais pas le dessin pour les begin/end ... y a toujours des raleurs ...

Faut pas déconner !

tiens j'avais pas vu le troll sur "doit-on caster en sortie de malloc ?".
C'est super intéressant, mais j'ai une autre question : pourquoi les gens n'utilisent pas plus alloca qui est vachement utile et rapide (aussi rapide qu'une allocation avec un GC bien foutu) dans le cas de buffers temporaires ?

parce que c'est pas ANSI ni POSIX et l'implémentation est souvent spécifique au compilateur, souvent par macro ce qui fait que la plus part du temps. en fait, par exemple, gcc définit une macro qui ne fait que déplacer le pointeur de pile, donc tu n'as pas moyen de vérifier la réussite de l'allocation et tu te retrouves dans le décors. mais comme tu dis, avec un gc ça marche (Boehm est facile à utiliser), et puis malloc est pas si désastreux que ça. en fait je pense que le problèmes de beaucoup de programmeurs C c'est encore de se débarasser des tableaux des tailles statiques. le C99 permet des tableaux de taille dynamique, mais encore une fois on retombe sur le problème du dépassement de capactié indétectable

Non non non, je ne veux pas entendre parle de Boehm, les GC font suffisement peur aux gens qui ne les ont pas étudiés pour que le commun des mortel utilise ce qui se fait de pire après le comptage de référence.
 
Soit on laisse les gens dans l'ignorance et effectivement les GC c'est le diable. Soit on leur montre des trucs corrects c'est-à-dire, au minimum compactants (d'une manière ou d'une autre, pas forcément l'implémentation bourrine) et à générations. Mais on leur montre pas une Lada pour leur expliquer qu'une Mercedes c'est plus sûr et ça va plus vite que leur Traban.

bah personnellement j'en utilise pas, et à chaque fois que j'en cherche un pour le C, on me dit Boehm
si t'as des références de GC à génération, compactants et tout le tralala qui est bien, je suis preneur

Bohem n'est pas un con, il a fait aussi bien qu'il a pu.
En C les racines sont ambigües -> on ne peut pas déplacer les objets. Un autre problème est que potentiellement, on pointe n'importe où dans l'objet et non au début (on teste donc un intervalle).
 
Racine ambigües : Dans la phase de marquage, tous les pointeurs de la pile vers le tas définissent des objets qui resteront vivants après le ramassage. Hors en C rien ne ressemble plus à un pointeur que 4 octets côte-à-côte alignés comme il faut. On considère donc comme pointeur tout ce qui pris comme une adresse mémoire pointerait entre le début et la fin d'un objet alloué. Que ce soit un groupe de 4 caractères contigüs d'une chaine de caratères, un entier, un fragment de nombre à virgule flottante double précision ou n'importe quoi.
Conservation :
On adopte donc une approche "conservative" : s'il y'a un truc qui semble pointer vers un objet, on marque ce dernier comme vivant, dans le doute (et le plus souvent se sera réellement un objet vivant). Mais ça veut dire qu'on ne peut pas déplacer l'objet et corriger le pointeur vers la nouvelle adresse, chose qu'on ferait si on était sûr que ce soit un pointeur.
 
Il est donc impossible de faire un GC correct pour C sans aide du compilo (de toutes façon il faudra aussi modifier le langage).
C'est pourquoi Bohem n'a pas de concurrent (à ma conaissance) : c'est ce qui se fait de mieux dans cet environnement technique.
 
Meyer a fait un document en 3 parties assez bien gaulé sur le sujet :  
 
 [P111] Proving Pointer Program Properties, Part 1: Context and overview, in Journal of Object Technology (JOT), vol. 2, no. 2, March-April 2003, pp. 87-108.
 
[P112] Proving Pointer Program Properties, Part 2: The Overall Object Structure, in Journal of Object Technology (JOT), vol. 2, no. 2, May-June 2003, pp. 77-100.  
 
(accessibles ici : http://www.inf.ethz.ch/~meyer/publications/index.html )
 
 
edit :
la tendence dans les environnement avec GC, n'est plus de pointer à l'adresse la plus basse de l'objet (qui serait le premier octet de l'entête) on pointe plutôt directement sur le champ le plus souvent accédé et on accède à l'entête par des décalages négatifs. Dans les langages orientés objet, c'est le pointeur vers la table des méthodes qui est pointé, dans le cas des langages fonctionnels, j'ai un trou de mémoire !¡!
Ce fait est bien entendu en soit pas un problème pour l'utilisateur du langage, souvent il ne le sait pas. Quand au concepteur de l'environnement, il a signé pour en chier.

certes. donc étant donné que c'est topic C, Boehm est donc une solution correcte. j'ai déjà lu les papiers de meyers. j'en ai lu d'autres à propos d'un GC comme il faut pour le C++ (avec modifications du langages)
je croyais que t'allais me filer le graal, mais comme tu dis, seule l'approche conservative est viable pour une utilisation comme celle de Boehm (petit #include et GC_malloc et un -l, plus simple tu meurs).
en fait, en C, j'utilise pas, mais c'est envisageable, mais vu l'état actuel des choses, pas questions en C++, je tiens trop à ma finalisation (qui n'est alors pas garantie)

tu parlais de destruction, bien sûr.

vi

 
    ... les deux ecritures sont equivalentes, la tienne arko est plus lisible c tout