/* Topic des codeurs couche-tard [1] */

grim7reaper · Le 18/06/2010, à 13:20

Pylade a écrit :

’tain, après avoir longtemps pesté contre le fait qu’il ne soit pas précisé si le type char était signé ou non, et que du coup ce n’était pas pratique pour tester les caractères, je me suis finalement rendu compte qu’en fait, comme l’ASCII n’allait que jusqu’à 127, on s’en foutait…

Je ne vois pas trop en quoi ça dérange vu que pour les tests il vaut mieux utiliser les constantes littérales plutôt que les valeurs numériques.
Sinon, pour le coup de l'ASCII c'est normal vu que c'était codé sur 7 bits à l'origine.

Super, je n’aurai pas perdu ma matinée, j’ai fait une découverte scientifique majeure ! \o/

Du genre ?

Bon, du coup j’hésite : quels sont les caractères interdits pour les options courtes ? J’ai pensé à interdire tous les caractères de contrôle de U+0 à U+1F, plus delete (U+7F), plus l’hyphen (U+2D), et je pense très sérieusement à aussi interdire l’espace. Tous les caractères non-ASCII seront aussi interdits.
Vous ne trouvez pas ça trop restrictif ? Ai-je raison d’interdire tous ces caractères ?

Oui, il faut être tordu pour vouloir utiliser les caractères de contrôle ou l'espace comme options.
Tu n'as qu'a accepter tout ce qui est accepté par isalnum() (ou isalpha() si tu ne veux pas des chiffres), non ?

Dernière modification par grim7reaper (Le 18/06/2010, à 13:21)

Pylades · Le 18/06/2010, à 13:35

grim7reaper a écrit :

Je ne vois pas trop en quoi ça dérange vu que pour les tests il vaut mieux utiliser les constantes littérales plutôt que les valeurs numériques.

Je sais, c’est ce que je fais, mais je me demandais si après compilation, l’utilisation sur une machine qui représente différemment les char pouvait poser problème.
Soucis de portabilité.

grim7reaper a écrit :

Sinon, pour le coup de l'ASCII c'est normal vu que c'était codé sur 7 bits à l'origine.

Bien sûr, je sais tout ça, un moment d’absence…

grim7reaper a écrit :

Pylade a écrit :
Super, je n’aurai pas perdu ma matinée, j’ai fait une découverte scientifique majeure ! \o/
Du genre ?

Du genre que je n’avais pas besoin de m’inquiéter car on a quand-même la garantie que les codes ASCII ne feront pas un integer overflow sur les char…

grim7reaper a écrit :

Oui, il faut être tordu pour vouloir utiliser les caractères de contrôle ou l'espace comme options.
Tu n'as qu'a accepter tout ce qui est accepté par isalnum() (ou isalpha() si tu ne veux pas des chiffres), non ?

En fait, je veux autoriser tous les caractères qui ne risquent pas d’être problématiques pour les options courtes.
Donc au revoir tous les caractères non-ASCII (problèmes d’encodage, toussa), au revoir les caractères de contrôle (U+0 à U+1F, et U+7F), et probablement au revoir l’espace, car bien qu’il soit utilisable avec bash, il un quand-même le rôle de séparateur de lorsqu’il n’est pas quoté, et il peut être considéré comme un caractère de contrôle (si, c’est Unicode qui le dit). Et bien entendu, au revoir l’hyphen ! ^^
Sinon, je veux que tout le reste soit accessible. J’ai le souvenir d’une commande qui utilisait le point d’interrogation, c’est pour ça.

grim7reaper · Le 18/06/2010, à 13:39

Pylade a écrit :

grim7reaper a écrit :
Je ne vois pas trop en quoi ça dérange vu que pour les tests il vaut mieux utiliser les constantes littérales plutôt que les valeurs numériques.
Je sais, c’est ce que je fais, mais je me demandais si après compilation, l’utilisation sur une machine qui représente différemment les char pouvait poser problème.
Soucis de portabilité.

Le fait d'utiliser les constantes littérales c'est portable…

grim7reaper a écrit :
Oui, il faut être tordu pour vouloir utiliser les caractères de contrôle ou l'espace comme options.
Tu n'as qu'a accepter tout ce qui est accepté par isalnum() (ou isalpha() si tu ne veux pas des chiffres), non ?
En fait, je veux autoriser tous les caractères qui ne risquent pas d’être problématiques pour les options courtes.
Donc au revoir tous les caractères non-ASCII (problèmes d’encodage, toussa), au revoir les caractères de contrôle (U+0 à U+1F, et U+7F), et probablement au revoir l’espace, car bien qu’il soit utilisable avec bash, il un quand-même le rôle de séparateur de lorsqu’il n’est pas quoté, et il peut être considéré comme un caractère de contrôle (si, c’est Unicode qui le dit). Et bien entendu, au revoir l’hyphen ! ^^
Sinon, je veux que tout le reste soit accessible. J’ai le souvenir d’une commande qui utilisait le point d’interrogation, c’est pour ça.

