Pointeurs de fonction et warnings - Page 2

damnvoid (./30) :
meme le c++ va bientot avoir le keyword auto, c'est dire...

Enfin ! Le C l'a depuis le début !
Cf http://www.space.unibe.ch/comp_doc/c_manual/C/CONCEPT/storage_class.html#auto

S'il est utilisé de la même façon que le "var" du C# 3.0, non merci.

damnvoid (./30) :
c'est quand meme vachement plus lisible avec n'importe quel langage non prehistorique, et qui a compris qu'imposer au developpeur d'ecrire lui meme les types alors que le compilateur peut les intuiter tout seul, c'est grotesque.

meme le c++ va bientot avoir le keyword auto, c'est dire...

je suis globalement d'accord pour dire que l'inférence de types c'est chouette

mais il y a aussi des bons arguments pour écrire les types, même dans un langage qui fait de l'inférence de types comme ocaml
1-ça sert de documentation
2-ça permet de contraindre la valeur d'un type

il y a aussi des langages dignes de ce nom où l'inférence n'est pas décidable et qui demandent au programmeur d'écrire au moins partiellement les types pour aider le compilateur à faire la vérification de types (par exemple en Scala)

bah oui en c++ c'est probablement pas decidable non plus, mais c'est quand meme bien de pouvoir par exemple ecrire "auto x = f(y);" a la place de "montype::avec<template::complique> x = f(y);" quand les types de f et de y sont connus.

je n'ai pas dit le contraire... je voulais juste nuancer tes propos sur l'inférence qui pouvait laisser croire qu'un langage qui n'offre pas l'inférence de types est forcément préhistorique

j'aime pas les types implicites. on sait jamais à qui on cause, ni ce qui se passe dans les cas ou on se plante.

Et en plus, je trouve que ça fait marcher la déclaration de types à l'envers.

Par contre, j'aimerais bien ne pas avoir à me répéter, du genre:

class UneClasse
{
....UneClasse(int);
};

...

UneClasse *pObj;
pObj new=(42); //Alloue un nouvel objet de type UneClasse

unsigned char *pBytes reinterpret_cast= pObj;

...Enfin, peut-être avec un truc plus élégant, mais c'est l'idée générale.

La répétition c'est bien pour la consistance du langage en lui même... (penses juste au cas des classes abstraites / classes dérivées pour le new et ça suffira...)
Il n'y a qu'un seul et unique cas où c'est réellement redondant c'est le cas où tu déclares/utilises une variable de type X et où tu lui assignes une valeur qui est exactement de type X (comprendre pas de type compatible avec, ni de type dérivé, etc...), mais au moins tu montres au compilateur (et aux lecteurs de ton code) que tu sais ce que tu fais, donc il n'y a aucune ambiguïté. (Un cast ou une création d'objet ce ne sont pas vraiment des opérations "anodines", donc c'est bien si c'est exprimé clairement)

euh, oui enfin si montrer que tu sais ce que tu fais ca implique d'ecrire des templates imbriques a une profondeur n, ca devient vite chiant (meme avec des typedef). Ce n'est pas a moi de prouver au compilateur que j'ai raison, c'est a lui de le verifier, c'est deja largement suffisant. En C++, des que tu te mets a faire des trucs a base de templates un peu subtils (en utilisant boost par exemple), tu finis toujours par passer des heures a verifier que t'as bien mis les bons trucs entre <>. Alors que le compilateur saurait quoi mettre dedans, mais il a juste envie de te faire faire le travail a sa place...