(par exemple, pourquoi les destructeurs ne sont-ils pas virtuels par défaut?)
Parce que la présence d'une méthode virtuelle implique la génération d'une vtable, qui a un impact sur les performances.
typiquement, les arguments de main
Portabilité & Compatibilité (oui, je sais) avec la famille execXY() standardisée par POSIX (ne pas oublier que la portabilité est importante pour les utilisateurs de C++).
Tu proposes quoi?
De renvoyer un bool et d'avoir un std::vector<std::string>const& en entrée?
Ça implique argc + 1 appels à new (puisqu'il faudrait copier ce que l'OS envoie, ces conteneurs n'étant pas capables de prendre la propriété d'un pointeur) pouvant throw en cas de problème mémoire. Et ou tu catch, puisque ça à throw avant même d'entrer dans le code?
Je ne mentionne pas le fait que std::string, c'est potentiellement 24 octets par objet (en plus du contenu, tu as en gros un pointeur vers les données, un vers la fin de la zone utilisable et un dernier qui indique la fin réelle. 3 * 8 sur une machine 64bits classique).
Si t'as en entrée un truc genre apt-cache pkgnames, ça risque de faire pas mal de mémoire (45237 entrée chez moi, autrement dit plus d'1Mio potentiels une fois *24. Je dis potentiels, parce qu'avec les SSO ça peut être moins, en fonction du compilo.) et de risques de throw, le tout pour faire plaisir à des gens qui n'ont rien à faire de la performance et de la portabilité, qui ne sont pas la cible première de C++?
Quel réel avantage y aurait-il? Au passage, std::basic_string<char> ou std::basic_string<wchar> (bon, j'ai un doute, je sais plus si c'est wchar ou wchar_t...)?
(personnellement, j'aime bien le comportement d'un bool qu'on a oublié d'initialiser)
Au moins n'est-il pas null, nil, nul ou whatever truc qu'on peut voir ailleurs. Ici, tu oublies un truc: en C++ on ne paye pas pour ce qu'on n'utilise pas. Et ce n'est pas toujours utile d'initialiser tes variables quand tu les déclares: par exemple une variable qui sera initialisée dans une boucle, et utilisée après la fin de cette boucle, il n'y a aucune raison de l'initialiser avant.
Au passage, ton compilo te préviendra pour 99% des cas (jusqu'à présent, il m'a toujours prévenu, mais bon, je laisse place à l'incertitude).
[^] # Re: Donc pour résumer...
Posté par freem . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 2.
Parce que la présence d'une méthode virtuelle implique la génération d'une vtable, qui a un impact sur les performances.
Portabilité & Compatibilité (oui, je sais) avec la famille
execXY()standardisée par POSIX (ne pas oublier que la portabilité est importante pour les utilisateurs de C++).Tu proposes quoi?
De renvoyer un bool et d'avoir un
std::vector<std::string>const&en entrée?Ça implique argc + 1 appels à new (puisqu'il faudrait copier ce que l'OS envoie, ces conteneurs n'étant pas capables de prendre la propriété d'un pointeur) pouvant throw en cas de problème mémoire. Et ou tu catch, puisque ça à throw avant même d'entrer dans le code?
Je ne mentionne pas le fait que std::string, c'est potentiellement 24 octets par objet (en plus du contenu, tu as en gros un pointeur vers les données, un vers la fin de la zone utilisable et un dernier qui indique la fin réelle. 3 * 8 sur une machine 64bits classique).
Si t'as en entrée un truc genre
apt-cache pkgnames, ça risque de faire pas mal de mémoire (45237 entrée chez moi, autrement dit plus d'1Mio potentiels une fois *24. Je dis potentiels, parce qu'avec les SSO ça peut être moins, en fonction du compilo.) et de risques de throw, le tout pour faire plaisir à des gens qui n'ont rien à faire de la performance et de la portabilité, qui ne sont pas la cible première de C++?Quel réel avantage y aurait-il? Au passage,
std::basic_string<char>oustd::basic_string<wchar>(bon, j'ai un doute, je sais plus si c'est wchar ou wchar_t...)?Au moins n'est-il pas null, nil, nul ou whatever truc qu'on peut voir ailleurs. Ici, tu oublies un truc: en C++ on ne paye pas pour ce qu'on n'utilise pas. Et ce n'est pas toujours utile d'initialiser tes variables quand tu les déclares: par exemple une variable qui sera initialisée dans une boucle, et utilisée après la fin de cette boucle, il n'y a aucune raison de l'initialiser avant.
Au passage, ton compilo te préviendra pour 99% des cas (jusqu'à présent, il m'a toujours prévenu, mais bon, je laisse place à l'incertitude).