Ils concluent à la fin que : We recommend that compilers for highly pipelined, speculative execution architectures : use profile-based static prediction methods to optimize C++ programs, use link-time information to remove indirect function calls, and customize call-sites using ‘if conversion’ based on profile information
Hors cet article date de 1994. GCC emploi depuis ces techniques et ses dérivées comme les "profile-guided optimisations" (pour les branch prediction et le l'inlining). Donc les compilos c++ actuels emploient déjà ces techniques qui se montrent aussi efficaces que les techniques dynamiques beaucoup plus couteuses en terme d'implémentation et d'overhead dans le runtime.
Pour ce qui est des appels via une table (indirection), tu auras beau mesurer dans tous les sens, ce sera toujours plus lent qu'un appel direct dans les cas génériques.
Ensuite, certaines plateformes sont optimisées pour minimiser le cout d'un appel indirect, mais ce cout sera juste dans le meilleurs des cas équivalent au cout d'un appel direct et dans les autres moins bon. Donc jamais meilleurs.
Penser à ce genre de mécanismes (même s'ils sont cachés au programmeur qui n'en ont rien à faire) à son importance dans certains contextes, par exemple pour les langages systèmes. Hors Go vise a devenir un langage système.
Exactement, quand j'ai vu les interfaces en Go je me suis tout de suite dit que j'avais déjà ça avec les templates en C++ ou en D. Cependant l'implémentation des interfaces Go ne me semblent pas claire. Quand est-ce que les mécanisme des interfaces sont ils résolu? à la compilation ou à l’exécution?
A la lecture de la documentation, j'en conclu que Go utilise des mécanisme dynamiques (résolution à l’exécution) et que les objets Go doivent embarquer une table virtuelle des méthodes pour permettre la résolution dynamique, voir plus lourds comme une table de signature de fonctions.
J'imagine quand même que quand la résolution peut se faire de manière statique (à la compilation), Go doit optimiser et éviter des appels à cette table, sinon, j'ai peur pour les performances.
Quelqu'un qui s'y connait dans l'implémentation des mécanismes de Go peut-il nous donner des exemple et nous pointer du doigt quand est-ce que la résolution se fait de manière statique et quand elle se fait de manière dynamique?
Il y a des entêtes internes au noyau et ce sont celles-là que linus considère non utilisable. La phrase de Linus en 2003 parlait des entête internes qui possèdent par exemple un grand nombre de macros qui ne sont donc plus seulement considérées comme des entêtes mais aussi comme du code source. Il répondait à un gars qui souhaitait les utiliser sans respecter la GPL, et Linus lui avait fait savoir que celà n'était pas possible.
Pour les entêtes user land, là linus à toujours été clair et dit que les entêtes ne contenant pas de code pouvaient être utilisés sans être considéré comme un travail dérivé.
Ouais, heureusement que debian est passé à eglibc. Je pense que Bosser avec Ulrich Drepper doit être une galère de tous les instants. Je plains ses collaborateurs.
Je dirais, parce que toutes les architectures n'ont pas de mécanisme de huge page et qu'utiliser des huge pages pour des petits processus on peut considérer ça comme du gachi.
Il vaut donc mieux utiliser par défaut le plus petit dénominateur commun et utiliser des pages plus grosses si le processus se met à utiliser plus de mémoire et que le mécanisme est fournit par l'architecture.
Plutôt que de faire un journal (j'espère que ça ne va pas devenir une habitude que tout le monde poste dans les journaux pour avoir plus de visibilité), envoye ton CV sur Lolix.
Lolix est orienté logiciel libre, et les sociétés qui cherchent des profils linux connaissent bien ce site. Tu auras plus de chance de trouver la-bas un œil intéressé, plutôt qu'ici.
Faisant du Vala a mes heures perdues... certainement pas.
Vala est très orienté GLib/GObject/Gtk. Le complilateur souffre de problèmes encore graves, qui font qu'un code qui compile avec la version X, ne compilera pas avec la version Y (X < Y).
Bref, vala est encore expérimental, et très orienté Linux pour le moment.
Le concurrent de C#, c'est plutôt Java qui ont tout les 2 un compilateur en Code Objet et un interpretteur JIT.
Python a plutôt comme concurrent, Perl et Ruby d'après ce que je vois.
Moi ce que je vois, c'est qu'il y a des torts des deux côtés.
KDE produit effectivement rarement des technologies non liées à Qt, et celà freine forcément l'adoption de ces technologies sur d'autres environnements. Gnome possède un processus très lourd (et lent) dans sa façon de normaliser une techno.
Pour ce qui est de réinventer la roue, les deux projets ont autant de mérites.
Cependant, pour les technologies issues de gnome, pulseaudio et DBus n'en font pas parti. Ce sont plutôt des technos de RedHat qui voulait dans les deux cas des implémentation qui ne soient pas dépendantes de l'une ou l'autre des plateformes. Ils ont refait DCOP en DBUS, car DCOP était trop couplé à Qt. Pour PulseAudio, les solutions qui existaient (ESD, ARTSD, JACK) ne répondaient pas bien au problème de mixage audio et chaque plateforme avait la sienne.
Le fait que gnome ait été prompt a adopter ces technologies et a participer a leur développement n'en fait pas des technologies issues de gnome pour autant.
A la lecture de l'article qui suis par là
On constate qu'il se pourrait que RedHat se mette a violer la GPL. En effet, une close de non divulgation (des sources entre autre) serait désormais demandé a ses clients, sans quoi, plus de support.
Red Hat grants you a personal, non-assignable license to use Red Hat Content for your own internal use while you are a Red Hat Customer (as defined in Section 2 above). Distributing any portion of Red Hat Content to a third party, using any Red Hat Content for the benefit of a third party or using Red Hat Content in connection with software other than Red Hat Software under an active Red Hat subscription are all prohibited. Red Hat authorizes you to display on your computer, download, play and print the Red Hat Content provided: (a) the copyright notice is not removed, (b) Red Hat Content is not be altered, (c) Red Hat Content is used only for your personal, educational and non-commercial use in support of your active valid subscriptions to Red Hat products and services and in accordance with your Customer Agreement, (d) you do not further redistribute or copy Red Hat Content and (e) you comply with any Additional Terms. In the event of a conflict, inconsistency or difference between this Section 6 and the terms of a License or Customer Agreement, the License or Customer Agreement will control (for example, for Red Hat Content licensed under a Creative Commons License, you will have the rights set forth in the applicable Creative Commons License). If you exceed your authorized use of Red Hat Content (for example, if you use Red Hat Content in support of Software for which you do not have an active valid subscription), you may be required under your Customer Agreement to purchase additional subscriptions to Red Hat products. In addition, your right to continue to access Red Hat Content from a Red Hat Portal is subject to your continued compliance with these Terms of Use, your Customer Agreement and the Additional Terms.
Confidentiality.
Red Hat Content may contain information that is designated as "confidential" and you agree not to disclose such information without Red Hat's prior written consent.
Je trouve que ça pose en effet de gros problèmes de compatibilité avec la GPL... car ils ne peuvent pas enpêcher leurs clients de divulguer du code GPL, même s'il leur appartient ou que les patch on été fait par eux.
ça risque de faire des vagues dans la communauté.
Tu a du mal comprendre. Je répondais a ta phrase :
mais new et delete sont nécessaires à la vie quotidienne du développeur C++
Mais je t'assure qu'on on peut très bien s'en passer en utilisant toute la palette des shared_ptr/shared_array/weak_ptr/auto_ptr/unique_ptr/scoped_ptr/scoped/array/rollback_ptr. Je n'utilise plus de delete depuis des lustres.
Comme le dit lupus_mic tu n'as pas compris ou se générait l'exception. Tu as oublié un point dans tes étapes, donc voici le déroulement complet de l'exécution :
copie de T pour pouvoir le retourner
suppression de T de la queue
copie de T au return <------ génération de l'exception
L'étape 3 peut être optimisé par le compilateur qui évitera de faire une copie dans certains cas par exemple en cas d'inlining, mais ce n'est pas garanti. Ne jamais oublier qu'une copie au retour de paramètre peut soulever des exceptions.
Savoir si une fonction est exception safe est important quand tu programme un truc qui doit être fiable (tourner sans planter plusieurs années sans être relancé).
Je ne saurais trop te conseiller la lecture de cet article sur la réalisation des interfaces exceptions safe.
De plus, sache qu'effectivement,les implémentation C#, Java ne sont pas exception safe. Ce qui pose un gros problème de robustesse. Cependant, pour faire du code robuste, on ne fait pas de c# ou du Java, c'est une question de bon sens, vu qu'il y a des bugs dans les implémentation des VM et des compilateurs JIT!
Je t'avoue que depuis que j'ai découvert les multi-index de boost, je ne jure que part eux en lieu et place de la std::map et std::set car en général on veux gérer plusieurs index et pas qu'un seul.
C'est franchement le conteneur ultime.
L'exception pourra se produire à la copie du paramètre retourné par split vu qu'il y a allocation mémoire et appel a un constructeur.
La copie de QStringList n'aura pas ici d'influence si tu fais un catch car split ne modifie pas à priori l'état de l'objet qui l'appelle... mais pour d'autres méthodes dans Qt c'est le cas.
Exemple avec QQueue :
Si une exception est générée à l'appel de dequeue (au moment de la copie):
Et bien tu te retrouve dans un état irrecupérable car tu a perdu ta chaine de caractère. C'est un peu partout pareil dans Qt et j'ai pas le temps de débusquer toutes les erreurs de design.
Donc je ne l'utilise que pour l'interface graphique, pour le reste boost et la stl le font mieux.
Il ne s'agit pas ici de splitter mais de faire un join...
Donc oui, on peut vouloir faire un join de nombres et de classes si ils peuvent être transformer en chaine de caractère!
Le truc c'est que la façon de faire de Qt n'est pas exception safe. Ce qui fait que si une exception est générer à l'appel de split t'auras des fuites mémoires.
Avec la façon de faire de boost et de la stl en général, ton code est exception safe car le design à été pensé dans cette optique.
C'est toute la différence, entre faire du code rapide a écrire et faire du code robuste. Entre les deux il faut choisir.
Moi pour tout ce qui ne touche pas à l'interface j'ai depuis longtemps fait mon choix d'utiliser boost à cause des problèmes du aux exceptions et pour l'interface graphique et seulement elle d'utiliser Qt ou Gtkmm en fonction des besoins.
Et bien a l'usage, je trouve que minuscules et underscore sont bien plus lisibles que camel case. C'est juste que dans l'enseignement on utilise partout camel case et changer ses habitudes pour mieux est parfois une dure expérience.
Pourquoije trouve ça mieux?
* déjà quand on tape, on gagne du temps si l'on utilise pas la complétion automatique car on n'a pas à appuyer sur shift pour utiliser des majuscules. On tape donc donc comme on écrit, vu que l'underscore est accessible sans combo clavier.
* on lit plus facilement, car on ne doit pas faire l'effort (car on a plus l'habitude de lire du texte espacé) de séparer les mots mentalement pour obtenir leur signification.
Au final, la syntaxe de la librairie standard du c++ et boost sont devenus une norme dans tous les projets de développement chez nous et on a gagné en lisibilité lors des relectures du code
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par ecyrbe . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 4.
Ils concluent à la fin que :
We recommend that compilers for highly pipelined, speculative execution architectures : use profile-based static prediction methods to optimize C++ programs, use link-time information to remove indirect function calls, and customize call-sites using ‘if conversion’ based on profile information
Hors cet article date de 1994. GCC emploi depuis ces techniques et ses dérivées comme les "profile-guided optimisations" (pour les branch prediction et le l'inlining). Donc les compilos c++ actuels emploient déjà ces techniques qui se montrent aussi efficaces que les techniques dynamiques beaucoup plus couteuses en terme d'implémentation et d'overhead dans le runtime.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par ecyrbe . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 2.
Pour ce qui est des appels via une table (indirection), tu auras beau mesurer dans tous les sens, ce sera toujours plus lent qu'un appel direct dans les cas génériques.
Ensuite, certaines plateformes sont optimisées pour minimiser le cout d'un appel indirect, mais ce cout sera juste dans le meilleurs des cas équivalent au cout d'un appel direct et dans les autres moins bon. Donc jamais meilleurs.
Penser à ce genre de mécanismes (même s'ils sont cachés au programmeur qui n'en ont rien à faire) à son importance dans certains contextes, par exemple pour les langages systèmes. Hors Go vise a devenir un langage système.
[^] # Re: Hassan Cehef
Posté par ecyrbe . En réponse à l’entrée du suivi Créer de nouvelles sections et en effacer d'autres. Évalué à 1 (+0/-0).
Pour C/C++ je vous donne ce logo fait avec inkscape et vous autorise à le mettre sous la license qu'il vous plaira :
[^] # Re: Quelle CSS ?
Posté par ecyrbe . En réponse à l’entrée du suivi CSS Signature. Évalué à 1 (+0/-0).
Avec quel navigateur?
[^] # Re: Logo ?
Posté par ecyrbe . En réponse à l’entrée du suivi Ajouter une catégorie « Distribution ». Évalué à 2 (+0/-0).
Un manchot linux ne serait-il pas adapté à ce type de situation générique?
[^] # Re: Oh non!
Posté par ecyrbe . En réponse à l’entrée du suivi Du vert dans grises.css. Évalué à 2 (+0/-0).
Vu les couleurs utilisées par cette css, on pourrait mettre du bleu.
au lieu de :
on pourrait mettre
En tout cas c'est la couleur que j'ai appliqué chez moi et qui ressort bien et ne jure pas avec le thème.
[^] # Re: Pas évident
Posté par ecyrbe . En réponse à l’entrée du suivi Hébergement de css. Évalué à 1 (+0/-0).
Je suis d'accord, si l'on ne permet pas de partager sa css avec d'autres utilisateurs celà ne devrait pas être un soucis...
[^] # Re: Quelle CSS ?
Posté par ecyrbe . En réponse à l’entrée du suivi CSS Signature. Évalué à 1 (+0/-0).
ça le fait avec la css 'grises' et 'opensuse'
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par ecyrbe . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 3.
Exactement, quand j'ai vu les interfaces en Go je me suis tout de suite dit que j'avais déjà ça avec les templates en C++ ou en D. Cependant l'implémentation des interfaces Go ne me semblent pas claire. Quand est-ce que les mécanisme des interfaces sont ils résolu? à la compilation ou à l’exécution?
A la lecture de la documentation, j'en conclu que Go utilise des mécanisme dynamiques (résolution à l’exécution) et que les objets Go doivent embarquer une table virtuelle des méthodes pour permettre la résolution dynamique, voir plus lourds comme une table de signature de fonctions.
J'imagine quand même que quand la résolution peut se faire de manière statique (à la compilation), Go doit optimiser et éviter des appels à cette table, sinon, j'ai peur pour les performances.
Quelqu'un qui s'y connait dans l'implémentation des mécanismes de Go peut-il nous donner des exemple et nous pointer du doigt quand est-ce que la résolution se fait de manière statique et quand elle se fait de manière dynamique?
[^] # Re: PCI : Raccrochage de branche
Posté par ecyrbe . En réponse au journal [ en attendant Vendredi ] Google, Linux et GPL. Évalué à 9.
Il y a des entêtes internes au noyau et ce sont celles-là que linus considère non utilisable. La phrase de Linus en 2003 parlait des entête internes qui possèdent par exemple un grand nombre de macros qui ne sont donc plus seulement considérées comme des entêtes mais aussi comme du code source. Il répondait à un gars qui souhaitait les utiliser sans respecter la GPL, et Linus lui avait fait savoir que celà n'était pas possible.
Pour les entêtes user land, là linus à toujours été clair et dit que les entêtes ne contenant pas de code pouvaient être utilisés sans être considéré comme un travail dérivé.
[^] # Re: secu
Posté par ecyrbe . En réponse à la dépêche Le noyau Linux est disponible en version 2.6.38. Évalué à 5.
Ouais, heureusement que debian est passé à eglibc. Je pense que Bosser avec Ulrich Drepper doit être une galère de tous les instants. Je plains ses collaborateurs.
[^] # Re: Transparent huge pages
Posté par ecyrbe . En réponse à la dépêche Le noyau Linux est disponible en version 2.6.38. Évalué à 3.
Je dirais, parce que toutes les architectures n'ont pas de mécanisme de huge page et qu'utiliser des huge pages pour des petits processus on peut considérer ça comme du gachi.
Il vaut donc mieux utiliser par défaut le plus petit dénominateur commun et utiliser des pages plus grosses si le processus se met à utiliser plus de mémoire et que le mécanisme est fournit par l'architecture.
# Justement, pour la visibilité, il y lolix
Posté par ecyrbe . En réponse au journal Licence pro et stage ... :/. Évalué à 10.
Plutôt que de faire un journal (j'espère que ça ne va pas devenir une habitude que tout le monde poste dans les journaux pour avoir plus de visibilité), envoye ton CV sur Lolix.
Lolix est orienté logiciel libre, et les sociétés qui cherchent des profils linux connaissent bien ce site. Tu auras plus de chance de trouver la-bas un œil intéressé, plutôt qu'ici.
[^] # Re: Python et Mono
Posté par ecyrbe . En réponse à la dépêche Entretien avec des développeurs Python francophones. Évalué à 3.
Faisant du Vala a mes heures perdues... certainement pas.
Vala est très orienté GLib/GObject/Gtk. Le complilateur souffre de problèmes encore graves, qui font qu'un code qui compile avec la version X, ne compilera pas avec la version Y (X < Y). Bref, vala est encore expérimental, et très orienté Linux pour le moment.
Le concurrent de C#, c'est plutôt Java qui ont tout les 2 un compilateur en Code Objet et un interpretteur JIT. Python a plutôt comme concurrent, Perl et Ruby d'après ce que je vois.
[^] # Re: ??
Posté par ecyrbe . En réponse au journal Test de Gnome 3 sur Archlinux. Évalué à 2.
Tu as un menu déroulant en haut pour aller aux différents chapitres du test. Du coup c'est bien plus fourni que ce journal.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par ecyrbe . En réponse au journal Gnome vs Canonical: l'avis de Aaron Seigo. Évalué à 2.
Moi ce que je vois, c'est qu'il y a des torts des deux côtés.
KDE produit effectivement rarement des technologies non liées à Qt, et celà freine forcément l'adoption de ces technologies sur d'autres environnements. Gnome possède un processus très lourd (et lent) dans sa façon de normaliser une techno.
Pour ce qui est de réinventer la roue, les deux projets ont autant de mérites.
Cependant, pour les technologies issues de gnome, pulseaudio et DBus n'en font pas parti. Ce sont plutôt des technos de RedHat qui voulait dans les deux cas des implémentation qui ne soient pas dépendantes de l'une ou l'autre des plateformes. Ils ont refait DCOP en DBUS, car DCOP était trop couplé à Qt. Pour PulseAudio, les solutions qui existaient (ESD, ARTSD, JACK) ne répondaient pas bien au problème de mixage audio et chaque plateforme avait la sienne.
Le fait que gnome ait été prompt a adopter ces technologies et a participer a leur développement n'en fait pas des technologies issues de gnome pour autant.
# Violation de la GPL
Posté par ecyrbe . En réponse au journal L'engagement de Red Hat envers l'open source. Évalué à 3.
A la lecture de l'article qui suis par là
On constate qu'il se pourrait que RedHat se mette a violer la GPL. En effet, une close de non divulgation (des sources entre autre) serait désormais demandé a ses clients, sans quoi, plus de support.
Voici les paragraphes en question, dans sa licence d'accès:
Use of Content.
Red Hat grants you a personal, non-assignable license to use Red Hat Content for your own internal use while you are a Red Hat Customer (as defined in Section 2 above). Distributing any portion of Red Hat Content to a third party, using any Red Hat Content for the benefit of a third party or using Red Hat Content in connection with software other than Red Hat Software under an active Red Hat subscription are all prohibited. Red Hat authorizes you to display on your computer, download, play and print the Red Hat Content provided: (a) the copyright notice is not removed, (b) Red Hat Content is not be altered, (c) Red Hat Content is used only for your personal, educational and non-commercial use in support of your active valid subscriptions to Red Hat products and services and in accordance with your Customer Agreement, (d) you do not further redistribute or copy Red Hat Content and (e) you comply with any Additional Terms. In the event of a conflict, inconsistency or difference between this Section 6 and the terms of a License or Customer Agreement, the License or Customer Agreement will control (for example, for Red Hat Content licensed under a Creative Commons License, you will have the rights set forth in the applicable Creative Commons License). If you exceed your authorized use of Red Hat Content (for example, if you use Red Hat Content in support of Software for which you do not have an active valid subscription), you may be required under your Customer Agreement to purchase additional subscriptions to Red Hat products. In addition, your right to continue to access Red Hat Content from a Red Hat Portal is subject to your continued compliance with these Terms of Use, your Customer Agreement and the Additional Terms.
Confidentiality.
Red Hat Content may contain information that is designated as "confidential" and you agree not to disclose such information without Red Hat's prior written consent.
Je trouve que ça pose en effet de gros problèmes de compatibilité avec la GPL... car ils ne peuvent pas enpêcher leurs clients de divulguer du code GPL, même s'il leur appartient ou que les patch on été fait par eux. ça risque de faire des vagues dans la communauté.
[^] # Re: Boost ? c'est quoi ?
Posté par ecyrbe . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 2.
Tu a du mal comprendre. Je répondais a ta phrase :
mais new et delete sont nécessaires à la vie quotidienne du développeur C++
Mais je t'assure qu'on on peut très bien s'en passer en utilisant toute la palette des shared_ptr/shared_array/weak_ptr/auto_ptr/unique_ptr/scoped_ptr/scoped/array/rollback_ptr. Je n'utilise plus de delete depuis des lustres.
[^] # Re: Boost ? c'est quoi ?
Posté par ecyrbe . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 1.
tu peux utiliser les smart pointers pour ne pas faire de delete... cf: boost
[^] # Re: Boost ? c'est quoi ?
Posté par ecyrbe . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 0.
Comme le dit lupus_mic tu n'as pas compris ou se générait l'exception. Tu as oublié un point dans tes étapes, donc voici le déroulement complet de l'exécution :
L'étape 3 peut être optimisé par le compilateur qui évitera de faire une copie dans certains cas par exemple en cas d'inlining, mais ce n'est pas garanti. Ne jamais oublier qu'une copie au retour de paramètre peut soulever des exceptions.
Savoir si une fonction est exception safe est important quand tu programme un truc qui doit être fiable (tourner sans planter plusieurs années sans être relancé).
Je ne saurais trop te conseiller la lecture de cet article sur la réalisation des interfaces exceptions safe.
De plus, sache qu'effectivement,les implémentation C#, Java ne sont pas exception safe. Ce qui pose un gros problème de robustesse. Cependant, pour faire du code robuste, on ne fait pas de c# ou du Java, c'est une question de bon sens, vu qu'il y a des bugs dans les implémentation des VM et des compilateurs JIT!
[^] # Re: Boost ? c'est quoi ?
Posté par ecyrbe . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 2.
Je t'avoue que depuis que j'ai découvert les multi-index de boost, je ne jure que part eux en lieu et place de la std::map et std::set car en général on veux gérer plusieurs index et pas qu'un seul.
C'est franchement le conteneur ultime.
[^] # Re: Boost ? c'est quoi ?
Posté par ecyrbe . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 5.
L'exception pourra se produire à la copie du paramètre retourné par split vu qu'il y a allocation mémoire et appel a un constructeur. La copie de QStringList n'aura pas ici d'influence si tu fais un catch car split ne modifie pas à priori l'état de l'objet qui l'appelle... mais pour d'autres méthodes dans Qt c'est le cas.
Exemple avec QQueue :
Si une exception est générée à l'appel de dequeue (au moment de la copie):
Et bien tu te retrouve dans un état irrecupérable car tu a perdu ta chaine de caractère. C'est un peu partout pareil dans Qt et j'ai pas le temps de débusquer toutes les erreurs de design.
Donc je ne l'utilise que pour l'interface graphique, pour le reste boost et la stl le font mieux.
[^] # Re: Boost ? c'est quoi ?
Posté par ecyrbe . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 1.
Il ne s'agit pas ici de splitter mais de faire un join...
Donc oui, on peut vouloir faire un join de nombres et de classes si ils peuvent être transformer en chaine de caractère!
[^] # Re: Boost ? c'est quoi ?
Posté par ecyrbe . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 4.
Le truc c'est que la façon de faire de Qt n'est pas exception safe. Ce qui fait que si une exception est générer à l'appel de split t'auras des fuites mémoires.
Avec la façon de faire de boost et de la stl en général, ton code est exception safe car le design à été pensé dans cette optique. C'est toute la différence, entre faire du code rapide a écrire et faire du code robuste. Entre les deux il faut choisir. Moi pour tout ce qui ne touche pas à l'interface j'ai depuis longtemps fait mon choix d'utiliser boost à cause des problèmes du aux exceptions et pour l'interface graphique et seulement elle d'utiliser Qt ou Gtkmm en fonction des besoins.
[^] # Re: Boost ? c'est quoi ?
Posté par ecyrbe . En réponse à la dépêche Sortie de Boost 1.46. Évalué à 0.
Et bien a l'usage, je trouve que minuscules et underscore sont bien plus lisibles que camel case. C'est juste que dans l'enseignement on utilise partout camel case et changer ses habitudes pour mieux est parfois une dure expérience. Pourquoije trouve ça mieux? * déjà quand on tape, on gagne du temps si l'on utilise pas la complétion automatique car on n'a pas à appuyer sur shift pour utiliser des majuscules. On tape donc donc comme on écrit, vu que l'underscore est accessible sans combo clavier. * on lit plus facilement, car on ne doit pas faire l'effort (car on a plus l'habitude de lire du texte espacé) de séparer les mots mentalement pour obtenir leur signification.
Au final, la syntaxe de la librairie standard du c++ et boost sont devenus une norme dans tous les projets de développement chez nous et on a gagné en lisibilité lors des relectures du code