Dans une boucle for avec size_type, la déclaration de la variable de
contrôle prend en effet beaucoup de place et presque toute la place !
Dans la pratique James, tu écris quoi ?
Dans une boucle for avec size_type, la déclaration de la variable de
contrôle prend en effet beaucoup de place et presque toute la place !
Dans la pratique James, tu écris quoi ?
Dans une boucle for avec size_type, la déclaration de la variable de
contrôle prend en effet beaucoup de place et presque toute la place !
Dans la pratique James, tu écris quoi ?
writes:
| Gabriel Dos Reis wrote in message
| news:...
| > "Michel Michaud" writes:
| > | Il me semble que James a déjà démontré par des articles de la
| > | norme, que vector<>::size_type ne peut pas être différent de
| > | size_t. Je me trompe ?
| > Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
| > unsigned int, même si size_t est un unsigned long.
| Moi non plus. En fait, il y a deux questions : dans le cas général,
| il me semble clair -- rien n'empêche d'écrire un allocateur avec un
| size_type char, si cela t'enchante. En revanche, la norme exige bien
| que le size_type de l'allocateur standard soit size_t. Reste la
| question si le size_type de std::vector doit être identique au
| size_type de son allocateur. Logiquement, je m'attendrais que si,
| mais je ne suis pas sûr que la norme l'exige.
La norme ne l'exige pas. Tout ce qu'elle dit c'est que c'est un
unsigned
qui peut représenter les valeurs positives de
vector<>::difference_type -- qui lui même mesure la distance algébrique
entre deux itérateurs sur un vecteur, et un vector<T*>::iterator n'est
pas obligé à être un T*. Si on veut ête minimaliste, on peut dire que
c'est un type entier qui peut représenter
vector<>::allocator_type::max_size() / sizeof (T).
Dans la pratique, je ne sais pas s'il y a beaucoup d'implémentations
qui se compliquent la vie avec ce minimalisme.
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote in message
| news:<m3k73dbyoc.fsf@merlin.cs.tamu.edu>...
| > "Michel Michaud" <mm@gdzid.com> writes:
| > | Il me semble que James a déjà démontré par des articles de la
| > | norme, que vector<>::size_type ne peut pas être différent de
| > | size_t. Je me trompe ?
| > Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
| > unsigned int, même si size_t est un unsigned long.
| Moi non plus. En fait, il y a deux questions : dans le cas général,
| il me semble clair -- rien n'empêche d'écrire un allocateur avec un
| size_type char, si cela t'enchante. En revanche, la norme exige bien
| que le size_type de l'allocateur standard soit size_t. Reste la
| question si le size_type de std::vector doit être identique au
| size_type de son allocateur. Logiquement, je m'attendrais que si,
| mais je ne suis pas sûr que la norme l'exige.
La norme ne l'exige pas. Tout ce qu'elle dit c'est que c'est un
unsigned
qui peut représenter les valeurs positives de
vector<>::difference_type -- qui lui même mesure la distance algébrique
entre deux itérateurs sur un vecteur, et un vector<T*>::iterator n'est
pas obligé à être un T*. Si on veut ête minimaliste, on peut dire que
c'est un type entier qui peut représenter
vector<>::allocator_type::max_size() / sizeof (T).
Dans la pratique, je ne sais pas s'il y a beaucoup d'implémentations
qui se compliquent la vie avec ce minimalisme.
writes:
| Gabriel Dos Reis wrote in message
| news:...
| > "Michel Michaud" writes:
| > | Il me semble que James a déjà démontré par des articles de la
| > | norme, que vector<>::size_type ne peut pas être différent de
| > | size_t. Je me trompe ?
| > Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
| > unsigned int, même si size_t est un unsigned long.
| Moi non plus. En fait, il y a deux questions : dans le cas général,
| il me semble clair -- rien n'empêche d'écrire un allocateur avec un
| size_type char, si cela t'enchante. En revanche, la norme exige bien
| que le size_type de l'allocateur standard soit size_t. Reste la
| question si le size_type de std::vector doit être identique au
| size_type de son allocateur. Logiquement, je m'attendrais que si,
| mais je ne suis pas sûr que la norme l'exige.
La norme ne l'exige pas. Tout ce qu'elle dit c'est que c'est un
unsigned
qui peut représenter les valeurs positives de
vector<>::difference_type -- qui lui même mesure la distance algébrique
entre deux itérateurs sur un vecteur, et un vector<T*>::iterator n'est
pas obligé à être un T*. Si on veut ête minimaliste, on peut dire que
c'est un type entier qui peut représenter
vector<>::allocator_type::max_size() / sizeof (T).
Dans la pratique, je ne sais pas s'il y a beaucoup d'implémentations
qui se compliquent la vie avec ce minimalisme.
Avant qu'il deviennent « mûrs », ils utilises « vector » -- sans
qualification.
| Tu ne m'as pas dit explicitement de quel type tu déclares les
| indices (je suppose que c'est int...).
for (int i = 0; i < N; ++i)
v[i] = xxxx;
Il est cohérent avec ce qu'il écrit dans son bouquin :-)
Avant qu'il deviennent « mûrs », ils utilises « vector » -- sans
qualification.
| Tu ne m'as pas dit explicitement de quel type tu déclares les
| indices (je suppose que c'est int...).
for (int i = 0; i < N; ++i)
v[i] = xxxx;
Il est cohérent avec ce qu'il écrit dans son bouquin :-)
Avant qu'il deviennent « mûrs », ils utilises « vector » -- sans
qualification.
| Tu ne m'as pas dit explicitement de quel type tu déclares les
| indices (je suppose que c'est int...).
for (int i = 0; i < N; ++i)
v[i] = xxxx;
Il est cohérent avec ce qu'il écrit dans son bouquin :-)
for (int i = 0; i < N; ++i)
v[i] = xxxx;
for (int i = 0; i < N; ++i)
v[i] = xxxx;
for (int i = 0; i < N; ++i)
v[i] = xxxx;
Yep.
template<class T, class A = std::allocator<T> >
struct vector : std::vector<T, A> {
// forwarding constructors
// define operator[] to do the "right thing"
};
C'est vrai. Si tu regardes bien, il utilise les iterator là où cela
devient non trivial. En fait, si tu adhères à la religion que tes
fonctions ne devraient pas faire plus d'une quizaine de lignes, il est
fréquent que la plupart des structures de contrôle s'expriment en
terme d'itérateurs.
Yep.
template<class T, class A = std::allocator<T> >
struct vector : std::vector<T, A> {
// forwarding constructors
// define operator[] to do the "right thing"
};
C'est vrai. Si tu regardes bien, il utilise les iterator là où cela
devient non trivial. En fait, si tu adhères à la religion que tes
fonctions ne devraient pas faire plus d'une quizaine de lignes, il est
fréquent que la plupart des structures de contrôle s'expriment en
terme d'itérateurs.
Yep.
template<class T, class A = std::allocator<T> >
struct vector : std::vector<T, A> {
// forwarding constructors
// define operator[] to do the "right thing"
};
C'est vrai. Si tu regardes bien, il utilise les iterator là où cela
devient non trivial. En fait, si tu adhères à la religion que tes
fonctions ne devraient pas faire plus d'une quizaine de lignes, il est
fréquent que la plupart des structures de contrôle s'expriment en
terme d'itérateurs.
Samuel Krempp writes:
| le Thursday 29 January 2004 00:42, écrivit :
|
| > Yep.
| >
| > template<class T, class A = std::allocator<T> >
| > struct vector : std::vector<T, A> {
| > // forwarding constructors
| > // define operator[] to do the "right thing"
| > };
|
| ca apporte qque chose d'hériter plutot que d'aggreger ?
Je poserais plutôt la question dans l'autre sens.
Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> writes:
| le Thursday 29 January 2004 00:42, gdr@cs.tamu.edu écrivit :
|
| > Yep.
| >
| > template<class T, class A = std::allocator<T> >
| > struct vector : std::vector<T, A> {
| > // forwarding constructors
| > // define operator[] to do the "right thing"
| > };
|
| ca apporte qque chose d'hériter plutot que d'aggreger ?
Je poserais plutôt la question dans l'autre sens.
Samuel Krempp writes:
| le Thursday 29 January 2004 00:42, écrivit :
|
| > Yep.
| >
| > template<class T, class A = std::allocator<T> >
| > struct vector : std::vector<T, A> {
| > // forwarding constructors
| > // define operator[] to do the "right thing"
| > };
|
| ca apporte qque chose d'hériter plutot que d'aggreger ?
Je poserais plutôt la question dans l'autre sens.
