Discussion :

[JolyLoic]

Plus sérieusement, même si ce sont deux langages différents avec un "tronc commun", je fais autant de C++ "pur et dur" que de "C with classes" que de C "le dév qui murmurait à l'oreille des CPU"... Et c'est aussi grâce à ça que j'ai du boulot, d'ailleurs : je connais les deux langages, et je sais les faire cohabiter lorsque c'est nécessaire.

Le domaine de l'embarqué est certainement un de ceux où le C est encore nécessaire.

A mon sens, il est important de connaître les deux. La "guéguerre" pour savoir lequel des deux est le plus beau est encore plus stérile que toutes les autres guerres de langage, car ils restent quoi que l'on dise indissociables l'un de l'autre. Les API des OS sont toutes en C, par exemple, et ça n'a jamais tué un dév C++ d'utiliser ces primitives "C" dans des classes C++, non ?

Je fais une nuance entre "connaître assez de C pour comprendre et utiliser une interface écrite en C" et "être capable de développer en C". Autant le premier point me semble nécessaire dans tous les cas, autant le second me semble inutile dans un grand nombre de contextes (en tout cas, en 12 de boulot en C++, je n'en n'ai jamais eu besoin).

Pour ce qui est des API d'OS en C, déjà, ce n'est pas forcément vrai (Next, Windows qui a des API en COM, et commence à proposer des API .NET par endroit), en plus, je suis loin d'être certain que ça n'ait jamais tué personne, par les bugs que ça a pu introduire, mais je n'ai pas d'exemple concret

Mais surtout, c'est une chose très lourde qui rend l'utilisation de ces API lourde, peu intuitive et risquée.

La preuve, c'est le nombre de gens qui prennent une bibliothèque portable en C++ wrappant une partie de l'OS alors même qu'ils savent bien que la portabilité ne sera jamais utilisée, simplement parce qu'elle offre une API plus agréable d'emploi (par exemple boost::thread, boost::filesystem) ou qui développent eux même un wrapper par dessus l'OS, dès qu'il s'agit d'appeler la fonction plus d'une fois (exemple : J'ai écrit une série de fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
template<class DestStringType, class SourceStringType>
DestString string_cast<DestStringType>(SourceStringType const &str)

pour wrapper les fonctions de conversions de types de caractères de windows, pour accéder à la registry, je me suis fait ma classe qui gère les libérations de ressources...).

[r0d]

Par contre, moi je ne suis pas contre utiliser du code C dans un projet C++, mais alors en prenant certaines précautions:
. le code C en question soit propre (autrement dit, savoir programmer en C)
. que ce soit séparé: au moins que le code C soit dans des fichiers séparé (avec extern C{} etc.) ou mieux, dans une lib à part.

Bref, ne pas mélanger les deux finalement.

[3DArchi]

Salut,
Les pratiques ne changeront pas tant qu'on pensera que C et C++ sont suffisamment cousins pour être mélangés allègrement. Cependant, à un moment, il faut se confronter à la réalité : beaucoup de projets C++ - mais pas tous - mêlent les 2. Et souvent, les annonces que j'ai vu mentionnent 'C/C++' même quand il ne s'agit que de C ou que de C++. Et certains projets sont obligés d'avoir des couches basses en C et des couches métiers en C++ ... avec une partie commune. Pas facile de trancher
Ensuite vient la question de départ : faut-il enseigner conjointement le C et le C++ ? Est-ce que le C++ est encore enseigné en tant que langage objet ? D'après ce que j'entends, on a plutôt tendance à enseigner le Java comme langage objet. Le C++ n'arrivant à se glisser que comme seconde partie du cours de C D'où une partie du problème.
L'intéressant serait de faire venir un prof qui nous donne son point de vue avec ses contraintes d'enseignement, sa vision plus globale d'un cursus, etc. Sans quoi je crains qu'on ne prêche que des convertis.

P.S. : @rod : le catalan ce n'est que du castillan parlé dans le sud de la france. Alors que le gallego, non ! C'est différent : c'est une vrai langue

[Invité]

Et souvent, les annonces que j'ai vu mentionnent 'C/C++' même quand il ne s'agit que de C ou que de C++.

En général, on met les 2 parce que les programmes sur lesquels on travaille sont du C++ (en ce sens qu'on utilise la syntaxe du C++ et qu'on compile avec un compilateur C++) mais incluant des bouts de code qui relèvent davantage du procédural façon C que du C++ moderne.

