Je suis confus sur les fonctions min et max, dans certains contextes.
Dans un contexte, lorsque vous utilisez les fonctions pour prendre la plus ou moins grande des deux valeurs, il n'y a pas de problème. Par exemple,
//how many autographed CD's can I give out?
int howManyAutographs(int CDs, int Cases, int Pens)
{
//if no pens, then I cannot sign any autographs
if (Pens == 0)
return 0;
//I cannot give away a CD without a case or a case without a CD
return min(CDs, Cases);
}
Facile. Mais dans un autre contexte, je suis confus. Si j'essaie de fixer un maximum ou un minimum, je le récupère à l'envers.
//return the sum, with a maximum of 255
int cappedSumWRONG(int x, int y)
{
return max(x + y, 255); //nope, this is wrong
}
//return the sum, with a maximum of 255
int cappedSumCORRECT(int x, int y)
{
return min(x + y, 255); //much better, but counter-intuitive to my mind
}
Est-il déconseillé de créer mes propres fonctions comme suit?
//return x, with a maximum of max
int maximize(int x, int max)
{
return min(x, max);
}
//return x, with a minimum of min
int minimize(int x, int min)
{
return max(x, min)
}
Évidemment, utiliser les fonctions intégrées sera plus rapide, mais cela me semble être une microoptimisation inutile. Y a-t-il une autre raison pour laquelle cela serait déconseillé? Qu'en est-il dans un projet de groupe?
std::clampfonction ou quelque chose de similaire.
up_to(pour min) et at_least(pour max)? Je pense qu'ils expriment mieux la signification que minimizeetc., bien qu'il faille peut-être un instant pour comprendre pourquoi ils sont commutatifs.
minet maxet aussi minimizeet maximizesont des noms totalement faux pour les fonctions que vous voulez écrire. Le défaut minet maxfont beaucoup plus de sens. Vous avez en réalité presque les bons noms de fonctions. Cette opération s'appelle serrage ou recouvrement et vous avez écrit deux fonctions de recouvrement. Je suggère capUpperBoundet capLowBound. Je n'ai pas à expliquer à qui que ce soit qui fait quoi, c'est évident.