> Le code machine, ca tourne partout, par definition
On a trouvé une fortune plus grosse que le malloc(INT_MAX) de pBpG là !
Le code machine ne tourne pas partout, non (que ce soit l’assembleur ou le code binaire résultant), et c’est précisément pour cette raison que deux gus dans leur garage (Dennis Ritchie et Kenneth Thompson) ont inventé un langage portable qui puisse être traduit dans ces langages non-portables.
> Ca devient du grand n'importe quoi la...
Je confirme. Je ne sais pas d’où m’est venue cette idée saugrenue que la portabilité pouvait avoir un vague rapport lointain avec le fait de pouvoir faire fonctionner le même code source sans modification sur deux architectures aussi différentes que le x86-64 et le MSP430, vraiment.
Désolé de t’avoir faire perdre ton temps avec une idée aussi stupide.
Sur ce, excuse-moi, mais je dois aller modifier mon dictionnaire pour redéfinir « portable » comme « langage tournant sur une machine virtuelle, mais impossible à faire tourner sur une architecture sur laquelle ladite machine virtuelle n’existe pas ».
> Ce n'est pas un problème d'API : on parle bien de la définition du langage
Ben si, la preuve : tu as des APIs en dehors de la librairie standard pour te faire de la serialisation. Toujours pas aussi simple à utiliser qu’en Java, certes, mais ça a plus à voir avec l’absence d’introspection.
> Ce n'est pas un comportement différent de l'API
Ben si.
Avec la librairie standard du C, tu peux écrire tout et n’importe quoi librement. Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme, ça a effectivement de fortes chances de pas bien se passer. Pour que ça fonctionne, tu dois définir correctement le format d’échange (endianness, taille des entiers, format des string, format des flottants,…). C’est quelque chose que les ingénieurs de Sun ont fait quand ils ont défini l’API de sérialisation, c’est quelque chose que C s’est refusé à faire (parce que c’est pas son boulot de faire des trucs haut niveau, parce que C a besoin de communiquer avec du non-C, et surement d’autres raisons que j’ignore).
C’est pareil en Java : si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas. La différence entre C et Java, c’est que le premier t’autorise à faire ça (en cohérence avec sa philosophie : le langage est pas là pour penser à la place du programmeur, et il y a des situations où faire une telle chose est tout à fait correct) et que le second ne t’y autorisera jamais.
Objective-C, en tant que langage, est exactement dans la même situation que le C à ce niveau (taille de l’entier qui varie, endianness, alignement, etc). Pourtant, OpenStep/Cococa a défini une API et un format d’échange, comme Java, et bizarrement, on ne voit personne pour pleurer sur la non-portabilité d’Objective-C et des plist.
Non, franchement, dire que le C n’est pas portable sous le prétexte que je peux pas charger brutalement le contenu brut de la mémoire d’une architecture vers l’autre (ce que tu fais quand tu fais un write+read direct de tes structures, hein), c’est un peu pareil que dire que Java n’est pas portable parce que je peux pas faire un core dump d’un programme tournant sur la JVM sun et charger ce core dump dans une autre JVM et que le programme puisse continuer sans rien remarquer.
tl;dr : quel que soit le langage, si tu veux être portable, tu dois définir un format d’échange, la seule différence entre Java et C étant qu’en Java tu as un format défini direct dans l’API standard.
> Peut-on vraiment parler de communication avec l'extérieur ?
Ben oui, quand tu communiques avec quelqu’un d’autre que toi (toi = fork(), en gros), tu dois faire gaffe : définir un format d’échange, et ne pas te contenter de lui balancer un dump mémoire à la gueule en le laissant se démerder. Si Java n’a pas ce problème, c’est parce qu’il n’autorise tout simplement pas à balancer un dump mémoire ([troll]c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime[/troll])
C’est vrai que ça tombe un peu comme un cheveu sur la soupe, mais sa remarque est pertinente : combien d’architectures supportées par la JVM, par .Net ? Parce que c’est bien beau de dire : c’est portable, yaka coder une implémentation de CLR/Java bytecode, en pratique, ça donne quoi ?
Personnellement, en C, je peux faire du code qui tourne sans modification sur mon PC et le MSP430 (je l’utilise pour faire des routines que je peux tester sur mon PC, c’est plus simple de débugger sur un PC que sur un MSP430). Java, il tourne sur un MSP430 ?
En étant un peu réaliste, dans un contexte d’utilisation normale, tu utilises des librairies pour te faciliter la vie, parce que le C n’est pas « battery included ».
> - c'est relativement complique
Si ton but c’est de faire un write((void*)&myStruct) parce qu’on peut le faire et que ça a l’air funton compilateur t’engueulera pas si tu le fais, oui.
Si ton but c’est de faire un truc qui juste marche, non, même en ANSI C : tu spécifies ton format de fichier et tu mets noir sur blanc l’endianness et la taille. Pas de problème d’alignement si tu fais pas un read((void*)&myStruct) mais que tu fais champ par champ. Oui, on sait : Java l’a fait pour toi. Mais la question « battery included » ou pas est orthogonale à la question « portable ou pas »
Et je te signale que tu entres ici dans la question de la portabilité des API, question que tu avais admis toi-même qu’elle était peu pertinente, tellement il est simple de faire non portable dans la communication avec l’extérieur.
> cela necessite beaucoup plus de code
Pas beaucoup non
write32(int32): 2 lignes (1 ligne pour le write, 1 ligne pour le htonl).
int32 read32(): 3 lignes (1 ligne pour le read, 1 ligne pour le ntohl, 1 ligne pour le return).
Le truc vraiment chiant à gérer c’est la représentation des flottants par contre, là je t’accorde que ce sera un peu plus que 5 lignes. Mais ce sera pas 3000 lignes non plus.
Bon, pour faire propre, double le nombre de lignes pour la gestion des erreurs.
> ou de se trimballer un framework expres pour comme le font beaucoup de projets portables
Parce que J2SE, c’est pas un framework peut-être ?
Heu, la fonction Write(Int32) de .Net (je suppose que c’est pareil en Java), c’est deux lignes à implémenter en C, je vois encore pas la différence.
La difficulté est d’obtenir l’offset en fonction de l’alignement et tout. Tu fais comment en Java, sans les APIs de sérialisation ?
Tu n’as pas compris ce que je voulais dire.
Java ne te permet pas de stocker des classes directement dans un fichier (l’équivalent de write(fd, (void*)&myStruct, sizeof(myStruct)). Tu dois passer par une API de sérialisation.
Ben en C, pareil : si tu veux pas te prendre la tête, tu passes par une API de sérialisation. Ce sera plus lourd en C à cause du manque d’introspection, je te l’accorde.
> le code ANSI C est toujours portable
J’ai une mauvaise nouvelle à t’annoncer : depuis le début, tu te bats contre un homme de paille.
Qui ici a dit que le C était toujours portable ?
> si je trouve un exemple, tu vas dire que la fonctionnalité est mal codée.
Ben voyons. Dire que caster les void* en int et vice-versa c’est mal coder (c’est un des premiers exemple de ton lien), c’est être de mauvaise foi ?
J’en déduis donc que chez toi c’est une bonne pratique de caster les pointeurs en entier ?
> car la norme en soit ne garantie pas un code portable
Je crois que tu n’as pas compris un truc. C est un langage qui a comme principe d’être très laxiste, qui t’autorise à faire d’énorme conneries. Java est un langage au contraire beaucoup plus strict. Donc oui, tu peux faire d’énormes conneries qui t’empêcheront d’être portables en C et pas en Java. De là à dire qu’un programme écrit normalement en C n’est pas portable, il y a un gouffre que je ne peux voir franchi sans réagir.
Je vais te faire une image : Java ne peut pas te garantir formellement que ton programme est conforme à sa spécification (le C ne peut te garantir la portabilité), contrairement à certains langages issus de la recherche. Quelle est la bonne chose à en déduire ?
- Java ne permet pas de faire du code correct (le C n’est pas portable)
- Si tu veux réussir à remplir ton cahier des charges, il faut suivre des bonnes pratiques (si tu veux être portable, il faut suive des bonnes pratiques)
> Je veux lire un fichier dans une structure en memoire et ensuite acceder a une valeur val de taille t dans cette structure situee a offset du debut.
Et en Java, tu fais comment ?
> Vaguement drôle, mais y dit qu'il voit pas le rapport.
Le rapport, c’est qu’à part la quantité de données que sera capable d’ingurgiter le programme, je vois pas ce que la taille des entiers change au niveau fonctionnel.
> Si t'as pas d'imagination, google est ton ami, exemples :
Ceci ne sont pas des exemples de fonctionnalités qui changent selon la taille d’un entier. Ce sont des listes de bonnes pratiques. Comme il y en a dans tous les langages — si tu les suis pas, vient pas pleurer si ton programme te pète dans les mains.
Encore une fois, ce que je te demande, c’est une fonctionnalité bien codée dont le comportement dépend de la taille d’un entier. Parce que si c’est juste pour dire qu’on peut faire du code pas portable en C en faisant n’importe quoi (genre caster un int en pointeur et vice versa), on était au courant, merci.
> PowerShell, c'est par définition la même chose que la ligne de commande sous Linux mais en plus puissant
Ben non. PowerShell, c’est une couche d’abstraction, comme on l’a souligné.
vim, il travaille sur des fichiers, il utilise fopen & co.
Donc, je doute que taper "vim HKEY_CURRENT_USER\ma_clef" soit possible. D’ailleurs pBpG semble le confirmer puisque pour lui, « c’est complètement crétin de vouloir faire ça ».
Ergo : non, même avec PowerShell, tu ne peux pas faire tout ce que tu peux faire avec le shell Unix.
> ça montre juste ta méconnaissance du sujet sur lequel tu trolls.
Je ne nie pas. Juste que ce qui m’intéressait, c’était la comparaison entre le design « canonique » de Windows (tout est accessible par des handle avec les APIs qui vont bien) et de Unix (tout est accessible à l’aide de fichiers). Qu’on puisse faire des couches d’abstraction qui vont de l’un à l’autre, j’entends bien merci, j’avais pas besoin de troller pendant 3 jours pour le deviner. Que la couche d’abstraction « Unix-like » pour Windows soit maintenant fournie par défaut, je ne peux qu’applaudir des deux mains. Mais c’était pas ce qui m’intéressait.
> tu vas dire à ton client "oui bah euh cette fonctionnalité dépend de la machine sur laquelle vous exécuter le logiciel...
Ha, parce que évidemment, dans le monde .Net/Java, on entend jamais « votre machine là, elle est pas assez puissante pour faire tourner cette fonctionnalité ».
> sa valeur diffère elle aussi d'une plateforme à l'autre.
Ben oui, évidemment, si tu fais un srand(INT_MAX) et que ton logiciel dépend des nombres sortis par ton peudo-RNG, sûr que le comportement diffèrera d’une plateforme à l’autre.
En dehors de ce cas, j’ai quelque difficultés à voir un code qui change ses fonctionnalités du tout au tout selon la valeur de INT_MAX (et sans erreur de programmation « mais non c’est du code tout à fait normal » à la malloc(INT_MAX)). Mais peut-être est-ce juste mon manque d’imagination ?
> Genre ton soft qui faisait des allocations de 64Ko, maintenant risque d'en faire de 4Go
En même temps, si tu t’amuses à faire des malloc(-1), je suis pas sûr qu’on puisse dire que ce soit la faute du langage si ça te pète à la gueule.
> Au niveau du gouvernement, oui, ça baisse
Ha, oui, j’ai compris ce que tu voulais dire. Effectivement, de ce point de vue, tu as raison, ma remarque était totalement HS :)
> Et de tout de facon qu'est ce qu'une licence si ce n'est une promesse?
Non, ce n’est pas la même chose. Une licence est une contrat entre deux parties, une promesse publique n’implique pas d’autre partie au moment de son énoncé.
Après, je sais pas quelles sont les implications juridiques :)
> Les chiffres sont aussi peu objectifs que n'importe quoi,
Les chiffres ne sont pas parfait certes, mais il y a des degrés dans l’imperfection, et c’est toujours mieux que « mon ressenti au doigt mouillé » (encore une fois, ça s’applique à moi aussi).
> C'est fou cette envie de pointer du doigt ce que coûtent les fonctionnaires, mais pas les autres.
C’est pas ce que j’ai dit.
Ce que j’ai dit, c’est que je vois pas en quoi le fait qu’ils soient payés par les collectivités locales ou directement l’état entre en compte dans ce qui nous occupe.
> mais on reste dans des valeurs raisonnables
Et des valeurs raisonnables, c’est décidé par qui ? sur quelles bases ? On s’arrête où dans l’égalisation ? Quand le rapport est de 1 à 100 ? de 1 à 10 ? de 1 à 1.5 ? de 1 à 1 ?
Question : ce que tu appelles "OK", un écart plus faible, pour toi, c’est une injustice acceptable ou de la justice ?
> Si tu veux évaluer la pauvreté, il existe tout un tas d'indicateurs, aucun n'étant parfaits, mais autrement plus complexes que le nombre de SDF.
Certes, c’est d’ailleurs pour ça que j’avais parlé de « miséreux » et non pas de « pauvres » initialement, du reste.
Tu mélanges tout.
Un des objectifs de la plateforme .Net (CLR & co) est d’être portable, et en pratique, ça marche.
Par contre, les APIs Microsoft de .Net (Windows Forms) n’ont jamais prétendu avoir cet objectif.
De plus, tu t’obstines à voir Mono comme « un effort de Microsoft pour se rapprocher du LL » (et vice-versa) avec des objectifs stratégiques des deux côtés alors qu’on se tue à te dire qu’on peut aussi tout simplement voir Mono comme une plate-forme de développement comme une autre, avec ses atouts (facile à déployer sous Windows & Linux, pas mal de langages différents, C# assez agréable à utiliser relativement au C++ ou à Java) et ses inconvénients (chiant à déployer sous MacOS X, pas d’API GUI standardisée, pas encore installé de base dans toutes les distributions).
Les suisses n’ont pas un problème démocratique, ils ont un problème que le peuple n’a pas ton opinion. Ce n’est pas la même chose.
À l’inverse, l’Europe a un problème démocratique (on s’assoit sur l’avis du peuple) alors que le peuple a l’avis contraire au tien (je pars du principe que tu étais pour le TCE, corrige-moi si je me trompe)
Note : je ne suis pas Suisse.
> Pour maintenant
Oui, j’avais les chiffres pour maintenant, mais ce qui m’intéresse, c’est son évolution.
Mais je pense qu’on ne le saura jamais.
Par contre, je suis très dubitatif sur le temps de travail en tant proxy pour la richesse. Après tout, le temps de travail n’est rien d’autre qu’un arbitrage temps libre/revenu ; il n’est absolument pas rare de voir, en occident, des ingénieurs sortant de l’école extrêmement bien payés mais qui ne comptent pas leurs heures et qui ne prennent pas de vacances pendant un an. Ça ne les rend pas vraiment pauvre pour autant.
> Je crois surtout que tu melanges absence de couche d'abstraction avec absence de fonctionalite.
Non, c’est juste qu’à force de répondre point par point, on a fini par ne plus parler de la même chose : tu parles de fonctionnalité possible, moi de fonctionnalités accessibles « out of the box » par le design du système (sans nécessiter de couche d’abstraction derrière).
> Ca veut dire quoi 'faire vim' ?
Éditer avec vim. Je peux faire "vim /etc/fstab". Je peux faire vim (manière d’accéder au registre en PowerShell) ?
> Tu exportes la branche "software" de la registry, tu laisses le soft tourner, tu exportes la branche "software" de nouveau, et tu fais un diff, en utilisant exactement le meme soft que tu ferais pour un diff texte vu que l'export est textuel.
J’avais essayé et ça m’avait explosé à la gueule, je sais plus pourquoi. L’ordre des clés qui différait entre deux exports peut-être, mais c’est vieux (Windows 2000 je crois), donc je me rappelle pas bien.
> Ben oui, et avec powershell aussi
Powershell ne fait pas partie du système chez moi.
Mais oui, je reconnais qu’un Unix-like-over-Windows est appréciable. Ce qui prouve que l’approche Unix a fait des émules chez Microsoft aussi. Reste que c’est « récent » (relativement à l’histoire de Windows & Unix — 2005 il me semble), donc dire « je peux faire avec PowerShell ce que je peux faire avec Unix, donc l’architecture de Windows et d’Unix, c’est kif-kif »), c’est légèrement de mauvaise foi. Mais c’est pas grave, on est sur TrollFR. tl;dr: PowerShell est là pour prouver que :
- de base, on peut pas faire la même chose avec Unix et Windows
- l’approche Unix est suffisamment intéressante pour l’émuler au-dessus de l’approche Windows
Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 4.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
On a trouvé une fortune plus grosse que le malloc(INT_MAX) de pBpG là !
Le code machine ne tourne pas partout, non (que ce soit l’assembleur ou le code binaire résultant), et c’est précisément pour cette raison que deux gus dans leur garage (Dennis Ritchie et Kenneth Thompson) ont inventé un langage portable qui puisse être traduit dans ces langages non-portables.
> Ca devient du grand n'importe quoi la...
Je confirme. Je ne sais pas d’où m’est venue cette idée saugrenue que la portabilité pouvait avoir un vague rapport lointain avec le fait de pouvoir faire fonctionner le même code source sans modification sur deux architectures aussi différentes que le x86-64 et le MSP430, vraiment.
Désolé de t’avoir faire perdre ton temps avec une idée aussi stupide.
Sur ce, excuse-moi, mais je dois aller modifier mon dictionnaire pour redéfinir « portable » comme « langage tournant sur une machine virtuelle, mais impossible à faire tourner sur une architecture sur laquelle ladite machine virtuelle n’existe pas ».
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Ben si, la preuve : tu as des APIs en dehors de la librairie standard pour te faire de la serialisation. Toujours pas aussi simple à utiliser qu’en Java, certes, mais ça a plus à voir avec l’absence d’introspection.
> Ce n'est pas un comportement différent de l'API
Ben si.
Avec la librairie standard du C, tu peux écrire tout et n’importe quoi librement. Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme, ça a effectivement de fortes chances de pas bien se passer. Pour que ça fonctionne, tu dois définir correctement le format d’échange (endianness, taille des entiers, format des string, format des flottants,…). C’est quelque chose que les ingénieurs de Sun ont fait quand ils ont défini l’API de sérialisation, c’est quelque chose que C s’est refusé à faire (parce que c’est pas son boulot de faire des trucs haut niveau, parce que C a besoin de communiquer avec du non-C, et surement d’autres raisons que j’ignore).
C’est pareil en Java : si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas. La différence entre C et Java, c’est que le premier t’autorise à faire ça (en cohérence avec sa philosophie : le langage est pas là pour penser à la place du programmeur, et il y a des situations où faire une telle chose est tout à fait correct) et que le second ne t’y autorisera jamais.
Objective-C, en tant que langage, est exactement dans la même situation que le C à ce niveau (taille de l’entier qui varie, endianness, alignement, etc). Pourtant, OpenStep/Cococa a défini une API et un format d’échange, comme Java, et bizarrement, on ne voit personne pour pleurer sur la non-portabilité d’Objective-C et des plist.
Non, franchement, dire que le C n’est pas portable sous le prétexte que je peux pas charger brutalement le contenu brut de la mémoire d’une architecture vers l’autre (ce que tu fais quand tu fais un write+read direct de tes structures, hein), c’est un peu pareil que dire que Java n’est pas portable parce que je peux pas faire un core dump d’un programme tournant sur la JVM sun et charger ce core dump dans une autre JVM et que le programme puisse continuer sans rien remarquer.
tl;dr : quel que soit le langage, si tu veux être portable, tu dois définir un format d’échange, la seule différence entre Java et C étant qu’en Java tu as un format défini direct dans l’API standard.
> Peut-on vraiment parler de communication avec l'extérieur ?
Ben oui, quand tu communiques avec quelqu’un d’autre que toi (toi = fork(), en gros), tu dois faire gaffe : définir un format d’échange, et ne pas te contenter de lui balancer un dump mémoire à la gueule en le laissant se démerder. Si Java n’a pas ce problème, c’est parce qu’il n’autorise tout simplement pas à balancer un dump mémoire ([troll]c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime[/troll])
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Personnellement, en C, je peux faire du code qui tourne sans modification sur mon PC et le MSP430 (je l’utilise pour faire des routines que je peux tester sur mon PC, c’est plus simple de débugger sur un PC que sur un MSP430). Java, il tourne sur un MSP430 ?
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Si ton but c’est de faire un write((void*)&myStruct) parce qu’on peut le faire et que ça a l’air funton compilateur t’engueulera pas si tu le fais, oui.
Si ton but c’est de faire un truc qui juste marche, non, même en ANSI C : tu spécifies ton format de fichier et tu mets noir sur blanc l’endianness et la taille. Pas de problème d’alignement si tu fais pas un read((void*)&myStruct) mais que tu fais champ par champ. Oui, on sait : Java l’a fait pour toi. Mais la question « battery included » ou pas est orthogonale à la question « portable ou pas »
Et je te signale que tu entres ici dans la question de la portabilité des API, question que tu avais admis toi-même qu’elle était peu pertinente, tellement il est simple de faire non portable dans la communication avec l’extérieur.
> cela necessite beaucoup plus de code
Pas beaucoup non
write32(int32): 2 lignes (1 ligne pour le write, 1 ligne pour le htonl).
int32 read32(): 3 lignes (1 ligne pour le read, 1 ligne pour le ntohl, 1 ligne pour le return).
Le truc vraiment chiant à gérer c’est la représentation des flottants par contre, là je t’accorde que ce sera un peu plus que 5 lignes. Mais ce sera pas 3000 lignes non plus.
Bon, pour faire propre, double le nombre de lignes pour la gestion des erreurs.
> ou de se trimballer un framework expres pour comme le font beaucoup de projets portables
Parce que J2SE, c’est pas un framework peut-être ?
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
La difficulté est d’obtenir l’offset en fonction de l’alignement et tout. Tu fais comment en Java, sans les APIs de sérialisation ?
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Si c’est pour dire que .Net/Java a une librairie standard plus fournie, j’étais au courant avant.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Java ne te permet pas de stocker des classes directement dans un fichier (l’équivalent de write(fd, (void*)&myStruct, sizeof(myStruct)). Tu dois passer par une API de sérialisation.
Ben en C, pareil : si tu veux pas te prendre la tête, tu passes par une API de sérialisation. Ce sera plus lourd en C à cause du manque d’introspection, je te l’accorde.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
J’ai une mauvaise nouvelle à t’annoncer : depuis le début, tu te bats contre un homme de paille.
Qui ici a dit que le C était toujours portable ?
> si je trouve un exemple, tu vas dire que la fonctionnalité est mal codée.
Ben voyons. Dire que caster les void* en int et vice-versa c’est mal coder (c’est un des premiers exemple de ton lien), c’est être de mauvaise foi ?
J’en déduis donc que chez toi c’est une bonne pratique de caster les pointeurs en entier ?
> car la norme en soit ne garantie pas un code portable
Je crois que tu n’as pas compris un truc. C est un langage qui a comme principe d’être très laxiste, qui t’autorise à faire d’énorme conneries. Java est un langage au contraire beaucoup plus strict. Donc oui, tu peux faire d’énormes conneries qui t’empêcheront d’être portables en C et pas en Java. De là à dire qu’un programme écrit normalement en C n’est pas portable, il y a un gouffre que je ne peux voir franchi sans réagir.
Je vais te faire une image : Java ne peut pas te garantir formellement que ton programme est conforme à sa spécification (le C ne peut te garantir la portabilité), contrairement à certains langages issus de la recherche. Quelle est la bonne chose à en déduire ?
- Java ne permet pas de faire du code correct (le C n’est pas portable)
- Si tu veux réussir à remplir ton cahier des charges, il faut suivre des bonnes pratiques (si tu veux être portable, il faut suive des bonnes pratiques)
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Et en Java, tu fais comment ?
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Le rapport, c’est qu’à part la quantité de données que sera capable d’ingurgiter le programme, je vois pas ce que la taille des entiers change au niveau fonctionnel.
> Si t'as pas d'imagination, google est ton ami, exemples :
Ceci ne sont pas des exemples de fonctionnalités qui changent selon la taille d’un entier. Ce sont des listes de bonnes pratiques. Comme il y en a dans tous les langages — si tu les suis pas, vient pas pleurer si ton programme te pète dans les mains.
Encore une fois, ce que je te demande, c’est une fonctionnalité bien codée dont le comportement dépend de la taille d’un entier. Parce que si c’est juste pour dire qu’on peut faire du code pas portable en C en faisant n’importe quoi (genre caster un int en pointeur et vice versa), on était au courant, merci.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Ben non. PowerShell, c’est une couche d’abstraction, comme on l’a souligné.
vim, il travaille sur des fichiers, il utilise fopen & co.
Donc, je doute que taper "vim HKEY_CURRENT_USER\ma_clef" soit possible. D’ailleurs pBpG semble le confirmer puisque pour lui, « c’est complètement crétin de vouloir faire ça ».
Ergo : non, même avec PowerShell, tu ne peux pas faire tout ce que tu peux faire avec le shell Unix.
> ça montre juste ta méconnaissance du sujet sur lequel tu trolls.
Je ne nie pas. Juste que ce qui m’intéressait, c’était la comparaison entre le design « canonique » de Windows (tout est accessible par des handle avec les APIs qui vont bien) et de Unix (tout est accessible à l’aide de fichiers). Qu’on puisse faire des couches d’abstraction qui vont de l’un à l’autre, j’entends bien merci, j’avais pas besoin de troller pendant 3 jours pour le deviner. Que la couche d’abstraction « Unix-like » pour Windows soit maintenant fournie par défaut, je ne peux qu’applaudir des deux mains. Mais c’était pas ce qui m’intéressait.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Ha, parce que évidemment, dans le monde .Net/Java, on entend jamais « votre machine là, elle est pas assez puissante pour faire tourner cette fonctionnalité ».
> sa valeur diffère elle aussi d'une plateforme à l'autre.
Ben oui, évidemment, si tu fais un srand(INT_MAX) et que ton logiciel dépend des nombres sortis par ton peudo-RNG, sûr que le comportement diffèrera d’une plateforme à l’autre.
En dehors de ce cas, j’ai quelque difficultés à voir un code qui change ses fonctionnalités du tout au tout selon la valeur de INT_MAX (et sans erreur de programmation « mais non c’est du code tout à fait normal » à la malloc(INT_MAX)). Mais peut-être est-ce juste mon manque d’imagination ?
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 8.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
En même temps, si tu t’amuses à faire des malloc(-1), je suis pas sûr qu’on puisse dire que ce soit la faute du langage si ça te pète à la gueule.
[^] # Re: Banques
Posté par Moonz . En réponse au journal Éloge du don. Évalué à 2.
Ha, oui, j’ai compris ce que tu voulais dire. Effectivement, de ce point de vue, tu as raison, ma remarque était totalement HS :)
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Non, ce n’est pas la même chose. Une licence est une contrat entre deux parties, une promesse publique n’implique pas d’autre partie au moment de son énoncé.
Après, je sais pas quelles sont les implications juridiques :)
[^] # Re: Banques
Posté par Moonz . En réponse au journal Éloge du don. Évalué à 2.
Les chiffres ne sont pas parfait certes, mais il y a des degrés dans l’imperfection, et c’est toujours mieux que « mon ressenti au doigt mouillé » (encore une fois, ça s’applique à moi aussi).
> C'est fou cette envie de pointer du doigt ce que coûtent les fonctionnaires, mais pas les autres.
C’est pas ce que j’ai dit.
Ce que j’ai dit, c’est que je vois pas en quoi le fait qu’ils soient payés par les collectivités locales ou directement l’état entre en compte dans ce qui nous occupe.
> mais on reste dans des valeurs raisonnables
Et des valeurs raisonnables, c’est décidé par qui ? sur quelles bases ? On s’arrête où dans l’égalisation ? Quand le rapport est de 1 à 100 ? de 1 à 10 ? de 1 à 1.5 ? de 1 à 1 ?
Question : ce que tu appelles "OK", un écart plus faible, pour toi, c’est une injustice acceptable ou de la justice ?
> Si tu veux évaluer la pauvreté, il existe tout un tas d'indicateurs, aucun n'étant parfaits, mais autrement plus complexes que le nombre de SDF.
Certes, c’est d’ailleurs pour ça que j’avais parlé de « miséreux » et non pas de « pauvres » initialement, du reste.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Un des objectifs de la plateforme .Net (CLR & co) est d’être portable, et en pratique, ça marche.
Par contre, les APIs Microsoft de .Net (Windows Forms) n’ont jamais prétendu avoir cet objectif.
De plus, tu t’obstines à voir Mono comme « un effort de Microsoft pour se rapprocher du LL » (et vice-versa) avec des objectifs stratégiques des deux côtés alors qu’on se tue à te dire qu’on peut aussi tout simplement voir Mono comme une plate-forme de développement comme une autre, avec ses atouts (facile à déployer sous Windows & Linux, pas mal de langages différents, C# assez agréable à utiliser relativement au C++ ou à Java) et ses inconvénients (chiant à déployer sous MacOS X, pas d’API GUI standardisée, pas encore installé de base dans toutes les distributions).
[^] # Re: google == evil
Posté par Moonz . En réponse au journal Do not be evil, enfin un peu tout de même. Évalué à 2.
[^] # Re: google == evil
Posté par Moonz . En réponse au journal Do not be evil, enfin un peu tout de même. Évalué à 1.
À l’inverse, l’Europe a un problème démocratique (on s’assoit sur l’avis du peuple) alors que le peuple a l’avis contraire au tien (je pars du principe que tu étais pour le TCE, corrige-moi si je me trompe)
Note : je ne suis pas Suisse.
[^] # Re: Banques
Posté par Moonz . En réponse au journal Éloge du don. Évalué à 2.
Oui, j’avais les chiffres pour maintenant, mais ce qui m’intéresse, c’est son évolution.
Mais je pense qu’on ne le saura jamais.
Par contre, je suis très dubitatif sur le temps de travail en tant proxy pour la richesse. Après tout, le temps de travail n’est rien d’autre qu’un arbitrage temps libre/revenu ; il n’est absolument pas rare de voir, en occident, des ingénieurs sortant de l’école extrêmement bien payés mais qui ne comptent pas leurs heures et qui ne prennent pas de vacances pendant un an. Ça ne les rend pas vraiment pauvre pour autant.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Non, c’est juste qu’à force de répondre point par point, on a fini par ne plus parler de la même chose : tu parles de fonctionnalité possible, moi de fonctionnalités accessibles « out of the box » par le design du système (sans nécessiter de couche d’abstraction derrière).
> Ca veut dire quoi 'faire vim' ?
Éditer avec vim. Je peux faire "vim /etc/fstab". Je peux faire vim (manière d’accéder au registre en PowerShell) ?
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
J’avais essayé et ça m’avait explosé à la gueule, je sais plus pourquoi. L’ordre des clés qui différait entre deux exports peut-être, mais c’est vieux (Windows 2000 je crois), donc je me rappelle pas bien.
> Ben oui, et avec powershell aussi
Powershell ne fait pas partie du système chez moi.
Mais oui, je reconnais qu’un Unix-like-over-Windows est appréciable. Ce qui prouve que l’approche Unix a fait des émules chez Microsoft aussi. Reste que c’est « récent » (relativement à l’histoire de Windows & Unix — 2005 il me semble), donc dire « je peux faire avec PowerShell ce que je peux faire avec Unix, donc l’architecture de Windows et d’Unix, c’est kif-kif »), c’est légèrement de mauvaise foi. Mais c’est pas grave, on est sur TrollFR. tl;dr: PowerShell est là pour prouver que :
- de base, on peut pas faire la même chose avec Unix et Windows
- l’approche Unix est suffisamment intéressante pour l’émuler au-dessus de l’approche Windows
Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?