La sp�cification du C++17 n'int�grera pas les concepts

La sp�cification du C++17 n'int�grera pas les concepts
D�couvrez les raisons logiques et techniques de son absence

La nouvelle sp�cification du C++, nomm�e C++17 approche � grands pas. Toutefois, la fonctionnalit� des concepts n'int�grera pas la future sp�cification. Tom Honermann explique sur son blog les raisons faisant que c'�tait improbable, voire impossible.
Toutefois, avant de d�crire ces raisons, rappelons ce que sont les concepts.

Prenons le concept suivant :

Code:

---

1 2 3

auto concept LessThanComparable<typename T> { bool operator<(T, T); }

---

Celui-ci indique que n�importe quel type ayant un operator< et qui prend en param�tre deux objets et retournant un bool�en sera consid�r� comme un LessThanComparable. Ensuite, il est possible d�utiliser le concept pour restreindre les types pouvant �tre pass�s � un template.

Le but des concepts est d'apporter une solution � un manque du C++. En effet, m�me s'il est possible de contourner le manque, il est impossible d'apporter une solution propre. Gr�ce aux concepts il devient possible :

• de contraindre les arguments d'une fonction sans pour autant d�sactiver la d�duction de ceux-ci et sans g�ner la meta arity des fonctions templates ainsi contraintes. Prenons l�exemple suivant :
  
  Code:

  ---

  template <class T> void f(T);

  ---

  L�exemple est plut�t simple. Toutefois, nous aimerions ajouter une interface. Pour ce faire, nous voudrions contraindre les param�tres de la fonction :
  
  Code:

  ---

  template <class T> void f(enable_if_t<my_trait_v<T>, T>);

  ---

  Mais ce faisant, nous avons perdu la d�duction des arguments. Aussi, cela ne fonctionnera pas pour les constructeurs templates. Une seconde approche serait :
  
  Code:

  ---

  template <class T> auto f(T) -> enable_if_t<my_trait_v<T>, void>;

  ---

  La contrainte du param�tre se situe dans le type de retour. Toutefois, cela ne marche toujours pas pour les constructeurs templates. Ce que nous pouvons corriger en ajoutant une contrainte sur l�argument template :
  
  Code:

  ---

  template <class T, typename = enable_if_t<my_trait_v<T>>> void f(T);

  ---

  Malheureusement, la meta arity est pass�e de 1 � 2. De plus, ce n��tait que des contournements alors qu�avec les concepts nous pourrions faire :
  
  Code:

  ---

  void f(MyConcept);

  ---

• d��crire plus facilement des surcharges tout en ayant des contraintes exclusives mutuellement. Il est souvent souhait� de pouvoir utiliser telle ou telle surcharge suivant certaines conditions sur les templates. Pour r�ussir, on pourrait �crire :
  
  Code:

  ---

  template <class T> void f(T, decltype(declval<T>().f())* = 0);

  ---

  Ce code est dangereux. On peut facilement en arriver � ce point si on ne souhaite pas cr�er de trait (car c�est l�unique utilisation). De plus, les r�f�rences ne sont pas g�r�es, la contrainte peut �tre ignor�e en passant deux arguments � la fonction. Avec les concepts, nous pourrions �crire :
  
  Code:

  ---

  1 2	template <class T> void f(T) requires requires (T t) {t.f();}; template <class T> void f(T);

  ---

  Les surcharges sont mutuellement exclusives.
• d��crire des contraintes aussi originales que n�cessaires.

Malgr� tout l�int�r�t que peuvent avoir les concepts, ceux-ci n'int�greront pas le prochain standard. En effet, plusieurs choses ne sont pas encore claires :

