lmg HS a écrit 174 commentaires

Le bouquin d'apprentissage du C++ qui a la meilleure presse (méritée) est Accelerated C++ de Koenig et Moe, publié chez Addisson-Wesley, non traduit.

La 4e édition du bouquin de de Lippman et Lajoie (C++ Primer) est très bien parail-t-il aussi (je ne l'ai pa lu pour juger celui là par contre). Moo a collaboré à la 4e édition qui n'a pas encore été traduite à ma connaissance.

Le Thinking in C++ est très bien, mais un tout petit peu vieillot par endroits. Il reste 100 fois meilleur à beaucoup d'autres bouquins qui trainent sur le marché.

Le bouquin de Stroustrup est très bien. Mais il s'agit d'un bouquin de référence. Il convient plus difficilement à l'apprentissage -- enfin, cela dépend des personnes.

VC6 ? Le truc qui est sorti en 97 avant la norme de 98 ?

Sorti de points très pointus souvent liés à la méta-programmation, les compilos d'aujourd'hui se valent.
Le tout est de faire attention aux bibliothèques, aux tailles des types entiers et autre problèmes d'endianess, et à éviter les extension propriétaires.

C'est un grand classique. Le C et le C++ privilégient les perfs aux vérifications. C'est à nous de faire attention.

Ceci dit, au lieu de faire du C avec des classes, fais du C++. Au lieu d'utiliser un tableau, utilise un std::vector et assure-toi que la S(T)L que tu utilises est "checkée" -- certaines versions de l'opérateur [] des vecteurs vérifient que l'indice soit bon à l'aide d'un assert, ce qui aurait au moins planté le programme en mode debug.

Le man. Car, il y a des techniques qui sont communes à beaucoup de make (comme la substitution, les règles implicites), et d'autres non (comme les wildcards, les appels au shell, .PHONY, ...)

Sinon, sur developpez Gilles Louise (si je me souviens bien) a écrit un petit tutoriel sur les makefile (de gmake).
Je te dirais bien de chercher sur wikipedia aussi.

INC_PATH = ${MODULE_ROOT}/include
SRC_PATH = ${MODULE_ROOT}/src
OBJ_PATH = ${MODULE_ROOT}/obj
SOURCES = toto.cpp titi.cpp
OBJECTS = ${SOURCES:%.cpp=${OBJ_PATH}/%.o}

INCLUDES = -I${INC_PATH}

DIRS = ${OBJ_PATH} ${BIN_PATH} .....

all: ${DIRS} ${TARGETS}

${OBJ_PATH}:
	mkdir -p $@

....

${OBJ_PATH}/%.o : ${SRC_PATH}/%.cpp
	${CCC} ${FLAGS} ${INCLUDES} -c $< -o $@

...

Il y a d'autres façons de faire, mais c'est une base où les seules choses à modifier sont SOURCES et TARGETS

http://groups.google.fr/groups?as_q=delannoy&as_ugroup=f(...)
http://c.developpez.com/livres/#L2212115008

Pour en revenir à QT et le C++. QT a sa propre philosophie qui l'éloigne un chouilla de l'état de l'art, ou du C++ moderne, ou appelez ça comme il vous plaira.

Accelerated C++ est l'ouvrage d'initiation qui a le plus la côte aujourdh'ui. En gros seule des bases algorithmiques sont nécessaires, ainsi que savoir lire l'anglais technique.

Ceci dit, j'avais croisé un bouquin d'initiation special QT+C++ qui m'avait paru pas trop mal. Evidemment, je ne me souviens plus du site sur lequel on peut le trouver (il a une version web/wiki), depuis wikipedia, je crois qu'il est référencé.

M'est avis que tu vas avoir un problème de typage.
Bien avant de décoder ton tableau, tu vas devoir savoir ce que tu vas décoder -- quel intérêt à stocker des données que l'on ne saurait pas manipuler ?

Perso, j'aurai tendance à jouer avec boost.multi_array (tableaux à N dimensions, le nombre de dimensions étant statique (devant être connu à la compilation), boost.any (pour contourner le systême de typage et donc mélanger carottes et choux -- les nombres dimensions quoi), boost.serialize (pour gérer sérialisation et désérialisation de tes tableaux si rien n'est déjà défini par défaut).

a- Oui, mais ca existe ça ? des GC directement disponnibles pour mon langage ?
b- C'est pour ça que j'en fais un ... que je compte accésoirement utiliser pour autre chose que les objets de mon langage.