Dire C/C++, c'est une façon de dire au programmeur : c'est du C++ mais attends toi à trouver des bouts de C dedans, et oui on sait que ce ne sont pas les bonnes pratiques, mais non, on s'en fout parce que ces bouts de C sont solides et testés.

C'est aussi un moyen de chasser les pinailleurs...


Quant à la séparation stricte dont parle RoD, souvent, on va récupérer une fonction, un bout de librairie, qu'on va utiliser telle quelle. Isoler ces librairies dans un module spécifique *parce que c'est du C* est possible, mais cela casse la logique du découpage en modules fonctionnels.

On en revient toujours au principe de réalité (je ne parle de la programmation C bas niveau qu'évoque Mac Lak, je ne la connais pas). Aujourd'hui, les offres d'emplois pour des developpeurs C++ portent majoritairement sur ces programmes hybrides, qui mèlent C et C++, souvent pour des raisons historiques.

La chance des développeurs C++, c'est qu'il y en a beaucoup, des programmes comme ca. Et qu'ils dureront pas mal de temps.

Le malheur des développeurs C++, c'est qu'on ne fait pas du beau C++ propre comme dans les livres...

Et la question pour les recruteurs, c'est de trouver des dev C++ qui seront suffisament enthousiastes pour faire progresser l'existant C/C++ vers un C++ meilleur, mais suffisament raisonnables pour ne pas se tirer une balle dans le pied la première semaine, en expliquant qu'il faut tout refaire...

Francois

[Luc Hermitte]

Et tant que l'on perdurera avec cette approche non pinailleuse, on continuera à faire du C/C++ pénible à maintenir sur les nouveaux projets ...

[3DArchi]

En général, on met les 2 parce que les programmes sur lesquels on travaille sont du C++ (en ce sens qu'on utilise la syntaxe du C++ et qu'on compile avec un compilateur C++) mais incluant des bouts de code qui relèvent davantage du procédural façon C que du C++ moderne.

Pour avoir fait les 2 (C et C++) en embarqué ou en PC, mon ressenti est plutôt qu'on met les 2 car dans l'esprit du recruteur, c'est la même chose. Et que beaucoup de développeur 'ancienne' génération (dont j'ai longtemps fait parti) ne perçoivent pas forcément les différences.
In fine, tu as raison : il y a le ciel et il y a la terre. Et on vit sur terre donc il faut aussi savoir cohabiter avec la réalité

[Médinoc]

Généralement, j'ai tendance à dire C∩C++ pour parler du sous-ensemble commun aux deux langages. Il m'arrive trop souvent de programmer ainsi, mais au moins j'en suis conscient.

[Jean-Marc.Bourguet]

Avant de repondre a la question, il me semble necessaire de determiner le contexte de la formation.

Quel est le public cible?
Quels sont les prerequis?
Quels sont les objectifs de la formation?
Quels sont les autres matieres?
Quels sont les volumes horaires assignes a chacune de ces matieres?
Quels sont les dependances? (Entre les matieres, avec des stages, ...)

[Invité]

Et tant que l'on perdurera avec cette approche non pinailleuse, on continuera à faire du C/C++ pénible à maintenir sur les nouveaux projets ...

Je ne crois pas... Il y a une évolution, lente, comme tout ce qui se fait dans le monde réel, mais bien réelle, de la façon dont on programme en entreprise.

Mais c'est lent, la STL commence à devenir la norme. Boost, c'est encore le futur, mais on commence à voir des templates utilisés de façon sérieuse.

C'est la réalité du métier, le C++, c'est souvent employé sur de gros programmes, gérés par des équipes importantes, et ayant de longues durées de vie. Ce sont des grosses machines, qui tournent lentement.

Francois

[r0d]

Avant de repondre a la question, il me semble necessaire de determiner le contexte de la formation.

Quel est le public cible?
Quels sont les prerequis?
Quels sont les objectifs de la formation?
Quels sont les autres matieres?
Quels sont les volumes horaires assignes a chacune de ces matieres?
Quels sont les dependances? (Entre les matieres, avec des stages, ...)

Effectivement, c'est très pertinent comme remarque. Mais l'idée originale de ma question portait plus sur une réflexion générale, qui s'appliquerait à tous types de formations. Peut-être est-ce tout simplement impossible de généraliser autant... cela explique peut-être le troll?

[Mac LAK]

Le domaine de l'embarqué est certainement un de ceux où le C est encore nécessaire.