Bah base toi sur isalnum() (il me semble que ces fonctions se basent sur les locales en plus) et autorise les autres caractères que tu veux (doit pas y en avoir énormément).

Pylades · Le 18/06/2010, à 14:13

nesthib…

Pylades · Le 18/06/2010, à 14:37

grim7reaper a écrit :

Le fait d'utiliser les constantes littérales c'est portable…

Nan, mais en fait je ne vais pas tester les caractères un par un, donc je ne peux pas utiliser de constante littérale, là… Je voulais vérifier si le caractère était dans un intervalle, donc j’avais peur de ne pas être portable. Mais en fait non, c’est bon. J’ai eu une absence…

grim7reaper a écrit :

Bah base toi sur isalnum() (il me semble que ces fonctions se basent sur les locales en plus) et autorise les autres caractères que tu veux (doit pas y en avoir énormément).

Mais je ne veux pas me limiter à l’alphanum, justement ! Pourquoi faire compliqué alors que je peux simplement vérifier un intervalle ?
Et puis j’ai une sainte horreur des locales dans le cœur (d’ailleurs cela serait plus que déplacé là). Et en plus je ne vois pas ce que les locales viennent foutre là, vu que sur un char tu peux coder les caractères ASCII (et ISO-8859-1, à la rigueur, mais , quoi…) et rien d’autre…

Dernière modification par Pylade (Le 18/06/2010, à 14:41)

Pylades · Le 18/06/2010, à 14:38

nesthib²…

grim7reaper · Le 18/06/2010, à 19:18

Pylade a écrit :

sur un char tu peux coder les caractères ASCII (et ISO-8859-1, à la rigueur, mais , quoi…) et rien d’autre…

Faux, il n'y a pas que les caractères ASCII et ISO-8859 caractères qui tiennent sur un char.
On peut trouver du :
- MacRoman ;
- CP850 ;
- CP1252 ;
- CP1252 ;
- EBCDIC ;
- etc.
Certes, certains beaucoup ont disparus mais d'autres sont encore répandus (EBCDIC).

Pourquoi faire compliqué alors que je peux simplement vérifier un intervalle ?

Tout simplement parce que tester des intervalles ça n'as rien de portable (et c'est encore pire quand on n'utilise pas les constantes littérales pour tester ces fameux intervalles ) !
Ça l'est juste pour l'ASCII et les systèmes qui l'utilisent. Ta lib va violemment chier dans la colle (enfin non, j'exagère . C'est juste que tu accepteras des caractères non prévu à l'origine) si on la lance sur un système qui autre chose que l'ASCII.

Et sinon, je ne sais pas quels caractères tu veux autoriser en dehors de ce qui est alphanumérique (le ? d'après ce que j'ai compris, il y en a d'autres ?).
Mais permet moi de douter de l'intérêt d'autoriser des caractère comme '{', '}', '(', ')', '[', ']' ou encore '&' en tant qu'options . Le gars en face va s'emmerder à gérer les interférences avec le shell s'il veut les utiliser.

Pylades · Le 18/06/2010, à 20:22

grim7reaper a écrit :

Faux, il n'y a pas que les caractères ASCII et ISO-8859 caractères qui tiennent sur un char.

Simplification… mais pas si fausse que ça.

grim7reaper a écrit :

Certes, certains beaucoup ont disparus mais d'autres sont encore répandus (EBCDIC).

Je n’allait pas citer tous les mourants, quand-même ?

grim7reaper a écrit :

Pylade a écrit :
Pourquoi faire compliqué alors que je peux simplement vérifier un intervalle ?
Tout simplement parce que tester des intervalles ça n'as rien de portable (et c'est encore pire quand on n'utilise pas les constantes littérales pour tester ces fameux intervalles ) !
Ça l'est juste pour l'ASCII et les systèmes qui l'utilisent. Ta lib va violemment chier dans la colle (enfin non, j'exagère . C'est juste que tu accepteras des caractères non prévu à l'origine) si on la lance sur un système qui autre chose que l'ASCII.