a- Pas sûr. Tu en auras pour les variables C++, mais pas pour les variables de ton langage. Il y aura peut-être moyen de créer u adaptateur pour utiliser un GC C++ pour les données de ton langage. Mais là, j'avoue qu'il est trop tard pour que j'ai une idée précise et juste sur la chose.

b- Méfie toi juste pour un truc, c'est un sujet complexe qui prendra du temps à réaliser. Beaucoup de temps. Et le reste de ton sujet n'est pas non plus trivial. D'autant que tu dis toi même ne pas connaitre très bien le C++. Ceci dit, ton premier essai n'est pas si mal, bien qu'il reste encore des gros détails à bien fignoler.


Bon. Partons d'en haut et descendons. Tu veux implémenter un interpréteur pour un langage disposant d'un GC. OK.
- Pourrais-tu nous montrer des exemples de code de ton langage?
- Exemples qui mettent en évidence l'utilisation d'un GC?
- Et à quoi penses-tu que ressemblerait ton binding (le mot français ne me revient plus) C++ .


Concernant ton bout code, j'ai un peu de mal à voir où tu vas.
P.ex. la classe Object. Le nom me gêne, il ne dit pas grand chose sur le rôle de la classe. Je ne sais pas trop s'il s'agit de données de ton langage, ou d'une tentative de reproduire le design d'un langage qui a des oeillières OO.
De sûr, cela sent la sémantique d'entité. J'interdirai la copie (par dérivation de boost::noncopyable p.ex.) histoire de blinder.

Ma gêne doit venir en partie du fait que je ne connais pas ta modélisation.

La FAQ C++ lite est effectivement l'original -- où ils passent très vite sur le sujet. Cela fait trop alinéa. :(

C'est plus clair dans XP++/GOTW et le coding standards de H.Sutter & A.Alexandrescu.

Pour le PS: je n'ai pas encore investi dans la 3ed du EC++. Qu'entends-tu pas "lagguer" ?

Pour le PPS: pfff en effet. :-/

Cela va même plus loin que cela. Il ne s'agit que de la partie syntaxico-visible de l'iceberg.

La question qu'il faut se poser est : "est-ce que les objets de la nouvelle classes seront des représentants de la classe ancêtre" <=> "peut-on substituer des objets fils là où l'on attend des objets du type parent?"

Bien souvent, on va se rendre compte que non -- dans le cas des conteneurs.
- s'il s'agit de rajouter des services, on peut les rajouter à côté. Ils feront toujours parti de l'interface publique, étendue de l'objet.
- Il est parfois acceptable (!= ultimement propre, ...) de dériver pour les rajouter tant qu'il n'y a pas de nouvelle donnée membre (pour éviter d'éventuels slicings), et que l'on ne joue pas à détruire polymorphiquement.
- s'il s'agit de modifier des services, ben ...on casse vite les contrats établis par le parent. L'exemple typique, c'est la définition d'une liste triée à partir d'un liste. Exemple typique où l'héritage (public en C++, quelconque en Java) n'est pas acceptable. Ici, on ne veut pas "être utilisé en place de" , on veut "réutiliser" => héritage privé ou délégation queconque
- s'il s'agit de spécialiser le conteneur pour des objets précis pour lesquels on veut un traitement suplémentaire bien précis, de nouveau, on bride le contrat initial. On veut réutiliser du code, pas être utilisés en place de.

Ici le polymorphisme d'inclusion (impliqué par l'héritage public) est rarement la solution si on veut factoriser le code. Au contraire du polymorphisme paramétrique et statique des templates du C++.

s/swap(rhs)/swap(other)/ Bien évidemment.

Tu n'es pas alllé voir mes liens ? Avoue. :P L'aspect de pessimisation n'est qu'un détail qui n'a pas la moindre importante.

Le problème est qu'il s'agit d'un contre-idiome qui résoud un problème théorique qui ne se produit jamais, et qui ne résoud pas un problème pratique qui se produit dans des cas aux limites liés à l'exécution. (!= code zarbi)

Ce hack des années 80-90 n'est pas exception-safe. Alors qu'une solution qui est exception-safe résoud implicitement le problème d'auto-affectation. Hack qui n'est dû qu'aux codes qui préféraient désaouller avant de réallouer, ce qui empéchait d'avoir des opérations atomiques.

