Concernant la disponibilité des bibliothèques externes, je ne suis pas d'accord. la glibc par exemple fournit énormément de fonctions en plus de ce que propose la libc-tout-court. GTK est portée à peu près partout. Après tu peux me dire que ces bibliothèques ne sont pas d'assez bonne qualité pour toi (rapport empreinte mémoire/performance, par exemple), mais c'est un autre débat. Idem pour SDL.
J'ai expliqué ce qu'est la portabilité dans un message plus haut. Le C n'est pas portable au sens ou la majorité des gens l'entend, c'est-à-dire qu'il tourne sur la majorité des combinaison d'OS et de hardware que l'on trouve chez la plupart des gens ou même dans sur des serveur de calcul, mais du code en C pure pourra aussi compiler pour à peu près toutes les architectures et OS existants.
Un compilateur C est en général une des premières choses portée sur un nouvell OS ou un nouvelle architecture.
Dans ce contexte, la GLibc est déjà moins portable tout comme GTK ou la SDL. Ces lib sont faites pour être bien plus haut niveau que ce que l'on attendrait d'un bon runtime en C qui reste portable.
Ma vision des couches de bibliothèques idéale du C serait plus la suivante. Une stdlib très basique qui ne contient que ce qui concerne la communication basique avec le système. Ensuite une bibliothèque qui n'utilise que le langage et la stdlib et qui fournit une couche plus haut niveau prenant en charge notament la gestion des chaines de caractères ou les entrées/sorties formatées.
Et au dessus de ça, des bibliothèques plus complexes qui font intervenir d'autres éléments du système non portables.
C'est toute la faiblesse du C, personne n'est au courant qu'il existe des alternatives plus efficaces dans la plupart des cas…
Je fais encore ma défense des langages de haut niveau, mais des trucs cons comme remplacer des strings par des ropes personne ne le fait, alors que le gain (et la sécurité) sont là dans au moins la moitié des logiciels pondus en C.
Le soucis c'est que tu as :
- un gain en perf : ce n'est pas toujours intéressant, il y a beaucoup de code ou la manipulations des chaines représente un pouillème du temps total ;
- un gain en sécurité : celui-ci est indéniable ;
- une dépendance de plus : donc des galères suppléméentaire quand tu déplois ton application ;
- une perte en portabilité : car la plupart de ces libs ne sont pas vraiment portable. Il n'y a pas besoin d'assembleur pour ne pas être portable, beaucoup d'entre elles suppose que les int sont sur 32bit ou bien en little-endian.
Donc dans beaucoup de cas, les gens trouvent que ça ne vaut pas le coup. Il n'y aurrait rien de base, les gens utiliserais forcement une lib, et celle-ci aurait surement fait plus d'éffort pour la simplicité et la portabilité.
Préfixées oui, mais la taille de l'entier était d'un octet. Super pratique pour des chaînes trèèèèèèèèès longues. Cela dit, je suis d'accord avec toi, faire un bête typedef struct string_s { char *str; unsigned len; } string_t;
Et pourtant ça peut êtrela pire des solutions... Si tes chaines sont toutes très petites le surcout en mémoire est important. Il suffit de regarder les chiffres sur la page ttp://www.and.org/ustr/ pour s'en convaincre. (très bonne lib soit dit en passant)
Le truc surtout c'est que recoder soit même une gestion des chaine c'est souvent s'exposer à encore plus de problèmes.
Saud qu'il n'a pas besoin de la stdlib pour cela. C'est purement une question d'implémentation du compilateur, et pour la plupart des cas cela ce résume à utiliser des intrinsics.
Et, pour ce qui est des bibliothèques externes, tu en as éffectivement de grandes quantité, et certaines de très bonnes qualité. Le problème c'est qu'elle ne sont pas si répandue que ça... La stdlib, tu peut être sur qu'elle disponible avec à peu près tous les compilateurs, ces bibliothèque c'est beaucoup moins sur.
C'est un cercle vicieux : la stdlib est disponible partout avec les bases ce qui n'est pas le cas des lib, donc on utilise la stdlib. Mais comme on utilise principalement la stdlib, ça vaut pas le coup de porter ces bibliothèque sur tous les systèmes...
Un peu de calme, s'il te plait avant que ça ne dégénère, on peut discuter calmement.
Ben oui, C est Turing-complete, merci du renseignement.
On tourne en rond, c'est le fait que le C soit Turing-complet qui fait que la gstion des chaines n'a rien à faire dans la stdlib. Par contre les primitives d'ouverture de fichiers ou de gestion des signaux par exemple, que le C soit Turing-Complet ou pas, tu ne peut pas le faire sans l'aide d'une bibliothèque bas-niveau.
Ce sont des primitives qui sont la pour abstraire le système, qui sont indispensable et qui on leur place dans la stdlib, au contraire de la gestion des chaines.
On parle de la gestion de chaînes de caractères et la norme n'a pas changé cet aspect du langage. Y a un truc compliqué à comprendre ?
Relis ce que j'ai écrit et tu verra que je n'ai jamais dis que la norme avais changé la gestion des chaine de caractères et c'est bien ce que je lui reproche et que je répette depuis plusieurs commentaires.
La norme pouvais le changer tout comme et à changé d'autres choses tout aussi importantes. Et le truc c'est que les gens on adopté la norme, et on changer leurs habitudes pour tout ce que la norme avait changer, donc, on en serait pas la si la norme avait changé la gestion des caractères.
Ah oui, optimiser strlen() en assembleur pour que le O(n) ressemble de loin à du O(1). T'as remarqué que c'était précisément le sujet de la discussion ? :-)
Et ? Ma remarque était juste la pour dire que ces fonctions ne sont pas des primitives bas-niveau mais déjà des fonctions plus haut niveau, la preuve étant que l'on trouve partout des versions en C avant d'en avoir des version en assembleur.
À moins que ta remarque ne soit pour me convaincre que les chaines terminées par 0 c'est nul car il faut des optimisations de fou pour avoir des perfs qui ressemblent vaguement à une autre implémentation. Parce que si c'est ça, je désespère que tu n'ais toujours pas compris que je suis d'accord là-dessus.
Non, ça c'est ta vision idyllique du langage C. En pratique le langage n'exprime pas tout ce qui est calculatoire, et c'est bien pour ça qu'on a notamment des fonctions de manipulation de chaînes (manipuler des chaînes, c'est aussi du calcul) dans la bibliothèque standard.
J'ai un peu de mal à comprendre ce que tu dis là. Tu dis que le langage n'exprime pas tout ce qui est calculatoire et que donc ils ont mit dans la stdlib les fonctions de manipulations de chaines pour palier à ce problème.
Le truc c'est que, comme tu le dis, la manipulation de chaine c'est purement calculatoire, et je te met au défi de me trouver une seule fonction de manipulation de chaine dans la stdlib qui ne peut pas être codé en C pure sans la stdlib.
Sur les 22 fonctions définies par string.h dans le standard, les sul soucis que tu vas avoir sont :
- strcoll et strxfrm qui sont liée à la gestion des locales, mais avec les primitive définie dans locale.h qui contient des fonction plus bas-niveau il n'y a plus de problèmes.
- strerror qui est une fonction systeme plus qu'une fonction de manipulation de chaine puisqu'elle sert à traduire un code d'erreur système en un message d'erreur.
Toutes les autres sont triviales à coder en C pur et j'irais même plus loin, presque toutes les implémentations de la stdlib en on une version en C pur en plus d'éventuelles version en assembleur optimisé car c'est bien plus portable.
Seule les vrai fonctions non calculatoire qui sont des appels systèmes ne peuvent être codée en C pure et nécéssite un petit bout d'assembleur. Et celles là mérittent vraiment leur place dans une lib bas-niveau.
Oui, enfin c'est hors-sujet là. La représentation des chaînes était là dès le C original, elle ne date pas de la standardisation, et elle n'a pas changé avec cette dernière.
Ce n'est pas hors-sujet du tout. Ce qui est utiliser actuellement c'est la version standard et pas la version de base. La norme à changé beaucoup de choses et les gens ce sont adaptés, à part dans de vieux codes on ne voit plus les anciennes version des prototypes de fonctions.
Donc si la norme à pus changer ce genre de choses elle aurait très bien pus changer la stdlib afin que celle-ci n'incite plus les dev à utiliser cette convention.
Il faut bien voir que cete convention c'est imposée et perdure encore aujourd'hui par ce que c'est la manière la plus simple de gérer les chaines de caractère de façon portable car si tu veux une autre gestion il te faut soit tout recoder à la main, soit utiliser une lib qui n'a pas pus se déveloper suffisament et être largement diffuser car une solution simple et pas trop muvaise éxistait.
Le comité de normalisation était la justement pour virer toutes les merdes des différentes versions du C, et s'il ont réussit sur certains points, ce n'est pas le cas pour la stdlib ou ils en ont encore trop laissé.
Heu... on est au 21ème siècle, c'est un peu ridicule de considérer un langage sans tenir compte de sa bibliothèque standard. On peut bien sûr réécrire un runtime différent depuis zéro, mais ce n'est certainement pas l'usage favorisé par l'écosystème.
Le probème ici c'est que justement la bibliothèque standard du C n'est pas vraiment ce qu'on appelle un runtime au 21 siècle. Elle propose à peu près rien comme fonctions par rapport à ce que l'on attend maintenant d'un runtime.
Donc le runtime du C c'est plus d'autre bibliothèques haut niveau et bien plus complètes. Donc dans ce cas la stdlib c'est juste une couche très bas niveau pour astraire le minimum du système et donc il y a dedans beaucoup de fonctions qui n'on rien à y faire.
Elle à donc bien le cul entre de chaise, pas vraiment un runtime et pas vraiment une bibliothèque minimaliste.
Là le problème ce n'est pas que les gens (en général) font n'importe quoi, c'est que c'est la bibliothèque standard qui fait n'importe quoi depuis le début et qui encourage le reste des développeurs à s'appuyer là-dessus (ainsi que sur les autres couches optionnelles qui sont venues s'ajouter à la dite bibliothèque standard).
On est d'accord sur le fait que la stdlib fait n'importe quoi depuis le début ; par contre je ne suis pas sur que l'on soit d'accord sur le n'importe quoi en question ;-)
Pour moi il n'y a aucun problème pour qu'elle gère les chaines de caractère en les terminant pas un zero (revenons au débat initial) par contre, il y a un gros problème quand elle commence à proposer des fonctions qui ne devrait pas être de son ressort et qui utilisent cette convention aussi alors que de manière générale c'est rarement la meilleure.
Mais il y a de la faute des utilisateurs eux aussi. Tout le monde sait qu'il y a beaucoup de cas ou ce n'est pas optimal, qu'il y a moyen de faire mieux et même que des libs existent pour faire mieux. Mais une grosse majorité des utilisateurs continue de suivre cette convention.
A partir du moment où une convention de représentation est choisie, il faut aussi générer et traiter les chaînes représentées selon cette convention, donc des fonctions de gestion adaptées. Fort logiquement, la stdlib a donc fourni des fonctions de gestion adaptées à la convention utilisée par les différents appels système.
Si tu te contente de faire une bibliothèque minimaliste qui ne propose que le minimum pour pouvoir travailer avec l'OS, tu n'en a pas besoin. L'idée c'est que les fondation c'est un langage qui permet d'exprimer tout ce qui est calculatoire, et une bibliothèque qui abstrait un minimum les appels système afin que ce soit portable.
Avec ça tu as une base minimaliste mais relativement portable ; et la dessus tu construit une vrai biliotheque de plus haut niveau.
Dans cette bibliothèque tu peut très bien fournir deux ou trois conventions diffrents pour les chaine de caractères si tu veux que l'utilisateur puisse choisir et aucun d'elles n'est forcée d'utiliser la convention du système qui est en dessous. Tu le dis toi-même dans un message au dessus, en interne, la représentation des chaines en python n'a rien à voir avec des chaine terminées par 0.
Cela me semble bizarre comme explication. Le C a été conçu pour écrire Unix, la motivation principale de la stdlib était donc probablement de faciliter l'écriture des outils système.
(le C n'a pas été un exercice académique de création d'un langage idéal ou désincarné comme l'ont été d'autres langages)
Les origines du C sont bien entendu liés à la création d'Unix, mais le C à pas mal évolué et est passé par plusieurs standardisations. Actuellement on en est au C99, mais le standard le plus connu reste celui que l'on appelle l'ansi/C qui date de 89. Et ces version du C sont différentes sur bien des points du C d'origine.
Au niveau du langage en lui-même, le C89 avait éssayer de rester le plus compatible possible avec les versions les plus utilisée à l'époque (qui était déjà bien différentes des premières version du C) en gardant certains structures mais en les indiquant comme non recomandée. Les prototypes des fonctions en son un exemple typique.
Pour la librairie par contre, si certaines chose on été gardé et si certaines convention sont les même, il y a eu énormément de changement, notament pour des raison de portabilité. Ils ont éssayer de trouver un dénominateur commun à toutes les librairies qui éxistait alors et normalement ils devaient faire les choses proprement... Le soucis est qu'ils ont préféré faire des compromis plutôt que d'aller au font des chose en la nétoyant au maximum quitte à standardiser une bibliothèque plus haut niveau à côté.
Tu as bien fait de barer les dauphins, il sont moins cons que nou et serons partis avant la fin du mone, sans oublier quand même de nous remercier pour le poisson.
Tout dépend de ce que tu entends par portabilité et là aussi c'est un grand débat...
Pour moi, il y a deux niveaux de portabilité. Le premier, celui auquel on pence le plus souvent consiste à dire qu'un programme est portable si on peut le faire tourner sur pas mal de platformes courantes que le commun des mortels utilise courrament et consciament. Donc en gros sur des ordinateurs au sens madame michu du terme avec un OS au sens au moins 1% de geek en a déjà entendu le nom.
Dans ce cas là, java est portable tout comme du C++ et je pense Qt ou la GLib. De même pas mal de langage de scripts vont entrer dans cette catégorie.
Le deuxième, celui auquel je faisait référence ici, concerne un bien plus grand nombre de machine et d'OS puisqu'il englobe tous les systèmes capable d'exécuter un programme, même les petits micro controleur ou autre. Ça concerne peut-être moins de monde ici, mais de manière globale ça concerne énormément de monde...
Dans ce cas la être portable ça eut dire être compilable sur un max de platformes très hétérogènes. Et pour ces platformes, en général un compilateur ansi/C est la première chose qui soit disponible pour compiler du code en dehors de l'assembleur ou d'un langage spécifique à la platforme.
Donc, la grande majorité du temps, un code portable dans ce sens c'est un code en ansi/C et la seule chose que ce code peut utiliser c'est des bibliothèques elles-aussi en ansi/C.
C'est ça qui à poussé les auteurs du langage Lua, par exemple, à le coder en ansi/C pur. Ils ont conçu le langage pour leur besoin à la base et les sytsème sur lesquels il était utilisé était très hétérogène, il n'avait donc pas trop le choix.
Le revert de la médaille c'est que c'est aussi un langage relativement pauvre en librairies fournies de base, beaucoup de chose sont soit impossible en c pur, soit tros complexe à réimplémenter et la aussi laissées au soins de lib externe qui ne sont plus forcément portable.
À mon avis il y a surtout de moins en moins de nouveaux projets qui commencent en C. Déja pour faire une interface graphique t'es obligé de rajouter une bibliothèque, genre glib ou Qt.
beaucoup de projets n'ont pas besoin d'interface graphique et ce sont en plus ceux qui sont le plus souvent codé en C...
Beaucoup de programme sont d'ailleur codé de cette manière, un coeur qui fait le gros du boulot codé en C ou dans un autre langage suffisament portable pour la tâche en utilisant le moins de lib non portables possible. (pas toujours évident)
Et à côter une interface graphique qui appelle l'autre code portable sous la forme d'un programme ou d'une lib.
Coder une interface graphique en C n'a pour moi que peu d'interet car il y a des langage ou c'est beaucoup plus simple, bien moins sujet au bugs et vu que l'interface graphique impose déjà des contraintes sur la portabilité autant faire au plus simple.
Il n'y a pas besoin de fonction de gestion de caractères pour donner un nom de fichier, il suffit juste de spécifier une convention pour ces fonctions. Avoir juste les primitive de gestion de fichiers était suffisant et aurait encouragé bien plus fortement l'utilisation des bibliothèques un peu plus haut niveau.
L'idée de base de bibliothèque standard était d'abstraire les quelques éléments spécifique au système qui ne font pas partit du langage, donc le minimum aurait suffit. Mais ils on quand même ajouté un peu plus histoire que l'on ne se retrouve pas trop nus. Résultat, il n'y a pas suffisament de fonction pour que l'on puisse ce passer de librairies mais il y en trop pour que ce ne soit vraiment qu'une couche bas niveau qui est à peu près tout le temps caché au programmeur.
Au final, on se retrouve dans une situation ou il y a suffisament de fonction pour que les programmeurs préfèrent recoder le peu qu'il manque et faire avec les problème de la stdlib, et donc aucune lib un peu plus touffue n'a réussie à s'imposer. Les deux son liés :
- pas de lib de bonne qualitée et répandue --> on fait avec ce qu'il y a et on recode le reste
- on fait avec et on recode --> les libs qui éxiste n'attirent pas assez de monde et se répandent peu
Le problème ce situe à l'origine et à mon avis on ne pourra rien y changer. Je suis le premier à faire avec la stdlib et à recoder pour la simple raison que actuellement, écrire un code en ansi/C est ce qui ce fait de plus portable. La quasi totalités des système éxistant disposent d'un compilateur ansi/C.
Le problème c'est que à peu près toutes les libs éxistante pas trop pourries reposent sur des extention du compilateur ou des éléments spécifiques à la platforme, donc on perd la portabilité. Mon choix est vite fait, j'ai ma petite collection perso de fonction et structure de données, et je repique dedans ce dont j'ai besoin.
Si seulement ils avait choisit de faire une lib complète ou pas de lib du tout au moment de la standardisation...
Le C, de base ne propose aucune gestion des chaine de caractères. Seule la librairie standard propose quelques fonctions qui reposent sur la convention de terminer les chaine par le caractère nul, convention qui à étée reprise par énormément de programme.
Le C est un langage bas niveau qui te laisse le choix de la manière dont tu code tes chaines de caractère, rien ne t'empeche d'utiliser une structure telle que : struct string {
size_t length;
char data[];
}
qui est du C tout aussi standard que les chaine terminé par nul. Et tu trouvera plein de bibliothèques qui te le proposent avec beaucoup de variantes dans les représentations.
C'est toute la puissance du C, tu n'est pas limité par un modèle, tu fais ce que tu veux. C'est aussi là, sa plus grande faiblesse, car, à donner trop de libertées, les gens font n'importe quoi.
Si ton programme nécessite d'avoir souvent accès à la longueur de la chaine, une représentation qui la concerve de manière explicite est parfaitement adapté. Mais si ton programme ce contente de faire des parcours de chaine relativement petites mais en grand nombre, le marqueur de fin est plus adapté, car le surcout est réduit.
Pour te paraphraser, la mémoire la moins gachée est celle qui est vraiment utilisée, donc si tu n'as que très rarrement besoin de la longueur d'une chaine, autant ne pas la stocker et la calculer juste une fois de temps en temps.
Le principal soucis est le design de la lib standard du C, elle à le cul entre deux chaise :
- d'un côté ils l'on voulut minimaliste et comptait sur tous les bibliothèques disponibles autour pour fournir l'éssentiel ;
- de l'autre, ils ont quand même mits dedans d'un fonctions qui sont trivialement codable en C pour gérer les chaines d'une manière qui n'est corecte que dans certains cas.
Ça à deux conséquences :
- puisque les bases sont disponibles, la convention adoptée par ces bases est utilisée trop souvent, et n'importe comment, plutot que d'aller chercher une bonne lib adaptée au programme ;
- puisque seule les bases sont disponibles, les programmeur recodent à chaque fois pleins de fonctions manquantes et multiplient les risques de bugs.
Si je comprends bien, ta solution au problème d'indentation consiste à ne jamais utiliser d'alignement vertical... Ce n'est pas tellement ce que j'appelle une solution.
Dans ma solution, le "if" et le "else" sont alignés verticalement, de même que le contenu du "if" et le contenu du "else".
Ma solution consiste à indenter en debut de ligne avec uniquement des tabulations, hors l'indentation est justement un alignement vertical.
De même, à mon avis il ne faut jamais utiliser de tabulation en dehors du début de ligne, l'alignement vertical à l'interieur des lignes ne doit ce faire qu'avec des espaces, donc si je reprend un de tes exemple au dessus, je le préfère de cette manière (avec les ~ pour symboliser les espace) : void f()
{
--int~~~i;
--char~j;
...
}
L'idée c'est de s'assurer que l'on puisse avoir un affichage à son gout tout en minimisant les risque que l'indentation deviennent incohérente.
La configuration par default de la majorité des éditeur consiste à utiliser les tabulations pour indenter, donc il y a peu de chances qu'une personne indente de manière incohérente sans le savoir.
Et pour les utilisateurs capable de modifier la config de leur éditeur, ils peuvent avoir l'aspect qu'ils désirent. Moi j'aime les grande indentation, donc mes tabulations sont reglées sur 8 espaces, alors qu'un pote préfère les petite donc il règle ses tabulations sur 2 espaces. Résultats on à tous les deux une indentation à notre gouts avec le même code.
Et en utilisant des espace pour lalignement à l'interieur des lignes, ont gardent tous les deux un alignement correct dans les lignes.
Avec ta solution, ça marche beaucoup moin bien. Moi j'aime les indentations homogène, si un codeur commence à mettre des espace comme dans ton code, certaine parties sont visuellement indentées avec plus d'espace que d'autres.
De même avec des tabulation régles sur 8 espaces, pour avoir des débuts de lignes qui me plaisent, l'alignement vertical avec des tabulation devient horrible, les variables sont séparées de eur type par plus de 8 espaces...
Je ne sais pas si c'est cette version mobile que wikipedia à gagné dans son partenaria avec orange, mais j'ai découvert il y a peu qu'en rajoutant un "m" dans l'url d'une adresse wikipedia on arrivait sur une version mobile.
Par exemple, une page classique telle que http://fr.wikipedia.org/wiki/Linuxfr peut être accédée en version mobile par http://fr.m.wikipedia.org/wiki/Linuxfr .
Cette version mobile est bien plus légère et organisée de telle manière que, même sur des petits écran, elle reste très lisible sans avoir à scroller dans tous les sens. C'est super agréable sur un téléphone.
Dans ce cas, pourquoi ne pas plutôt écrire :
def plop truc
--truc =
----if truc.nil?
------0
----else
------truc.to_i
...
end
Ça n'utilise que des tabulations et l'alignement est à mon gout bien plus clair, on voit bien à quel if correspond le else mais surtout on voit bien qu'il y a un if dans l'affectation.
Ça fait une ligne de plus, mais de nos jours, on n'est plus vraiment limité à 20 ou 25 lignes à l'écran.
Le faire tel que tu le fait me semble dangeureux. Cela nécéssite que toutes les personne qui travail sur le même code que toi reglent leur éditeur pour qu'il reproduise l'indentation de la ligne précédente à l'identique. C'est le genre de truc qui finit toujours par merder et faire perdre un max de temps parce qu'un boulet à fait un commit sans vérifier.
Je comprend pas ta méthode. Pour quoi faire : def plop truc
--truc = if truc.nil?
-- --0
-- else
-- --truc.to_i
...
end
Plutôt que : def plop truc
--truc = if truc.nil?
------0
----else
------truc.to_i
...
end
C'est bien plus simple et lisible à mon avis d'indenter du même espacement dans tous les cas.
Je ne vois pas dans ce cas qu'elle est la logique qui te fais utiliser un espace à partir de la troisième ligne.
Là par contre je ne suis pas du tout d'accord. La seul manière d'avoir une indentation correcte quelle que soit la taille d'une tabulation et de n'utiliser que l'un ou l'autre.
Tout mélange finira par t'apporter des problèmes : avec ta méthode : bip
--bop
-- bap
--bop
----bap
Rien ne t'oblige à utiliser la même indentation pour les deux "bap" alors que ça doit être le cas.
Et j'irais même plus loin, la seule méthode d'indentation correcte consiste à utiliser une tabulation par niveau, ce qui permet à chacun de choisir la largeur de ses tabulation et de voir un ode à son gout.
Les tabulation étant très simple à remplacer par des espaces, les plus grincheux sont contents aussi. (alors que dans l'autre sens on retrouve des problèmes)
Pour ce qui est de l'alignement vertical, qui est une chose différente de l'indentation, mais que l'on trouve dans ton premier exemple, l'utilisation de tabulation me semble inapproprié. Tu te trouve à éloigner parfois très fortement le nom de la variable de sa déclaration ce qui peut rendre la lecture difficile.
Le plus simple est souvent de ne faire cet alignement que de manière intelligente, en regroupant les variables ou autres de manière cohérente et en utilisant des espaces.
D'ailleurs, ton affirmation que les délimiteurs rendent le code sans ambiguïté peut facilement être remise en question. Je te sors quelques classiques :
Mon affirmation ne portait pas sur l'ensemble du langage mais uniquement sur la partie délimitée par le délimiteur. Ce que je disait c'est qu'avoir des parenthèse autour de la condition dans les if ou dans les boucles c'est bien plus lisible et beaucoup moins ambigue à mon gout. Cela ne veut pas dire que le reste de la syntaxe ne pose pas de problèmes.
Le C est plein de problèmes à ce niveaux là, mais dans ce cas, pourquoi gardez tout ces problème et en rajouter d'autres ? Pourquoi ne pas plutôt juste corriger les problèmes existants ?
En tout cas, les deux exemples font la même chose, je continue à trouver la version python plus lisible. Et je n'ai pas triché sur le C++, j'ai utilisé la méthode officielle d'itérer sur un tableau STL.
Tu ne triche pas sur le C++ mais quelques petites remarques :
- La STL à été fait avec les pieds par des manchots aveugle qui voulait ce venger du reste du monde ;
- Pour un exemple comme celui là, utiliser un vector ne sert qu'à perdre du temps, il faudrait comparer sur des exemple un peut plus intéressants ;
- Tu prend exactement un des pires cas de la STL (qui démontre très bien d'ailleurs l'absurdité de beaucoup de chose dans cette bibliothèque.)
Si on oubli les outils de torture et que l'on ce place dans une situation un peu réaliste pour du C, tu 98% de chance d'avoir la taille de ton tableau quelque part dans une variable accessible. Si ce n'est pas le cas, il y a de fortes chances que tu ait un problème et le code devient : for (int i = 0; i < len; i++)
printf("%d\n", tab[i]);
Qui est déjà beaucoup plus lisible que la version C++....
Alors, en soit ça peut sembler plus complexe et plus verbeux que ta version en python, mais l'avantage c'est que ta boucle est quasiment identique si tu veux parcourir ton tableau dans l'autre sens, ou si tu veux afficher les indices en même temps que les valeurs, ou parcourir deux tableaux en même temps.
Donc sur un exemple on à l'impression d'être perdant, mais sur une utilisation générale, tu y gagne en homogénéité : tous les parcours seront codé sur le même modèle.
C'est vraiment une question de gouts mais moi j'ai fait mon choix ;-)
Donc pour en revenir à nos moutons,[...]
Je pense que je rentre maintenant dans la case vieux barbus, vu que je ne suis pas choqué mais que j'ai plutôt tendance à regarder ce genre de nouveau langage avec un petit sourire en coin ;-)
C'est domage, je ne pensait entrer dans cette catégorie que l'an prochain, et merde, j'ai pris un an d'avance
Quand tu écris la formule sur une feuille, tu écris bien
45020089
-------------
8!
tu peut aussi écrire :
45020089
--------------- !
8
Quand tu écrit la division sous cette forme, ça revient à mettre des parenthèses. Dans ton code par contre l'ambiguïté demeure.
Et que ce soit programmé par des gens avec de bonnes intentions et le faisant de manière très logique ne change rien au problème. Avoir le même opérateur avec une priorité différente et une sémantique différentes suivant le type rend le programme beaucoup plus difficile à lire.
Si tu surcharge les opérateurs pour un type vecteurs par exemple, il devient naturel de ce demander si le '*' correspond au produit par composantes, au produit vectoriel au produit scalaire. Tu trouvera toujours des gens plein de bonnes intentions qui trouverons des raison parfaitement valable de choisir l'un plutôt que l'autre.
Le gros problème c'est que quand tu te retrouve face à leur code, tu te demandera toujours si le mec qui à codé la lib à la même logique que toi.
C'est, pour moi, un des plus gros points noir du C++. Combien de fois je me suis retrouver devant un code ou un mec à cru malin de redéfinir les opérateur pour rendre son code plus concis par la suite et en théorie plus clair... la plupart du temps tout ce que l'on obtient c'est un code extrêmement difficile à débugger car une expression qui semble évidente fait quelque chose auquel on aurait même pas penser dans nos pire cauchemars.
Donc, la surcharge d'opérateur est pour moi quelque chose d'encore plus dangereux que les pointeurs car ses effets pervers peuvent être quasiment invisibles, là ou un pointeur est bien visible. Quand je vois un pointeur, je sais que je dois faire particulièrement attention, pour les opérateur, il est dur de dire s'il y a danger ou pas.
On a les opérations infixées, préfixées, postfixées, ... Tu peux donc définir la priorité des opérateurs comme tu le souhaites. C'est fait pour pouvoir écrire tes formules au plus près de l'écriture mathématique classique.
L'intention est louable mais le problème c'est que ton code est illisible. Sans parenthèses je me demande toujours si je doit comprendre (45020089/8)! ou bien 45020089/(8!). Et le fait de pouvoir spécifier la priorité de ces opérateurs de manière différente suivant le type de données manipulée rend les choses encore pire.
Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.
Des programmeurs "qui en usent sans en abuser et qui le font avec précautions" et qui sont capable de maitriser la chose, maintenant ça se compte sur les doigts de la main : va bosser dans des SSII, des boites ou on fait du logiciel de gestion, etc... Tu verras que très peu sont capable de faire du code propre sans qu'on soit constamment derrière leur dos, alors faire du code propre avec des pointeurs...
Pour récapituler : les pointeurs sont un outils très puissant dans les mains des bon programmeurs mais une grosse bombe à retardement dans les main des mauvais programmeurs.
Le problème est que l'on à peu près que des mauvais programmeurs. Donc on oubli les pointeurs, on va pas prendre de risque.
Pour tout dire, tu prend le paragraphe précédent et tu remplace pointeur par surcharge d'opérateurs et le texte reste parfaitement vrai.
Tu prend du C++ pondu en SSII et tu regardes à quoi sert la surcharge d'opérateur. Le plus souvent tu te retrouve avoir des objets qui s'additionne ou ce multiplie de manière complètement illogique et le code deviens incompréhensible et tout aussi dangereux qu'avec des pointeurs.
D'après toi pourquoi PHP, qui est un des langage les plus permissif et non rigoureux a eu un tel succès ?
Parce que le programmeur moyen a un niveau assez bas.
Faut faire des langages qui s'adaptent aux gens, pas l'inverse.
Le problème c'est que lorsque le niveau est si bas, il ne faut pas un langage permissif mais au contraire un langage extrêmement strict et très redondant afin que le compilateur puisse détecter le maximum d'erreurs et afficher des messages les plus clairs possible.
C'est pour cela que le PHP est une bouse infâme : il a une syntaxe qui lui permet de ne se préoccuper des erreur que le plus tard possible : en général quand il est trop tard. Ajoute à cela le fait qu'il est principalement utiliser sur des machine connectée au net et tu peut en déduire ce que je pense de ce langage.
Je ne le juge pas uniquement sur la syntaxe, mais cela fait partit de tout ce qui entre en compte dans mes choix. Et le fait que je trouve les boucle for de Go illisible par exemple est un élément vraiment bloquant pour moi.
Quand tu relis du code pour vérifier qu'il fait bien ce que tu pense ou que tu traque un bug, la lisibilité est un facteur très important. Et je préfère un langage un peu moins expressif mais parfaitement lisible, à un code ambiguë où, sous prétexte de taper quelques caractères de moins, on a supprimer des délimiteurs redondant mais qui facilitent énormément la lecture.
C'est le même problème avec l'indentation en python. L'idée de base de forcé les gens à indenter correctement leur code est louable même si je suis contre. Le problème c'est que même en faisant ça, les gens réussissent à te faire des horreurs. Il suffit de voir que les guidelines continue quand même de parler de la manière d'indenter le code et que certains pondent des horreurs comme celle-là : http://lapagearegis.free.fr/guidedestyle.html qui conseillent de mélanger les espaces et les tabulations.
Donc, quoi que tu fasses, tu peux être sur que ceux qui veulent foutre le bordel réussirons à le faire d'une manière ou d'une autre.
L'avantage des délimiteurs est justement de rendre le code lisible sans ambiguïtés quelque soit le style choisit par le programmeur.
Ils sont redondant de la même manière que dans les langues naturelles il y a de nombreuses redondances. Tout comme les ; en fin de ligne ne sont pas toujours nécessaire, mais ils permettent d'indiquer clairement ou ce termine une instruction et ou commence la suivante.
L'objectif de tout cela est de faciliter la lecture du code. De manière idéale, lorsque tu lis du code, tu ne devrait pas avoir à réfléchir sur les aspects syntaxiques ; tu devrais voir directement à quoi correspond chaque instructions et l'effort mental ne devrait concerner que la logique du code pour essayer de comprendre ce que fait le programme et voir si c'est bien ce que tu veux.
- Compilation séparée, bonjour les perfs, surtout que là avec un embryon d'objet ça va commencer à poser quelques problèmes niveau perfs... T'as pas de VM pour rattraper le coup ici...
Ce serait pas le cas du C qui reste à ce niveau là un des meilleurs langage ? Et le cas du C++ aussi ?
De plus la compilation séparée n'est pas un élément du langage mais principalement du compilateur. C'est celui-ci qui choisit de considérer chaque module indépendament ou comme un tout.
- Pas de redef des opérateurs. Change pas cela dit, par rapport à ce que la plupart des gens connaissent. (Nous, en Lisaac, on est assez fière de pouvoir écrire 45_020_089/8!.print )
J'espère que tu blagues en disant ça ? Utilisé proprement et avec beaucoup de modération, la redéfinition des opérateur peut-être utile mais dans ton exemple, on peut se poser des question sur la signification du "!" et le ".print" à la fin est pas vraiment plus lisible et plus clair qu'une méthode classique.
En voyant ton exemple je me pause les question suivante :
- est ce que le "/" veut encore dire division ou est-ce qu'un boulet en a changer le sens ?
- est-ce que le "!" veut dire factorielle ou autre chose et si oui, qu'est-ce qui est vraiment calculer si la valeur n'est pas ntière ?
- entre le "/" le "!" et le "." qu'elle sont les règles de prioritées et donc est-ce qu'il va bien m'afficher le résultat du calcul et surtout faire le bon calcul ?
- Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
On peut critiquer autant qu'on veut les pointeurs mais c'est comme la surcharge des opérateurs, dans les mains d'andouille qui font n'importe quoi ça pête dans tous les sens ; mais dans les mains de bon programmeur qui en usent sans en abuser et qui le font avec précautions, ça fait des choses magnifiques.
Mais au final, tout le monde a un avis différent sur l'esthétique du code et donc on se contente de limiter le nombre de personnes qui vont adopter le langage.
Par exemple, les identifiant (de classe il me semble mais je ne suis plus sûr) tout en majuscules de Lisaac sont la principale raison qui m'a fait abandonner ce langage qui pourtant contenait pas mal de bonne idées. Mais non, je n'ai pas réussit à m'habituer à ces horreurs.
De la même manière que je ne fait pas de python à cause de cette indentation qu'il faut faire d'une manière bien particulière et que j'ai toujours vu poser plus de problèmes qu'elle n'en résout.
Sans parler du fait que toutes ces conventions qui sont utilisées de manière implicite par le compilateur rendent le programme plus difficile à comprendre pour une personne externe.
Un codeur qui ne connait rien à Go, lorsqu'il va voir du code avec des nom en majuscule et d'autre en minuscule, il va se dire que le programmeur est un branleur qui pourrait au moins faire un code homogène ; il se dira surement pas : à tiens, ça doit surement servir à dire au compilateur qu'elle sont les méthodes externes.
Donc en gros, on se retrouve avec un langage ou "d'un point de vue personnel" tous les programme, même ceux que moi je suis susceptible d'écrire, sont forcément moche.
Peut-être que pour d'autre c'est joli, mais je continue de penser que le langage ne devrait rien imposer à ce niveau là.
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 2.
J'ai expliqué ce qu'est la portabilité dans un message plus haut. Le C n'est pas portable au sens ou la majorité des gens l'entend, c'est-à-dire qu'il tourne sur la majorité des combinaison d'OS et de hardware que l'on trouve chez la plupart des gens ou même dans sur des serveur de calcul, mais du code en C pure pourra aussi compiler pour à peu près toutes les architectures et OS existants.
Un compilateur C est en général une des premières choses portée sur un nouvell OS ou un nouvelle architecture.
Dans ce contexte, la GLibc est déjà moins portable tout comme GTK ou la SDL. Ces lib sont faites pour être bien plus haut niveau que ce que l'on attendrait d'un bon runtime en C qui reste portable.
Ma vision des couches de bibliothèques idéale du C serait plus la suivante. Une stdlib très basique qui ne contient que ce qui concerne la communication basique avec le système. Ensuite une bibliothèque qui n'utilise que le langage et la stdlib et qui fournit une couche plus haut niveau prenant en charge notament la gestion des chaines de caractères ou les entrées/sorties formatées.
Et au dessus de ça, des bibliothèques plus complexes qui font intervenir d'autres éléments du système non portables.
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 2.
Je fais encore ma défense des langages de haut niveau, mais des trucs cons comme remplacer des strings par des ropes personne ne le fait, alors que le gain (et la sécurité) sont là dans au moins la moitié des logiciels pondus en C.
Le soucis c'est que tu as :
- un gain en perf : ce n'est pas toujours intéressant, il y a beaucoup de code ou la manipulations des chaines représente un pouillème du temps total ;
- un gain en sécurité : celui-ci est indéniable ;
- une dépendance de plus : donc des galères suppléméentaire quand tu déplois ton application ;
- une perte en portabilité : car la plupart de ces libs ne sont pas vraiment portable. Il n'y a pas besoin d'assembleur pour ne pas être portable, beaucoup d'entre elles suppose que les int sont sur 32bit ou bien en little-endian.
Donc dans beaucoup de cas, les gens trouvent que ça ne vaut pas le coup. Il n'y aurrait rien de base, les gens utiliserais forcement une lib, et celle-ci aurait surement fait plus d'éffort pour la simplicité et la portabilité.
Préfixées oui, mais la taille de l'entier était d'un octet. Super pratique pour des chaînes trèèèèèèèèès longues. Cela dit, je suis d'accord avec toi, faire un bête
typedef struct string_s { char *str; unsigned len; } string_t;Et pourtant ça peut êtrela pire des solutions... Si tes chaines sont toutes très petites le surcout en mémoire est important. Il suffit de regarder les chiffres sur la page ttp://www.and.org/ustr/ pour s'en convaincre. (très bonne lib soit dit en passant)
Le truc surtout c'est que recoder soit même une gestion des chaine c'est souvent s'exposer à encore plus de problèmes.
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 2.
Et, pour ce qui est des bibliothèques externes, tu en as éffectivement de grandes quantité, et certaines de très bonnes qualité. Le problème c'est qu'elle ne sont pas si répandue que ça... La stdlib, tu peut être sur qu'elle disponible avec à peu près tous les compilateurs, ces bibliothèque c'est beaucoup moins sur.
C'est un cercle vicieux : la stdlib est disponible partout avec les bases ce qui n'est pas le cas des lib, donc on utilise la stdlib. Mais comme on utilise principalement la stdlib, ça vaut pas le coup de porter ces bibliothèque sur tous les systèmes...
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 1.
Ben oui, C est Turing-complete, merci du renseignement.
On tourne en rond, c'est le fait que le C soit Turing-complet qui fait que la gstion des chaines n'a rien à faire dans la stdlib. Par contre les primitives d'ouverture de fichiers ou de gestion des signaux par exemple, que le C soit Turing-Complet ou pas, tu ne peut pas le faire sans l'aide d'une bibliothèque bas-niveau.
Ce sont des primitives qui sont la pour abstraire le système, qui sont indispensable et qui on leur place dans la stdlib, au contraire de la gestion des chaines.
On parle de la gestion de chaînes de caractères et la norme n'a pas changé cet aspect du langage. Y a un truc compliqué à comprendre ?
Relis ce que j'ai écrit et tu verra que je n'ai jamais dis que la norme avais changé la gestion des chaine de caractères et c'est bien ce que je lui reproche et que je répette depuis plusieurs commentaires.
La norme pouvais le changer tout comme et à changé d'autres choses tout aussi importantes. Et le truc c'est que les gens on adopté la norme, et on changer leurs habitudes pour tout ce que la norme avait changer, donc, on en serait pas la si la norme avait changé la gestion des caractères.
Ah oui, optimiser strlen() en assembleur pour que le O(n) ressemble de loin à du O(1). T'as remarqué que c'était précisément le sujet de la discussion ? :-)
Et ? Ma remarque était juste la pour dire que ces fonctions ne sont pas des primitives bas-niveau mais déjà des fonctions plus haut niveau, la preuve étant que l'on trouve partout des versions en C avant d'en avoir des version en assembleur.
À moins que ta remarque ne soit pour me convaincre que les chaines terminées par 0 c'est nul car il faut des optimisations de fou pour avoir des perfs qui ressemblent vaguement à une autre implémentation. Parce que si c'est ça, je désespère que tu n'ais toujours pas compris que je suis d'accord là-dessus.
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 1.
J'ai un peu de mal à comprendre ce que tu dis là. Tu dis que le langage n'exprime pas tout ce qui est calculatoire et que donc ils ont mit dans la stdlib les fonctions de manipulations de chaines pour palier à ce problème.
Le truc c'est que, comme tu le dis, la manipulation de chaine c'est purement calculatoire, et je te met au défi de me trouver une seule fonction de manipulation de chaine dans la stdlib qui ne peut pas être codé en C pure sans la stdlib.
Sur les 22 fonctions définies par string.h dans le standard, les sul soucis que tu vas avoir sont :
- strcoll et strxfrm qui sont liée à la gestion des locales, mais avec les primitive définie dans locale.h qui contient des fonction plus bas-niveau il n'y a plus de problèmes.
- strerror qui est une fonction systeme plus qu'une fonction de manipulation de chaine puisqu'elle sert à traduire un code d'erreur système en un message d'erreur.
Toutes les autres sont triviales à coder en C pur et j'irais même plus loin, presque toutes les implémentations de la stdlib en on une version en C pur en plus d'éventuelles version en assembleur optimisé car c'est bien plus portable.
Seule les vrai fonctions non calculatoire qui sont des appels systèmes ne peuvent être codée en C pure et nécéssite un petit bout d'assembleur. Et celles là mérittent vraiment leur place dans une lib bas-niveau.
Oui, enfin c'est hors-sujet là. La représentation des chaînes était là dès le C original, elle ne date pas de la standardisation, et elle n'a pas changé avec cette dernière.
Ce n'est pas hors-sujet du tout. Ce qui est utiliser actuellement c'est la version standard et pas la version de base. La norme à changé beaucoup de choses et les gens ce sont adaptés, à part dans de vieux codes on ne voit plus les anciennes version des prototypes de fonctions.
Donc si la norme à pus changer ce genre de choses elle aurait très bien pus changer la stdlib afin que celle-ci n'incite plus les dev à utiliser cette convention.
Il faut bien voir que cete convention c'est imposée et perdure encore aujourd'hui par ce que c'est la manière la plus simple de gérer les chaines de caractère de façon portable car si tu veux une autre gestion il te faut soit tout recoder à la main, soit utiliser une lib qui n'a pas pus se déveloper suffisament et être largement diffuser car une solution simple et pas trop muvaise éxistait.
Le comité de normalisation était la justement pour virer toutes les merdes des différentes versions du C, et s'il ont réussit sur certains points, ce n'est pas le cas pour la stdlib ou ils en ont encore trop laissé.
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 2.
Le probème ici c'est que justement la bibliothèque standard du C n'est pas vraiment ce qu'on appelle un runtime au 21 siècle. Elle propose à peu près rien comme fonctions par rapport à ce que l'on attend maintenant d'un runtime.
Donc le runtime du C c'est plus d'autre bibliothèques haut niveau et bien plus complètes. Donc dans ce cas la stdlib c'est juste une couche très bas niveau pour astraire le minimum du système et donc il y a dedans beaucoup de fonctions qui n'on rien à y faire.
Elle à donc bien le cul entre de chaise, pas vraiment un runtime et pas vraiment une bibliothèque minimaliste.
Là le problème ce n'est pas que les gens (en général) font n'importe quoi, c'est que c'est la bibliothèque standard qui fait n'importe quoi depuis le début et qui encourage le reste des développeurs à s'appuyer là-dessus (ainsi que sur les autres couches optionnelles qui sont venues s'ajouter à la dite bibliothèque standard).
On est d'accord sur le fait que la stdlib fait n'importe quoi depuis le début ; par contre je ne suis pas sur que l'on soit d'accord sur le n'importe quoi en question ;-)
Pour moi il n'y a aucun problème pour qu'elle gère les chaines de caractère en les terminant pas un zero (revenons au débat initial) par contre, il y a un gros problème quand elle commence à proposer des fonctions qui ne devrait pas être de son ressort et qui utilisent cette convention aussi alors que de manière générale c'est rarement la meilleure.
Mais il y a de la faute des utilisateurs eux aussi. Tout le monde sait qu'il y a beaucoup de cas ou ce n'est pas optimal, qu'il y a moyen de faire mieux et même que des libs existent pour faire mieux. Mais une grosse majorité des utilisateurs continue de suivre cette convention.
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 2.
Si tu te contente de faire une bibliothèque minimaliste qui ne propose que le minimum pour pouvoir travailer avec l'OS, tu n'en a pas besoin. L'idée c'est que les fondation c'est un langage qui permet d'exprimer tout ce qui est calculatoire, et une bibliothèque qui abstrait un minimum les appels système afin que ce soit portable.
Avec ça tu as une base minimaliste mais relativement portable ; et la dessus tu construit une vrai biliotheque de plus haut niveau.
Dans cette bibliothèque tu peut très bien fournir deux ou trois conventions diffrents pour les chaine de caractères si tu veux que l'utilisateur puisse choisir et aucun d'elles n'est forcée d'utiliser la convention du système qui est en dessous. Tu le dis toi-même dans un message au dessus, en interne, la représentation des chaines en python n'a rien à voir avec des chaine terminées par 0.
Cela me semble bizarre comme explication. Le C a été conçu pour écrire Unix, la motivation principale de la stdlib était donc probablement de faciliter l'écriture des outils système.
(le C n'a pas été un exercice académique de création d'un langage idéal ou désincarné comme l'ont été d'autres langages)
Les origines du C sont bien entendu liés à la création d'Unix, mais le C à pas mal évolué et est passé par plusieurs standardisations. Actuellement on en est au C99, mais le standard le plus connu reste celui que l'on appelle l'ansi/C qui date de 89. Et ces version du C sont différentes sur bien des points du C d'origine.
Au niveau du langage en lui-même, le C89 avait éssayer de rester le plus compatible possible avec les versions les plus utilisée à l'époque (qui était déjà bien différentes des premières version du C) en gardant certains structures mais en les indiquant comme non recomandée. Les prototypes des fonctions en son un exemple typique.
Pour la librairie par contre, si certaines chose on été gardé et si certaines convention sont les même, il y a eu énormément de changement, notament pour des raison de portabilité. Ils ont éssayer de trouver un dénominateur commun à toutes les librairies qui éxistait alors et normalement ils devaient faire les choses proprement... Le soucis est qu'ils ont préféré faire des compromis plutôt que d'aller au font des chose en la nétoyant au maximum quitte à standardiser une bibliothèque plus haut niveau à côté.
[^] # Re: Soirée mondaine
Posté par beagf (site web personnel) . En réponse au journal Le réchauffement climatique est une vaste blague. Un complot.... Évalué à 1.
ok ~~~~~~~~~~~>[]
PS: Vu le ton du journal, j'ai pas envie de raconter autre chose que des conneries dessus ;-)
[^] # Re: faux débat
Posté par beagf (site web personnel) . En réponse au journal Le réchauffement climatique est une vaste blague. Un complot.... Évalué à 10.
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 3.
Pour moi, il y a deux niveaux de portabilité. Le premier, celui auquel on pence le plus souvent consiste à dire qu'un programme est portable si on peut le faire tourner sur pas mal de platformes courantes que le commun des mortels utilise courrament et consciament. Donc en gros sur des ordinateurs au sens madame michu du terme avec un OS au sens au moins 1% de geek en a déjà entendu le nom.
Dans ce cas là, java est portable tout comme du C++ et je pense Qt ou la GLib. De même pas mal de langage de scripts vont entrer dans cette catégorie.
Le deuxième, celui auquel je faisait référence ici, concerne un bien plus grand nombre de machine et d'OS puisqu'il englobe tous les systèmes capable d'exécuter un programme, même les petits micro controleur ou autre. Ça concerne peut-être moins de monde ici, mais de manière globale ça concerne énormément de monde...
Dans ce cas la être portable ça eut dire être compilable sur un max de platformes très hétérogènes. Et pour ces platformes, en général un compilateur ansi/C est la première chose qui soit disponible pour compiler du code en dehors de l'assembleur ou d'un langage spécifique à la platforme.
Donc, la grande majorité du temps, un code portable dans ce sens c'est un code en ansi/C et la seule chose que ce code peut utiliser c'est des bibliothèques elles-aussi en ansi/C.
C'est ça qui à poussé les auteurs du langage Lua, par exemple, à le coder en ansi/C pur. Ils ont conçu le langage pour leur besoin à la base et les sytsème sur lesquels il était utilisé était très hétérogène, il n'avait donc pas trop le choix.
Le revert de la médaille c'est que c'est aussi un langage relativement pauvre en librairies fournies de base, beaucoup de chose sont soit impossible en c pur, soit tros complexe à réimplémenter et la aussi laissées au soins de lib externe qui ne sont plus forcément portable.
À mon avis il y a surtout de moins en moins de nouveaux projets qui commencent en C. Déja pour faire une interface graphique t'es obligé de rajouter une bibliothèque, genre glib ou Qt.
beaucoup de projets n'ont pas besoin d'interface graphique et ce sont en plus ceux qui sont le plus souvent codé en C...
Beaucoup de programme sont d'ailleur codé de cette manière, un coeur qui fait le gros du boulot codé en C ou dans un autre langage suffisament portable pour la tâche en utilisant le moins de lib non portables possible. (pas toujours évident)
Et à côter une interface graphique qui appelle l'autre code portable sous la forme d'un programme ou d'une lib.
Coder une interface graphique en C n'a pour moi que peu d'interet car il y a des langage ou c'est beaucoup plus simple, bien moins sujet au bugs et vu que l'interface graphique impose déjà des contraintes sur la portabilité autant faire au plus simple.
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 5.
L'idée de base de bibliothèque standard était d'abstraire les quelques éléments spécifique au système qui ne font pas partit du langage, donc le minimum aurait suffit. Mais ils on quand même ajouté un peu plus histoire que l'on ne se retrouve pas trop nus. Résultat, il n'y a pas suffisament de fonction pour que l'on puisse ce passer de librairies mais il y en trop pour que ce ne soit vraiment qu'une couche bas niveau qui est à peu près tout le temps caché au programmeur.
Au final, on se retrouve dans une situation ou il y a suffisament de fonction pour que les programmeurs préfèrent recoder le peu qu'il manque et faire avec les problème de la stdlib, et donc aucune lib un peu plus touffue n'a réussie à s'imposer. Les deux son liés :
- pas de lib de bonne qualitée et répandue --> on fait avec ce qu'il y a et on recode le reste
- on fait avec et on recode --> les libs qui éxiste n'attirent pas assez de monde et se répandent peu
Le problème ce situe à l'origine et à mon avis on ne pourra rien y changer. Je suis le premier à faire avec la stdlib et à recoder pour la simple raison que actuellement, écrire un code en ansi/C est ce qui ce fait de plus portable. La quasi totalités des système éxistant disposent d'un compilateur ansi/C.
Le problème c'est que à peu près toutes les libs éxistante pas trop pourries reposent sur des extention du compilateur ou des éléments spécifiques à la platforme, donc on perd la portabilité. Mon choix est vite fait, j'ai ma petite collection perso de fonction et structure de données, et je repique dedans ce dont j'ai besoin.
Si seulement ils avait choisit de faire une lib complète ou pas de lib du tout au moment de la standardisation...
[^] # Re: Humm...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 8.
Le C est un langage bas niveau qui te laisse le choix de la manière dont tu code tes chaines de caractère, rien ne t'empeche d'utiliser une structure telle que :
struct string {size_t length;
char data[];
}
qui est du C tout aussi standard que les chaine terminé par nul. Et tu trouvera plein de bibliothèques qui te le proposent avec beaucoup de variantes dans les représentations.
C'est toute la puissance du C, tu n'est pas limité par un modèle, tu fais ce que tu veux. C'est aussi là, sa plus grande faiblesse, car, à donner trop de libertées, les gens font n'importe quoi.
Si ton programme nécessite d'avoir souvent accès à la longueur de la chaine, une représentation qui la concerve de manière explicite est parfaitement adapté. Mais si ton programme ce contente de faire des parcours de chaine relativement petites mais en grand nombre, le marqueur de fin est plus adapté, car le surcout est réduit.
Pour te paraphraser, la mémoire la moins gachée est celle qui est vraiment utilisée, donc si tu n'as que très rarrement besoin de la longueur d'une chaine, autant ne pas la stocker et la calculer juste une fois de temps en temps.
Le principal soucis est le design de la lib standard du C, elle à le cul entre deux chaise :
- d'un côté ils l'on voulut minimaliste et comptait sur tous les bibliothèques disponibles autour pour fournir l'éssentiel ;
- de l'autre, ils ont quand même mits dedans d'un fonctions qui sont trivialement codable en C pour gérer les chaines d'une manière qui n'est corecte que dans certains cas.
Ça à deux conséquences :
- puisque les bases sont disponibles, la convention adoptée par ces bases est utilisée trop souvent, et n'importe comment, plutot que d'aller chercher une bonne lib adaptée au programme ;
- puisque seule les bases sont disponibles, les programmeur recodent à chaque fois pleins de fonctions manquantes et multiplient les risques de bugs.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 2.
Dans ma solution, le "if" et le "else" sont alignés verticalement, de même que le contenu du "if" et le contenu du "else".
Ma solution consiste à indenter en debut de ligne avec uniquement des tabulations, hors l'indentation est justement un alignement vertical.
De même, à mon avis il ne faut jamais utiliser de tabulation en dehors du début de ligne, l'alignement vertical à l'interieur des lignes ne doit ce faire qu'avec des espaces, donc si je reprend un de tes exemple au dessus, je le préfère de cette manière (avec les ~ pour symboliser les espace) :
void f(){
--int~~~i;
--char~j;
...
}
L'idée c'est de s'assurer que l'on puisse avoir un affichage à son gout tout en minimisant les risque que l'indentation deviennent incohérente.
La configuration par default de la majorité des éditeur consiste à utiliser les tabulations pour indenter, donc il y a peu de chances qu'une personne indente de manière incohérente sans le savoir.
Et pour les utilisateurs capable de modifier la config de leur éditeur, ils peuvent avoir l'aspect qu'ils désirent. Moi j'aime les grande indentation, donc mes tabulations sont reglées sur 8 espaces, alors qu'un pote préfère les petite donc il règle ses tabulations sur 2 espaces. Résultats on à tous les deux une indentation à notre gouts avec le même code.
Et en utilisant des espace pour lalignement à l'interieur des lignes, ont gardent tous les deux un alignement correct dans les lignes.
Avec ta solution, ça marche beaucoup moin bien. Moi j'aime les indentations homogène, si un codeur commence à mettre des espace comme dans ton code, certaine parties sont visuellement indentées avec plus d'espace que d'autres.
De même avec des tabulation régles sur 8 espaces, pour avoir des débuts de lignes qui me plaisent, l'alignement vertical avec des tabulation devient horrible, les variables sont séparées de eur type par plus de 8 espaces...
# Wikipedia mobile
Posté par beagf (site web personnel) . En réponse au journal Il y a Wikipedia, et Wikipedia (by Orange). Évalué à 10.
Par exemple, une page classique telle que http://fr.wikipedia.org/wiki/Linuxfr peut être accédée en version mobile par http://fr.m.wikipedia.org/wiki/Linuxfr .
Cette version mobile est bien plus légère et organisée de telle manière que, même sur des petits écran, elle reste très lisible sans avoir à scroller dans tous les sens. C'est super agréable sur un téléphone.
[^] # Re: Proxy
Posté par beagf (site web personnel) . En réponse au journal Traduction fail.. Évalué à 3.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 2.
def plop truc
--truc =
----if truc.nil?
------0
----else
------truc.to_i
...
end
Ça n'utilise que des tabulations et l'alignement est à mon gout bien plus clair, on voit bien à quel if correspond le else mais surtout on voit bien qu'il y a un if dans l'affectation.
Ça fait une ligne de plus, mais de nos jours, on n'est plus vraiment limité à 20 ou 25 lignes à l'écran.
Le faire tel que tu le fait me semble dangeureux. Cela nécéssite que toutes les personne qui travail sur le même code que toi reglent leur éditeur pour qu'il reproduise l'indentation de la ligne précédente à l'identique. C'est le genre de truc qui finit toujours par merder et faire perdre un max de temps parce qu'un boulet à fait un commit sans vérifier.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 2.
def plop truc--truc = if truc.nil?
-- --0
-- else
-- --truc.to_i
...
end
Plutôt que :
def plop truc--truc = if truc.nil?
------0
----else
------truc.to_i
...
end
C'est bien plus simple et lisible à mon avis d'indenter du même espacement dans tous les cas.
Je ne vois pas dans ce cas qu'elle est la logique qui te fais utiliser un espace à partir de la troisième ligne.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 2.
Tout mélange finira par t'apporter des problèmes : avec ta méthode :
bip--bop
-- bap
--bop
----bap
Rien ne t'oblige à utiliser la même indentation pour les deux "bap" alors que ça doit être le cas.
Et j'irais même plus loin, la seule méthode d'indentation correcte consiste à utiliser une tabulation par niveau, ce qui permet à chacun de choisir la largeur de ses tabulation et de voir un ode à son gout.
Les tabulation étant très simple à remplacer par des espaces, les plus grincheux sont contents aussi. (alors que dans l'autre sens on retrouve des problèmes)
Pour ce qui est de l'alignement vertical, qui est une chose différente de l'indentation, mais que l'on trouve dans ton premier exemple, l'utilisation de tabulation me semble inapproprié. Tu te trouve à éloigner parfois très fortement le nom de la variable de sa déclaration ce qui peut rendre la lecture difficile.
Le plus simple est souvent de ne faire cet alignement que de manière intelligente, en regroupant les variables ou autres de manière cohérente et en utilisant des espaces.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 3.
Mon affirmation ne portait pas sur l'ensemble du langage mais uniquement sur la partie délimitée par le délimiteur. Ce que je disait c'est qu'avoir des parenthèse autour de la condition dans les if ou dans les boucles c'est bien plus lisible et beaucoup moins ambigue à mon gout. Cela ne veut pas dire que le reste de la syntaxe ne pose pas de problèmes.
Le C est plein de problèmes à ce niveaux là, mais dans ce cas, pourquoi gardez tout ces problème et en rajouter d'autres ? Pourquoi ne pas plutôt juste corriger les problèmes existants ?
En tout cas, les deux exemples font la même chose, je continue à trouver la version python plus lisible. Et je n'ai pas triché sur le C++, j'ai utilisé la méthode officielle d'itérer sur un tableau STL.
Tu ne triche pas sur le C++ mais quelques petites remarques :
- La STL à été fait avec les pieds par des manchots aveugle qui voulait ce venger du reste du monde ;
- Pour un exemple comme celui là, utiliser un vector ne sert qu'à perdre du temps, il faudrait comparer sur des exemple un peut plus intéressants ;
- Tu prend exactement un des pires cas de la STL (qui démontre très bien d'ailleurs l'absurdité de beaucoup de chose dans cette bibliothèque.)
Si on oubli les outils de torture et que l'on ce place dans une situation un peu réaliste pour du C, tu 98% de chance d'avoir la taille de ton tableau quelque part dans une variable accessible. Si ce n'est pas le cas, il y a de fortes chances que tu ait un problème et le code devient :
for (int i = 0; i < len; i++)printf("%d\n", tab[i]);
Qui est déjà beaucoup plus lisible que la version C++....
Alors, en soit ça peut sembler plus complexe et plus verbeux que ta version en python, mais l'avantage c'est que ta boucle est quasiment identique si tu veux parcourir ton tableau dans l'autre sens, ou si tu veux afficher les indices en même temps que les valeurs, ou parcourir deux tableaux en même temps.
Donc sur un exemple on à l'impression d'être perdant, mais sur une utilisation générale, tu y gagne en homogénéité : tous les parcours seront codé sur le même modèle.
C'est vraiment une question de gouts mais moi j'ai fait mon choix ;-)
Donc pour en revenir à nos moutons,[...]
Je pense que je rentre maintenant dans la case vieux barbus, vu que je ne suis pas choqué mais que j'ai plutôt tendance à regarder ce genre de nouveau langage avec un petit sourire en coin ;-)
C'est domage, je ne pensait entrer dans cette catégorie que l'an prochain, et merde, j'ai pris un an d'avance
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par beagf (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 2.
45020089
-------------
8!
tu peut aussi écrire :
45020089
--------------- !
8
Quand tu écrit la division sous cette forme, ça revient à mettre des parenthèses. Dans ton code par contre l'ambiguïté demeure.
Et que ce soit programmé par des gens avec de bonnes intentions et le faisant de manière très logique ne change rien au problème. Avoir le même opérateur avec une priorité différente et une sémantique différentes suivant le type rend le programme beaucoup plus difficile à lire.
Si tu surcharge les opérateurs pour un type vecteurs par exemple, il devient naturel de ce demander si le '*' correspond au produit par composantes, au produit vectoriel au produit scalaire. Tu trouvera toujours des gens plein de bonnes intentions qui trouverons des raison parfaitement valable de choisir l'un plutôt que l'autre.
Le gros problème c'est que quand tu te retrouve face à leur code, tu te demandera toujours si le mec qui à codé la lib à la même logique que toi.
C'est, pour moi, un des plus gros points noir du C++. Combien de fois je me suis retrouver devant un code ou un mec à cru malin de redéfinir les opérateur pour rendre son code plus concis par la suite et en théorie plus clair... la plupart du temps tout ce que l'on obtient c'est un code extrêmement difficile à débugger car une expression qui semble évidente fait quelque chose auquel on aurait même pas penser dans nos pire cauchemars.
Donc, la surcharge d'opérateur est pour moi quelque chose d'encore plus dangereux que les pointeurs car ses effets pervers peuvent être quasiment invisibles, là ou un pointeur est bien visible. Quand je vois un pointeur, je sais que je dois faire particulièrement attention, pour les opérateur, il est dur de dire s'il y a danger ou pas.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par beagf (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 5.
L'intention est louable mais le problème c'est que ton code est illisible. Sans parenthèses je me demande toujours si je doit comprendre (45020089/8)! ou bien 45020089/(8!). Et le fait de pouvoir spécifier la priorité de ces opérateurs de manière différente suivant le type de données manipulée rend les choses encore pire.
Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.
Des programmeurs "qui en usent sans en abuser et qui le font avec précautions" et qui sont capable de maitriser la chose, maintenant ça se compte sur les doigts de la main : va bosser dans des SSII, des boites ou on fait du logiciel de gestion, etc... Tu verras que très peu sont capable de faire du code propre sans qu'on soit constamment derrière leur dos, alors faire du code propre avec des pointeurs...
Pour récapituler : les pointeurs sont un outils très puissant dans les mains des bon programmeurs mais une grosse bombe à retardement dans les main des mauvais programmeurs.
Le problème est que l'on à peu près que des mauvais programmeurs. Donc on oubli les pointeurs, on va pas prendre de risque.
Pour tout dire, tu prend le paragraphe précédent et tu remplace pointeur par surcharge d'opérateurs et le texte reste parfaitement vrai.
Tu prend du C++ pondu en SSII et tu regardes à quoi sert la surcharge d'opérateur. Le plus souvent tu te retrouve avoir des objets qui s'additionne ou ce multiplie de manière complètement illogique et le code deviens incompréhensible et tout aussi dangereux qu'avec des pointeurs.
D'après toi pourquoi PHP, qui est un des langage les plus permissif et non rigoureux a eu un tel succès ?
Parce que le programmeur moyen a un niveau assez bas.
Faut faire des langages qui s'adaptent aux gens, pas l'inverse.
Le problème c'est que lorsque le niveau est si bas, il ne faut pas un langage permissif mais au contraire un langage extrêmement strict et très redondant afin que le compilateur puisse détecter le maximum d'erreurs et afficher des messages les plus clairs possible.
C'est pour cela que le PHP est une bouse infâme : il a une syntaxe qui lui permet de ne se préoccuper des erreur que le plus tard possible : en général quand il est trop tard. Ajoute à cela le fait qu'il est principalement utiliser sur des machine connectée au net et tu peut en déduire ce que je pense de ce langage.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 3.
Quand tu relis du code pour vérifier qu'il fait bien ce que tu pense ou que tu traque un bug, la lisibilité est un facteur très important. Et je préfère un langage un peu moins expressif mais parfaitement lisible, à un code ambiguë où, sous prétexte de taper quelques caractères de moins, on a supprimer des délimiteurs redondant mais qui facilitent énormément la lecture.
C'est le même problème avec l'indentation en python. L'idée de base de forcé les gens à indenter correctement leur code est louable même si je suis contre. Le problème c'est que même en faisant ça, les gens réussissent à te faire des horreurs. Il suffit de voir que les guidelines continue quand même de parler de la manière d'indenter le code et que certains pondent des horreurs comme celle-là : http://lapagearegis.free.fr/guidedestyle.html qui conseillent de mélanger les espaces et les tabulations.
Donc, quoi que tu fasses, tu peux être sur que ceux qui veulent foutre le bordel réussirons à le faire d'une manière ou d'une autre.
L'avantage des délimiteurs est justement de rendre le code lisible sans ambiguïtés quelque soit le style choisit par le programmeur.
Ils sont redondant de la même manière que dans les langues naturelles il y a de nombreuses redondances. Tout comme les ; en fin de ligne ne sont pas toujours nécessaire, mais ils permettent d'indiquer clairement ou ce termine une instruction et ou commence la suivante.
L'objectif de tout cela est de faciliter la lecture du code. De manière idéale, lorsque tu lis du code, tu ne devrait pas avoir à réfléchir sur les aspects syntaxiques ; tu devrais voir directement à quoi correspond chaque instructions et l'effort mental ne devrait concerner que la logique du code pour essayer de comprendre ce que fait le programme et voir si c'est bien ce que tu veux.
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par beagf (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 7.
Ce serait pas le cas du C qui reste à ce niveau là un des meilleurs langage ? Et le cas du C++ aussi ?
De plus la compilation séparée n'est pas un élément du langage mais principalement du compilateur. C'est celui-ci qui choisit de considérer chaque module indépendament ou comme un tout.
- Pas de redef des opérateurs. Change pas cela dit, par rapport à ce que la plupart des gens connaissent. (Nous, en Lisaac, on est assez fière de pouvoir écrire 45_020_089/8!.print )
J'espère que tu blagues en disant ça ? Utilisé proprement et avec beaucoup de modération, la redéfinition des opérateur peut-être utile mais dans ton exemple, on peut se poser des question sur la signification du "!" et le ".print" à la fin est pas vraiment plus lisible et plus clair qu'une méthode classique.
En voyant ton exemple je me pause les question suivante :
- est ce que le "/" veut encore dire division ou est-ce qu'un boulet en a changer le sens ?
- est-ce que le "!" veut dire factorielle ou autre chose et si oui, qu'est-ce qui est vraiment calculer si la valeur n'est pas ntière ?
- entre le "/" le "!" et le "." qu'elle sont les règles de prioritées et donc est-ce qu'il va bien m'afficher le résultat du calcul et surtout faire le bon calcul ?
- Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
On peut critiquer autant qu'on veut les pointeurs mais c'est comme la surcharge des opérateurs, dans les mains d'andouille qui font n'importe quoi ça pête dans tous les sens ; mais dans les mains de bon programmeur qui en usent sans en abuser et qui le font avec précautions, ça fait des choses magnifiques.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à -1.
Par exemple, les identifiant (de classe il me semble mais je ne suis plus sûr) tout en majuscules de Lisaac sont la principale raison qui m'a fait abandonner ce langage qui pourtant contenait pas mal de bonne idées. Mais non, je n'ai pas réussit à m'habituer à ces horreurs.
De la même manière que je ne fait pas de python à cause de cette indentation qu'il faut faire d'une manière bien particulière et que j'ai toujours vu poser plus de problèmes qu'elle n'en résout.
Sans parler du fait que toutes ces conventions qui sont utilisées de manière implicite par le compilateur rendent le programme plus difficile à comprendre pour une personne externe.
Un codeur qui ne connait rien à Go, lorsqu'il va voir du code avec des nom en majuscule et d'autre en minuscule, il va se dire que le programmeur est un branleur qui pourrait au moins faire un code homogène ; il se dira surement pas : à tiens, ça doit surement servir à dire au compilateur qu'elle sont les méthodes externes.
[^] # Re: Première remarques
Posté par beagf (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 2.
Peut-être que pour d'autre c'est joli, mais je continue de penser que le langage ne devrait rien imposer à ce niveau là.