GTK... tiens, je vais marcher dedans, pour le fun.
Me semblait que si GTK est plus utilisé que Qt, c'est parce qu'à l'origine, Qt n'était totalement libre. Les deux semblent plus ou moins autant utilisés en C++, au pifomètre.
Depuis 1992 on reproche les mêmes choses encore et encore au c++
Marrant, je pense qu'en fait, le premier standard (qui est de 98) à dû résoudre pas mal de problèmes, par exemple les soucis de compatibilité entre les compilo (du moins ceux qui acceptent de respecter les standards).
Les nouvelles normes foutent la merde? Je ne pense pas, honnêtement, je pense même que c'est tout le contraire.
Par exemple, si je prend C++11:
* std::array permets d'utiliser les algo standards avec des tableaux à dimension fixe, et donc de ne pas réinventer la roue. Ce n'est pas une mauvaise chose pour moi.
* std::unique_ptr, uniquement possible grâce à la move semantic, permets de lutter contre les memory leaks en augmentant la garantie qu'un seul propriétaire contrôle un espace mémoire (on peut contourner, comme toujours en C++, et je parie que cette possibilité est conservée du fait qu'on doive interagir avec du C...).
* for( auto i : foo ){ i*=10; }, c'est quand même vachement plus lisible (et sûr) que les alternatives plus anciennes for( int i = 0; i < foo.size(); ++i ){ foo[i]*=10; } ou for( std::vector<int>::iterator it = foo.begin(); it != foo.end(); ++it ){ *it*=10; } non?
Ça, c'est pour les critiques sur les nouvelles normes, mais pour être juste, je me dois de mentionner une fonctionnalité de C++03 (ou 98?) que seul commeau à implémenté, conseillant fortement aux autres dev de compilo de ne pas le faire, parce que ça n'apporte au final rien, semble-t-il. Quelques recherches devraient pouvoir en dire plus.
Maintenant, dire que C++ c'est de la merde contre le C... allez, je marche encore :)
Ça me fait assez sourire quand je vois des gens dire que C++ c'est de la merde comparé au C, en fait. Il suffit de lire du code C pour comprendre ce que C++ à ajouté.
La RAII permets de rendre un code bien plus maintenable et sûr, et les templates ou les fonctions inline permettent de s'affranchir en grande partie des macros, ce qui évite pas mal d'emmerdes.
Avant, les jeux, comme quake par exemple, étaient stables. Ils étaient codés en C. Il faut dire que, les malloc y étaient rares, tous les tableaux étant statiquement alloués, donc les problèmes de mémoire simples à éviter.
Ceci dit, j'ai quelques souvenirs de jeux pour lesquels le dépassement de buffer est simple à causer. En même temps, c'est logique: en C, il faut vérifier le retour de la moindre fonction, manuellement, pour être sûr que tout s'est passé comme prévu.
En C++, et dans tous les langages évolués, la mécanique des exceptions permets de s'affranchir de ce problème. Mais ici, l'avantage du C++ sur d'autres langages, c'est qu'on peut s'affranchir de ces fameuses exceptions.
Et quand on lit un code source C qui utilise de manière intensive de la construction de chaînes de caractères, quelle joie que de voir des buffer alloués avec des tailles impressionnantes, et ensuite une succession de strcat, parce que strcpy( foo, bar ); strcat( foo, "world" ); c'est vrai que c'est tellement plus lisible que foo += bar + "world";.
Je vais m'arrêter là, je pense. Je veux bien que l'on compare C++ avec Java, C# ou d'autres, mais avec le C... soyons sérieux un instant, le seul avantage que je puisse voir du C sur C++ réside de son ABI stable en toutes circonstances (utile pour les plugins).
Dans le cas du C++, l'ABI n'est stable que si l'on n'utilise pas de méthodes virtuelles, voire si l'on utilise des structures pures. En d'autres mots, si on se restreint à des fonctionnalités C.
Ah, non, il y a aussi un cas ou j'ai eu un comportement différent selon les compilos, mais il faut avouer que j'avais cherché la merde, et le workaround était relativement simple.
Ça, ça bug: foo( bar[++i], bar[++i], bar[++i] ); avec VS2008 "i" faut la même valeur à chaque fois, donc la même valeur est utilisée dans les 3 arguments, contrairement à ce que GCC fait. Et les deux comportements semblent être standards, pour une question d'optimisation. Pour l'info, le workaround était, de mémoire, ceci: foo( (bar[++i]), (bar[++i]), (bar[++i]) );.
Mais c'était une construction sale, qui n'avait pour unique but que celui de réduire encore un peu le nombre de lignes de code d'une encapsulation que j'avais fait autour d'une API sur laquelle je n'avais aucun contrôle et qui sans ça demandait de répéter les informations jusqu'à 3 fois, dans 3 fonctions différentes... (powerbuilder, vous connaissez?).
[^] # Re: En vrac
Posté par freem . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à 7. Dernière modification le 18 août 2014 à 12:08.
GTK... tiens, je vais marcher dedans, pour le fun.
Me semblait que si GTK est plus utilisé que Qt, c'est parce qu'à l'origine, Qt n'était totalement libre. Les deux semblent plus ou moins autant utilisés en C++, au pifomètre.
Marrant, je pense qu'en fait, le premier standard (qui est de 98) à dû résoudre pas mal de problèmes, par exemple les soucis de compatibilité entre les compilo (du moins ceux qui acceptent de respecter les standards).
Les nouvelles normes foutent la merde? Je ne pense pas, honnêtement, je pense même que c'est tout le contraire.
Par exemple, si je prend C++11:
* std::array permets d'utiliser les algo standards avec des tableaux à dimension fixe, et donc de ne pas réinventer la roue. Ce n'est pas une mauvaise chose pour moi.
* std::unique_ptr, uniquement possible grâce à la move semantic, permets de lutter contre les memory leaks en augmentant la garantie qu'un seul propriétaire contrôle un espace mémoire (on peut contourner, comme toujours en C++, et je parie que cette possibilité est conservée du fait qu'on doive interagir avec du C...).
*
for( auto i : foo ){ i*=10; }, c'est quand même vachement plus lisible (et sûr) que les alternatives plus anciennesfor( int i = 0; i < foo.size(); ++i ){ foo[i]*=10; }oufor( std::vector<int>::iterator it = foo.begin(); it != foo.end(); ++it ){ *it*=10; }non?Ça, c'est pour les critiques sur les nouvelles normes, mais pour être juste, je me dois de mentionner une fonctionnalité de C++03 (ou 98?) que seul commeau à implémenté, conseillant fortement aux autres dev de compilo de ne pas le faire, parce que ça n'apporte au final rien, semble-t-il. Quelques recherches devraient pouvoir en dire plus.
Maintenant, dire que C++ c'est de la merde contre le C... allez, je marche encore :)
Ça me fait assez sourire quand je vois des gens dire que C++ c'est de la merde comparé au C, en fait. Il suffit de lire du code C pour comprendre ce que C++ à ajouté.
La RAII permets de rendre un code bien plus maintenable et sûr, et les templates ou les fonctions inline permettent de s'affranchir en grande partie des macros, ce qui évite pas mal d'emmerdes.
Avant, les jeux, comme quake par exemple, étaient stables. Ils étaient codés en C. Il faut dire que, les malloc y étaient rares, tous les tableaux étant statiquement alloués, donc les problèmes de mémoire simples à éviter.
Ceci dit, j'ai quelques souvenirs de jeux pour lesquels le dépassement de buffer est simple à causer. En même temps, c'est logique: en C, il faut vérifier le retour de la moindre fonction, manuellement, pour être sûr que tout s'est passé comme prévu.
En C++, et dans tous les langages évolués, la mécanique des exceptions permets de s'affranchir de ce problème. Mais ici, l'avantage du C++ sur d'autres langages, c'est qu'on peut s'affranchir de ces fameuses exceptions.
Et quand on lit un code source C qui utilise de manière intensive de la construction de chaînes de caractères, quelle joie que de voir des buffer alloués avec des tailles impressionnantes, et ensuite une succession de strcat, parce que
strcpy( foo, bar ); strcat( foo, "world" );c'est vrai que c'est tellement plus lisible quefoo += bar + "world";.Je vais m'arrêter là, je pense. Je veux bien que l'on compare C++ avec Java, C# ou d'autres, mais avec le C... soyons sérieux un instant, le seul avantage que je puisse voir du C sur C++ réside de son ABI stable en toutes circonstances (utile pour les plugins).
Dans le cas du C++, l'ABI n'est stable que si l'on n'utilise pas de méthodes virtuelles, voire si l'on utilise des structures pures. En d'autres mots, si on se restreint à des fonctionnalités C.
Ah, non, il y a aussi un cas ou j'ai eu un comportement différent selon les compilos, mais il faut avouer que j'avais cherché la merde, et le workaround était relativement simple.
Ça, ça bug:
foo( bar[++i], bar[++i], bar[++i] );avec VS2008 "i" faut la même valeur à chaque fois, donc la même valeur est utilisée dans les 3 arguments, contrairement à ce que GCC fait. Et les deux comportements semblent être standards, pour une question d'optimisation. Pour l'info, le workaround était, de mémoire, ceci:foo( (bar[++i]), (bar[++i]), (bar[++i]) );.Mais c'était une construction sale, qui n'avait pour unique but que celui de réduire encore un peu le nombre de lignes de code d'une encapsulation que j'avais fait autour d'une API sur laquelle je n'avais aucun contrôle et qui sans ça demandait de répéter les informations jusqu'à 3 fois, dans 3 fonctions différentes... (powerbuilder, vous connaissez?).