Faire le test ne correspond alors plus qu'à une vaine tentative d'optimisation qui se résoud systématiquement en pessimisation -- sauf code pour le moins étrange.

Et difficile de faire plus kiss que l'idiome de la copie par swap -- qui s'avère parfois lourd sur les objets ne se résumant à un pointeur encapsulé. Sachant qu'en plus il n'y a strictement aucun intérêt à définir les deux opérations de recopie pour les classes dont tous les membres ont déjà une sémantique de copie -- i.e. pas de ressource brute -- ce qui est encore bien plus dans la philo "kiss".

struct SmthgCopiable {
    SmthgCopiable ( SmthgCopiable const& rhs ) : ... {...}
    SmthgCopiable & operator=( SmthgCopiable const& rhs) {
        SmthgCopiable temp(rhs);
        this->swap(rhs);
        return this;
    }
    void swap(SmthgCopiable & other);
};

Côté portabilité, le GC de boehm s'en sort bien à voir la liste des plateformes supportées. On ne peut pas en dire autant de toutes les bibliothèques C++.

Mais ... le GC demandé, c'est pour ton nouveau langage? Pas pour le C++ si je ne m'abuse. Du coup, je ne suis pas sûr qu'un GC pour le C++ te soit vraiment utile, au contraire d'un GC pour ton langage, mais codé en C++.

Pour ton smart-ptr, ce peut être un peu inutilement compliqué à implémenter -- ton langage sera-t-il multi-thréadé/multi-processus/multi-machines/... ? Vois si tu auras le temps de faire ça plus tout le reste : ton langage. D'autant qu'il existe déjà des smart-ptr prêts à l'emploi dans divers frameworks, à commencer par boost (voire std::tr1 suivant la génération de compilo visé).

Sinon, beaucoup de discussions dernièrement au sujet des GCs dans news:comp.lang.c++.moderated.
news:fr.comp.lang.c++ peut être un endroit intéressant où poser ce genre de questions.

PS: je mitouille avec Robin des Bulles comme quoi ce peut être passionant. Mais attention, tu risques d'y passer beaucoup de temps alors qu'il te reste l'utilisation et l'intégration d'un outil pour parser ton langage (lex/yak, ANTLR, boost.spirit, huile-de-coude, ...)

Non.
Ceci est un contre idiome qui se résume à une pessimisation.

http://c.developpez.com/faq/cpp/?page=surcharge#DIVERS_auto_(...)

http://www.gotw.ca/gotw/059.htm

std::istream::getline n'existe pas. C'est une illusion d'optique. Oublie l'existence de ce truc tout pourri.

Par contre, avec std::getline, c'est différent.

La solution à la main:

