[F] [mOved] Mon langage est mieux que le tien - Page 81

Je n'arrive pas a lire cet blog post, je pense que mon cerveau est fatigué :/

Godzil > c'est vrai que c'est pas super clair, mais le point qui me semble important, c'est que la stratégie n'est plus "tous les langages .NET sont à égalité", mais désormais "C# sera privilégié pour les nouvelles features". J'imagine que pour la plupart des gens ici, ça ne va pas changer grand-chose, mais je trouve que c'est intéressant de voir ce changement de stratégie.

En meme temps il me semble que c'est deja le cas, le subset .NET accessible deui VB.NET n'est pas complet. Je ne connais pas F# ceci dit..

Il me semblait que justement si, jusqu'ici on pouvait faire en VB.NET tout ce qu'on pouvait faire en C# (mais ça fait des années que je n'ai pas regardé, c'est vrai).

Ok je ne sais pas le status actuel (coucou Golden Crystal?) mais a l'origine VB.net ne supportait pas tout le framework

À ma connaissance il y a effectivement des choses non accessibles avec certains langages depuis un moment. Je ne connais ni VB.net ni F# mais il me semble que VB.net ne supporte pas les types non signés, par exemple, alors qu'ils font partie de la VM. L'essentiel de la bibliothèque standard est codé de façon à rester compatible (par exemple List.Length est un entier signé ), mais ça veut quand même dire qu'on peut écrire du C# non-compatible VB.net depuis les toutes premières versions.

(Je comprends que ça paraisse débile d'avoir des entiers signés pour des tailles, mais en pratique ça ne m'a jamais manqué en JAVA. Je pense que c'est plus source de problèmes qu'autre chose. Et j'utilise vraiment rarement des longs en plus.)

Qu'est-ce qui est une source de problèmes, d'utiliser des entiers non signés pour représenter des longueurs ? Perso j'aime autant que le compilateur détecte mes erreurs le plus tôt possible, c'est à peu près la seule raison pour laquelle j'utilise un langage typé. Par exemple si je commence à mélanger des signés et des longueurs de liste, ça m'intéresse d'avoir au moins un warning pour me prévenir que je fais quelque chose de probablement pas super logique.

Je suis de ton avis, mais il me semble que c'est un sujet de troll :
http://stackoverflow.com/questions/10168079/why-is-size-t-unsigned

Des que tu tape des tailles de fichiers de plus de 2Go tu es content d'avoir des uint32_t...

./2410 >
Non, je parlais du mix des signés/non signés. En java, il n'a que du signé, et je pense que ça résout (évite) plus de problème que ça n'en créé.
J'aime bien ta remarque concernant le typage fort, mais dans ce cas il faudrait que ce soit carrément une erreur de compilation, parce qu'en pratique il suffit de compiler n'importe quel source de C/C++ pour se rendre compte qu'il y a un milliard de warnings concernant des mélanges de signés et non signés.
Du coup je préfère éviter le risque d'avoir des tests de signes négatifs pour des entiers non signés

./2412 > en java c'est des longs (64 bits signés), ça laisse de la marge.

Bah c'est un choix ça, déjà tu peux effectivement décider d'ignorer les warnings mais dans ce cas il faut tout autant te demander si tu as vraiment besoin d'utiliser un langage avec un compilateur riche si c'est pour jeter les infos qu'il te donne. Tu peux aussi passer certains/tous ces warnings en erreur si tu veux être sûr de ne pas les louper, je pense que ce ne sont pas les options qui manquent. Je comprends que ce soit un sujet de troll, mais pour moi entendre "j'utilise des signés partout c'est plus simple", c'est un peu comme les gens qui utilisent un langage typé mais représentent 80% de leurs données avec des strings, c'est quand même doublement dommage et une sacré perte de temps (ou d'efficacité, selon) :/

Ah mais je suis d'accord avec toi, mais dans ma réalité, je ne commence pas tous mes projets à partir de rien, il y a des années d'historique derrière, et quand il y a des milliers de warnings, tu fais comment ?
Pareil pour les const, j'aime beaucoup, mais quand ils n'y sont pas, c'est l'enfer à modifier.
Ce que je déplore, c'est que souvent ce n'est pas un choix du tout pour moi.

Bah tu peux essayer de les éliminer localement, ou si ça n'est pas possible mettre en place des rapports d'analyse de code pour vérifier que tu arrives bien à les résorber petit à petit et que tu n'empires pas la situation. En fait j'ai du mal à comprendre la logique inverse, ça serait "bof de toutes façons il y a déjà plein de warnings donc quelques-uns de plus c'est pas bien grave" ? Si plusieurs devs se succèdent avec cette pratique sur une même base de code ça ne présage pas grand chose de bon pour la maintenance, si ?

