Discussion :

[mick009]

Bonjour,
J'aimerais savoir s'il existe une bibliothèque qui permet de gérer facilement des classes simples (strings, ...) et qui respecte le principe de la POO ?
Il y aurait QtCore mais j'aimerais éviter de l'utiliser si possible et boost, mais je pense, à mon avis, que la POO n'est pas respectée (en plus les classes sont mélangées entre elles).
Je pourrais utiliser tout simplement la STL, mais ce sont des classes de "base". J'aimerais des classes un peu plus évoluée !

Merci par avance pour vos propositions

[Davidbrcz]

il te manque quoi dans std::string et dans la STL en général ?

[Goten]

Bonjour,
J'aimerais savoir s'il existe une bibliothèque qui permet de gérer facilement des classes simples (strings, ...) et qui respecte le principe de la POO ?
Il y aurait QtCore mais j'aimerais éviter de l'utiliser si possible et boost, mais je pense, à mon avis, que la POO n'est pas respectée (en plus les classes sont mélangées entre elles).
Je pourrais utiliser tout simplement la STL, mais ce sont des classes de "base". J'aimerais des classes un peu plus évoluée !

Merci par avance pour vos propositions

La POO n'est pas respectée dans boost? tu pourrais nous en dire plus? ..

[JolyLoic]

La POO n'est pas respectée dans boost? tu pourrais nous en dire plus? ..

Dans boost::preprocessor, tu n'as pas d'héritage, pas de fonction virtuelle, pas d'encapsulation, et même pas de classe !

Plus sérieusement, la POO est un outil, pas une religion. Comme tout outil, il y a des moments où il est utile, d'autre moins, voire néfaste. C'est la fameuse phrase : Si tout ce qu'on a à disposition est un marteau, alors les vis commencent à ressembler furieusement à des clous...

J'ai du mal à adhérer à un discours comme "X ne respecte pas la POO". Par contre, je suis friand de discours comme X n'est pas bien car on ne peut pas l'étendre dans telle direction, parce qu'il ne permet pas de travailler avec Y, parce qu'on pourrait faire Z qui remplierait les mêmes fonctions de base, mais en plus ferait .., .. et ...

Par exemple, ce genre d'arguments sur la STL se traduirait par : "Les conteneurs et algorithmes n'utilisent pas d'héritage, ça ça créerait une structure bien trop rigide, où il serait compliqué d'introduire des classes prédatant cette bibliothèque, ou simplement développé à part. Au lieu de ça, une structure où la notion d'itérateur sert d'adaptateur entre conteneurs et algorithme est plus souple.

S'il fallait trouver des principes servant de guide, ce serait plus du côté du principe ouvert/fermé (un code doit être ouvert à l'extension, fermé à la modification) et consorts qu'il faudrait regarder. La POO n'est qu'une manière parmi d'autre de respecter ces principes.

[Goten]

C'était pas le côté technique en fait que je discuté, c'était le fait que ça puisse être un reproche. Comme toi je pense que la POO n'est qu'un outil en soit, et que on est pas forcé d'en mettre partout, la preuve en est avec boost..
Mais c'est surtout le terme de "pas respecté" qui m'a fait tilté, car jamais il est dit qu'en C++ on doit absolument usé de POO.

[loufoque]

La POO c'est archi nul, en particulier pour des conteneurs.
En C++, je recommande même de ne pas l'utiliser en dehors de détails d'implémentation...

Dans la bibliothèque standard, le seul endroit où c'est utilisé par exemple, c'est les iostreams, et c'est presque transparent.

Si tu veux de la POO partout, va faire du Java, franchement.

[mick009]

La POO c'est archi nul, en particulier pour des conteneurs.
En C++, je recommande même de ne pas l'utiliser en dehors de détails d'implémentation...

Dans la bibliothèque standard, le seul endroit où c'est utilisé par exemple, c'est les iostreams, et c'est presque transparent.

Si tu veux de la POO partout, va faire du Java, franchement.

Mais si je demande dans le forum C++ c'est justement parce que je veux continuer le C++. Je sais que Java est très orienté niveau POO mais je n'ia pas envie d'utiliser ce langage.

C'était pas le côté technique en fait que je discuté, c'était le fait que ça puisse être un reproche. Comme toi je pense que la POO n'est qu'un outil en soit, et que on est pas forcé d'en mettre partout, la preuve en est avec boost..
Mais c'est surtout le terme de "pas respecté" qui m'a fait tilté, car jamais il est dit qu'en C++ on doit absolument usé de POO.

Ceci c'est mon avis. Certaines bibliothèques de boost ne présente pas d'interface POOO (je précise "certaines"). Certaines la respectent mais pas tous.
Il est vrai qu'on est pas obligé de respecter la POO, mais si je demande cela c'est justement parce que je considère la POO comme très très pratique.

il te manque quoi dans std::string et dans la STL en général ?

