Nouveaux types prédéfinis < couleur > ou < son >

Tu peux regarder du côté de l'énoncé  enum

Salut, il y a t'il un intérêt surtout? Tout d'abord à quoi correspond le typage de données dans un langage?

En premier à un stockage(ou plutôt prévision de stockage pour une valeur de stockage nommé affectueusement "variable") donc stocker une valeur char, int , bool etc... est simplement différent car cela nécessite plus ou moins d'espace: une valeur entière est potentiellement plus volumineuse qu'une valeur booléenne: ainsi l'esdpace" de stockage prévu permet de coder le nombre 1735678 où une valeur binaire true ou false nécessite nettement moins d'espace. Idem pour une "valeur" d'une chaîne de charactéres qui est différente aussi bien en format qu'en espace mémoire possible.

Ce qui m'améne au second point important: l'utilité du typage de données.

L'avantage de la restriction de devoir déclarer un type de données à stocker(par oppostion au non typage ou typage dynamique qui permet de changer de types "à la volée") est l'intégrité des données: éviter les erreurs et améliorer la clarté d'un programme, deux choses utiles et toujours bonnes à prendre. En effet une valeur déclarée en int ne pourra accepter qu'on y stocke une valeur décimale. Si c'est le cas le programme cesse de fonctionner ce qui est beaucoup mieux que fonctionner avec des données illogiques. Par exemple sur une commande le fait de pouvoir mettre une valeur en int ou en float influe selon la donnée à stocker. Ainsi commander 542 grammes d'un produit est structurellement différent dans le programme de pouvoir commander 0.542 chaussures. Bref on ne peut simplement pas commander 0.542 d'une chaussure car cette quantité n'a aucun sens mais par contre une valeur entière indique que l'on commande 1,2, 3 etc.... paires de chaussures. Vous voyez l'avantage(en simplifié) du typage de données, il interdit simplement des absurdités qui n'ont aucun sens.

Nouveaux types de données? les types de données sont la valeur atomique(ou leur réduction la plus simple) de valeurs qui refléte une réalité/simulation bref les données ont un sens exprimée par leur type. Réduire leur valeur est avant tout une nécessité de stockage comme précisé dans mon 1er point et 2nd point(stocker un entier est différrent en espace mémoire de stocker un nombre décimal, à une structure/formatage différente, correspond à différentes réalités de ces données qui sont mutuellement exclusives: on ne peut utiliser une valeur en grammes pour indiquer un nombre der paires de chaussures et c'est tant mieux parce que si ce n'est pas le cas ça a aucun sens et le programme et pire que s'il ne fonctionne pas puisqu'il permet des erreurs).

