State_alarm récupère l’état d’un interrupteur et en fonction devras faire une petit icone sur l’écran home d’où le volatile. ( je n’ai pas implémenté la fonction encore )
Je doute quand même que volatile soit justifié, mais à voir.
Je vais approfondir ce passage la… Pourquoi un const est important, au delà qu’il n’est pas modifiable?
J’ai l’impression de répondre à la question en la posant, mais je cherche surtout à savoir quel serais le problème s’il on ne l’utilisais pas.
Il n’y a pas de réel problème, mais un const offre plus de garantie pour celui qui implémente la fonction: il ne peut pas modifier l’état des variables constante, et pour celui qui l’utilise: il sait qu’il n’y aura pas de modification des états. Dans le cas contraire, il y aura une erreur à la compilation. Pour cette même raison, seules les fonctions membres const sont accessibles depuis une variable const. Si const n’est pas respecté de bout en bout, il va encore une fois y avoir une erreur de compilation.
D’ailleurs, une chaîne de caractère de la forme "bla bla" est un tableau constant. Le passer à une fonction qui prend un char* devrait au minimum retourner un avertissement: cela n’est pas autorisé en C++, mais pour des raisons historiques lié au C, les compilateurs l’autorisent encore.
Oui l’heure effectivement est statique mais pas la date, l’utilisation de calloc viens du fait que j’ai eu beaucoup de mal a faire retourner un char par ma fonction. J’ai vu cette solution sur un forum.
Pas un char, mais un tableau. Les tableaux du C sont une plaie et les retourner dans une fonction revient à retourner un pointeur et non pas le tableau complet. C’est pour cela qu’il existe dans le standard un std::array. Grosso modo, ce n’est qu’une structure qui contient un tableau. Mais contrairement au tableau, une structure peut être copiée.
struct SecretNumber
{
char data[5];
};
SecretNumber secret()
{
SecretNumber secret_number;
return secret_number;
}
Avec des templates, on peut spécifier la taille du tableau interne
template<unsigned N>
struct Array
{
char data[N];
};
using TimeString = Array<16>;
using DateString = Array<50>;
TimeString Screen::_format_time(int hh, int mm, int ss)
{
TimeString buf;
sprintf(buf.data, "%02d:%02d:%02d", hh, mm, ss);
return buf;
}
Classe pour virer les strlen pourquoi ? (1) j’ai déjà lu qu’il valais mieux éviter de les mettre dans les conditions il y à un problème avec eux ?
- C’est plutôt éviter de les faire plusieurs fois alors qu’on peut conserver le résultat dans une variable et la réutiliser.
Mais à mon sens, le vrai problème est de calculer la taille de la chaîne alors que cette taille est presque systématiquement connue. Par exemple, la famille des printf retourne le nombre de caractère écrit, cela correspond à la taille (sauf erreur si la taille du buffer est insuffisant, ce qui n’est pas le cas ici). Ta fonction display_home fait un strlen de today_date, appel _scroll_one_line qui fait également un strlen de today_date. Il y a 2 appels à strlen, alors que la taille aurait pu être conservée dès le début. Même si le compilateur va probablement virer le second appel et peut-être même le premier, il ne pourra pas toujours faire ce genre d’optimisation ce qui ferra tourner le programme pour rien.
Quelque chose de vraiment basique ressemblerait à
template<unsigned N>
struct StaticString
{
char data[N];
unsigned size;
};
using TimeString = StaticString<16>;
TimeString Screen::_format_time(int hh, int mm, int ss)
{
TimeString buf;
buf.size = sprintf(buf.data, "%02d:%02d:%02d", hh, mm, ss);
return buf;
}