Il est vrai que je n'ai pas trop précisé mais j'aimerais bien avoir des fonctions du style "split" qui permet de découper les chaînes avec des délimitateurs (cette fonction est repris par boost mais en tant que fonction et non en tant que membre, à moins que j'ai dû rater quelque chose )

La POO n'est pas respectée dans boost? tu pourrais nous en dire plus? ..

Le fait que je dise que la POO n'est pas respecté chez boost est un avis personnel, il faut pas le prendre mal et "monter sur ses grands chevaux".
Je pose juste une question pas la peine de m'agresser !

Merci par avance pour vos réponses !

[Goten]

Mon ton était agressif??? Je demandais des précisions parce que justement ton avis m'intéressait ... :/.

[mick009]

Mon ton était agressif??? Je demandais des précisions parce que justement ton avis m'intéressait ... :/.

Ah je pensais que c'était un ton agressif... excuse-moi
J'ai déjà vu des gens qui s'énervaient sur des personnes juste parce qu'ils donnaient leurs avis...

Et mon avis, je pense mais après je suis pas non plus un spécialiste que boost malgré sa très grande efficacité ne respecte pas tout le temps la POO, ce qu'il n'était pas obligé de faire.
Par contre, je vais prendre l'exemple de Qt et wxWidgets. On sait tous (ou du moins je pense , parce que je ne vais pas parler au nom de tous) que Qt est largement plus apprécier par son côté POO (WxWidgets le respecte mais son code est un peu "foutoir", je dis ceci après l'avoir testé pendant de nombreux mois).