Oh, pas que là : les couches bas niveau le requièrent aussi (driver, kernel, etc.) pour des raisons de performances. Certes, il est possible d'avoir du C++ quasiment aussi performant que du C, mais cela a un coût : inlining à outrance (= adieu la RAM), ou suppression des possibilités d'héritage (classes statiques) pour éliminer l'indirection induite par les classes qui, dans un tel domaine, peut parfois devenir rédhibitoire.

Je fais une nuance entre "connaître assez de C pour comprendre et utiliser une interface écrite en C" et "être capable de développer en C". Autant le premier point me semble nécessaire dans tous les cas, autant le second me semble inutile dans un grand nombre de contextes (en tout cas, en 12 de boulot en C++, je n'en n'ai jamais eu besoin).

Disons que c'est tout à fait normal si ce n'est pas toi qui développe lesdites couches basses...

Pour ce qui est des API d'OS en C, déjà, ce n'est pas forcément vrai (Next, Windows qui a des API en COM, et commence à proposer des API .NET par endroit), en plus, je suis loin d'être certain que ça n'ait jamais tué personne, par les bugs que ça a pu introduire, mais je n'ai pas d'exemple concret

Tu as un souci d'intéropérabilité avec les langages avec les API en C++, à cause de l'ABI. A noter d'ailleurs que COM est orienté objet, mais ce n'est pas de l'objet.

A COM interface is not an object. It is simply a related group of functions and is the binary standard through which clients and objects communicate. As long as it can provide pointers to interface methods, the object can be implemented in any language with any internal state representation.

Du coup, c'est portable et utilisable dans tous les langages de programmation supportant l'importation de fonctions C classiques (WINAPI). Pour ceux qui ne voient pas de quoi je veux parler, c'est en gros une structure avec des tas de champs qui sont des pointeurs de fonction.
Par contre, je te confirme que les MFC et .NET sont bel et bien de l'objet pur et dur. Du coup, utiliser les MFC en dehors du C++ sous Visual est, je pense, impossible (ou alors, chapeau à celui qui a réussi). Pour .NET, c'est du managé, donc c'est aussi une ABI différente, et qui n'a pas de "passif" : les langages .NET se sont simplement adaptés à l'ABI définie, donc pas de soucis d'intéropérabilité du coup.

La preuve, c'est le nombre de gens qui prennent une bibliothèque portable en C++ wrappant une partie de l'OS alors même qu'ils savent bien que la portabilité ne sera jamais utilisée, simplement parce qu'elle offre une API plus agréable d'emploi <...> ou qui développent eux même un wrapper par dessus l'OS, dès qu'il s'agit d'appeler la fonction plus d'une fois <...>

Oui et non : il y a trois raisons à ça, et pas forcément la syntaxe plus ou moins agréable.

La première, c'est de rendre des fonctions [quelquechose]-safe alors qu'elles ne le sont pas naturellement, et ceci en évitant d'avoir à chaque fois à appeler plusieurs fonctions (et surtout en évitant de les oublier ! ).
Le thread-safe est courant, bien sûr, mais parfois c'est le rendre process-safe qui est nécessaire, ou une protection quelconque spécifique.
Cette raison d'encapsuler est très saine : on groupe des fonctions qui sont des primitives du système afin d'effectuer des opérations un peu plus complexe, tout en gardant une interface simple au niveau du système (fonctions basiques et unitaires, donc).

La seconde, c'est la portabilité entre plusieurs OS. Certes, il existe de nombreuses librairies permettant de telles abstractions, mais elles ne sont pas toujours adaptées au besoin : elles peuvent être trop lourdes, trop light, ne pas supporter la plate-forme désirée, etc.
Cette raison est également très saine, que l'on refasse ou que l'on utilise peu importe. On abstrait une dépendance à un système d'exploitation (ou à un processeur) via les possibilités du langage. On peut aussi le faire en C, c'est vrai, mais on arrive souvent devant le problème non négligeable des surcharges.

La dernière, c'est de ne pas avoir réussi à comprendre qu'une fonction C peut être appelée depuis du C++, et surtout de croire que si ce n'est pas une classe, c'est forcément "mal" et "pas C++".
Cette raison là est au contraire malsaine, et entretient la guéguerre entre les deux langages. Wrapper un truc aussi primaire et autonome que "GetTickCount()" (sous Windows) dans une classe qui ne contient que cette méthode, c'est franchement débile. Rigole pas, j'ai hélas déjà vu ça dans du code.