Euh… Ça existe encore des trucs qui n’utilisent pas l’ASCII ? Ce n’est pas devenu un quasi standard universel ?
Il me semble que le C ne peut se compiler qu’en ASCII, normalement… (Bon, GCC gère les autres encodages.)

grim7reaper a écrit :

Et sinon, je ne sais pas quels caractères tu veux autoriser en dehors de ce qui est alphanumérique (le ? d'après ce que j'ai compris, il y en a d'autres ?).

Tout ce qui ne risque pas de poser problème.

grim7reaper a écrit :

Mais permet moi de douter de l'intérêt d'autoriser des caractère comme '{', '}', '(', ')', '[', ']' ou encore '&' en tant qu'options . Le gars en face va s'emmerder à gérer les interférences avec le shell s'il veut les utiliser.

Certes. Mais je ne préjuge pas du shell que compte utiliser le mec, il fait comme il veut. Et puis : « _ / ^ @ ~ ( ) , »…

Bon, je vais manger.

grim7reaper · Le 18/06/2010, à 20:42

Pylade a écrit :

grim7reaper a écrit :
Pylade a écrit :
Pourquoi faire compliqué alors que je peux simplement vérifier un intervalle ?
Tout simplement parce que tester des intervalles ça n'as rien de portable (et c'est encore pire quand on n'utilise pas les constantes littérales pour tester ces fameux intervalles ) !
Ça l'est juste pour l'ASCII et les systèmes qui l'utilisent. Ta lib va violemment chier dans la colle (enfin non, j'exagère . C'est juste que tu accepteras des caractères non prévu à l'origine) si on la lance sur un système qui autre chose que l'ASCII.
Euh… Ça existe encore des trucs qui n’utilisent pas l’ASCII ?

Oui, les ordinateurs sous MVS et sous OS/400 pour ne citer que ceux que je connais.
Ces 2 familles sont encores très répandus.

grim7reaper a écrit :
Mais permet moi de douter de l'intérêt d'autoriser des caractère comme '{', '}', '(', ')', '[', ']' ou encore '&' en tant qu'options . Le gars en face va s'emmerder à gérer les interférences avec le shell s'il veut les utiliser.
Certes. Mais je ne préjuge pas du shell que compte utiliser le mec, il fait comme il veut. Et puis : « _ / ^ @ ~ ( ) , »…

Certains de ces caractères sont communs à tout les shells, non ?

Bon, je vais manger.

Bon app' alors.

Dernière modification par grim7reaper (Le 18/06/2010, à 20:43)

Pylades · Le 18/06/2010, à 20:42

Déjà fini !

helly · Le 19/06/2010, à 00:45

#include "Vie.h"
#include <iostream>
int main(void)
{
 Vie moi;
 moi.addPoints(4);
 moi.addNuit(1);
 moi.addJour(-1);
 return -1;
}

Pylades · Le 19/06/2010, à 00:52

O_o'
Tu utilises où iostream ? Et depuis quand on met void en C++ ?
Édit : j’ai testé, pas de warning. Bizarre…

grim7reaper a écrit :

Certains de ces caractères sont communs à tout les shells, non ?

Bof… et alors ?
Je laisse le choix.
Je n’autorise pas les non-ASCII juste parce que je ne suis pas sûr de pouvoir les gérer…

Dernière modification par Pylade (Le 19/06/2010, à 00:58)

grim7reaper · Le 19/06/2010, à 01:06

Pylade a écrit :

O_o'
Tu utilises où iostream ? Et depuis quand on met void en C++ ?
Édit : j’ai testé, pas de warning. Bizarre…

Normal, c'est autorisé (compatibilité avec le C).

grim7reaper a écrit :
Certains de ces caractères sont communs à tout les shells, non ?
Bof… et alors ?
Je laisse le choix.