Oui enfin java et optimisation...

Tiens tu représente comment ton espace mémoire 64Bit en java vu que tu n'a que des valeur signé? Ou alors tu ne peux addresser que la moitié de l'espace mémoire? Non parce que bon une adresse négative n'a aucun sens, ou alors l'adresse 0 est au milieu de la mémoire?
Ca peux être drôle ceci dit hein, mais ca me semble plutôt assez chiant en fait.

Edit: Les warning si ils sont la, en tout cas en C (et C++) ce n'est pas pour faire joli, la majorité des warnings pointent sur des bugs potentiels (Ok il y a au moins le check des parametres printf sont plutot chiant surtout quand sur des plateformes differentes certains parametre n'attendent pas le meme type.. et qui est assez inutile)

Tu n'a pas ce problème vu que tu ne gères pas d'adresses toi-même en Java, la VM le fait à ta place et je suppose qu'elle n'a aucun souci à traiter des adresses 64 bits.

Donc la VM java en interne utilisé des nombre non signé C'est paradoxal..

(oui je sais que java n'utilise pas de pointeur, enfin tu n'a pas acces aux valeurs) ceci dit il me semble qu'il y a des passerelles natif/java, on fait comment si le natif attends du non signé et/ou un pointeur?

./2417 Je corrige de temps en temps quand mes yeux se posent dessus, mais honnêtement, j'ai abandonné l'espoir de les virer tous, oui. Certaines portions du code restent relativement inchangées donc les warnings ne seront jamais résorbés naturellement.
C'est économiquement impossible de les virer tous.
Cela dit, je n'ajoute pas de warnings moi même, je suis plutôt du genre pénible

Godzil (./2417) :
Les warning si ils sont la, en tout cas en C (et C++) ce n'est pas pour faire joli, la majorité des warnings pointent sur des bugs potentiels

Heu... Pas la peine d'essayer de me convaincre, hein ?

Godzil > Vu que c'est un langage qui n'utilise pas de pointeurs, je pense que tu peux les considérer comme un type opaque ? Du coup tu peux caster à la sauvage ; ça veut dire que les pointeurs au-delà de 2 Go seront négatifs, mais on s'en fout parce que leur valeur n'a de toute façon pas de signification pour le code Java.

Par contre, même sans pointeurs, utiliser des entiers signés veut dire qu'on ne peut pas avoir de tableau d'octets qui fait plus de 2 Go.

Pen^2 (./2420) :
je suis plutôt du genre pénible !p

Oui je confirme, tu es plutôt du genre pénible



()

Ça n'est même pas un type opaque, c'est une notion qui n'est pas exposée du tout dans le langage. Certains types sont des référence, c'est à dire que la VM va en réalité les traiter comme des pointeurs vers des espaces alloués sur le tas, mais il n'y a pas de moyen simple de traverser cette abstraction et de faire apparaître une notion de pointeur (dans le sens "valeur numérique qui représente l'emplacement mémoire d'une valeur"). Le but d'un langage managé c'est d'abstraire totalement la notion de pointeurs, ça serait une abstraction un peu loupée si c'était utile de la faire réapparaître aussi facilement

(bon après, ce que je dis est complètement faux en C# où on peut quand même faire apparaître une notion de pointeurs, qui n'en sont pas réellement mais y ressemblent sémantiquement déjà beaucoup plus)

./2422 >

./2421 > longs 64 bits signés sur les fichiers, sur les tableaux c'est mort, effectivement.

Godzil (./2417) :
Tiens tu représente comment ton espace mémoire 64Bit en java vu que tu n'a que des valeur signé?

Comme ça.

Zeph (./2423) :
Ça n'est même pas un type opaque, c'est une notion qui n'est pas exposée du tout dans le langage.

Oui je sais, je parlais du cas où tu fais appel à des APIs natives qui utilisent des pointeurs (tu peux par exemple passer un pointeur retourné par une fonction native à une autre fonction native, même si ton langage n'a pas de notion de pointeurs, en traitant le pointeur comme un entier opaque - ça se faisait en VB6 par exemple).

Oui, ça reste des octets ^^

Godzil: pas d'espace mémoire en java.
la VM en interne ne gère pas non plus de nombre non signé ni d'espace mémoire.
la seule "mémoire" adressable c'est les tableaux mais rien n'existe au dela des limites du tableau.
c'est l'implémentation qui se démerde, mais elle ne donne pas acces a la notion universelle de "pointeur".

Qt Jambi stocke ses pointeurs dans des long, la valeur étant interprétée par le code C++ comme non signée.