C'est la réalité du métier, le C++, c'est souvent employé sur de gros programmes, gérés par des équipes importantes, et ayant de longues durées de vie. Ce sont des grosses machines, qui tournent lentement.

Tout à fait. 10 à 25 ans en moyenne... A mes débuts, il y a 10 ans, utiliser la STL était synonyme de galère en chaîne, de performances minables, d'inflation de la taille des binaires et de bugs à tout va. J'ai passé plus de six mois à péter du code STL posant problème (STL pas si standard que ça, support des templates aléatoire, etc.) vers du C (ou même du C++) "à la main", mais qui offrait les performances attendues.

Dix ans plus tard, je fais (presque) le contraire : les compilateurs ont évolué, les anciennes plate-formes deviennent obsolètes (et LE compilateur de la plate-forme avec au passage), et les choses évoluent au fur et à mesure de la reprise du code. Sauf qu'il faut continuer à expliquer aux dévs débutants que des choses comme les maps indexées par des strings, ou des réallocation de mémoire en plein milieu d'un code temps réel, c'est mal...

[JolyLoic]

La première, c'est de rendre des fonctions [quelquechose]-safe alors qu'elles ne le sont pas naturellement, et ceci en évitant d'avoir à chaque fois à appeler plusieurs fonctions (et surtout en évitant de les oublier ! ).
Le thread-safe est courant, bien sûr, mais parfois c'est le rendre process-safe qui est nécessaire, ou une protection quelconque spécifique.

Le memory-leak-safe (et sa version plus luxueuse le exception-safe, qui vient quasiment pour le même prix) est pour moi la principale raison de wrapping. Toutes ces fonctions qui allouent des buffers de caractères, des handles, du lock/unlock en deux fonctions séparées, ça me met mal à l'aise.

Cette raison là est au contraire malsaine, et entretient la guéguerre entre les deux langages. Wrapper un truc aussi primaire et autonome que "GetTickCount()" (sous Windows) dans une classe qui ne contient que cette méthode, c'est franchement débile. Rigole pas, j'ai hélas déjà vu ça dans du code.

Pour ma part, je plaide coupable d'avoir wrappé QueryPerformanceCounter, et de deux manières en plus... Et si c'était à refaire, je le referais, et je pense que j'aurais le même raisonnement pour GetTickCount. Pourquoi ? Car mon wrapping apportait des fonctionnalités supplémentaires. Dans un cas, juste la mémoire de l'instant de démarrage de l'horloge, et l'affichage du résultat dans une unité gérable par un humain : la seconde.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Clock clk;
f();
cout << "f a duré " << clk.run() << "s" << endl;

Dans un autre cas, la même chose, plus la gestion de pauses où l'on arrête de mesurer le temps.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Clock clk;
f();
clk.pause();
dumpDebugData();
clk.resume();
g();
cout << "f+g ont duré " << clk.run() << "s" << endl;

[Mac LAK]

Toutes ces fonctions qui allouent des buffers de caractères, des handles, du lock/unlock en deux fonctions séparées, ça me met mal à l'aise.

Il est parfois nécessaire de laisser deux fonctions pour ça à cause de traitement très longs et/ou interprocess : en général, je les appelle "StartXXXX" / "StopXXXX" ou "BeginXXXX" / "EndXXXX" en fonction du contexte. Toutefois, c'est sûr que pour protéger une fonction par mutex, une classe d'autolock par portée est préférable.

Pour ma part, je plaide coupable d'avoir wrappé QueryPerformanceCounter, et de deux manières en plus... Et si c'était à refaire, je le referais, et je pense que j'aurais le même raisonnement pour GetTickCount. Pourquoi ? Car mon wrapping apportait des fonctionnalités supplémentaires. Dans un cas, juste la mémoire de l'instant de démarrage de l'horloge, et l'affichage du résultat dans une unité gérable par un humain : la seconde.

Pour QPC, c'est très différent, et je l'ai fait aussi. Pourquoi ? Parce que déjà, il faut utiliser QueryPerformanceFrequency avant, en stocker la valeur, et que l'unité "finale" (liée à la résolution du timer) ne peut pas être connue à l'avance, contrairement à GetTickCount, ou autres gettimeofday, par exemple. Donc, là, le besoin d'une classe rentre dans le premier cas que j'énonçais, et tu n'es coupable de rien !
D'ailleurs, ma classe Delphi gérant ça est même encore pire : elle adapte l'unité d'affichage en fonction de la durée écoulée, de la nanoseconde jusqu'à l'heure...