• la sp�cification des concepts a �t� publi�e le 15 novembre 2015, laissant peu de temps pour un retour efficace et fiable ;
• la seule impl�mentation est dans une version non publi�e de GCC ;
• l�impl�mentation r�alis�e dans GCC a �t� r�alis�e par l�auteur de la sp�cification. Il n�y a donc pas eu d�avis externe sur la question de l�impl�mentation dans GCC ou dans les autres compilateurs ;
• seuls quelques projets utilisent les concepts, mais la sp�cification n�a pas �t� assez mise � l��preuve dans des cas r�els ;
• la sp�cification ne fournit pas de biblioth�que de d�finitions de concepts. Donc il n�est pas possible de savoir si l��criture d�une telle biblioth�que est possible.

Toutefois, m�me si tous ces points avaient �t� r�gl�s, Tom Honermann doute de l�int�gration des concepts � la sp�cification du langage. En effet :

• les concepts apportent une nouvelle �criture pour les templates. Toutefois, une fonction template abr�g�e peut �tre identique � une fonction non template. Le type serait le seul indicateur pour savoir si la fonction est non template ou si elle est template :
  
  Code:

  ---

  void f(X x) {}

  ---

• la proposition d�finit une nouvelle syntaxe pour d�clarer des templates respectant une contrainte :
  
  Code:

  ---

  C{A,B} void f(A a, B b);

  ---

  toutefois, cette syntaxe n�est pas appr�ci�e ;
• l�utilisation d�un concept n�cessite de conna�tre comment il a �t� d�fini (fonction ou variable). Cela apporte confusion et est source d�erreurs ;
• les concepts sont attendus pour am�liorer les messages d�erreur. Toutefois, l�utilisation erron�e des concepts peut apporter des erreurs encore plus denses qu�� l�accoutum�e li�es � la surcharge des fonctions ;
• de nombreuses autres questions ont �t� soulev�es et ne pourront �tre r�pondues qu�� travers des tentatives d�utilisation.

M�me si ce constat est malheureux pour tout utilisateur du langage souhaitant les concepts au plus t�t, ces derniers devraient arriver dans la prochaine sp�cification. De plus, il y a de grandes chances pour que chaque compilateur propose une impl�mentation bien avant la compl�tion du futur standard. Finalement, ce retard permet d�affiner l�impl�mentation et ainsi, au comit� de proposer une meilleure fonctionnalit�.


Votre opinion

:fleche: Aviez-vous d�j� imagin� des cas d�utilisation pour les concepts ? Quels sont-ils ?
:fleche: Quelles autres fonctionnalit�s du C++ attendez-vous ?


Source

Blog de Tom Honermann
IsoCPP

Je suis assez en d�saccord avec ce post qui pr�sente pour moi une vue biais�e de la situation. M�me si je n'�tais pas � la derni�re r�union, j'ai suivi d'assez pr�s son contenu.

Citation:

---

la sp�cification des Concepts a �t� publi�e le 15 novembre 2015, laissant peu de temps pour un retour efficace et fiable

---

La sp�cification des concepts existe depuis longtemps... C'est le fait que cette sp�cification soit sous forme de TS qui est r�cent. M�me si le design a commenc� bien avant, la premi�re sp�cification existe depuis janvier 2014. Elle a �volu�, certes, mais si on va par l�, toutes les propositions �voluent, c'est leur objectif, et si on imposait � toute �volution une p�riode de non �volution de plusieurs ann�es avant d'�tre accept�es, on n'aurait rien dans C++17.

Citation:

---

la seule impl�mentation est dans une version non publi�e de GCC ;

---

Version qui ne pouvait pas �tre publi�e, puisque les concepts ne sont pas dans le langage.... C'est l��uf et la poule... Et c'�tait l'int�r�t du TS que de rassurer les fabricants de compilateurs � faire l'effort d'impl�mentation avant la standardisation. Et il faut savori que de nombreuses fonctionnalit�s du langage ne sont que dans des versions non publi�es avant d'�tre accept�es (certaines ne sont m�me pas impl�ment�es dans leur forme finale...).

Citation:

---

l�impl�mentation r�alis�e dans GCC a �t� r�alis�e par l�auteur de la sp�cification. Il n�y a donc pas eu d�avis externe sur la question de l�impl�mentation dans GCC ou dans les autres compilateurs ;

