Zerosquare (./33772) :
(Par ailleurs, je pressens que Ximoon aura deux mots à te dire à propos de l'utilisation de continue )
Pen^2 (./33774) :Oula, fatigué moi o_o
(c'est pas les pointeurs c'est les premiers éléments respectifs que Folco compare — je suggère de tester les autres aussi en dur en déroulant )
Zeph (./33779) :
./33776 : boah ça me semble pas si terrible ça, c'est également utile si tu veux faire une boucle entre zéro et une borne variable (genre strlen(toto)) sans forcément avoir à la déclarer dans une variable temporaire qui ne sert qu'à ça. C'est un petit hack, mais quand c'est pour implémenter un algo qui n'a aucune raison de parcourir une collection dans un sens plutôt que dans un autre ça ne me choque pas.
La nation française est à ses côtés et ça c'est beau. pic.twitter.com/juseUIFE1I
— peu importe (@MateuilB) April 24, 2018
Folco (./33789) :Parce qu'il a bon goût
Pourquoi n'es-tu pas fan de l'appel de fonction dans le test ?
Folco (./33789) :Comme l'a dit Godzil, c'est déjà moins lisible (même si le test est implicitement de savoir si la valeur de retour n'est pas zéro, c'est toujours mieux de voir ça explicitement, c'est plus lisible), et ensuite ça empêche notamment de mettre un point d'arrêt pour visualiser la valeur de la variable de retour lorsque tu débogues.
Ximoon -> c'est un blob qui comprend des données de config, des chemins d'accès, les sources du programes et diverses données sérialisées.
Pourquoi n'es-tu pas fan de l'appel de fonction dans le test ? un truc du genre if (strlen(str)) te raye les yeux ? Et pour quelles raisons ?
Simple: si les deux premières valeurs sont égales, tu n'exécutes que ton test. Par contre, si elle ne le sont pas, tu les testes une fois, puis tu appelles la fonction memcmp dans laquelle elles sont à nouveau testées. Donc si tes buffers sont différents mais pas à partir de la première donnée, ton appel sera en fait plus lent. Tout dépend donc de la première donnée dans le buffer, si elle est plus volatile que le reste. Je dirais même plus, lors de l'appel à la fonction tu sais déjà que les valeurs sont égales, tu peux donc commencer à la donnée d'après.
L'archi utilsée est un x86.
Mais je peux pas comprendre comment ça perdrait du temps de comparer deux caractères (cmp.b x(an),dn) vs un appel de fonction, avec push/pop de trois arguments pour chaque caractère.
protected virtual void FromStream<TKey>(Stream fileStream, StorageOptions options) where TKey : struct
{
IReader fileReader = null;
Signatures signature;
using (var reader = new BinaryReader(fileStream, true))
{
signature = (Signatures)reader.ReadUInt32();
switch (signature)
{
case Signatures.WDBC:
fileReader = new WDBC(fileStream);
break;
case Signatures.WDB2:
fileReader = new WDB2(fileStream);
break;
case Signatures.WDB5:
fileReader = new WDB5<TKey>(fileStream);
break;
case Signatures.WDB3:
case Signatures.WDB4:
throw new NotSupportedVersionException($"{signature} files cannot be read without client metadata.");
default:
throw new NotSupportedVersionException($"Unknown signature 0x{(int)signature:X8}!");
}
}
fileReader.Options = options;
if ( !fileReader.ReadHeader())
return;
fileReader.ReadSegments();
LoadRecords(fileReader);
}
Warpten (./33784) :C'était un exemple parmi d'autres, tu peux remplacer strlen par n'importe quelle fonction pure non-triviale qu'un compilo ne saura pas détecter comme pure et le problème restera identique.
je suis sur a 99% que n'importe quel compilo actuel est capable de pousser le resultat de strlen sur la pile et de s'en servir dans la boucle
_CRTIMP size_t __cdecl __MINGW_NOTHROW strlen (const char*) __MINGW_ATTRIB_PURE;
Donc la fonction est explicitement indiquée comme pure dans les headers. Si tu utilisais un strlen() externe qui ne le serait pas, logiquement le header serait différent, donc pas de souci.