Le topic de la programmation, string, chaînes, cuir et compagnie

**ducon** · 27/12/2014, 15h26

Tu mélanges les choses.
1.0 est un nombre flottant, pas une chaîne de caractères même si Python sait transformer une liste en une chaîne (essaie str([1,2])).
Essaie plutôt d’agir au moment où tu crées ta liste, ça sera plus simple qu’a posteriori.
Essaie ça :

Code:

for l in liste:
  r=[int(i) for i in str(l.pop()).split('.')]
  l+=r

**Møgluglu** · 27/12/2014, 15h31

Si c'est des float, alors c'est juste des nombres qui sont stockées dans la liste. Qu'ils apparaissent avec un point ou une virgule est décidé au moment de l'affichage ou de la conversion en chaînes. Sinon, tu convertis de nouveau en float et tu perds le formattage.
C'est plutôt le code d'affichage qu'il faut vérifier.

**ducon** · 27/12/2014, 15h32

Oui, sinon ta liste va contenir trois éléments au lieu de deux (à moins que ce ne soit l’effet désiré).

**Noospray** · 27/12/2014, 16h28

Effectivement, je me suis mal exprimé.
En fait, ces deux bouts de code font partie de ma fonction d'affichage.
Je cherche donc à convenir le float contenu dans la liste en string en remplaçant le point par la virgule au passage.

J'ai compris grâce à vous que mes deux codes ne sont pas comparables, vu que dans le second je pars déjà d'une chaîne de caractères, mais je ne comprend pas pourquoi le premier ne fonctionne pas...

**olih** · 27/12/2014, 17h08

