Est-il valide d'utiliser std :: transform avec std :: back_inserter?

Cppreference a cet exemple de code pour std::transform:

std::vector<std::size_t> ordinals;
std::transform(s.begin(), s.end(), std::back_inserter(ordinals),
               [](unsigned char c) -> std::size_t { return c; });

Mais cela dit aussi:

std::transformne garantit pas l'application dans l'ordre de unary_opou binary_op. Pour appliquer une fonction à une séquence dans l'ordre ou pour appliquer une fonction qui modifie les éléments d'une séquence, utilisez std::for_each.

C'est probablement pour permettre des implémentations parallèles. Cependant, le troisième paramètre de std::transformest un LegacyOutputIteratorqui a la postcondition suivante pour ++r:

Après cette opération, il rn'est pas nécessaire d'être incrémentable et aucune copie de la valeur précédente de rne doit plus être déréférencable ou incrémentable.

Il me semble donc que l'affectation de la sortie doit se faire dans l'ordre. Signifient-ils simplement que l'application de unary_oppeut être hors service et stockée dans un emplacement temporaire, mais copiée dans l'ordre de sortie? Cela ne ressemble pas à quelque chose que vous voudriez faire.

La plupart des bibliothèques C ++ n'ont pas encore implémenté d'exécuteurs parallèles, mais Microsoft l'a fait. Je suis sûr que c'est le code correspondant, et je pense qu'il appelle cette fonction pour enregistrer des morceaux de itérateurs à la sortie, ce qui est certainement pas une chose valable de le faire parce que peut être invalidée par incrémenter copies.populate()LegacyOutputIterator

Qu'est-ce que je rate?

1) Les exigences de l'itérateur de sortie dans la norme sont complètement rompues. Voir LWG2035 .

2) Si vous utilisez un itérateur de sortie purement et une plage de source d'entrée purement, l'algorithme ne peut pas faire grand-chose d'autre en pratique; il n'a d'autre choix que d'écrire dans l'ordre. (Cependant, une implémentation hypothétique peut choisir de mettre en cas particulier ses propres types, comme std::back_insert_iterator<std::vector<size_t>>; je ne vois pas pourquoi une implémentation voudrait le faire ici, mais elle est autorisée à le faire.)

3) Rien dans la norme ne garantit l' transformapplication des transformations dans l'ordre. Nous examinons un détail d'implémentation.

Cela std::transformne nécessite que des itérateurs de sortie ne signifie pas qu'il ne peut pas détecter des forces d'itérateur plus élevées et réorganiser les opérations dans de tels cas. En effet, les algorithmes distribuent tout le temps la force des itérateurs , et ils ont un traitement spécial pour les types d'itérateurs spéciaux (comme les pointeurs ou les itérateurs vectoriels) tout le temps .

Lorsque la norme veut garantir une commande particulière, elle sait comment la dire (voir std::copy«partir de firstet continuer vers last»).

De n4385:

§25.6.4 Transformer :

template<class InputIterator, class OutputIterator, class UnaryOperation>
constexpr OutputIterator
transform(InputIterator first1, InputIterator last1, OutputIterator result, UnaryOperation op);

template<class ExecutionPolicy, class ForwardIterator1, class ForwardIterator2, class UnaryOperation>
ForwardIterator2
transform(ExecutionPolicy&& exec, ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 result, UnaryOperation op);

template<class InputIterator1, class InputIterator2, class OutputIterator, class BinaryOperation>
constexpr OutputIterator
transform(InputIterator1 first1, InputIterator1 last1, InputIterator2 first2, OutputIterator result, BinaryOperation binary_op);

template<class ExecutionPolicy, class ForwardIterator1, class ForwardIterator2, class ForwardIterator, class BinaryOperation>
ForwardIterator
transform(ExecutionPolicy&& exec, ForwardIterator1 first1, ForwardIterator1 last1, ForwardIterator2 first2, ForwardIterator result, BinaryOperation binary_op);

§23.5.2.1.2 back_inserter

template<class Container>
constexpr back_insert_iterator<Container> back_inserter(Container& x);

Renvoie: back_insert_iterator (x).

§23.5.2.1 Modèle de classe back_insert_iterator

using iterator_category = output_iterator_tag;

std::back_inserterNe peut donc pas être utilisé avec des versions parallèles de std::transform. Les versions qui prennent en charge les itérateurs de sortie lisent à partir de leur source avec les itérateurs d'entrée. Comme les itérateurs d'entrée ne peuvent être pré- et post-incrémentés (§23.3.5.2 Itérateurs d'entrée) et qu'il n'y a qu'une exécution séquentielle ( c'est -à- dire non parallèle), l'ordre doit être préservé entre eux et l'itérateur de sortie.

Donc, ce qui m'a manqué, c'est que les versions parallèles prennent LegacyForwardIterators, non LegacyOutputIterator. A LegacyForwardIterator peut être incrémenté sans invalider des copies de celui-ci, il est donc facile de l'utiliser pour implémenter un parallèle hors service std::transform.

Je pense que les versions non parallèles de std::transform doivent être exécutées dans l'ordre. Soit cppreference se trompe, soit la norme laisse simplement cette exigence implicite car il n'y a pas d'autre moyen de l'implémenter. (Le fusil de chasse ne parcourt pas la norme pour le savoir!)

Je crois que la transformation est garantie d'être traitée dans l'ordre . std::back_inserter_iteratorest un itérateur de sortie (son iterator_categorytype de membre est un alias pour std::output_iterator_tag) selon [back.insert.iterator] .

Par conséquent, std::transformn'a pas d'autre option sur la façon de procéder à la prochaine itération que d'appeler membre operator++sur le resultparamètre.

Bien sûr, cela n'est valable que pour les surcharges sans politique d'exécution, où std::back_inserter_iteratorne peut pas être utilisé (ce n'est pas un itérateur de transfert ).

BTW, je ne voudrais pas argumenter avec des citations de cppreference. Les déclarations y sont souvent imprécises ou simplifiées. Dans de tels cas, il est préférable de regarder la norme C ++. Où, en ce qui concerne std::transform, il n'y a aucune citation sur l'ordre des opérations.