Moi, je te parle d'un goret (pas d'autre mot) qui, à quelques lignes près, a pondu cette classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
class TickCount {
  public:
    TickCount() {} ;
    virtual ~TickCount() {} ;
 
    virtual unsigned long int GetTick() { return GetTickCount() ; }
 
} ;

Tu remarqueras l'absence de "static" gaiement remplacé par du "virtual", l'inutilité de la classe vu le manque de valeur ajoutée (pas même un << ou >> redéfini...), pas même un namespace qui pourrait justifier un truc comme ça et autres joyeusetés du même ordre. Promis, je n'invente pas, j'ai réellement vu ce ... machin, on va dire, dans un projet.

[metagoto]

Moi, je te parle d'un goret (pas d'autre mot) qui, à quelques lignes près, a pondu cette classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
class TickCount {
  public:
    TickCount() {} ;
    virtual ~TickCount() {} ;
 
    virtual unsigned long int GetTick() { return GetTickCount() ; }
 
} ;

Il aurait au moins pu mettre ça dans une struct, ça aurait déjà eu plus de gueule

Je ne crois pas... Il y a une évolution, lente, comme tout ce qui se fait dans le monde réel, mais bien réelle, de la façon dont on programme en entreprise.

Mais c'est lent, la STL commence à devenir la norme. Boost, c'est encore le futur, mais on commence à voir des templates utilisés de façon sérieuse.

Moi j'ai l'impression que boost commence à entrer en force dans de nombreux projets.. en tout cas open sources puisque j'ai pu regarder leur codes. Pour les trucs fermés spécifiques aux entreprises, là j'en sais trop rien. En top des charts, je dirais boost *_ptr, lexicalcast, noncopyable (), regex. A vrai dire, j'ai bien l'impression que ces librairies sont utilisées de manière plus fréquente que ce qu'on trouve dans <algorithm>.

[Invité]

Moi j'ai l'impression que boost commence a entrer en force dans de nombreux projets.. en tout cas open sources puisque j'ai pu regarder leur codes. Pour les trucs fermés spécifiques aux entreprise, là j'en sais trop rien.

J'ai l'impression que l'open source est toujours plus "moderniste" que le monde de l'entreprise. J'y vois trois raisons :

- les projets sont plus récents (un projet open source qui à 5 ans, c'est déjà un truc bien établi, un logiciel d'entreprise du même âge est très très jeune)
- les développeurs sont généralement plus jeunes (donc plus friands de modernité)
- les programmes open source servent souvent de vitrine à leurs auteurs, il y a une forte tendance à privilégier des approches techniques, modernes, voire hasardeuses, l'entreprise, à l'inverse, favorise l'ancien et l'éprouvé

Ce que j'observe, néanmoins, c'est qu'en entretien, on te regarde moins avec de grands yeux quand tu dis boost qu'il y a deux ou trois ans (dans ces entretiens je suis du coté du recruteur, et je vois souvent des gens ayant déjà une expérience).

En top des charts, je dirais boost *_ptr, lexicalcast, noncopyable (), regex. A vrai dire, j'ai bien l'impression que ces librairies sont utilisées de manière plus fréquente que ce qu'on trouve dans <algorithm>.

Pour regex, ca s'explique par le fait qu'il s'agit d'une technique ancienne, bien connue, mais pour laquelle il n'y avait pas de solution "de base". Boost remplit ce vide. Pour les pointeurs, boost comble une lacune de la STL.

Maintenant, pour <algorithm>, je ne suis pas d'accord. Les find(), copy(), fill() remove() et sort(), et merge() sont assez communément utilisés (parce qu'ils répondent à des besoins courants).

Les algorithmes plus "génériques" (transform et autres qui prennent des foncteurs en paramètres) le sont moins.

On pourrait dire la même chose des conteneurs, d'ailleurs. Les vecteurs et les string sont passés dans la pratique. Les map et les set sont utilisés (mais presque toujours de travers), les list, les deques, et les multi*, très peu.

En fait, et ca nous ramène au début de cette discussion, partout ou la STL ou Boost apportent une solution efficace à un problème classique (tris, recherches, copies, tableaux associatif, expressions régulières), ils sont utilisés.

Partout où ils introduisent une nouvelle façon d'aborder un problème (inner_product, partial_sum), ils mettent plus de temps.

Francois

[r0d]

