lmg HS a écrit 174 commentaires

La surcharge au travers d'un héritage revient en fait à un masquage.
Il te faut réinjecter ta fonction à l'endroit de la surcharge (b) avec un :
using a::foo;

Quant à l'argument par défaut, à supposer que cela soit vraiment utilisable dans son problème, il est de bon ton de l'avoir dans toutes les déclarations. Ce qui, du coup, n'aide pas forcément.

Autre solution : utiliser le Design Pattern "Template Method", que je préfère de loin aux appels explicites aux implémentations des fonctions définies dans les classes parentes.

Si le format est imposé, il y a effectivement le grand classique lex/yacc (/ flex/bison), mais aussi des alternatives un chouilla plus simple à utiliser comme par exemple :
- boost.spirit (requiert un compilo C++ récent, une grammaire pas trop compliqué (ou ne pas être préssé))
- ANTLR

Il doit y en avoir d'autres.

C'est n'importe quoi! Je suis sérieux.
C'est pas un espace de noms qui va ralentir tes compilations.

Un conseil reprends plutôt tes dépendances. Utilises des déclarations en avant quand tu le peux (typiquement pour les données manipulées par référence ou pointeur, et non par valeur), et autres techniques de compilation-firewall (qui amélioreront aussi les recompilations). Des infos dans Exceptional C++ et donc sur GOTW si vous ne voulez pas investir dans cet incontournable bouquin (je ne peux que conseiller les autres livres de la gamme C++ Advanced chez Addisson Wesley).

Des fichiers d'en-tête précompilés sont aussi une bonne façon d'accélérer les compilations. Typiquement, pour chaque module tu auras un fichier d'en-tête précompilés incluant les fichiers utilisés partout dans chacun de tes modules (typiquement, <string>, <vector> et autres fichiers qui vous sont propres).

Pour quel besoin cherchais-tu comment on introspectait en C++ ?

Parce que, en supposant que cela soit pour un besoin de serialization, il existe déjà quantité de bibliothèques qui facilitent la tâche finale à réaliser.

A la louche et rapidement, il manque un #include<string> dans le .h,
Difficile de dire si c'est là l'erreur, ou s'il s'agit d'un oubli de recopie du code.

PS: faire un using dans un .h n'est pas considéré comme une bonne pratique. Cf. n'importe quelle FAQ qui se respecte pour les explications.

Il manque les [] à delete.
Et pourquoi s'embéter avec des chaines limitées en longueurs ?
#include <iostream>
#include <string>

int main()
{
std::string ligne;
std::getline(std::cin, ligne);
if (std::cin)
std::cout << "Ligne lue: " << ligne << std::endl;
return 0
}

PS: c'est quoi la balise pour le code ?

std::string::find, std::string::find_first_of, ....
-> http://www.dinkumware.com/manuals/reader.aspx?b=p/&h=str(...)
(passer la pub)

std::string, c'est bien. Surtout si tu débutes. Plus tard, tu auras largement le temps de revenir sur les détails de gestion de la mémoire.

Hum. Je n'avais pas eu vent de la v2. A voir ce que cela corrige.

Autrement, la grosse référence pédagogique est Accelerated C++ de Koenig et Moo, publié chez Addisson Wesley, non traduit. Je ne connais pas d'équivalent en VF, à l'exception de la traduction du bouquin de Francis Glassborough qui ne va pas assez loin pour un "professionnel".

Et si tu as du temps, suivre les échanges sur des forums (comme fclc++, clc++.m, ou developppez) est un excellent moyen pour progresser.

boost.file_system c'est bien aussi pour les manipulations sur les noms de fichiers.

Cela devient moins vrai en C++ je trouve.

On dispose de plus de bibliothèques portables (boost, QT, wxWidget, ACE, ...) qui font abstraction de ces détails. Ou plus exactement les encapsulent vu que certaines utilisent exactement le même mécanisme en interne, ou des mécanismes alternatifs. Ce qui fait que l'on ne va plus passer directement par le résultat des auto-tools, mais par ces bibliothèques portables.

