Oui. Hypothèses pour justifier ça :
- avec les opérateurs, on sait exactement ce qu'on fait ;
- avec les opérateurs, on sait ce qui va être généré (attention au >> tout de même) ;
- avec les champs de bits C, incertitude sur le padding ?
- avec les champs de bits C, incertitude sur l'ordre des champs, des bits, des octets, des mots ?
- avec les champs de bits C, incertitude sur la taille du type crée ?
J'ai mis des points d'interrogation car je ne suis pas sûr qu'il y ait des problèmes potentiels (un spécialiste de la norme confirmerait/infirmerait), mais ça ne m'étonnerait pas. Et du coup, si comme moi, les autres programmeurs médiocres ne le sentent pas, ça peut expliquer que le champ de bits ne soit pas trop utilisé.
Je ne sais pas si en Ada (c'est bien de l'Ada, tes exemples ?) on a plus de certitudes.
[^] # Re: suckless !! More is less !
Posté par gnx . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Oui. Hypothèses pour justifier ça :
- avec les opérateurs, on sait exactement ce qu'on fait ;
- avec les opérateurs, on sait ce qui va être généré (attention au >> tout de même) ;
- avec les champs de bits C, incertitude sur le padding ?
- avec les champs de bits C, incertitude sur l'ordre des champs, des bits, des octets, des mots ?
- avec les champs de bits C, incertitude sur la taille du type crée ?
J'ai mis des points d'interrogation car je ne suis pas sûr qu'il y ait des problèmes potentiels (un spécialiste de la norme confirmerait/infirmerait), mais ça ne m'étonnerait pas. Et du coup, si comme moi, les autres programmeurs médiocres ne le sentent pas, ça peut expliquer que le champ de bits ne soit pas trop utilisé.
Je ne sais pas si en Ada (c'est bien de l'Ada, tes exemples ?) on a plus de certitudes.