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.
Dans ce cas, le concept même de coder en C++ a un impact sur les performances. Parce que si tu n'utilises pas le polymorphisme, ni la STL, ni les exceptions, ni les templates et que tu préfères utiliser des pointeurs nus et des macros, alors ça ressemble furieusement à ce que certains appellelent du C/C++, qui n'est en fait ni du C ni du C++.
Au passage, la règle pourrait bien être que les destructeurs d'une classe qui a au moins une méthode virtuelle sont virtuels. Ou de définir un mot clé "nonvirtual" pour les 0.01% des cas où on veut explicitement éviter la création d'une vtable.
Portabilité & Compatibilité (oui, je sais) avec la famille execXY() standardisée par POSIX
Dans ce cas, je ne vois pas le problème à surcharger la fonction main, une en int main(int, char**) et une en bool main(vector<string>). Encore une fois, si tu veux faire du C/C++, tu peux utiliser la version C, le compilo peut bien voir quelle version tu utilises.
des gens qui n'ont rien à faire de la performance et de la portabilité, qui ne sont pas la cible première de C++?
On pourrait débattre indéfiniment sur la cible première du C++, mais la performance et la portabilité ne peuvent pas être les deux seuls critères ; autrement, les gens feraient du C. Le C++, c'est avant tout la POO, la programmation générique, l'encapsulation, la STL, et tous les petits trucs du C++ moderne (lambda, inférence de type, shared_pointers, etc). Je t'accorde qu'il existe des gens comme toi qui interprètent le langage en tant que C amélioré, et notamment qui pondèrent l'utilisation d'un certain nombre de fonctionnalités du langage par les coûts induits en temps d'exécution et en mémoire. Mais il faut aussi voir que pour une très vaste communauté, ces choses n'ont aucun intérêt par rapport aux avantages de l'encapsulation, de la gestion des erreurs, ou des vérifications de types faites à la compilation?
[^] # Re: Donc pour résumer...
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 2.
Dans ce cas, le concept même de coder en C++ a un impact sur les performances. Parce que si tu n'utilises pas le polymorphisme, ni la STL, ni les exceptions, ni les templates et que tu préfères utiliser des pointeurs nus et des macros, alors ça ressemble furieusement à ce que certains appellelent du C/C++, qui n'est en fait ni du C ni du C++.
Au passage, la règle pourrait bien être que les destructeurs d'une classe qui a au moins une méthode virtuelle sont virtuels. Ou de définir un mot clé "nonvirtual" pour les 0.01% des cas où on veut explicitement éviter la création d'une vtable.
Dans ce cas, je ne vois pas le problème à surcharger la fonction main, une en
int main(int, char**)et une enbool main(vector<string>). Encore une fois, si tu veux faire du C/C++, tu peux utiliser la version C, le compilo peut bien voir quelle version tu utilises.On pourrait débattre indéfiniment sur la cible première du C++, mais la performance et la portabilité ne peuvent pas être les deux seuls critères ; autrement, les gens feraient du C. Le C++, c'est avant tout la POO, la programmation générique, l'encapsulation, la STL, et tous les petits trucs du C++ moderne (lambda, inférence de type, shared_pointers, etc). Je t'accorde qu'il existe des gens comme toi qui interprètent le langage en tant que C amélioré, et notamment qui pondèrent l'utilisation d'un certain nombre de fonctionnalités du langage par les coûts induits en temps d'exécution et en mémoire. Mais il faut aussi voir que pour une très vaste communauté, ces choses n'ont aucun intérêt par rapport aux avantages de l'encapsulation, de la gestion des erreurs, ou des vérifications de types faites à la compilation?