Discussion :

[Luc Hermitte]

et merci pour le tuyeau de recherche dans google , grâce a ça j'ai trouver un article http://www.technologyreview.com/InfoTech/17831/ de stroustrup et on voit bien qu'il met aussi l'accent entre autre sur la conception comme facteur qui a contribuer au fait que c++ devient expert friendly.

Alors jette un œil à l'article qui accompagne son dernier livre. Je soupçonne qu'il y a des choses qui vont t'intéresser dedans.
(mais pourquoi il y a toutes sortes de traductions en cours, mais pas en français, pourtant plus répandu que certaines de ces autres langues ? Même chose pour AC++.)

[Goten]

Alors jette un œil à l'article qui accompagne son dernier livre. Je soupçonne qu'il y a des choses qui vont t'intéresser dedans.
(mais pourquoi il y a toutes sortes de traductions en cours, mais pas en français, pourtant plus répandu que certaines de ces autres langues ? Même chose pour AC++.)

/hs c'est pas plus mal... au vue de certaines traductions amha il vaut mieux garder l'original. hs/

[loufoque]

Toutes les classes de string fournissent une version const char*.
Il suffit que les algorithmes prennent des const char* au lieu de const std::string& (ce qui serait d'ailleurs une bien meilleure idée)

[JolyLoic]

(mais pourquoi il y a toutes sortes de traductions en cours, mais pas en français, pourtant plus répandu que certaines de ces autres langues ? Même chose pour AC++.)

Je lui ai demandé la dernière fois que je l'ai croisé. Il m'a dit que déjà, ce n'est pas lui qui décide, mais son éditeur. A ce qu'il a compris, le marché français n'est pas si intéressant que ça, car il y a une assez forte concurrence en France entre la VO et la VF, et le nombre d'exemplaires en plus que pourrait constituer une VF n'est pas si important qu'on pourrait imaginer.
Intuitivement, j'imagine plus difficilement cette concurrence sur des livres pour débutants, mais je ne suis pas éditeur et n'ai vu aucun chiffre de vente.

/hs c'est pas plus mal... au vue de certaines traductions amha il vaut mieux garder l'original. hs/

D'un autre côté, une traduction de qualité, c'est possible. Bjarne m'a repporté par exemple que le traducteur polonais, qui ne connaissait pas du tout le C++ lui avait fait des remarques très pertinentes, et lui avait remonté des erreurs dans la VO. Il avait finalement appris le C++ en traduisant. Je suis près à parier que cette traduction sera de qualité.

[Issam_Lahlali]

Toutes les classes de string fournissent une version const char*.
Il suffit que les algorithmes prennent des const char* au lieu de const std::string& (ce qui serait d'ailleurs une bien meilleure idée)

std::string comme paramètre dans les algo STL a aussi l'avantage de faire abstraction au fait que l'a chaine de caractère peut être en Unicode.

si on on passe que les char* il faut penser a dupliquer les méthodes pour donner la possibilité de passer wchar* aussi.

[Alp]

std::string comme paramètre dans les algo STL a aussi l'avantage de faire abstraction au fait que l'a chaine de caractère peut être en Unicode.

si on on passe que les char* il faut penser a dupliquer les méthodes pour donner la possibilité de passer wchar* aussi.

Si je ne m'abuse, std::string <=> std::basic_string<char>, et std::wstring <=> std::basic_string<wchar>.

[Goten]

std::string comme paramètre dans les algo STL a aussi l'avantage de faire abstraction au fait que l'a chaine de caractère peut être en Unicode.

si on on passe que les char* il faut penser a dupliquer les méthodes pour donner la possibilité de passer wchar* aussi.

Non car std::string n'est qu'un typedef de std::basic_string<char> il y'aurait le même problème pour gérer l'unicode il faut passez par std::wstring qui est un typedef de std::basic_string<wchar_t>

edit : oups désolé pour la redondance de mon poste alp mais j'avais pas vu qu'il y'avait une nouvelle page quand j'ai répondu

[Issam_Lahlali]

Si je ne m'abuse, std::string <=> std::basic_string<char>, et std::wstring <=> std::basic_string<wchar>.

Non car std::string n'est qu'un typedef de std::basic_string<char> il y'aurait le même problème pour gérer l'unicode il faut passez par std::wstring qui est un typedef de std::basic_string<wchar_t>

non t'abuse pas du tout et autant pour moi pour cette confusion

Dans ma tête je pense toujours a l'abstraction et c'était pour moi tellement évident que std::string faisait abstraction a l'unicode

d'ailleurs on parlant de l'internationalisation pourquoi il n y a pas abstraction comme les autres langages de cet aspect d'Unicode?

c'est le genre de problématique qu'on devait dépasser depuis longtemps en C++.

[metagoto]

A l'origine, il me semble que wchar_t a été défini en vue de supporter unicode mais finalement ça n'a pas été possible, ce dernier ayant dépassé les limites fixées.

C++0x apporte des nouvelles string literals pour utf8, 16 et 32.

[JolyLoic]

wchar_t supporte unicode, il suffit de savoir lequel...

Sous windows, il supporte très bien UCS-2 (qui est désormais obsolète), et il me semble que sous linux, il supporte UCS-4.

Il ne supporte ni UTF-8, ni UTF-16, mais je ne suis pas convaincu de l'intérêt de les supporter en interne pour autre chose que des E/S.

[Jean-Marc.Bourguet]

A l'origine, il me semble que wchar_t a été défini en vue de supporter unicode

Ah? Il n'y aurait pas un problème de causalité là? (wchar_t est en C89, Unicode avant 89 n'était qu'un projet interne à Xerox et Apple).

wchar_t a été iintroduit pour supporter les grands charsets, et rien n'empèche de l'utiliser pour supporter Unicode (autre que des problèmes de compatibilité avec les versions précédentes pour certaines implémentations -- il y a aussi des problèmes à standardiser des solutions avant qu'elles ne deviennent réellement stables).

C++0x apporte des nouvelles string literals pour utf8, 16 et 32.

C'est un mécanisme en plus qui permet de supposer le codage utilisé est un encodage d'Unicode et de simplifier alors le code sur cette base (le mécanisme des wchar_t est mal compris, en partie à cause d'une complexité due à la possibilité de supporter des charsets différents dans wchar_t).

[Florian Goo]

Bonsoir Issam,

si le concept existait réellement donc un interface standardisé de ce que doit être une chaine de caractères ça sera plus facile pour tout le monde.

Mais il existe, le concept des strings ! Ce n'est pas parce qu'il n'est pas formalisé explicitement dans le langage qu'il n'existe pas.
Le concept, c'est celui défini par std::string et les algorithme de la STL… à ton avis, pourquoi est-ce que QString comporte des fonctions membres push_back(), push_front() et consort au beau milieu de sa convention de nommage mixedCase ?
Cette remarque vaut également pour les autres classes conteneurs et toutes les redondances de la STL.

Autre chose, tu devrais arrêter avec tes « je trouve qu'en c++ qu'en privilégie l'implémentation que les concepts » et autres généralités du genre. Je suis développeur C++ et je sais ce qu'est le principe d'inversion de dépendance, l'un n'empêche pas l'autre. Il est un peu insultant d'établir une règle empirique décrétant le contraire, basée sur le fait que tu n'as connu que des mauvais développeurs.
Mais bref, les autres intervenants ont eu l'occasion de s'exprimer à ce sujet.

Enfin, je trouve que ce « débat » (y en a-t-il vraiment un ?) est totalement stérile. On est tous d'accord qu'ignorer la conception, c'est mal. Si tu déplores que certains développeurs C++ ont cette fâcheuse tendance, le mieux à faire est encore de répondre aux questions posées sur le forum ou encore d'écrire des articles sur le sujet.

(En ce qui concerne l'analyse de code source visant à dédouaner le programmeur des problématiques techniques redondantes de bas niveau, j'y travaille .)

[Issam_Lahlali]

Mais il existe, le concept des strings ! Ce n'est pas parce qu'il n'est pas formalisé explicitement dans le langage qu'il n'existe pas.

C'est justement la le problème l'interface existe virtuellement , pour les chaines de caractères il y a autant de types que de libraires techniques.

et si t'utilise std::string il y en a d'autres qui utilisent char* ou QString ou CString ou ATL::CString ou autre.

et le vrai intérêt du concept ce n'est pas de l'avoir dans la tête mais concrètement avoir l'entité qui fait l'abstraction pour que la communication entre librairies soit facile.
et pour ta critique sur ma phrase:

je trouve qu'en c++ qu'en privilégie l'implémentation que les concepts

pour être clair pour concept je parle la de classe abstract pure indépendante de toute implémentation, a tu compter combien il y en a dans STL,Boost et QT ?

par exemple dans QTCore de QT je peux t'assurer qu'il n y a pas assez d'abstraction et essaye d'énumérer combien de classes abstraites pur qu tu rencontre dans les différents projets sur lesquels t'a travailler.


d'autre part ne prenais pas comme attaque personel chaque idée evoqué, on est entrain de débattre de la manière d'aborder c++ pour convaincre les décideurs que C++ n'est pas si compliqué que ca.

et si t'est convaincu que le monde de C++ c'est le paradis et il n y a aucun souci de complexité de ces librairies (je parle bien de librairies mais non du langage) tu n'a qu'a demander a ton DRH combien maintenant c'est mission impossible de trouver un bon profil C++.

Et encore une fois C++ peut faire tout ce qu'on peut faire avec C# alors pourquoi on peut pas avoir un framework aussi simple et cohérent que Dotnet.

c'est pas le but de lancer un troll mais le but est d'avoir des réflexions sur la manière d'aborder ce langage et surtout apprendre a simplifier la complexité et non lui trouver des arguments.

[Jean-Marc.Bourguet]

Et encore une fois C++ peut faire tout ce qu'on peut faire avec C# alors pourquoi on peut pas avoir un framework aussi simple et cohérent que Dotnet.

Tu n'auras qu'une lib de plus, inconsistante avec ce qui existe déjà.

[Issam_Lahlali]

Tu n'auras qu'une lib de plus, inconsistante avec ce qui existe déjà.

tout a fait raison et c'est ce qui est regrettable , peut etre c'est trop tard pour les libraries techniques.

dans un monde idéal on peut dire que QT peut adresser pas mal de besoin technique mais la réalité c'est autre chose, par exemple même si QT a des classes pour gerer XML mais des fois on est obligé d'utiliser une autre librairie parce qu'elle est plus optimisé, donc finalement dans le monde réel tôt ou tard on se trouve confronter a utiliser plusieurs librairies.

et la raison pour laquelle je parle toujours du cas de chaine de caractères c'est que je ne sais pas pour quelle raison chaque librairie définit son propre type de chaine de caractère et finalement on travaille avec plusieurs librairies sans abstraction commune et ça devient vite compliqué.

[Luc Hermitte]

J'ai arrêté de chercher à comprendre les raisons du NIH ambiant.

Et oui, on utilise plusieurs bibliothèque. Mais ne va pas croire, c'est pareil ailleurs. Ils n'ont pas qu'une seule bibliothèque ou un seul framework.

[Jean-Marc.Bourguet]

et la raison pour laquelle je parle toujours du cas de chaine de caractères c'est que je ne sais pas pour quelle raison chaque librairie définit son propre type de chaine de caractère

Regarde leur date de conception et la date d'introduction de std::string. Tu as déjà une approche de raison. Bon, certains sont atteints de NIHite aigue, mais ce n'est probablement pas propre au C++. Et toute conception est un point de compromis. S'il ne te conviens pas, tu peux parfois avoir de bonnes raisons de réinventer la roue (pour la faire dentée pour ton train à crémaillère).

La possibilité d'évoluer rentre en conflit avec l'idée d'avoir un tout bien conçu et cohérent. Vu le poids de l'existant dans notre domaine, la fenêtre pour imposer une solution dominante est très étroite, d'autant plus étroite qu'il y a du monde. Les nouveaux problèmes vont être traités de différentes manières (en interne par les grosses boîtes le rencontrant, en public par ceux qui voient un marché dans la fourniture d'une solution) et donc de la fragmentation.

Si tu veux faire avancer les choses, la participation à boost, pour y publier des bibliothèques pour les problèmes qui t'intéresse, ou au minimum pousser pour utiliser boost dans les projets auxquels tu participes, semble la seule possibilité.

[Issam_Lahlali]

J'ai arrêté de chercher à comprendre les raisons du NIH ambiant.

Et oui, on utilise plusieurs bibliothèque. Mais ne va pas croire, c'est pareil ailleurs. Ils n'ont pas qu'une seule bibliothèque ou un seul framework.

a part le faite que c'est cohérent , on a pas plusieurs types pour les strings , les files , smart_ptr,....

si chaque développeur c++ ça lui parait normale toute cette redondance , je retire tout ce que j'ai dis depuis le début de cette discussion parceque je comprendrais mieux les critiques.

en tout cas j'arrive pas a suivre et mettre en tête plusieurs possibilités pour finalement faire la même chose , je préfère me concentrer sur l'aspect métier de l'application.

[Jean-Marc.Bourguet]

a part le faite que c'est cohérent , on a pas plusieurs types pour les strings , les files , smart_ptr,....

Parce qu'ils ont été introduits en même temps que le langage. Tout ce qui n'est pas introduit en même temps que le langage, et même ce qui a été introduit en même temps que le langage mais dans une conception boîteuse -- parce que le problème n'était pas encore clairement compris -- va se retrouver tôt ou tard dans cette situation.

[Issam_Lahlali]

Regarde leur date de conception et la date d'introduction de std::string. Tu as déjà une approche de raison. Bon, certains sont atteints de NIHite aigue, mais ce n'est probablement pas propre au C++. Et toute conception est un point de compromis. S'il ne te conviens pas, tu peux parfois avoir de bonnes raisons de réinventer la roue (pour la faire dentée pour ton téléphérique).

bien sur l'histoire a son poids j'en suis conscient, mais par contre ce que nous faisant actuellement on peut le faire autrement.

un développeur débutant va prendre comme modele ce qui est déjà fait, et puisqu'il y a des choses qui était imposé par l'histoire et non bien fait il va suivre le mauvais modèle.

par exemple pour la classe abstract pure pour représenter les contrats , un développeur C++ ne la voit bcp dans les librairies qu'ils utilisent, par contre un développeur c# voit régulièrement les interfaces.

on peut pas du jour au lendemain avoir la librairie magique mais un developpeur c++ même débutant a le droit de critiquer s'il voit qu'une librairie est complexe a utiliser et acquérir le réflexe de faire une abstraction la ou c'est compliqué et eviter de lui donner le sentiment que c'est de sa faute s'il ne sait pas utiliser une librairie.