Cependant, on s'éloigne un peu du sujet et je ne sais même pas si une telle bibliothèque existe
Ce que j'apprécierai particulièrement et que je n'ai pas trop précisé (et j'en suis désolé) c'est que j'apprécierai une certaine "uniformité" dans les classes proposées. C'est à dire que soit on respecte la poo soit on la respecte pas, si on a un certain style de codage (majuscule en début de membre ou non).

Je précise que si je dis POO, je tiens à préciser que je ne suis pas capricieux pour cela. Je demande pas non plus du codage haut niveau mais l'"uniformité" !

[koala01]

Salut,
Il faudrait peut être commencer par se mettre d'accord sur ce que tu considère comme "orienté objet"...

En effet si, pour suivre le paradigme OO, tu considère que "tout doit être objet" et / ou que toute classe devrait dériver d'une classe de base "commune", c'est clairement que tu as une approche un peu trop... "javaiste" de l'OO

Typiquement, le paradigme objet se défini selon cinq axes:

• l'encapsulation des données
• le fait d'être en mesure de cacher des données
• l'héritage
• le polymorphisme
• la réutilisablilité du code

Si tu t'en tiens à cela, tu peux, certes, déjà faire des choses sympa, mais tu restes malgré tout limité

il est ensuite quand même bon de préciser (rappeler ) que C++ est un langage "multi paradigme", créé et "fourni". Il existe

• le paradigme purement procédural
• le paradigme OO
• le paradigme générique

Le plus beau de l'histoire, c'est que les trois paradigmes sont parfaitement intégrés:
Après avoir eu la curiosité de m'intéresser quelque peu aux fichiers qui prennent place dans le dossier include/C++/bits (arborescence donnée avec MinGW), aux traits de politique et aux CRTP, je peux t'assurer, que, non seulement, l'OO est beaucoup plus respecté que tu ne semble l'imaginer (selon les cinq axes évoqués plus haut), mais en plus que la généricité (les template) s'intègre parfaitement dans le concept et permet une évolutivité et une souplesse incroyable, sans oublier les possibilités de tests à la compilation qu'apporte la programmation générique

Si elle ne mettait pas aussi longtemps à être générée, je te proposerais volontiers de lancer une génération de documentation avec doxygen sur le dossiers include de C++ et à t'intéresser à la "hiérarchie des classes"...

J'ai l'impression que la surprise serait au rendez vous

D'un autre côté, je ne nie pas qu'il puisse manquer l'une ou l'autre fonction ou fonction membre dans les classes...

Mais je suis aussi d'avis qu'il est *à mon sens* souvent préférable d'avoir une fonction (libre) "templatisée" qu'une fonction membre (non templatisée) identique, quitte à ce qu'il y ait les deux versions :

Cela te permet, justement, de sortir du "carcan" parfois trop étroit de "l'OO à tout prix"

Enfin, je ne peux m'empêcher de réagir à

Ce que j'apprécierai particulièrement et que je n'ai pas trop précisé (et j'en suis désolé) c'est que j'apprécierai une certaine "uniformité" dans les classes proposées. C'est à dire que soit on respecte la poo soit on la respecte pas, si on a un certain style de codage (majuscule en début de membre ou non).

En effet, pour ce qui en est de la S(T)L et de boost, les règles de codages sont parfaitement établies et respectées d'un bout à l'autre du code de ces bibliothèques:
Elles sont, certes, différentes de ce qui se fait généralement en java, mais, pour la S(T)L, et boost par exemple, on a:

• un identifiant commençant par _ (ou __ selon les implémentations) est à usage interne
• les identifiants "composés" (plusieurs mots) voient chaque mot séparé par un _ (push_back, make_pair, find_first_of, ...)
• les mots sont écrits en minuscules
• les identifiant "préprocesseurs" sont écrits en majuscules

On peut, bien sur, regretter que les "grandes bibliothèques graphiques" (Vcl, Qt, framework .Net, ...) aient utilisé une convention différente... Mais rien ne t'empêche de choisir ta propre convention en java non plus

[loufoque]

Il n'y a pas de raison que split soit une fonction membre.
C'est un algorithme, pas une primitive.

[koala01]

Il n'y a pas de raison que split soit une fonction membre.
C'est un algorithme, pas une primitive.

Je tempérerais volontiers sous la forme de

Il n'y a pas de raison que split soit exclusivement une fonction membre.

Car, si c'est effectivement un algorithme, il n'empêche qu'il peut s'appliquer à "autre chose" que des chaines de caractères, et qu'il risque donc de devoir s'adapter à la situation propre de la "collection" sur laquelle il s'applique (finalement, une chaine de caractères est fort semblable à une collection de caractères ), au même titre que find, sort et autre fonctions sympa

[EDIT]Ce que je veux dire par là est qu'il est en effet beaucoup plus facile de justifier le fait que split() soit une fonction libre par le fait que c'est un algorithme que de de justifier qu'elle ne doive pas être fonction membre pour la même raison

[mick009]

Bon je crois que je me suis très très mal expliqué et "emmêlé les pinceaux" et j'en suis désolé.
Je vais essayer de reprendre de zéro en m'exprimant un peu mieux où sinon vous ne comprendrez pas où je veux en venir .

En fait, j'aimerais savoir s'il existe une bibliothèque ayant ensemble de classe de base (strings, vector, ...) qui possède des membres d'algorithme. Par exemple (et j'insiste sur le "par exemple" ), pour le string, on aurait le membre split, pour les vector, on aurait les membres startsWith, endsWith.
Il est vrai que boost reprend l'algorithme split (boost::tokenizer, je crois) mais en tant que fonctions et non en tant que membre (il aurait donc fallu alors créer une classe spécifique).
Et il faudrait que ces classes soit programmé avec l'idée de la POO.

Merci d'avance pour vos réponses !

[Luc Hermitte]

boost.string_algo dispose des algo manquants.

Quand au fait de rajouter des tonnes de fonctions membres à string, il a été entre temps perçu qu'il s'agissait d'une erreur de conception, car en effet où et quand s'arrêter ?

Pourquoi réduire l'applicabilité d'un algo "générique" à un seul type d'implémentation de string, alors qu'une autre implémentation serait parfaitement valable dans un autre contexte ? (on peut imaginer des chaines qui sont en fait des vues (et non des "copies" en charge de leur mémoire) vers des zones mémoires "externes", chaines que l'on voudrait splitter -- cf p.ex. le parseur SAX de adobe.ASL qui ne réalise justement aucune copie du texte XML parsé).

Idem le isStartingWith du vecteur, il faudrait copier-coller le code pour les chaines. Côté réutilisation, on a vu beaucoup mieux.

Je t'invite à lire les notes de Stepanov sur la conception de la STL -> Note on Programming si je me souviens bien du titre du rapport.


Bref, ne te laisse pas enfermer dans une vision de l'OO induite par les langages bridés -- ceux ne disposant pas du polymorphisme paramétrique et qui font qu'il y a de l'héritage dans tous les sens.

[koala01]

boost.string_algo dispose des algo manquants.

Quand au fait de rajouter des tonnes de fonctions membres à string, il a été entre temps perçu qu'il s'agissait d'une erreur de conception, car en effet où et quand s'arrêter ?
<snip>

D'autant plus que, d'une certaine manière, string fait déjà figure de "couteau suisse"

[mick009]

Quand au fait de rajouter des tonnes de fonctions membres à string, il a été entre temps perçu qu'il s'agissait d'une erreur de conception, car en effet où et quand s'arrêter ?

C'est vrai, je n'avais pas pensé que les membres pouvaient être infinis...
En fait, ce que je demandais c'était juste les algorithmes les plus importants des classes de base, mais c'est vrai que je n'avais pas vu qu'une fonction pouvait être aussi très pratique (cf http://www.stepanovpapers.com/notes.pdf)
Cependant, je pense aussi que les fonctions peuvent contribuer à créer des classes spécialisés (strings, etc....)

Je vais donc mettre ce sujet en résolu parce que je pense pas qu'il existe une telle bibliothèque...
Merci encore à tous pour votre aide, j'ai pas mal progressé dans la conception du C++ !