Je vais surement dire un truc débile, mais ce n'est pas le rôle des fonctions d'internationalisation de prendre en charge ce type de problèmes ? (le print d'un float avec une virgule)

**Sp1d3r** · 27/12/2014, 17h50

Non, tu as raison c'est ça qu'il faut faire.

import locale
locale.setlocale(locale.LC_ALL,"French")
a=3.2
print(locale.str(a))

A noter que sous linux, il faut peut être utiliser autre chose que "French" comme paramètre pour setlocale...

EDIT :

Heu, ton premier bout de code ne peut pas fonctionner : tu itères avec row et ensuite tu assignes à une variable de nom row une valeur qui n'est valable que dans le corps de la boucle. Jamais tu ne modifies la valeur dans la liste.

**Noospray** · 27/12/2014, 18h11

D'accord, je ne connaissais pas cette fonctionnalité des locales.

Par contre, effectivement je ne touche qu'à la variable row, mais je fait la même chose avec élément dans mon second exemple. Or celui ci fonctionne. Ou du moins affiche ce que je désirais

EDIT : bon en fait je suis vraiment un débutant doublé d'un boulet, mes deux fonctions ne marchent pas en fait. Ce qui me rassure d'un côté, parce que si l'une fonctionnait, je ne voyais pas pourquoi l'autre ne marchait pas. Bref.

En fait, je cherche à remplacer le point d'un float par une virgule avant d'enregistrer la liste les contenant dans un fichier. Ceci dans un but de compatibilité avec un Excel français, qui ne comprend pas les points.
A votre avis quelle est la solution la plus élégante ?

**Tomaka17** · 29/12/2014, 20h56

"Quake on an oscilloscope"

**rOut** · 02/01/2015, 18h46

L'edition 2015 de "The Grand C++ Error Explosion Competition": http://tgceec.tumblr.com/

J'ai participé avec 4Go de message d'erreur pour le oneshot, j'ai peut être une chance :3

**rOut** · 03/01/2015, 10h15

Pour les amateurs de C++ moderne, le Filesystem TS a été unanimement approuvé et va être publié prochainement: http://article.gmane.org/gmane.comp....t.devel/256220. En gros c'est Boost.Filesystem en un peu différent. Youpi!

**Tramb** · 03/01/2015, 11h33

Vraiment, l'opérateur / pour append les paths ? Les branleurs... :-)
C'est un peu dommage qu'ils mandatent l'utilisation d'une std::string avec l'allocateur par défaut dans les path, aussi, dans le cas où une application veut faire quelques trucs avec le fs sur la stack avant d'avoir initialisé des allocateurs (je pense à l'embarqué). Edit: Et du coup on peut rien faire sur les paths sans risquer une exception.
Et les permissions directement wirées sur UNIX, mouais. set_uid dans le C++, ça me fait bizarre !
Bon, de toute façon, l'IO c'est pas très portable, alors ça sera quand même mieux qu'avant pour une grande majorité d'applications. Et c'est cool d'avoir le choix entre les exceptions et les codes d'erreur.
Par contre j'ai pas regardé comment l'implémenteur de la toolchain et de middleware peuvent étendre les codes d'erreur standards (pour des storages non inventés encore, par exemple) , mais j'imagine que c'est fait pour.
En revanche c'est dommage (encore une fois), de ne pas avoir un message d'erreur à partir d'un code sans une std::string et donc de potentielles allocations, quand tout commence à partir en sucette, ou quand on est dans un destructeur.

**rOut** · 03/01/2015, 12h14

Les codes d'erreur c'est là dedans : http://en.cppreference.com/w/cpp/header/system_error

**Tramb** · 03/01/2015, 12h34

Mais error_code::value est un int donc c'est cool, ça permet donc de l'étendre. En tout cas c'est bien foutu et fourni en erreurs de base.

**Tomaka17** · 03/01/2015, 13h24

Envoyé par Tramb

Vraiment, l'opérateur / pour append les paths ? Les branleurs... :-)

C'est ce que je disais sur l'overload il y a quelques pages.

En temps normal quand tu vois "a / b" tu sais que tu divises "a" par "b".
Mais si tu overload "/" pour faire quelque chose de totalement différent, tu perds en lisibilité et en prédictibilité.

**rOut** · 03/01/2015, 13h46

Ou pas.

**Tramb** · 03/01/2015, 14h01

On peut débattre sur la perte de lisibilité, mais je crois que c'est assez factuel que c'est de la pignole.

**rOut** · 03/01/2015, 14h21

Bin pas forcément, ça évite peut être de faire des conversions / assomptions plus ou moins judicieuses. Par exemple, c'est ambigu si le mec écrit :

Code:

path p = "coucou ";
p += "\\le filesystem";
p += "/";
p += "c est";
p += "\\/ rigolol"

Alors que ça ne l'est pas avec

Code:

path p = "coucou ";
p /= "le filesystem";
p /= "c est";
p /= " rigolol"

Bon c'est un peu du détail, ils auraient peut être pu dire que le séparateur natif est implementation-dependant mais que le séparateur à utiliser dans le code est "/", comme c'est déjà le cas avec "\n". Mais bon...

Je ne sais pas ce que fait Boost.Filesystem avec les "/" passés dans les chaines par exemple, est-ce qu'il convertit tout les / en : (sur je ne sais plus quel OS qui utilise : ) ou bien est-ce qu'il ne considère comme séparateur que les opérateurs /.

**Tramb** · 03/01/2015, 14h29

Ah mais les concaténation en tant que strings et en tant que liste de tokens ont toutes les deux leur intérêt.
Mais bon, "+" et "/", franchement... J'attends une utilisation smart de l'overloading de ? et * pour faire le glob :-)

**rOut** · 03/01/2015, 14h45

Tu veux dire que tu préfèrerait un truc comme en Java avec genre path.appendString, path.appendDirectory ?

**Tramb** · 03/01/2015, 15h05

Absolument.

**rOut** · 03/01/2015, 15h11

Argh.

**Tramb** · 03/01/2015, 15h23

Mais ce qui serait top, c'est d'avoir des file_path, des directory_path et des path_element pour désambiguer tout ça.
Et là, l'overloading de append ou de + me conviendrait bien. C'est un peu dommage de ne pas plus exploiter le typage. Mais sans doute pas facile à faire élégamment et efficacement en C++.

**Orhin** · 03/01/2015, 15h27

Ça manque d'AbstractFactory tout ça.

**Tomaka17** · 03/01/2015, 15h40

Comment tu veux différencier un file_path d'un directory_path ? On passerait son temps à faire des va-et-viens entre les deux.

Par exemple directory_path::append(path_segment), ça renverrait un file_path ou un directory_path ?

**Tramb** · 03/01/2015, 15h47

Bah soit tu types filename_element et directory_element, soit tu abandonnes le append au profit de append_filename_element ou append_directory_element.
J'ai déjà vu des systèmes en prod avec ce genre de système, ça marche très bien, et dès qu'il y a une ambiguité, tu repasses par un type ambigü et tu laisses le programmeur résoudre l'ambiguité (ce que tu fais toujours avec des strings en maintenant de la métaconnaissance de ce que représentent les différentes chaînes).

Mais a priori, ils ont choisi la simplicité en wrappant juste le path autour d'une std::string, c'est un choix sans trop de polémique et plus facile à implémenter, j'aurais fait pareil si il fallait faire voter 30 personnes :-)

**Tomaka17** · 03/01/2015, 16h12

Envoyé par Orhin

Ça manque d'AbstractFactory tout ça.

Je suis tombé par hasard sur http://loup-vaillant.fr/articles/ant...rphism-and-oop en cliquant sur des articles au pif.
Ne lisez pas l'article, il n'a aucun intérêt. Par contre le code en bas (avec les étudiants et les salles de classe) me donne envie de hurler parce que je vois ça tout le temps.

Ton programme ne manipule pas des étudiants et des salles de classe. Ton programme manipule des infos mémoire à propos d'étudiants et de salles de classe.
Tu ne *déplaces* pas un étudiant vers une classe, tu modifies les informations d'un étudiant afin de mettre à jour son numéro de classe par exemple.
Du coup il n'y a absolument aucun intérêt à appeler ça "move" plutôt que "set_classroom" ou à passer un "Classroom*" comme paramètre plutôt qu'un "ClassroomID" ou un truc similaire.

En Java et ses clones, à la limite c'est pas une gigantesque connerie de passer "Classroom" plutôt que "ClassroomID". Etant donné que les objets Java sont persistants, c'est un peu comme si tu utilisais le pointeur mémoire comme identifiant.
Mais en C/C++ ça n'a aucun sens.

Et d'ailleurs une des choses qui me plaît dans le Rust c'est qu'il est impossible de faire ça. Le revers de la médaille c'est que plein de gens viennent nous dire que "méheu, j'arrive pas à faire ce que je veux".

**TiNitro** · 04/01/2015, 01h10

tain comment tu te prends la tête Tomaka. En comparaison du code que je vois tous les jours, le jour ou je me prendrais la tête avec des trucs comme ça... Champagne.

Sans compter que ta remarque est assez discutable: appeler une fonction "change d'endroit" (set_classroom) ou déplace_toi" (move), on pinaille non ? La catastrophe c'est que move a un sens bien précis en C++ et que là on a une ambiguïté.

**Tomaka17** · 04/01/2015, 09h50

C'est pas une question de nom de méthode, c'est une question de mentalité. Je vois tellement de questions sur le net de débutants qui essayent de manipuler des trucs abstraits et qui se cassent les dents parce qu'ils ne comprennent pas que ce ne sont que des données qu'ils manipulent et pas des vrais élèves et salles de classes.

Sinon l'alpha de Rust 1.0 sort vendredi \o/
L'inconvénient c'est qu'il y a à peu près 10 breaking changes par jour. Tous les changements en question ont été discutés et acceptés depuis longtemps, mais par contre pour les rajouter dans le langage c'est le gros rush à une semaine de la fin.

**Forseti** · 04/01/2015, 13h08

Envoyé par Tomaka17

C'est pas une question de nom de méthode, c'est une question de mentalité. Je vois tellement de questions sur le net de débutants qui essayent de manipuler des trucs abstraits et qui se cassent les dents parce qu'ils ne comprennent pas que ce ne sont que des données qu'ils manipulent et pas des vrais élèves et salles de classes.

Sinon l'alpha de Rust 1.0 sort vendredi \o/
L'inconvénient c'est qu'il y a à peu près 10 breaking changes par jour. Tous les changements en question ont été discutés et acceptés depuis longtemps, mais par contre pour les rajouter dans le langage c'est le gros rush à une semaine de la fin.

Je ne connaissais pas du tout, ça m'a l'air pas mal

Ca vise surtout les projets critiques de l'embarqué? (successeur de l'ADA?)

**Tomaka17** · 04/01/2015, 13h30

Envoyé par Forseti

Je ne connaissais pas du tout

Faut suivre un peu le topic

Le but du Rust c'est de marcher sur les plates-bandes du C/C++, c'est à dire tout ce qui est low-level ou bien rapide. Si toutes les librairies C existantes étaient écrites en Rust, on aurait probablement cent fois moins de failles de sécurité.

Tout ce qui est embarqué ou sans O/S fonctionne aussi, mais c'est un peu secondaire pour le moment.

Discussion: Le topic de la programmation, string, chaînes, cuir et compagnie

Outils de la discussion

Règles de messages