Donc tout dépends de la donnée et de l'utilisation de celle ci. Il reste la solution d'utiliser des données non atomiques(qui ne peuvent être réduites à leur plus simple expression comme c'est le cas pour int, float, bool, char...et exprimée leur idée et place mémoire nécessaire différente). Et cela c'est le paradigme objet.

Ma donnée à certains critères que les types de données "primitives"(primaires ou primordiales) ne peuvent pas exrpimer. Dans ce cas il faut enrichir cela avec un objet. Exemple la description d'un véhicule n'est pas une valeur entière, elle contient des aspects qui sont des charactères, d'autres numériques. Encapsuler ces données c'est créer un objet ou moule ou modèle qui prenjds cela en compte, ainsi:

Vehicule:

nombre de roues: int,

couleur: char

longueur: float

etc...

Pour de nombreuses raisons cela est à privilégier dans de nombreux cas. Cela permet la même sécurité qu'un type de données tout en enrichissant les règles du programme, à "aider" le programme à donner une représentation de données proche de ce qu'elle représente.

Ainsi par exemple pour une couleur nous pouvons envisager un objet qui contient 3 valeurs entières de 0 à 255, chacune codant une valeur de rouge, vert et bleu.

Rien n'empêche d'ajouter une méthode interne à l'objet couleur si la valeur doit être exprimée différemment, par exemple au lieu d'une notation rgb en notation haxadécimale ou exprimée autrement(CMJN, K HSL...etc cela dépends donc du contexte et l'objet peut s'adapter faciçlement-en rajoutant la régle/méthode nécessaire qui n'impacte pas les anciennes utilisations- selon les utilisations et ainsi permettre de varier le programme pour de nouvelles utilisations potentielles, l'autre alternative étant de tout reccomencer de zéro et donc d'avoir perdu son temps sur un programme bon à jeter)

Même chose pour un objet "son": c'est le contexte et les nécessités d'utilisations qui déterminent la donnée et non un programme qui est idiot et ne sait faire que ce qu'on lui dit de faire dans la limite de ses compétences. Par exemple est il utile de stocker la durée, le format, le style de musique etc... d'un son? Si c'est le cas l'objet peut et doit le prendre en compte ce qui n'exclut pas-au contraire- qu'il soit lui même composé de valeurs atomiques qui elles garantissent la sécurité du programme et la bonne marche du stockage des données.

Donc passer par l'objet est satisfaisant pour restreindre les erreurs aussi bien qu'enrichir la qualité d'un programme, c'est simplement indispensable pour un programme de qualité et pas du tout en contradiction avec le but et rôle du typage, c'est un méta typage au sens où il ajoute des "types" de données mais n'invalide pas le fait que un entier, un nombnre décimal, une valeur booléenne existent et sont le moyen de traitement du programme de ceux ci.

Voilà comment il faut faire selon moi, parce que réinventer l'eau chaude ou le typage de données est inutile et contre-productif(perte de sécurité+ complexité inutile et non adaptable à ajouts/modificaitons) quand il y a déjà des solutions existantes et pratiquées couramment: le paradigme objet qui est à la base de la programmation depuis plus de 30ans(avec nottament le C++ qui en est un des chevaliers).

regarder du côté de l'énoncé  enum

Oui enum est bien pratique dans certaines situations, il nous rapproche des types prédéfinis.

les types de données sont la valeur atomique

Je suis d'accord avec cela, un type prédéfini < dégradé > ou < palette de coloris > ... serait nuisible à la sécurité du programme et la bonne marche du stockage des données.

Par contre type prédéfini < couleur > composé de 3 valeurs R G B garantit la sécurité du programme et la bonne marche du stockage des données. En théorie ce n'est pas une valeur atomique mais letype prédéfini < couleur >  sera considéré comme tel par un codeur.

Bonjour,

Réponse courte

Il n'y a pas de blocage théorique, mais pas de réel intérêt pratique, et c'est ce qui explique pourquoi après toutes ces années, il n'y a pas de type de base.

Réponse détaillée

Pour commencer, la question initiale porte du C++ et non du C, donc en fait c'est plutôt du côté des classes qu'il faut regarder.

De base, le C++ (plus exactement la STL) apporte de nombreux types (listes, ensembles, dictionnaires, flux, etc...). Cela montre qu'on peut parfaitement envisager créer de nouveaux types (ou plutôt de nouvelles classes). C'est d'ailleurs le but des librairies C++, en fonction de leur domaine de prédilection.

On pourrait également parler de la librairie boost, étend ce que fait la STL avec des types encore plus évolués (graphes, matrices, etc..).

Maintenant, pour revenir à la question initiale il suffit regarder du côté par exemple de la librairie Qt (utilisée pour faire des applications graphiques). On peut voir que oui, définir une classe C++ pour un son ou une couleur a du sens.

• QSound
• QColor

Et il en irait de même pour des librairies dédiées au interfaces graphiques (notamment GTK, SDL, etc.).

Donc il n'y a pas de blocage théorique.

Cependant, chaque librairie à ses propres fonctionnalités, conventions de nommages, etc. Et c'est pour ça qu'en pratique, il n'y a pour le moment pas de type unifié. Peut-être que si un type unifié apparaissait, ces librairies s'appuieraient dessus pour définir leurs propres classe. Ou peut-être pas.

Ce qui soulève la question suivante : a-t'on besoin d'un type unifié. Eh bien, difficile à dire, car en pratique, les gens qui ont besoin de ces types ont souvent besoin de plein d'autres choses, et donc de choisir une librairie type Qt ou autre. Du coup, l'intérêt d'avoir un type standard n'est pas vraiment utile en pratique.

Bonne chance

Je connais programmation objet Whismeril que j'avais étudié à la fac et au travail je code en VisualBasic. Mais je ne suis pas un chercheur au CNRS ou la la fac en informatique. Donc même si personnellement je ne perçoit pas de blocage théorique à intégrer de nouveaux types prédéfinis comme < couleur > ou < son > ... je me renseigne.

Content de savoir qu'il n'y a pas de blocage théorique. Je vais engager une nouvelle conservation sur les possibilités d'ajouter de nouveaux types unifiés aux langages libres.

Personnellement je pense que l'on a besoin de plus de type unifié mamiemando a condition qu'il s'agisse de valeur atomique ou du moins considéré comme tel par un codeur.

La diversité ne sera pas remise en cause, comme tu le dit chaque librairie à ses propres fonctionnalités et conventions de nommages ... et ces types unifiés ne seront pas un obstacle à ce que 2 ou 5 ... librairies traitant du même sujet soient différentes les une des autres.

Par contre de nouveaux types unifiés < dégradé > ou < palette de coloris > ... qui ne seraient pas des valeur atomique bloqueraient tout.

De la façon dont tu as posé la question initiale et répondu ensuite, j'ai cru que tu débutais.

À partir du moment où les types de bases permettent de construire n'importe quel autre type (par exemple en objet puisque tu connais et que les différents langages que tu cites, C++, Rust, VB le permettent) ils sont assez nombreux.

Et ce n'est pas parce que certains langages ont intégré dans leur livrée initiale des types plus complexes que cela couvre tous les besoins. Il m'est arrivé de devoir définir une classe de temps et de durée en .Net alors qu'il existe déjà DateTime et TimeSpan, mais elle ne satisfaisaient pas à mes besoins.

Si on regarde le C, Bool et String n'existent pas de base, on peut pourtant traiter des informations textuelles ou booléennes. Et souvent, elles sont traitées de la même façon en C++, malgré la possibilité d'intégration de bibliothèques qui gèrent ces types.

Toi, tu dis qu'une couleur c'est 3 valeurs, admettons, mais que faits tu de la luminosité et de la transparence ?

Si tu n'en as pas besoin, tu peux définir ta classe ou en chercher une sans ces paramètres. Mais quelqu'un qui en aura besoin devra en définir ou chercher une autre.

A partir du moment où couleur n'a pas de définition unique, comme type par défaut peut poser question. Et quoi qu'il en soit 3 valeurs ne peuvent pas être considéré comme valeur atomique