---

C'est le cas pour l'immense majorit� des nouvelles fonctionnalit�s du langage. Et je n'ai jamais entendu cet argument utilis� pour autre chose que les concepts... Pour les autres cas, une question est r�currente est "Est-ce que �a a �t� impl�ment�?". Pour les concepts, il semblerait que la question soit "Est-ce que ca a �t� impl�ment� 3 fois par 3 �quipes diff�rentes dont aucune n'a le droit de contenir l'auteur principal de la proposition?"...

Citation:

---

seuls quelques projets utilisent les concepts, mais la sp�cification n�a pas �t� assez mise � l��preuve dans des cas r�els ;

---

Et comment pourrait-elle l'�tre plus, tant que la proposition n'est pas accept�e ? Elle a �t� utilis�e dans divers contextes, le contexte manquant le plus g�nant �tant la STL. Mais des grandes biblioth�ques l'ont utilis�e (range, par exemple)

Citation:

---

la sp�cification ne fournit pas de biblioth�que de d�finitions de concepts. Donc il n�est pas possible de savoir si l��criture d�une telle biblioth�que est possible.

---

C'est un point g�nant mais h�las classique. Les gens qui travaillent sur le langage et ceux qui travaillent sur la biblioth�que sont diff�rents, et tant qu'une fonctionnalit� n'a pas �t� accept�e dans la langage, impl�ment�e dans plusiuers compilateurs, les biblioth�ques ont du mal � suivre. Par exemple, plusieurs ann�es apr�s la mise en place de noexcept, on ne savait toujours pas sur quelles fonctions de la biblioth�que mettre noexcept ou pas. M�me chose pour constexpr qui est seulement en train d'�tre ajout� � la biblioth�que standard.

Citation:

---

les Concepts apportent une nouvelle �criture pour les templates. Toutefois, une fonction template abr�g�e peut �tre identique � une fonction non template. Le type serait le seul indicateur pour savoir si la fonction est non template ou si elle est template :

---

C'est le cas depuis le d�but, �a a �t� discut� et accept�. Apr�s, certains n�aiment pas, mais � part rouvrir sans cesse les vieux d�bats...
Il est courant en C++ de ne pas pouvoir dire ce qu'est un code sans conna�tre le contexte. Si je dis

Code:

---

1 2	void f(double d) {}; f(2);

---

Je ne peux pas dire si cette fonction f sera appel�e sans savoir s'il n'y a pas aussi visible dans le scope une autre fonction qui serait pr�f�r�e. C'est la base de la surcharge, et �a ne g�ne personne.
Et bien, dans le m�me ordre d'id�e, si je vois void f(Container const &c), je ne peux pas savoir sans un peu de contexte si je d�finis une fonction ou un template, mais :
- G�n�ralement, je connais le contexte, et je peux dire par exemple que Container est un concept, et donc que je d�finis un template, mais que f(vector<int> const &v) va d�finir une fonction.
- Le nom lui m�me doit m'aider
- Et la plupart du temps, je m'en moque totalement de savoir si une fonction est un template ou pas. J'ai sous la main en conteneur (sans savoir forc�ment son type exact, il est peut-�tre dans une variable auto initialis�e par un retour de fonction, ou dans un argument template), je peux appeler f, c'est tout ce qui compte.

Citation:

---

les Concepts sont attendus pour am�liorer les messages d�erreur. Toutefois, l�utilisation erron�e des Concepts peut apporter des erreurs encore plus dense qu�� l�accoutum�e li� � la surcharge des fonctions ;

---