std::string id, line;
if ((line >> id) && (std::getline(std::cin, line))) {
    if (id == "EXIT") {
        if ( ! line.empty()) throw ....
    } elseif (id == "toto") {
        std::istringstream iss(line);
        float f1, f2; int i3;
        if ( ! (line >> f1 >> f2 >> i3)) throw ...
        do_toto(f1, f2, i3);
......

Autant dire que la gestion des erreurs complique vite la sauce.

Il y a aussi des solutions pour utiliser des parsers (lex/yacc si tu es courageux, boost.spirit si ce que tu dois parser est simple, ANTLR, ....)

Enfin, ton problème me fait penser aux chain-factories. Tu pourrais ainsi créer ta commande à la volée et l'exécuter par la suite.

PS: Les flux n'ont jamais fait parti de la STL (qui n'est qu'une appellation historique pour un sous-ensemble de la SL du C++). Ils sont dans la SL.

Je n'étais pas un fervent partisant de la "première édition" du cours de Christian Casteyde. Trop encyclopédique et orienté C -> C++.
Maintenant, je ne connais pas la "seconde edition". J'imagine qu'il y a eu des améliorations.

Le bouquin de Bruce Eckel, Thinking in C++, est très très bien, mais un peu viellot sur certains détails.

La référence pédagogique pour le C++ est Accelerated C++de Koenig et Moo, publié chez Addisson-Wesley (LA crémerie C++). Il n'est malheureusement pas traduit.

Dans le genre, mais qui va beaucoup moins loin (n'aborde pas l'aspect OO), il y a Le bouquin de Francis Glassborrough (un des pilliers de l'ACCU -- http://accu.org/ ). Il a été traduit chez Micro Application sous le titre Je me lance.

En référence pédagogique, on a aussi C++ Primer de Lippman. Moo a participé à la dernière édition qui n'a pas encore été traduite je crois.

Enfin, a tout hasard:
- http://c.developpez.com/faq/cpp/?page=generalites
- et il y a des échanges réguliers à ce sujet sur fclc++ ou sur les forums C++ de developpez.

J'ai oublié la syntaxe exacte pour les filtres. Mais cela doit y être dans la présentation que Sébastien Michel avait donnée au CULTe il y a quelques étés de cela.

Pour le SMTP, il est possible de patcher mutt pour qu'il ait un mini serveur SMTP intégré. Ou bien, on peut directement attaquer les serveurs installés sur nos machines.

Des liens utiles:
- http://muttfr.org/ il ne s'y passe plus grand chose, mais il y a plein de bonnes infos. Arg! Le lien a l'air d'être mort. C'est excessivement domage.
- http://hermitte.free.fr/mutt/ mon site. Tu y trouveras ma config mutt, Et aussi des liens vers la présentation de Sébastien, le wiki de mutt (avec plein de liens vers des muttrc), ...

Au temps pour moi.
Je voulais bien évidemment parler des "références non-const qui ne peuvent être attachées à des temporaires (non nommés)".

Tout ce que demande la référence const, c'est une convertion implicite entre le type de l'expression (produisant un éventuel temporaire) et le type de la référence-const.

Soit, ton GCC se comporte normalement.

A tout hasard.

Matthias (OP)> En effet, la méthode Left() renvoie un const...

J'ai l'impression en lisant cela que tu t'es contenté de lever le const du type de retour et que cela passe maintenant. Ce qui me parait surprenant. Quelle version de GCC utilises-tu ?

NB: même si cela passe avec un ancienne version de GCC (ou tout autre vieux compilo VC6, SunWSPro 5.4, ...) il ne faut pas s'attendre à ce que cela continue ainsi -- GCC a été patché, VC a dû l'être aussi. Comme je l'ai déjà signalé il n'y a que 3 corrections valables -- et en plus compatibles avec les vieux compilos. Retirer le const n'en est pas une.
-> DString Experiment::FullShotPath(DString const&relativepath) ; si FullShotPath n'altère pas l'objet reçu en paramètre.
-> DString Experiment::FullShotPath(DString relativepath) ; si FullShotPath n'altère pas l'objet reçu en paramètre et que l'on est prêts à payer une copie.
-> Temporaire nommé intermédiaire

Dit autrement, retirer le const ne servira que sur les environnements sur lesquels on n'a pas réalisé de monté de version des compilos depuis pratiquement 8 ans.

Bench> certains compilos n'aiment pas que l'on passe un paramètre temporaire non 'const' (ex: DString ) en à une fonction qui accepte une référence (DString&)

Deux précisions:
- ce n'est pas certains compilos, mais les compilos à jour sur ce point de la norme. Ceux qui ne le sont pas encore le seront très probablement dans le futur,
- que le paramètre temporaire soit const ou pas ne change rien. Une référence ne peut pas être attachée à un temporaire.

Bench> Une bonne pratique est de doubler ses fonctions type get(), l'une qui renvoit un const et l'autre un modifiable (c'est ce que fait la stl à tour de bras pour les méthodes begin() et end() )

Cela ne s'utilise pas dans le même contexte. Si getLeft() renvoie une valeur créée à la volée et ne modifie pas l'objet sur lequel elle est appliqué, alors la fonction doit être const, et renvoyer une copie. Que la copie renvoyée soit const empêche, aujourd'hui, d'appeler des fonctions (membre) non const sur l'objet renvoyé.
Les deux versions de begin() et end() des conteneurs de la SL permettent d'obtenir des itérateurs vers des données modifiables, sauf pour les conteneurs non modifiables qui ne permettent d'obtenir que des itérateurs vers des données itérables non modifiables.

Concernant l'évolution d'un langage en général : regarde bien qui fait évoluer le C ou le C++. Un indice : il ne s'agit pas d'une assemblée démocratique. :-) Au contraire, il s'agit d'industriels, qui se crèpent (crêpent ?) le chignon pour une histoire de virgule, de point de séquence, ou de point virgule...

Il y a beaucoup d'industriels avec parfois des visions différentes, mais pas que. Et un des plus gros problèmes semble plus être le temps et les moyens qu'autre chose. Un certain nombre d'évolutions risquent de passer à la trappe à cause de cela.

Pour ceux que cela intéresse, à la 3e page [1] des discussions associées à un article sur le C++09 [2] commencent des explications sur le fonctionnement du commité de standardisation.

Quant à l'aspect démocratique, à côté, C++/CLI qui est porté par Microsoft (à l'image de Java par Sun) a pu évoluer plus tranquillement je trouve -- au détail que sorti du GC, il n'y a pas d'évolutions majeures (concepts, rvalue references, ...)

[1] http://www.artima.com/forums/flat.jsp?forum=226&thread=1(...)
[2] http://www.artima.com/cppsource/cpp0x.html

La norme ne permet pas de placer des références non const sur des temporaires non nommés. Peu importe ce que fait la fonction First dans son corps. Seule la signature compte. D'où que si la fonction ne modifie pas la variable, alors il vaut mieux prendre une référence constante (abus de langage -> "référence sur objet non modifiable" est plus "correct"), ou une copie (ce qui fait perdre l'aspect [in,out] de la référence)

Ce sont les vieux compilos qui acceptaient cela.

Ca. Il y a toujours le problème des compilos pré 98 plus maintenus, et des projets déjà lancés qui n'acceptent plus de cots.
Car c'est typiquement le genre d'endroit où réinventer, et valider, la roue n'a pas un énorme intérêt.

Ta fonction qui prend un DString& ne peut pas accepter de paramètre non nommé.
Si elle ne modifie pas ce qu'elle reçoit => "Dstring const&"
Si elle modifie ce qu'elle reçoit => nomme ton temporaire.

Vu que tu programmes en C++, tu sais que tu as tout ce qu'il faut dans boost.file_system pour manipuler des chemins ? (Cela repose sur la classe de chaînes standard std::string)

Contrairement aux idées reçues, le C n'est pas un passage nécessaire pour l'apprentissage du C++. Il complique pas mal les premiers pas du débutant en forçant très tôt l'apprentissage de notions évoluées qui auraient pu être vues en toute quiétude bien plus tard. C'est aussi comme cela que l'on se retrouve avec des cours/TPs/TDs qui montrent des codes incorrects (typiquement qui font dans le buffer overflow), les codes justes étant trop complexes pour des débutants.

Et non, commencer par le C++, ne veut pas dire de commencer par l'OO. Il s'agit juste de s/char*/std::string, s/array/std::vector, s/passage de pointeurs par valeur/passage d'argument par référence/, s/syntaxe et pièges de printf/cout, s/scanf(ptr)/cin>>donnée/, ... C'est tout bête, mais cela fait toute la différence : on peut se concentrer sur l'algorithmique et autres choses vraiment importantes dans un premier temps.

Bref. Plein de ressources à ce sujet :
- la FAQ sur le site de Stroustrup, avec un lien vers un article que je ne peux que conseiller de lire et de méditer. Il traite du pourquoi le C++ doit être enseigné comme un langage à part entière
- la FAQ sur developpez qui a une Q/R sur comment débuter en C++.

Je vous laisse sortir votre moteur de recherche préféré.

Côté cours de C++, le meilleur que je connaisse, c'est Accelerated C++, par Koenig et Moo chez Addisson Wesley. Il n'a pas été traduit. C'est un ouvrage pédagogique qui n'est pas un ouvrage de référence, et qui ne traite ni de C, ni de C/C++, mais bel et bien de C++98.


Pour en revenir à ce que cherche à faire l'OP. Non seulement le C++ n'est pas le plus adapté à ce genre de traitements (tout comme le C ; Cf. la redirection déjà montrée qui prend un tiers de ligne à écrire), mais en plus le C++ natif ne doit pas le permettre si mes souvenirs sont bons -- je ne suis pas persuadé que l'on puisse ouvrir /dev/lp0 avec un simple std::fstream, mais je peux me tromper. Il y a de fortes chances qu'il faille utiliser des APIs système ou POSIX, dont les interfaces demandent des connaissances en C...

Normalement, les outils compilés avec GCC en mode cygwin supportent les chemins à-la-*nix. Et dans mes souvenirs, les chemins à la windows sont également supportés.

Le problème arrive quand il y a p.ex., besoin de convertir des chemins *nix en chemin windows pour les outils win32 que l'on veut exécuter depuis des outils compilés pour Cygwin.

L'outil utiliserait des chemins en dur qui ne correspondent pas à ta conf ?