J'ai l'impression que l'open source est toujours plus "moderniste" que le monde de l'entreprise. J'y vois trois raisons

Je ne sais pas trop ce que tu entends par "moderniste"... peut-être le fait d'assimiler des notions qui ont montré leur efficacité récemment?
De toutes façons, il n'y a aucune raison de couper un cheveux en quatre ici, la raison est vraiment très simple: la collaboration est plus efficace que la concurrence.

[Invité]

J'ai mis le mot entre guillemets parce que je n'en trouvais pas de meilleur. Par moderniste, je voulais dire sensible à la nouveauté. Le monde de l'open source intègre rapidement les nouveautés techniques, celui de l'entreprise avance plus prudemment, et plus lentement.

Je ne crois pas que l'un ait raison et que l'autre ait tort. En se précipitant sur toutes les nouveautés techniques, on progresse plus vite, mais on essuie les plâtres (il y a des idées à la mode qui se révèlent mauvaises, en informatique comme ailleurs). En attendant trop longtemps, on limite les risques, mais aussi la croissance.

Francois

[GR3lh442kR]

Salut!

programmeur "C with class"

Je me considère malheureusement comme ça, et j'avoue que c'est surement la faute des profs, le problème c'est peut être aussi les compilateur qui acceptent le mélange des 2 sans problème.

J'aimerai beaucoup savoir réellement coder en C++, mais ça simplifie pas mal la programmation (pas le programme hein) d'utiliser du C dans le code, plutôt que d'aller chercher et de comprendre le fonctionnement d'un moyen de le faire en C. BOOST par exemple, c'est tellement vaste que je ne sait même pas par ou l'aborder, je ne sait même pas si ça me sera réellement profitable... surement mais bon...

peut être y aurait il moyen de faire une FAQ "du C au C++" montrant pour des problèmes récurant comment faire en C++ l'équivalent d'un bout de code en C.
Par exemple, sur mon dernier projet en "C with class" je me suis décidé a utiliser les fonctions/méthodes C++ pour la gestion des fichiers plutôt que les fonctions C que j'utilisai jusque maintenant. le problème c'est que ça m'a tout fait planter, alors pour éviter de perdre du temps a chercher, (je suis feignant, c'est ma faute) ben j'ai finalement utilisé... le C...

bref, le C++ , quand on connait déjà le C, il faudrait l'aborder comme un nouveau langage, mais je pense que personne le fait, personnellement j'essaye de migrer petit a petit, mais c'est pas facile sans personne pour me dire "tu devrais utiliser ça plutôt que ça, ça te simplifierai la vie..."

[Lavock]

... mais c'est pas facile sans personne pour me dire "tu devrais utiliser ça plutôt que ça, ça te simplifierai la vie..."

Je penses que tout le problème est là... L'apprendre comme un nouveau langage, c'est peut-être (même très certainement) une bonne solution. Mais pas facile lorsque ça se ressemble autant.

Le problème est en soit que l'enseignement s'arrête généralement au C with Classes...
Honnêtement, pour boost, je suis a peu près dans le même cas que toi. J'essaye de regarder si il y a des trucs qui pourrait m'intéresser dedans au cas part cas, et si oui, je m'y penche sérieusement. Il y a aussi la STL, et c'est d'ailleurs prioritaire à mon avis, que tu dois apprendre à maîtriser.

Malheureusement, si tu veux bien apprendre, il y a un moment ou tu dois prendre ton temps : dit toi que faire du "vrai" C++, c'est du temps de gagner en cas de mis-à-jour de ton programme.

[Goten]

J'ai l'impression que l'open source est toujours plus "moderniste" que le monde de l'entreprise. J'y vois trois raisons :

Ah bon? J'ai l'impression contraire. Que par l'héritage et l'habitude la grande majorité des projets open source reste ancré dans la tradition C.

@ lavock : t'as changé d'avis au final ? :p. (sur l'apprentissage).

Quand a boost, j'étais comme ça aussi plus 'jeune' (comprendre y'a quelques mois xD) finalement faut commencez par un bout, pas un truc énorme non plus (genre boost.spirit), si je me souviens bien j'avais commencé par boost.signal par besoin, (je compte pas smart_ptr que j'utilisais déjà) puis de fil en aiguille je me suis intéressé un peu à toute les parties assez rapidement assimilée au final. (je compte pas les trucs spécifiques comme gil ou python etc).
Mais je rejoins lavock la priorité c'est la SL.