Je manque de recul sur ce point (toujours pareil, tant qu'on ne l'a pas vraiment dans un compilo qu'on utilise quotidiennement...), mais :
- Ce n'est pas le cas le plus courant
- Lire une longue liste de surcharge reste au niveau s�mantique de l'interface. Pour les gens ayant l'habitude de plonger dans l'impl�mentation, peut-�tre que c'est un peu plus long, mais pour les gens voulant rester au niveau de l'interface, c'est mieux !
- Je ne doute pas qu'avec le temps, les compilateurs pourront affiner les messages d'erreur li�s aux concepts (par exemple, lister en premier parmi les surcharges celle qui �tait le plus proche de passer, et donc la plus susceptible d'�tre la bonne).

Citation:

---

de nombreuses autres questions ont �t� soulev�es et ne pourront �tre r�pondues qu�� travers des tentatives d�utilisations.

---

Et ces tentatives ne pourront avoir lieu que quand les compilateurs proposeront cette fonctionnalit�. Et qu'ils la proposeront vraiment, pas avec un flag "exp�rimental" et d'autres joyeuset�s qui emp�cheraient les gens de l'utiliser dans un vrai contexte professionnel. J'esp�re vraiment que la pr�sence du TS ira dans cette direction... Je ne doute pas qu'il y aura des petits probl�mes avec les concepts... Il y en a eu avec toutes les grosses fonctionnalit�s du langage. La move s�mantic �tait totalement bancale bien apr�s qu'elle ait �t� mise dans la langage, les lambda �taient incomplets...

Le probl�me, c'est qu'il y a un risque � ne pas livrer les concepts qui est pour moi plus important que le risque actuel de livrer des concepts imparfaits. Pour une autre vision sur le sujet, je vous propose de lire http://www.open-std.org/jtc1/sc22/wg...6/p0225r0.html

Code:

---

auto concept

---

Rien que de voir �a je me demande ce qu'il se passe dans la t�te du commit� parfois.

C'est pas plus mal. Y'en a marre de ces standards qui s'enrichissent de fonctionnalit�s trop compliqu�s (tout langages confondus).
"auto concept"...ils peuvent pas choisir d�j� des termes moins compliqu�s ?

auto, car tant qu'a faire, utiliser la d�duction de type.
Il aurait pu �crire bool concept LessThanComparable<typename T> {bool operator<(T, T);}.

Cela dit, je crois que la syntaxe propos�e �tait plutot:

Code:

---

1 2 3 4

template<typename T> concept bool LessThanComparable = requires(T a, T b) { { a < b } -> bool; };

---

les deux mots cl�s sont requires et concept. la fonction est n�cessairement bool.

Regardez par exemple sur cppreference.com pour la proposition actuelle de Concepts Technical Specification ISO/IEC TS 19217:2015.

La proposition est suffisamment int�ressante � mon gout, elle permet de sp�cifier des attentes plus complexes, telles que "dispose de begin et end", "dispose de size()", ou encore est un appelable avec tels arguments.
Je dois dire que j'ai r�cemment �crit une biblioth�que de manipulation de fonctions math�matiques (somme, produit, composition, etc) et qu'un concept tel que callable_as<arg1, arg2> m'aurait grandement arrang�.
La moiti� du code de cette biblioth�que consiste pr�cis�ment � me donner cette capacit�, au prix d'appel de deux classes de traits (et sept sp�cialisations chacune), de pleins de static_assert.

Avec les concepts, je n'aurai eu qu'a �crire une template de concept, et c'est tout.

Tiens, on en a parl� un peu hier � la rencontre C++ de Montpellier:

Citation:

---

C++17 sera vraissemblablement une version mineure:

• pas de Modules
• pas de Concepts
• pas de Range (d�pendance sur les concepts)
• pas de Coroutines
• pas de *uniform call syntax*

Rendez-vous en 2020 ou peut-�tre m�me 2019 pour ces points l�.

---

Pas de concepts �a implique aussi pas de range... Dommage pour le uniform call syntax aussi... Mais malgr� tout, C++17 devrait quand m�me pas mal changer notre style:

Citation:

---

Ce qui sera inclus dans C++17:

• STL parall�le / vectoris�e
• Library Fundamentals TS (any, optional, string_view, ...)
• File System TS
• Beaucoup de petits ajouts et am�liorations qui vont faire �voluer notre style de programmation:
  
  • if constexpr
  • lambdas constexpr
  • operator. (smart references)
  • g�n�ration de comparateurs par d�faut (==, !=, <, <=, >, >=)
  • attributs [[fallthrough]], [[nodiscard]], [[maybe_unused]]
  
  

---

Les mart reference en particulier, je suis curieux de voir ce que �a va donner!

Citation:

---

Envoy� par paladice

C'est pas plus mal. Y'en a marre de ces standards qui s'enrichissent de fonctionnalit�s trop compliqu�s (tout langages confondus).

---

Je pense �galement que le C++ est en train de devenir un langage de plus en plus compliqu�, de plus en plus �litiste. Et d'ailleurs, pourquoi pas ! Le probl�me, c'est qu'ils pr�tendent le simplifier, et dans une certaine mesure on peut effectivement dire qu'il se simplifie, mais seulement pour ceux qui maitrisent d�j� l'ensemble du langage. Pour les d�butants par contre, �a va �tre de plus en plus hard-core de l'apprendre.

Oui, le langage devient de plus en plus complet / complexe.
Mais du coup son utilisation devient plus simple (et l'apprentissage de son utilisation aussi).

Les d�butants n'ont pas / plus besoin d'apprendre les choses compliqu�es.
Pour donner un exemple avec les concepts : l'apprentissage et l'utilisation des concepts est beaucoup plus simple que celles de SFINAE.
Certains programmes qui �taient compliqu�s peuvent �tre r��crits en programmes relativement simples (m�me pour les d�butants).

On ne peut pr�tendre maitriser un langage que si l'on maitrise l' ENSEMBLE de ses fonctionnalit�s, et pas simplement les plus r�centes, qui viennent en g�n�rale r�parer les problemes de la sp�cification pr�c�dente.
Donc, en fait, d;une certaine mani�re, tu abondes en mon sens. Pour celui qui a conscience des probl�me li�s aux SFINAE, les concepts paraissent simple, mais pour celui qui par de z�ro, il va devoir tout comprendre, les SFINAE et les concepts.

Citation:

---

Envoy� par nikau6

On ne peut pr�tendre maitriser un langage que si l'on maitrise l'ENSEMBLE de ses fonctionnalit�s, et pas simplement la plus r�cente, qui vient en g�n�rale r�parer les problemes de la sp�cification pr�c�dente.

---

Tout d�pend de la d�finition de "ma�triser" un langage. Mais en mon sens, si tu maitrise l'orient� objet, l'utilisation des fonctions, des boucles et des conditions en C++, tu sais d�j� te d�brouiller dans �norm�ment de cas.

C++11 a introduit les boucle de type foreach en se basant sur les it�rateurs. On peut sans aucun probl�me continuer � se contenter des boucles for classique sans se sentir limit�. Est-ce qu'ignorer cette fonctionnalit� emp�che de ma�triser le reste?

Car au final, on ne ma�trise que ce qu'on utilise, et quand la boite � outils est si grande, on ne peut pas tout ma�triser. Seuls les gourous peuvent dirent qu'il ma�trisent le langage dans ce cas. Et �a repr�sente quoi? entre 1000 et 5000 personnes sur Terre...

Un peu comme Excel o� un utilisateur normal utilise 1% des fonctionnalit�s et un power-user 10%.

Si on ne maitrise pas l'ensemble d'un langage on est forcement tr�s limit� pour comprendre le code �crit par d'autres. Il est la le probl�me. Si tu te limite � la lecture de ton propre code alors pas de probl�mes et je te donne raison.

Citation:

---

Envoy� par nikau6

On ne peut pr�tendre maitriser un langage que si l'on maitrise l' ENSEMBLE de ses fonctionnalit�s, et pas simplement les plus r�centes, qui viennent en g�n�rale r�parer les problemes de la sp�cification pr�c�dente.
Donc, en fait, d;une certaine mani�re, tu abondes en mon sens. Pour celui qui a conscience des probl�me li�s aux SFINAE, les concepts paraissent simple, mais pour celui qui par de z�ro, il va devoir tout comprendre, les SFINAE et les concepts.

---

(Il y a une diff�rence entre l'apprentissage / l'utilisation du langage par un d�butant et sa ma�trise.)

Je n'aime pas trop parler de ma�trise d'un langage. C'est une notion un peu flou pour moi.
M�me si on conna�t toutes les r�gles et la syntaxe, il est possible de ne pas "comprendre" un code (pour des questions d'algo par exemple) ou ne pas savoir l'�crire de la fa�on la plus propre. Programmer n'est pas qu'une histoire de langage mais aussi de combinaison de diff�rents techniques / patterns.

� l'inverse je pense que l'on peux conna�tre la sous partie du langage qui me permet de comprendre / d'�crire l'ensemble des codes que je rencontre / souhaite d�velopper.
Est-ce vraiment grave de ne pas tout conna�tre ?

je sais pas si on peut dire que le c++ pour les d�butant est hard-core. disons que oui si c'est le 1er langage qu�on apprend.

personnellement j'ai toujours regrett� d�avoir appris le c++ comme 1er langage avant le c.

J'ajouterai qu si beaucoup des nouvelles fonctionnalit�s rendent l'�criture plus simple, elles rendent �galement la lecture plus compliqu�. Bient�t, ne pourront comprendre un code �crit en C++ que ceux qui l'auront �cris, et encore ..

Citation:

---

Envoy� par nikau6

On ne peut pr�tendre maitriser un langage que si l'on maitrise l' ENSEMBLE de ses fonctionnalit�s, et pas simplement les plus r�centes, qui viennent en g�n�rale r�parer les problemes de la sp�cification pr�c�dente.
Donc, en fait, d;une certaine mani�re, tu abondes en mon sens. Pour celui qui a conscience des probl�me li�s aux SFINAE, les concepts paraissent simple, mais pour celui qui par de z�ro, il va devoir tout comprendre, les SFINAE et les concepts.

---

A ce compte l�, personne ne maitrise rien. Tout langage confondu. Combien maitrisent vraiment la notion d'objets ? Les bonnes pratiques de SOLID ? Combien comprennent que l'OO n'est pas une question d'organiser les donn�es, mais les comportements ?
Pour maitriser un langage OO, il faut maitriser cela.

De plus, on est conscient qu'il y a plusieurs niveaux d'utilisation. Entre celui qui va juste enchainer des briques et celui qui va les �crire, il va y avoir des diff�rences dans l'utilisation du langage. Pas besoin de connaitre la m�ta-prog pour enchainer des op�rations.

Citation:

---

Envoy� par Aiekick

personnellement j'ai toujours regrett� d�avoir appris le c++ comme 1er langage avant le c.

---

Pour avoir subit l'inverse, je peux te garantir que C puis C++ c'est la combo maudite pour faire de la merde sans le savoir.

Arr�tez de pendre vos lunettes de vieux cons, comment pouvez-vous regretter l'utilisation syst�matique de pointeurs nus dans un langage � exception ?
Les smart pointeurs, c'est irrempla�able, jusqu'� trouver encore mieux.

La normalisation du C++ a une d�marche proche des framework progressifs, rendre simple les cas courants, faire en sorte que les cas courants couvre le plus de cas possible et faire en sorte que les cas rares et complexes soient
Et oui, la programmation g�n�rique (template simple), le code fonctionnel � base de lambda, la programmation parall�le ou concurrente sont des cas maintenant des plus courants ou en passe de l'�tre. Et que les normalisateurs me tracent une autoroute pour m'en servir le plus simplement du monde, je leur en suis profond�ment reconnaissant.

Moi, je ne maitrise pas le C++, m�me apr�s plus de 20ans d'utilisation, mais tant que j'arrive � faire ce que je veux et qu'en cherchant un peu je trouve de super trucs qui me simplifient la vie, biblioth�que ou nouvelles normes, je suis content.

Avoir l'illusion de maitriser un machin et bien plus d�vastatrice que de savoir qu'on ne sait rien.

D�sol� les gars, mais les seules personnes qui peuvent dire que le C++ est trop compliqu�, c'est les vrais d�butants, pas ceux qui se paluchent les intrinsics des compilateurs en assembleur x64 ou Itanium.

Parmi les changements en pr�paration pour la r�union de juin, il y a des choses sympas, comme la d�duction des types templates dans les constructeurs.
C'est � dire la suppression du besoin de toutes les fonctions make_bidule (que ce soit unique, shared, pair, tuple, optional...).

Il y a aussi if constexpr (...) qui r�duira le nombre de sp�cialisation de template � �crire.

Puis viens l'incroyable T& operator . ()

Citation:

---

Envoy� par Luc Hermitte

A ce compte l�, personne ne maitrise rien. Tout langage confondu. Combien maitrisent vraiment la notion d'objets ? Les bonnes pratiques de SOLID ? Combien comprennent que l'OO n'est pas une question d'organiser les donn�es, mais les comportements ?
Pour maitriser un langage OO, il faut maitriser cela.

De plus, on est conscient qu'il y a plusieurs niveaux d'utilisation. Entre celui qui va juste enchainer des briques et celui qui va les �crire, il va y avoir des diff�rences dans l'utilisation du langage. Pas besoin de connaitre la m�ta-prog pour enchainer des op�rations.

---

Je suis d'accord pas besoin de connaitre la m�ta-prog et en parlant de maitriser compl�tement un langage j�exag�re un peu. Je ne suis pas un expert du C++, loin s'en faut.. Je maitrise peut �tre 30% du langage, et encore.. Mais il n�emp�che que plus un langage se complexifie, se compl�te diront certain, et plus il devient difficile de lire du code �crit par d'autres. En tous les cas moi �a me cause des probl�mes.

EDIT: Par exemple, j'ai r�cemment jet� un �il au code du moteur Doom3. Un vrai r�gal. Du C with class. Pas d'utilisation excessive des templates, de l'h�ritage multiple, etc.. Juste ce qu'il faut. Et bien le code est clair, limpide..

Ceci est le genre de code que l'on �crit dans un langage d�nu� de quantit� de "nouvelles" (ici constructeurs et r�f�rences) fa�on d'organiser nos traitements.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

enum class Code { OK, NOK };   struct Image { double * pixels; std::size_t nb_pixels; };   Code get_size(Image const* im, std::size_t * size) { if (!im || !size) return Code::NOK; *size = im->nb_pixels; return Code::OK; }   Code get_pixel(Image const* im, std::size_t idx, double * pixel) { if (!im || !im->pixels || !pixel) return Code::NOK; std::size_t size; Code c = get_size(im, &size); if (c != Code::OK) return c; else if (idx >= size) return Code::NOK; else { *pixel = im->pixels[idx]; return Code::OK; } }

---

Ce n'est que la version du code d'acc�s � un pixel. Chose que l'on fera dans une boucle.

Personnellement, j'ai le plus grand mal � lire ce genre de code -- imaginez la couche englobante qui va tester ou non le succ�s des op�rations.
(Le enum class est un d�tail, s'il vous g�ne remplacez juste par un simple enum)

Citation:

---

Envoy� par Luc Hermitte

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

enum class Code { OK, NOK };   struct Image { double * pixels; std::size_t nb_pixels; };   Code get_size(Image const* im, std::size_t * size) { if (!im || !size) return Code::NOK; *size = im->nb_pixels; return Code::OK; }   Code get_pixel(Image const* im, std::size_t idx, double * pixel) { if (!im || !im->pixels || !pixel) return Code::NOK; std::size_t size; Code c = get_size(im, &size); if (c != Code::OK) return c; else if (idx >= size) return Code::NOK; else { *pixel = im->pixels[idx]; return Code::OK; } }

---

---

Du code comme je l'aime :-)