C'est sûr, alors qu'une bonne expression régulière aurait fait des miracles en un seul appel.
Ceci dit, le pattern Fluent est vraiment agréable à utiliser (pour ceux qui font du JQuery, lodash, etc... par exemple, impossible de penser autrement maintenant).
Le vrai problème du code ci dessus vient de la signature de la fonction replace qui modifie la chaîne au lieu de retourner une nouvelle string. Si cela avait été le cas, alors l'ordre d'appel, on s'en balance. Avec un replace immutable, alors il faut, logiquement faire la recherche de la sous chaîne par la fin pour garantir que les modifications soient appliquées au bon endroit.
Mais au final, on retombe encore sur les signatures bancales de la classe string, qui ne propose qu'un nombre limité de méthodes (au nom d'une simplification de l'implémentation STL, mais qui, en pratique, force chaque projet à réimplémenter les fonctions de bases avec tous les bugs que ça impliquent). Un string replace(const string & this, const string & by_that) serait alors bien plus simple et dans la majorité des cas (le reste, c'est faisable par un erase + insert). De même pour tout ce qui est basé sur des index en fait, dans la majorité des cas, c'est inutile et vraiment pénible dès lors que l'on fait du UTF-8.
Un code comme ceci est bien plus compréhensible:
String s = "The blue cat doesn't like the yellow dog";
return s.replace("yellow", "blue").replace("blue", "yellow").replace("dog", "cat").replace("cat", "dog");
// Autre exemple, plus concret
String get_authority(const String & url) {
// Exemple: url = "http://whatever.org/path/to/index.html";
return url.from_first("://").to_first("/");
}
Le deuxième exemple, montre que, même si en interne la classe utilise des index pour trouver les sous chaînes, ils ne sont pas visibles dans la signature des méthodes, et donc c'est carrément plus intuitif. Côté performance, avec du COW, c'est mieux que du code à base de find & replace, vu qu'il ne faut plus "sortir" les index de la stack dans les fonctions supérieures, une seule fonction appelée, moins de registres utilisés et donc, au final, tourne beaucoup plus vite.
[^] # Re: Erreur de livre et experts C++
Posté par xryl669 . En réponse à la dépêche C++17 fixe l’ordre d’évaluation des expressions. Évalué à 5.
C'est sûr, alors qu'une bonne expression régulière aurait fait des miracles en un seul appel.
Ceci dit, le pattern Fluent est vraiment agréable à utiliser (pour ceux qui font du JQuery, lodash, etc... par exemple, impossible de penser autrement maintenant).
Le vrai problème du code ci dessus vient de la signature de la fonction replace qui modifie la chaîne au lieu de retourner une nouvelle string. Si cela avait été le cas, alors l'ordre d'appel, on s'en balance. Avec un replace immutable, alors il faut, logiquement faire la recherche de la sous chaîne par la fin pour garantir que les modifications soient appliquées au bon endroit.
Mais au final, on retombe encore sur les signatures bancales de la classe string, qui ne propose qu'un nombre limité de méthodes (au nom d'une simplification de l'implémentation STL, mais qui, en pratique, force chaque projet à réimplémenter les fonctions de bases avec tous les bugs que ça impliquent). Un string replace(const string & this, const string & by_that) serait alors bien plus simple et dans la majorité des cas (le reste, c'est faisable par un erase + insert). De même pour tout ce qui est basé sur des index en fait, dans la majorité des cas, c'est inutile et vraiment pénible dès lors que l'on fait du UTF-8.
Un code comme ceci est bien plus compréhensible:
String s = "The blue cat doesn't like the yellow dog";
return s.replace("yellow", "blue").replace("blue", "yellow").replace("dog", "cat").replace("cat", "dog");
// Autre exemple, plus concret
String get_authority(const String & url) {
// Exemple: url = "http://whatever.org/path/to/index.html";
return url.from_first("://").to_first("/");
}
Le deuxième exemple, montre que, même si en interne la classe utilise des index pour trouver les sous chaînes, ils ne sont pas visibles dans la signature des méthodes, et donc c'est carrément plus intuitif. Côté performance, avec du COW, c'est mieux que du code à base de find & replace, vu qu'il ne faut plus "sortir" les index de la stack dans les fonctions supérieures, une seule fonction appelée, moins de registres utilisés et donc, au final, tourne beaucoup plus vite.