l'id=E9e est assez simple. Comment puis je r=E9cup=E9rer une
variable/instance de type vector apr=E8s l'appel l'algorithm for_each.
Comme dans l'exemple. Je parcours une string. pour chaque car.
convertit en entier que je place dans un vector<int>.
Mais apr=E8s l'appel =E0 for_each comme puis je acc=E9der au vector ?
merci d'avance
Fr=E9d=E9ric
class ConvertCharToInt
{
vector<int> vFmt;
public:
void operator() (char c)
{
vFmt.push_back(atoi(c));
}
};
class CFmt
{
public :
string szFmt;
void GetStringFormat(const string a){ szFmt=3D a;};
void SplitFmt(){
std::for_each(szFmt.begin(),szFmt.end(),ConvertCharToInt());
};
};
main()
{
CFmt *obj;
obj=3D new CFmt;
obj->GetStringFormat("123456");
obj->SplitFmt();
delete obj;
}
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | "kanze" écrivait: | > | | > | > Un getter ne permet pas d'habitude une modification de l'objet. | > | > Il renverra donc soit une copie, soit une référence à const. (De | > | > même, il serait const lui-même.) | > | | > | L'anglais est une langue pauvre ;-) En français tu as accesseur en | > | lecture (seule) ; accesseur en écriture (seule) et accesseur en | > | lecture/écriture. Comment tu appelles le dernier en anglais ? | > | > read | > write | > readwrite | > ? | | Non, nous parlions de getter/setter.
Je sais de quoi il était question à l'origine.
Maintenant, relis bien ton précédent message. Take a deep breath. Et relis mon message.
-- Gaby
Franck Branjonneau <fasbjx@free.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
|
| > Franck Branjonneau <fasbjx@free.fr> writes:
| >
| > | "kanze" <kanze@gabi-soft.fr> écrivait:
| > |
| > | > Un getter ne permet pas d'habitude une modification de l'objet.
| > | > Il renverra donc soit une copie, soit une référence à const. (De
| > | > même, il serait const lui-même.)
| > |
| > | L'anglais est une langue pauvre ;-) En français tu as accesseur en
| > | lecture (seule) ; accesseur en écriture (seule) et accesseur en
| > | lecture/écriture. Comment tu appelles le dernier en anglais ?
| >
| > read
| > write
| > readwrite
| > ?
|
| Non, nous parlions de getter/setter.
Je sais de quoi il était question à l'origine.
Maintenant, relis bien ton précédent message. Take a deep breath. Et
relis mon message.
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | "kanze" écrivait: | > | | > | > Un getter ne permet pas d'habitude une modification de l'objet. | > | > Il renverra donc soit une copie, soit une référence à const. (De | > | > même, il serait const lui-même.) | > | | > | L'anglais est une langue pauvre ;-) En français tu as accesseur en | > | lecture (seule) ; accesseur en écriture (seule) et accesseur en | > | lecture/écriture. Comment tu appelles le dernier en anglais ? | > | > read | > write | > readwrite | > ? | | Non, nous parlions de getter/setter.
Je sais de quoi il était question à l'origine.
Maintenant, relis bien ton précédent message. Take a deep breath. Et relis mon message.
-- Gaby
Franck Branjonneau
Gabriel Dos Reis écrivait:
Franck Branjonneau writes:
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | "kanze" écrivait: | > | | > | > Un getter ne permet pas d'habitude une modification de l'objet. | > | > Il renverra donc soit une copie, soit une référence à const. (De | > | > même, il serait const lui-même.) | > | | > | L'anglais est une langue pauvre ;-) En français tu as accesseur en | > | lecture (seule) ; accesseur en écriture (seule) et accesseur en | > | lecture/écriture. Comment tu appelles le dernier en anglais ? | > | > read | > write | > readwrite | > ? | | Non, nous parlions de getter/setter.
Je sais de quoi il était question à l'origine.
Maintenant, relis bien ton précédent message. Take a deep breath. Et relis mon message.
Getter peur se traduire par accesseur.
Parler de getter non const a alors un sens.
-- Franck Branjonneau
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
Franck Branjonneau <fasbjx@free.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
|
| > Franck Branjonneau <fasbjx@free.fr> writes:
| >
| > | "kanze" <kanze@gabi-soft.fr> écrivait:
| > |
| > | > Un getter ne permet pas d'habitude une modification de l'objet.
| > | > Il renverra donc soit une copie, soit une référence à const. (De
| > | > même, il serait const lui-même.)
| > |
| > | L'anglais est une langue pauvre ;-) En français tu as accesseur en
| > | lecture (seule) ; accesseur en écriture (seule) et accesseur en
| > | lecture/écriture. Comment tu appelles le dernier en anglais ?
| >
| > read
| > write
| > readwrite
| > ?
|
| Non, nous parlions de getter/setter.
Je sais de quoi il était question à l'origine.
Maintenant, relis bien ton précédent message. Take a deep breath. Et
relis mon message.
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | "kanze" écrivait: | > | | > | > Un getter ne permet pas d'habitude une modification de l'objet. | > | > Il renverra donc soit une copie, soit une référence à const. (De | > | > même, il serait const lui-même.) | > | | > | L'anglais est une langue pauvre ;-) En français tu as accesseur en | > | lecture (seule) ; accesseur en écriture (seule) et accesseur en | > | lecture/écriture. Comment tu appelles le dernier en anglais ? | > | > read | > write | > readwrite | > ? | | Non, nous parlions de getter/setter.
Je sais de quoi il était question à l'origine.
Maintenant, relis bien ton précédent message. Take a deep breath. Et relis mon message.
Getter peur se traduire par accesseur.
Parler de getter non const a alors un sens.
-- Franck Branjonneau
Gabriel Dos Reis
Franck Branjonneau writes:
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | Gabriel Dos Reis écrivait: | > | | > | > Franck Branjonneau writes: | > | > | > | > | "kanze" écrivait: | > | > | | > | > | > Un getter ne permet pas d'habitude une modification de l'objet. | > | > | > Il renverra donc soit une copie, soit une référence à const. (De | > | > | > même, il serait const lui-même.) | > | > | | > | > | L'anglais est une langue pauvre ;-) En français tu as accesseur en | > | > | lecture (seule) ; accesseur en écriture (seule) et accesseur en | > | > | lecture/écriture. Comment tu appelles le dernier en anglais ? | > | > | > | > read | > | > write | > | > readwrite | > | > ? | > | | > | Non, nous parlions de getter/setter. | > | > Je sais de quoi il était question à l'origine. | > | > Maintenant, relis bien ton précédent message. Take a deep breath. Et | > relis mon message. | | Getter peur se traduire par accesseur.
accesseur en lecture seule ? Très certainement.
| Parler de getter non const a alors un sens.
Probablement-être, mais mon message répondait spécifiquement au paragraphe cité.
-- Gaby
Franck Branjonneau <fasbjx@free.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
|
| > Franck Branjonneau <fasbjx@free.fr> writes:
| >
| > | Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
| > |
| > | > Franck Branjonneau <fasbjx@free.fr> writes:
| > | >
| > | > | "kanze" <kanze@gabi-soft.fr> écrivait:
| > | > |
| > | > | > Un getter ne permet pas d'habitude une modification de l'objet.
| > | > | > Il renverra donc soit une copie, soit une référence à const. (De
| > | > | > même, il serait const lui-même.)
| > | > |
| > | > | L'anglais est une langue pauvre ;-) En français tu as accesseur en
| > | > | lecture (seule) ; accesseur en écriture (seule) et accesseur en
| > | > | lecture/écriture. Comment tu appelles le dernier en anglais ?
| > | >
| > | > read
| > | > write
| > | > readwrite
| > | > ?
| > |
| > | Non, nous parlions de getter/setter.
| >
| > Je sais de quoi il était question à l'origine.
| >
| > Maintenant, relis bien ton précédent message. Take a deep breath. Et
| > relis mon message.
|
| Getter peur se traduire par accesseur.
accesseur en lecture seule ? Très certainement.
| Parler de getter non const a alors un sens.
Probablement-être, mais mon message répondait spécifiquement au
paragraphe cité.
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | Gabriel Dos Reis écrivait: | > | | > | > Franck Branjonneau writes: | > | > | > | > | "kanze" écrivait: | > | > | | > | > | > Un getter ne permet pas d'habitude une modification de l'objet. | > | > | > Il renverra donc soit une copie, soit une référence à const. (De | > | > | > même, il serait const lui-même.) | > | > | | > | > | L'anglais est une langue pauvre ;-) En français tu as accesseur en | > | > | lecture (seule) ; accesseur en écriture (seule) et accesseur en | > | > | lecture/écriture. Comment tu appelles le dernier en anglais ? | > | > | > | > read | > | > write | > | > readwrite | > | > ? | > | | > | Non, nous parlions de getter/setter. | > | > Je sais de quoi il était question à l'origine. | > | > Maintenant, relis bien ton précédent message. Take a deep breath. Et | > relis mon message. | | Getter peur se traduire par accesseur.
accesseur en lecture seule ? Très certainement.
| Parler de getter non const a alors un sens.
Probablement-être, mais mon message répondait spécifiquement au paragraphe cité.
Avec une référence, tu ne peux plus utiliser l'operateur d'affectation par defaut, et donc sans code supplementaire le functor n'est plus Assignable (et je ne sais pas si c'est toujours un pré-requis pour le parametre de for_each, ca l'etait néanmoins dans la STL version SGI).
"Alexandre" <alex.g@netcourrier.com> a écrit dans le message de
news:4404d0f4$0$6433$626a54ce@news.free.fr...
Avec une référence, tu ne peux plus utiliser l'operateur d'affectation par
defaut,
et donc sans code supplementaire le functor n'est plus Assignable (et je ne
sais
pas si c'est toujours un pré-requis pour le parametre de for_each, ca
l'etait
néanmoins dans la STL version SGI).
Avec une référence, tu ne peux plus utiliser l'operateur d'affectation par defaut, et donc sans code supplementaire le functor n'est plus Assignable (et je ne sais pas si c'est toujours un pré-requis pour le parametre de for_each, ca l'etait néanmoins dans la STL version SGI).
kanze
Michel Decima wrote:
"Alexandre" a écrit dans le message de news:4404d0f4$0$6433$
Avec une référence, tu ne peux plus utiliser l'operateur d'affectation par defaut, et donc sans code supplementaire le functor n'est plus Assignable (et je ne sais pas si c'est toujours un pré-requis pour le parametre de for_each, ca l'etait néanmoins dans la STL version SGI).
C'en est un. Même si c'est probable que ça marche quand même avec beaucoup d'implémentations.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Michel Decima wrote:
"Alexandre" <alex.g@netcourrier.com> a écrit dans le message de
news:4404d0f4$0$6433$626a54ce@news.free.fr...
Avec une référence, tu ne peux plus utiliser l'operateur
d'affectation par defaut, et donc sans code supplementaire le
functor n'est plus Assignable (et je ne sais pas si c'est
toujours un pré-requis pour le parametre de for_each, ca
l'etait néanmoins dans la STL version SGI).
C'en est un. Même si c'est probable que ça marche quand même
avec beaucoup d'implémentations.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avec une référence, tu ne peux plus utiliser l'operateur d'affectation par defaut, et donc sans code supplementaire le functor n'est plus Assignable (et je ne sais pas si c'est toujours un pré-requis pour le parametre de for_each, ca l'etait néanmoins dans la STL version SGI).
C'en est un. Même si c'est probable que ça marche quand même avec beaucoup d'implémentations.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Michel Decima
In news:, kanze typed:
Avec une référence, tu ne peux plus utiliser l'operateur d'affectation par defaut, et donc sans code supplementaire le functor n'est plus Assignable (et je ne sais pas si c'est toujours un pré-requis pour le parametre de for_each, ca l'etait néanmoins dans la STL version SGI).
C'en est un. Même si c'est probable que ça marche quand même avec beaucoup d'implémentations.
Merci pour la verification. Et effectivement, ca marche quand meme avec xlC-6 et GCC-4 (pour ce dernier, je constate que le concept Assignable n'est pas testé dans le code de for_each)
In news:1141217549.541745.221070@u72g2000cwu.googlegroups.com,
kanze <kanze@gabi-soft.fr> typed:
Avec une référence, tu ne peux plus utiliser l'operateur
d'affectation par defaut, et donc sans code supplementaire le
functor n'est plus Assignable (et je ne sais pas si c'est
toujours un pré-requis pour le parametre de for_each, ca
l'etait néanmoins dans la STL version SGI).
C'en est un. Même si c'est probable que ça marche quand même
avec beaucoup d'implémentations.
Merci pour la verification. Et effectivement, ca marche quand meme
avec xlC-6 et GCC-4 (pour ce dernier, je constate que le concept
Assignable n'est pas testé dans le code de for_each)
Avec une référence, tu ne peux plus utiliser l'operateur d'affectation par defaut, et donc sans code supplementaire le functor n'est plus Assignable (et je ne sais pas si c'est toujours un pré-requis pour le parametre de for_each, ca l'etait néanmoins dans la STL version SGI).
C'en est un. Même si c'est probable que ça marche quand même avec beaucoup d'implémentations.
Merci pour la verification. Et effectivement, ca marche quand meme avec xlC-6 et GCC-4 (pour ce dernier, je constate que le concept Assignable n'est pas testé dans le code de for_each)
kanze
Michel Decima wrote:
In news:, kanze typed:
Avec une référence, tu ne peux plus utiliser l'operateur d'affectation par defaut, et donc sans code supplementaire le functor n'est plus Assignable (et je ne sais pas si c'est toujours un pré-requis pour le parametre de for_each, ca l'etait néanmoins dans la STL version SGI).
C'en est un. Même si c'est probable que ça marche quand même avec beaucoup d'implémentations.
Merci pour la verification. Et effectivement, ca marche quand meme avec xlC-6 et GCC-4 (pour ce dernier, je constate que le concept Assignable n'est pas testé dans le code de for_each)
Alors, peut-être il n'en est pas un. Je n'arrive pas à trouver des pré-requis pour for_each où que ce soit ; je suppose qu'il doit être Copiable, parce qu'on le passe par copie, mais c'est tout. Dans le paragraphe « Effects », il dit « Applies f to the result of dereferencing the iterator ». Sans dire ce qu'il entend par « applies » ; je suppose cependant que ce qu'on veut, c'est que l'expression f(*iter) soit légale. Mais effectivement, je ne vois pas d'exigeance pour Assignable.
Ni pour les prédicats, d'ailleurs. Dans tous les cas, je déduis Copiable parce qu'ils sont passés par copie -- la norme n'en dit rien explicitement. (Mais il y a beaucoup de choses que ma copie de la norme -- C++98 quand même -- ni dit pas. Mais que le bon sens nous dit : l'objet fonctionnel dans for_each ne doit pas invalider les itérateurs, par exemple.)
Alors, j'ai toujours supposé que Assignable allait de pair avec CopyConstructable. Mais à régarder de plus près... CopyConstructible fait partie des pré-requis généraux, décris dans §20.1. Assignable est décrit dans §23.1 ; est-ce qu'on doit conclure qu'il ne s'applique que dans cette section, pour les éléments d'une collection ? Je rémarque aussi que les output iterators doivent être Assignable, mais les input iterators, pas forcément. Chose qui m'étonne, parce que j'aurais crû que les input interators et les output iterators suivaient la même règle ici (et c'est un concepte assez lache d'Assignable).
En fin de compte, je me rends compte que je ne sais pas quels sont les pré-requis pour Function dans for_each. Je dirais même qu'a priori, il n'y en a pas ; il n'y a que des restrictions déduites par le bon sens (Copiable, Callable avec un std::iterator_traits< Iter >::reference, n'invalide pas les itérateurs utilisés par for_each lui-même.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Michel Decima wrote:
In news:1141217549.541745.221070@u72g2000cwu.googlegroups.com,
kanze <kanze@gabi-soft.fr> typed:
Avec une référence, tu ne peux plus utiliser l'operateur
d'affectation par defaut, et donc sans code supplementaire
le functor n'est plus Assignable (et je ne sais pas si
c'est toujours un pré-requis pour le parametre de for_each,
ca l'etait néanmoins dans la STL version SGI).
C'en est un. Même si c'est probable que ça marche quand même
avec beaucoup d'implémentations.
Merci pour la verification. Et effectivement, ca marche quand
meme avec xlC-6 et GCC-4 (pour ce dernier, je constate que le
concept Assignable n'est pas testé dans le code de for_each)
Alors, peut-être il n'en est pas un. Je n'arrive pas à trouver
des pré-requis pour for_each où que ce soit ; je suppose qu'il
doit être Copiable, parce qu'on le passe par copie, mais c'est
tout. Dans le paragraphe « Effects », il dit « Applies f to the
result of dereferencing the iterator ». Sans dire ce qu'il
entend par « applies » ; je suppose cependant que ce qu'on veut,
c'est que l'expression f(*iter) soit légale. Mais effectivement,
je ne vois pas d'exigeance pour Assignable.
Ni pour les prédicats, d'ailleurs. Dans tous les cas, je déduis
Copiable parce qu'ils sont passés par copie -- la norme n'en dit
rien explicitement. (Mais il y a beaucoup de choses que ma
copie de la norme -- C++98 quand même -- ni dit pas. Mais que le
bon sens nous dit : l'objet fonctionnel dans for_each ne doit
pas invalider les itérateurs, par exemple.)
Alors, j'ai toujours supposé que Assignable allait de pair avec
CopyConstructable. Mais à régarder de plus près...
CopyConstructible fait partie des pré-requis généraux, décris
dans §20.1. Assignable est décrit dans §23.1 ; est-ce qu'on doit
conclure qu'il ne s'applique que dans cette section, pour les
éléments d'une collection ? Je rémarque aussi que les output
iterators doivent être Assignable, mais les input iterators, pas
forcément. Chose qui m'étonne, parce que j'aurais crû que les
input interators et les output iterators suivaient la même règle
ici (et c'est un concepte assez lache d'Assignable).
En fin de compte, je me rends compte que je ne sais pas quels
sont les pré-requis pour Function dans for_each. Je dirais même
qu'a priori, il n'y en a pas ; il n'y a que des restrictions
déduites par le bon sens (Copiable, Callable avec un
std::iterator_traits< Iter >::reference, n'invalide pas les
itérateurs utilisés par for_each lui-même.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avec une référence, tu ne peux plus utiliser l'operateur d'affectation par defaut, et donc sans code supplementaire le functor n'est plus Assignable (et je ne sais pas si c'est toujours un pré-requis pour le parametre de for_each, ca l'etait néanmoins dans la STL version SGI).
C'en est un. Même si c'est probable que ça marche quand même avec beaucoup d'implémentations.
Merci pour la verification. Et effectivement, ca marche quand meme avec xlC-6 et GCC-4 (pour ce dernier, je constate que le concept Assignable n'est pas testé dans le code de for_each)
Alors, peut-être il n'en est pas un. Je n'arrive pas à trouver des pré-requis pour for_each où que ce soit ; je suppose qu'il doit être Copiable, parce qu'on le passe par copie, mais c'est tout. Dans le paragraphe « Effects », il dit « Applies f to the result of dereferencing the iterator ». Sans dire ce qu'il entend par « applies » ; je suppose cependant que ce qu'on veut, c'est que l'expression f(*iter) soit légale. Mais effectivement, je ne vois pas d'exigeance pour Assignable.
Ni pour les prédicats, d'ailleurs. Dans tous les cas, je déduis Copiable parce qu'ils sont passés par copie -- la norme n'en dit rien explicitement. (Mais il y a beaucoup de choses que ma copie de la norme -- C++98 quand même -- ni dit pas. Mais que le bon sens nous dit : l'objet fonctionnel dans for_each ne doit pas invalider les itérateurs, par exemple.)
Alors, j'ai toujours supposé que Assignable allait de pair avec CopyConstructable. Mais à régarder de plus près... CopyConstructible fait partie des pré-requis généraux, décris dans §20.1. Assignable est décrit dans §23.1 ; est-ce qu'on doit conclure qu'il ne s'applique que dans cette section, pour les éléments d'une collection ? Je rémarque aussi que les output iterators doivent être Assignable, mais les input iterators, pas forcément. Chose qui m'étonne, parce que j'aurais crû que les input interators et les output iterators suivaient la même règle ici (et c'est un concepte assez lache d'Assignable).
En fin de compte, je me rends compte que je ne sais pas quels sont les pré-requis pour Function dans for_each. Je dirais même qu'a priori, il n'y en a pas ; il n'y a que des restrictions déduites par le bon sens (Copiable, Callable avec un std::iterator_traits< Iter >::reference, n'invalide pas les itérateurs utilisés par for_each lui-même.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Michel Decima
In news:, kanze typed:
Michel Decima wrote:
In news:, kanze typed:
En fin de compte, je me rends compte que je ne sais pas quels sont les pré-requis pour Function dans for_each. Je dirais même qu'a priori, il n'y en a pas ; il n'y a que des restrictions déduites par le bon sens (Copiable, Callable avec un std::iterator_traits< Iter >::reference, n'invalide pas les itérateurs utilisés par for_each lui-même.)
La doc SGI ne dit pas explicitement que le Function de for_each doit etre Assignable, en revanche elle dit qu'il doit etre un modele de UnaryFunction, lequel est un raffinement de Assignable (qui regroupe constructeur de copie, operator=, et swap). C'est peut etre un peu excessif comme exigences dans le cas de for_each, mais c'est comprehensible si on considere les predicats des containers, qui doivent forcement etre Assignable.
Une question sans rapport avec for_each: j'ai eu besoin hier de l'equivalent de copy_n, qui est present chez SGI mais pas dans la norme (chez GCC, c'est une extension). Est ce qu'il y a une raison qui explique pourquoi copy_n n'a pas été repris dans la norme, alors que fill_n l'a été par exemple ?
MD.
In news:1141289043.789158.269710@t39g2000cwt.googlegroups.com,
kanze <kanze@gabi-soft.fr> typed:
Michel Decima wrote:
In news:1141217549.541745.221070@u72g2000cwu.googlegroups.com,
kanze <kanze@gabi-soft.fr> typed:
En fin de compte, je me rends compte que je ne sais pas quels
sont les pré-requis pour Function dans for_each. Je dirais même
qu'a priori, il n'y en a pas ; il n'y a que des restrictions
déduites par le bon sens (Copiable, Callable avec un
std::iterator_traits< Iter >::reference, n'invalide pas les
itérateurs utilisés par for_each lui-même.)
La doc SGI ne dit pas explicitement que le Function de for_each doit etre
Assignable,
en revanche elle dit qu'il doit etre un modele de UnaryFunction, lequel est
un raffinement
de Assignable (qui regroupe constructeur de copie, operator=, et swap).
C'est peut etre
un peu excessif comme exigences dans le cas de for_each, mais c'est
comprehensible
si on considere les predicats des containers, qui doivent forcement etre
Assignable.
Une question sans rapport avec for_each: j'ai eu besoin hier de l'equivalent
de copy_n,
qui est present chez SGI mais pas dans la norme (chez GCC, c'est une
extension).
Est ce qu'il y a une raison qui explique pourquoi copy_n n'a pas été repris
dans la norme,
alors que fill_n l'a été par exemple ?
En fin de compte, je me rends compte que je ne sais pas quels sont les pré-requis pour Function dans for_each. Je dirais même qu'a priori, il n'y en a pas ; il n'y a que des restrictions déduites par le bon sens (Copiable, Callable avec un std::iterator_traits< Iter >::reference, n'invalide pas les itérateurs utilisés par for_each lui-même.)
La doc SGI ne dit pas explicitement que le Function de for_each doit etre Assignable, en revanche elle dit qu'il doit etre un modele de UnaryFunction, lequel est un raffinement de Assignable (qui regroupe constructeur de copie, operator=, et swap). C'est peut etre un peu excessif comme exigences dans le cas de for_each, mais c'est comprehensible si on considere les predicats des containers, qui doivent forcement etre Assignable.
Une question sans rapport avec for_each: j'ai eu besoin hier de l'equivalent de copy_n, qui est present chez SGI mais pas dans la norme (chez GCC, c'est une extension). Est ce qu'il y a une raison qui explique pourquoi copy_n n'a pas été repris dans la norme, alors que fill_n l'a été par exemple ?
MD.
Gabriel Dos Reis
"Michel Decima" writes:
[...]
| Une question sans rapport avec for_each: j'ai eu besoin hier de l'equivalent | de copy_n, | qui est present chez SGI mais pas dans la norme (chez GCC, c'est une | extension). | Est ce qu'il y a une raison qui explique pourquoi copy_n n'a pas été repris | dans la norme, | alors que fill_n l'a été par exemple ?
Lorsque la STL a été présentée au comité (circa Janvier 1994), celui-ci l'a trouvée très excitante mais aussi assez large (et donc certains émettaient des réserves). Il a donc fallu qu'un volontaire designé coupe quelque chose comme les 2/3 et le tri n'a pas toujours été cohérent ou systématique. Alex confessera plus tard que cela lui a brisé le coeur...
| Une question sans rapport avec for_each: j'ai eu besoin hier de l'equivalent
| de copy_n,
| qui est present chez SGI mais pas dans la norme (chez GCC, c'est une
| extension).
| Est ce qu'il y a une raison qui explique pourquoi copy_n n'a pas été repris
| dans la norme,
| alors que fill_n l'a été par exemple ?
Lorsque la STL a été présentée au comité (circa Janvier 1994),
celui-ci l'a trouvée très excitante mais aussi assez large (et donc
certains émettaient des réserves). Il a donc fallu qu'un volontaire
designé coupe quelque chose comme les 2/3 et le tri n'a pas toujours
été cohérent ou systématique. Alex confessera plus tard que cela lui
a brisé le coeur...
| Une question sans rapport avec for_each: j'ai eu besoin hier de l'equivalent | de copy_n, | qui est present chez SGI mais pas dans la norme (chez GCC, c'est une | extension). | Est ce qu'il y a une raison qui explique pourquoi copy_n n'a pas été repris | dans la norme, | alors que fill_n l'a été par exemple ?
Lorsque la STL a été présentée au comité (circa Janvier 1994), celui-ci l'a trouvée très excitante mais aussi assez large (et donc certains émettaient des réserves). Il a donc fallu qu'un volontaire designé coupe quelque chose comme les 2/3 et le tri n'a pas toujours été cohérent ou systématique. Alex confessera plus tard que cela lui a brisé le coeur...