+1 (des fois je ne comprends pas pourquoi le choix "pertinent" n'est pas offert)

De toutes façons, il y a plein de bonnes choses utiles dans boost (scoped_ptr<> au minimum, non_copyable, bind&function, regex, ...)

man make/aap/scons/bjam ?

Ces choses sont gérées par les outils qui s'occupent des chaines de compilation. Typiquement, ils font appel à cc/CC/gcc/g++/... avec l'option -c qui demande à produire des fichiers objets. Quant à l'édition de liens, cela se fait en rassemblant les .o (et non en compilant tous les .c/.C/.cpp/...)

Pas exactement. De ce que j'ai vaguement compris, pour linker avec gcc, il te faudra rajouter une option (bibliothèque C++) pour lier avec du C++.
Utiliser g++ directement est bien plus simple.

Et stdio.h ici ne sert à rien (rarement (/jamais?) utile en même temps que les IOStreams), et math.h devrait devenir <cmath>

Il y a moyen d'HTMLizer (avec couleurs) des fichiers depuis des éditeurs de texte orientés développement. Je le fais régulièrement avec Vim.

Dans le genre, Doxygen produit également des fichiers HTML contenant le source d'une application.

Et pour pour définir une singleton "structurel" (vérifié à la compilation), il faut déclarer en privé et ne pas définir les opérations à interdire, ou hériter de boost::non_copyable comme déjà signalé.
(l'autre type d' approche étant celle de ACE ou Loki, "singleton" étant une caractéristique que l'on colle à un type existant (non "structurellement" singleton) pour en définir un nouveau (type) qui sera un singleton)

De plus, il n'est pas rare de vouloir disposer de _plusieurs_ objets non copiables. Typiquement quand on a une sémantique de référence, on veut rarement avoir la copie. Cela me semble être la situation dans laquelle locnet (l'OP) se trouve. Sa démarche est bonne, il ne connaissait juste pas les deux idiomes consacrés pour les sémantiques interdisant la copie.

http://www.accu.org/(...) pour des critiques de bouquins

Accelerated C++ peut être un bon choix. Ceci dit, QT peut te forcer la main à utiliser ses conteneurs et chaines non standard.

Note: Le C++ n'est pas que OO. Tout comme l'Ada il dispose de généricité. Bien que celle du C++ m'évoque parfois plus le Lisp ou le Prolog.

Il commence à être un peu vieux maintenant.
Pour des aspects design, il a toutes fois de très bons restes.

À noter que c'est type-safe, et que boost.format permet de spécifier les positions des arguments, et non pas les types associées.

Il ne faut pas non plus que le code évolue et que les types et paramètres soient appelés à changer.
Bien au delà des lacunes, il y a la simplicité d'utilisation et la maintenabilité.
Rien de tel qu'un coredump lors un log à cause d'un paramètre en conflit avec le format (et vice-versa). L'expérience ne change rien à l'inattention.

Ce que je voulais dire, à la dyslexie près, c'est qu'il n'est ni plus rapide ni plus lent. Pour un même code C, il ne devrait pas y avoir d'impacts de performances, pour une transposition "objet" de la même chose non plus.
Je pense que l'on se rejoint assez en fait.
Indirections vs liaisons tardives (mise en oeuvre du polymorphisme d'héritage) c'est un peu le même combat -- voir le draft n1359 pour des exemples de chiffres. Pour la mémoire, je ne suis pas persuadé non plus que par défaut il y ait une différence sur les types POD.

Toujours est-il, pour ce qui est des performances, voilà de la lecture pertinente: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1359.pdf(...)

Petites remarques et nuances en vrac:
- Nul besoin de faire de l'OO en C++ pour profiter du C++. La généricité est un apport non négligeable. De même que les std::string, les références et autres abstractions qui le rendent d'ailleurs bien plus simple pour les débutants. Un des exemples à ce sujet est la comparaison des codes qui permettent de lire, stocker et trier un nombre quelconque de chaines de tailles quelconques (non fixées à la compilation) (tout en ayant au final un code sûr et non sujet aux buffers overflow, et autres joyeusetés)

- Cette remarque précédente n'empêche pas que coder en C++ comme en C est une fort mauvaise approche qui donne pas particulièrement de bonnes choses.

- Cela n'empêche pas non plus que le C++ est plus vaste et plus complexe. Bien plus complexe.

- Concernant les perfs, C++ n'est pas lent plus que le C. C'est le code et le design de l'application qui vont ralentir, accélerer (cf std::sort vs qsort) l'exécution, ou de rien changer (une indirection reste une indirection). Pour le domaine de calcul scientifique en particulier, depuis quelques temps déjà, des benchmarks montrent un C++ qui rivalise avec le C et le fortran tout en permettant une expressivité plus "mathématique".
A noter toutes fois, que tous les compilos ne sont pas égaux devant le C++. Tous n'optimisent pas aussi bien.

- Il existe des bibliothèques comme boost.python qui facilitent l'interaction du C++ avec Python -- je ne l'ai pas encore essayée personnellement.

Non. Par defaut 'Q' permet d'activer le mode 'Ex' (cf. ':h Q') pour plus d'infos.
Cependant, dans beaucoup de .vimrc, 'Q' a été mappé en 'gq'.

-- Luc