À ce moment-là, laisse tout les caractère ASCII (de toute façon je le vois mal insérer des caractères de contrôle pour l'utilisation).

\\Ouranos// · Le 19/06/2010, à 01:08

BN.

Pylades · Le 19/06/2010, à 01:17

grim7reaper a écrit :

À ce moment-là, laisse tout les caractère ASCII (de toute façon je le vois mal insérer des caractères de contrôle pour l'utilisation).

Ah, non, les caractères de contrôle, ça fout la merde. Et l’hyphen aussi.

Sinon, je ne trouve aucun tuto cool pour le C++, c’est grave ?

grim7reaper · Le 19/06/2010, à 01:29

Pylade a écrit :

grim7reaper a écrit :
À ce moment-là, laisse tout les caractère ASCII (de toute façon je le vois mal insérer des caractères de contrôle pour l'utilisation).
Ah, non, les caractères de contrôle, ça fout la merde. Et l’hyphen aussi.

L'espace aussi, nan ?
Sinon tu crois vraiment que l'utilisateur peut entrer des caractères de contrôle en entrée de ton programme via la ligne de commande ?

Sinon, je ne trouve aucun tuto cool pour le C++, c’est grave ?

Si tu cherche en français c'est normal.
En anglais je n'en sais rien.
Stroustrup est la base, bien que peu pédagogique (en parlant de bouquin, il faut que j'ajoute celui de Tanenbaum sur les OS à ma liste de course pour quand j'aurais de la thune), quoiqu'il a écrit un bouquin plus adapté au débutant (mais il n'est pas traduit en français).

Sinon là je suis sur le blog d'un gars qui me semble bien calé en C++ (encore un Emmanuel ^^), mais c'est surtout au niveau Architecture Orientée Objet (loi de Demeter, principe de substitution de Liskov, RAII, etc) et de l'analyse technique de la futur norme C++ (en gros rien de bien intéressant pour un débutant, mais il y a 2-3 trucs cool même si je regarde surtout le côté architecture là).

Dernière modification par grim7reaper (Le 19/06/2010, à 02:02)

Pylades · Le 19/06/2010, à 02:21

grim7reaper a écrit :

Pylade a écrit :
Ah, non, les caractères de contrôle, ça fout la merde. Et l’hyphen aussi.
L'espace aussi, nan ?

Ouais, il me semble (ou pas). Mais bon, normalement c’est sensé pouvoir être un caractère de contrôle, alors, je l’interdis aussi, tiens…

grim7reaper a écrit :

Sinon tu crois vraiment que l'utilisateur peut entrer des caractères de contrôle en entrée de ton programme via la ligne de commande ?

C’est toujours possible…
Et puis d’ailleurs, avec gnome-terminal, je peux, via <Ctrl><Shift>u.

grim7reaper a écrit :

Pylade a écrit :
Sinon, je ne trouve aucun tuto cool pour le C++, c’est grave ?
Si tu cherche en français c'est normal.
En anglais je n'en sais rien.

Je cherche en ce qui vient. J’ai trouvé un truc pas trop mauvais, je crois. Pas d’une rigueur à toute épreuve, mais qui essaie de l’être un minimum, et qui ne commence pas par « Ce cours suppose que vous ayez déjà des notions de C. » Mieux, il recommande aux codeurs en C de ne pas sauter des chapitres pour ne pas passer à côté de détails importants. M’enfin, les premiers chapitres, qu’est-ce qu’on se fait chier… stou pareil (ou presque)…
Enfin bon, on a quand-même le droit au sempiternel using namespace std; de portée globale…

grim7reaper a écrit :

Stroustrup est la base, bien que peu pédagogique […].

Stroustrup m’énerve un peu, avec ses assertions péremptoires et douteuses (genre le C++ est supérieur au C quoi que tu veuilles faire ). En plus sa homepage est mal faite.

grim7reaper a écrit :

Sinon là je suis sur le blog d'un gars qui me semble bien calé en C++ (encore un Emmanuel ^^), mais c'est surtout au niveau Architecture Orientée Objet (loi de Demeter, principe de substitution de Liskov, RAII, etc) et de l'analyse technique de la futur norme C++ (en gros rien de bien intéressant pour un débutant, mais il y a 2-3 trucs cool même si je regarde surtout le côté architecture là).

Hum… j’vais p’t’être regarder. C’est où ?

grim7reaper · Le 19/06/2010, à 02:26

Pylade a écrit :

grim7reaper a écrit :
Stroustrup est la base, bien que peu pédagogique […].
Stroustrup m’énerve un peu, avec ses assertions péremptoires et douteuses (genre le C++ est supérieur au C quoi que tu veuilles faire ). En plus sa homepage est mal faite.

Bah, il vend son produit .

grim7reaper a écrit :
Sinon là je suis sur le blog d'un gars qui me semble bien calé en C++ (encore un Emmanuel ^^), mais c'est surtout au niveau Architecture Orientée Objet (loi de Demeter, principe de substitution de Liskov, RAII, etc) et de l'analyse technique de la futur norme C++ (en gros rien de bien intéressant pour un débutant, mais il y a 2-3 trucs cool même si je regarde surtout le côté architecture là).
Hum… j’vais p’t’être regarder. C’est où ?

Là.
Bon il faut déjà avoir des notions de POO pour aborder les articles sur l'architecture (certains demandent même une bonne connaissance du paradigme), pour ce qui est du C++ pur je n'ai lu qu'un article mais si les autres sont de la même qualité je ne me fait pas de souci .

Pylades · Le 19/06/2010, à 02:54

OK.

Bah v’là autre chose, maintenant… Le forum a à nouveau une vitesse normale, et c’est Wikipédia et les autres sites qui merdent… Super ! \o/

><'

grim7reaper · Le 19/06/2010, à 03:06

Chez moi tout est fluide.

Allez, je glob et BN World !

Кຼزດ · Le 19/06/2010, à 03:23

ZZZZzzzzzzzzzzzzzz;!:;

Pylades · Le 19/06/2010, à 03:37

OMG!
Je ne pensais pas dire un truc pareil en voyant du code moche, mais là, on explose les limites de l’horreur apocalyptique ignoblement moche du putain de code de merde. Sans rire.

Et puis, à la fin :

element->address[0] = '10';

OMG!²
Il paraît que c’est le compilo qui permet de produire telle horreur ballmerienne.

Bon, je me retire, il est plus que temps. Et encore je crois qu’il est trop tard : je vais faire des cauchemars cette nuit. ><'

nesthib · Le 19/06/2010, à 03:57

plop

helly · Le 19/06/2010, à 10:32

Pylade a écrit :

O_o'
Tu utilises où iostream ?

Nul part, j'ai fait ce code comme ça sans vraiment refléchir(/me va se fouetter )

Pylade a écrit :

Et depuis quand on met void en C++ ?
Édit : j’ai testé, pas de warning. Bizarre…

D'après le farfadet spacial ça permet de se conformer à la future norme C++, tout en restant conforme à la norme actuelle

Dernière modification par helly (Le 19/06/2010, à 10:33)

helly · Le 19/06/2010, à 10:36

Au fait c'est quoi déjà le nom du truc qui va «dépasser» le C++ ?
Un nom genre C+.0x, ou un nom dans le genre, jm'en souviens plus…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#201 Le 18/06/2010, à 13:20

Re : /* Topic des codeurs couche-tard [1] */

#202 Le 18/06/2010, à 13:35

Re : /* Topic des codeurs couche-tard [1] */

#203 Le 18/06/2010, à 13:39

Re : /* Topic des codeurs couche-tard [1] */

#204 Le 18/06/2010, à 14:13

Re : /* Topic des codeurs couche-tard [1] */

#205 Le 18/06/2010, à 14:37

Re : /* Topic des codeurs couche-tard [1] */

#206 Le 18/06/2010, à 14:38

Re : /* Topic des codeurs couche-tard [1] */

#207 Le 18/06/2010, à 19:18

Re : /* Topic des codeurs couche-tard [1] */

#208 Le 18/06/2010, à 20:22

Re : /* Topic des codeurs couche-tard [1] */

#209 Le 18/06/2010, à 20:42

Re : /* Topic des codeurs couche-tard [1] */

#210 Le 18/06/2010, à 20:42

Re : /* Topic des codeurs couche-tard [1] */

#211 Le 19/06/2010, à 00:45

Re : /* Topic des codeurs couche-tard [1] */

#212 Le 19/06/2010, à 00:52

Re : /* Topic des codeurs couche-tard [1] */

#213 Le 19/06/2010, à 01:06

Re : /* Topic des codeurs couche-tard [1] */

#214 Le 19/06/2010, à 01:08

Re : /* Topic des codeurs couche-tard [1] */

#215 Le 19/06/2010, à 01:17

Re : /* Topic des codeurs couche-tard [1] */

#216 Le 19/06/2010, à 01:29

Re : /* Topic des codeurs couche-tard [1] */

#217 Le 19/06/2010, à 02:21

Re : /* Topic des codeurs couche-tard [1] */

#218 Le 19/06/2010, à 02:26

Re : /* Topic des codeurs couche-tard [1] */

#219 Le 19/06/2010, à 02:54

Re : /* Topic des codeurs couche-tard [1] */

#220 Le 19/06/2010, à 03:06

Re : /* Topic des codeurs couche-tard [1] */

#221 Le 19/06/2010, à 03:23

Re : /* Topic des codeurs couche-tard [1] */

#222 Le 19/06/2010, à 03:37

Re : /* Topic des codeurs couche-tard [1] */

#223 Le 19/06/2010, à 03:57

Re : /* Topic des codeurs couche-tard [1] */

#224 Le 19/06/2010, à 10:32

Re : /* Topic des codeurs couche-tard [1] */

#225 Le 19/06/2010, à 10:36

Re : /* Topic des codeurs couche-tard [1] */

Pied de page des forums