> - 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 ?
[^] # 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 ?