C'est intéressant pour un débutant en C++: ça ne fait pas de mal de rappeler aux gens qu'utiliser un langage rapide ne sert a rien si on ne sait pas s'en servir, et clairement faire des calculs redondants ou des copies inutiles, ça a un coût potentiellement important sur les performances.
Créer des programmes efficaces reste une activité qui nécessite de réfléchir et de connaître un minimum ses outils, assez pour les utiliser correctement, et surtout utiliser ceux adaptés à la situation.
Je suppose que l'une des prochaines optimisations sera d'utiliser stringview pour éviter les copies?
Posté par Florian.J .
Évalué à 1.
Dernière modification le 26 mars 2023 à 18:03.
La préallocation est souvent évoquée (à juste titre), mais ca serait pas mal de préciser que ca peut avoir des conséquences imprévues
J'ai tout récemment eu un problème sur un std::vector<> ou le bug a été difficile à identifier à cause ce ça.
Exemple, cette abbération marche:
std::vector<int> v;
v.reserve(10);
v[0] = 42;
std::cout << "VAL=" << v.front() << std::endl;
Le truc c'est que seule la fonction std::vector.at() contrôle les erreurs de débordement, pas l'opérateur [], back() ou front(). C'est d'ailleurs précisé dans la norme: https://en.cppreference.com/w/cpp/container/vector
Mon cas a été plus tordu, puisque qu'à cause d'une erreur dans mon code, je modifiais mon vecteur avec back() sans qu'il y ait eu de push_back() au préalable.
Ce qui a eu conséquence (sans que je comprenne exactement pourquoi) de faire planter le programme au moment de l'appel du destructeur.
SIGABRT : double free or corruption
Le mauvais côté c'est que si j'avais pas utilisé reserve(), le programme aurait planté dès l'appel à back(), ce qui m'aurait dirigé directement à la source de l'erreur.
Du coup c'est très bien dans l'idée mais maintenant je ne réserverai plutôt à du code de production.
# intéressant
Posté par freem . Évalué à 4.
C'est intéressant pour un débutant en C++: ça ne fait pas de mal de rappeler aux gens qu'utiliser un langage rapide ne sert a rien si on ne sait pas s'en servir, et clairement faire des calculs redondants ou des copies inutiles, ça a un coût potentiellement important sur les performances.
Créer des programmes efficaces reste une activité qui nécessite de réfléchir et de connaître un minimum ses outils, assez pour les utiliser correctement, et surtout utiliser ceux adaptés à la situation.
Je suppose que l'une des prochaines optimisations sera d'utiliser
stringviewpour éviter les copies?[^] # Re: intéressant
Posté par Julien Jorge (site web personnel) . Évalué à 3.
Tout à fait, c'est la prochaine étape :)
# Petit retour d'expérience.
Posté par Florian.J . Évalué à 1. Dernière modification le 26 mars 2023 à 18:03.
La préallocation est souvent évoquée (à juste titre), mais ca serait pas mal de préciser que ca peut avoir des conséquences imprévues
J'ai tout récemment eu un problème sur un std::vector<> ou le bug a été difficile à identifier à cause ce ça.
Exemple, cette abbération marche:
std::vector<int> v;
v.reserve(10);
v[0] = 42;
std::cout << "VAL=" << v.front() << std::endl;
Le truc c'est que seule la fonction std::vector.at() contrôle les erreurs de débordement, pas l'opérateur [], back() ou front(). C'est d'ailleurs précisé dans la norme:
https://en.cppreference.com/w/cpp/container/vector
Mon cas a été plus tordu, puisque qu'à cause d'une erreur dans mon code, je modifiais mon vecteur avec back() sans qu'il y ait eu de push_back() au préalable.
Ce qui a eu conséquence (sans que je comprenne exactement pourquoi) de faire planter le programme au moment de l'appel du destructeur.
SIGABRT : double free or corruption
Le mauvais côté c'est que si j'avais pas utilisé reserve(), le programme aurait planté dès l'appel à back(), ce qui m'aurait dirigé directement à la source de l'erreur.
Du coup c'est très bien dans l'idée mais maintenant je ne réserverai plutôt à du code de production.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.