Discussion :

[oodini]

Hello,

Disons que vous avez régulièrement besoin d'effectuer des concaténations de chaînes, par exemple pour des messages d'exception.

Il existe plusieurs méthodes, dont :

1. utilisation de l'opérateur +
2. utilisation de append
3. utilisation d'un ostringstream

Je me retrouve dans un projet où la première solution est systématiquement utilisée.
Elle est réputée peu performante (création d'un nouvel objet string à chaque application d'une opération +). Toutefois, les flux ne sont pas non plus très réputés, point de vue performances.
La seconde est sans doute la plus rapide, mais la moins "présentable".

Qu'utilisez-vous, de votre côté ?

[Bousk]

Salut,

en terme de perf, le préprocesseur au maximum, sinon l'opérateur += d'une classe string faute de mieux.
Les flux rarement.
De toutes façons il faut bien en utiliser un, et si c'est uniquement pour générer des messages d'erreur, les perfs sont carrément secondaires, à moins que tu en aies beaucoup, auquel cas tu as un autre problème bien plus important.
Si tu réalises régulièrement des concaténations diverses, peut-être qu'un autre format que la chaîne de caractères pour passer l'information est préférable.
Sinon, utilises un buffer. std::string a une interface reserve.

[ternel]

Le jour où ce sont les concaténations de chaines qui seront le problème de performances, je me poserai la question.

Une exception ne devant survenir que lors de problèmes anormaux, sa gestion est toujours faite en remontant à un fonctionnement plus lent: intervention utilisateur, abandon du processus en cours, arrêt du programme.
Dans tous les cas, on sort du flux de calculs rapides, et le manque de performance n'est pas grave.

Avec un ostringstream, on peut réserver une certaine capacité, supprimant les besoins de réallocation à chaque chaine concaténée.
Le seul défaut concret d'un ostringstream, c'est qu'on perd sa nature de ostringstream après le premier appel à <<.
Cela empèche de chainer l'appel à str() et donc son utilisation dans une expression.

Il suffit de faire une petite capsule autour pour que ce ne soit plus le cas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
struct capsule {
std::ostringstream stream;
 
template <typename T>
capsule& operator << (T const& t) { stream << t; return *this; }
 
operator std::string () const { return stream.str(); }
};
 
voif f() { throw std::runtime_error(capsule{} << "un probleme est survenu avec " << "id" << " dans la fonction f"); }

A améliorer, bien sûr, mais ca fait la base.

[oodini]

C'est vrai que les yeux irrités par ces additions de chaînes, je n'avais pas pris conscience du caractère exceptionnel de la chose dans l'exécution du code, et que ce n'est peut-être pas si important.

Toutefois, pour en rester aux considérations théoriques, une chose m'intrigue :

Le seul défaut concret d'un ostringstream, c'est qu'on perd sa nature de ostringstream après le premier appel à <<.
Cela empèche de chainer l'appel à str() et donc son utilisation dans une expression.

Il faut juste appeler str() sur une instruction à part.

[ternel]

Oui, certes. Et, il faut aussi définir le stream encore à part.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
voif f(int a, int b) {
    if ( bad(a, b) ) {
        throw std::runtime_error(capsule{} << "illegal values (" << a << ", " << b << ").");
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
voif f(int a, int b) {
    if ( bad(a, b) ) {
        std::ostringstream s;
        s << "illegal values (" << a << ", " << b << ").":
        throw std::runtime_error(s.str());
    }
}

Dans la première version, le bruit technique est plus restreint.

[oodini]

Ah, OK. je n'avais pas compris ce que tu avais à l'esprit.

Merci pour l'astuce.