Si je n'ajuste pas reference, il reste vide. Dans un exemple plus
complexe, j'ai du segfault: avec des shared_ptr, swap tente d'échanger
le pointeur courant avec le pointeur courant d'un emplacement mémoire
qui n'est pas un shared_ptr.
Je comprends que std::transform ne redimensionne pas mon std::vector
de destination. La raison est-elle qu'on paye pour ce qu'on utilises ?
Au plaisir de vous lire.
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Comment le pourrait-il ? Tu ne lui passes pas le vector en question, mais juste un itérateur.
Justement, c'est un truc que je ne comprends toujours pas. Comment un itérateur peut à la fois référencer un conteneur et ne pas y avoir accès ?
Dans l'implémentation, un itérateur doit bien conserver des références vers le conteneur. Rien que pour pouvoir progresser dans la collection. Du coup, à l'instar d'un pointeur habile, il pourrait fournir une fonction membre vers le conteneur itéré ? Ou encore une fois c'est une question de découplage ?
Comment le pourrait-il ? Tu ne lui passes pas le vector en question,
mais juste un itérateur.
Justement, c'est un truc que je ne comprends toujours pas. Comment un
itérateur peut à la fois référencer un conteneur et ne pas y avoir accès ?
Dans l'implémentation, un itérateur doit bien conserver des
références vers le conteneur. Rien que pour pouvoir progresser dans la
collection. Du coup, à l'instar d'un pointeur habile, il pourrait
fournir une fonction membre vers le conteneur itéré ? Ou encore une fois
c'est une question de découplage ?
Comment le pourrait-il ? Tu ne lui passes pas le vector en question, mais juste un itérateur.
Justement, c'est un truc que je ne comprends toujours pas. Comment un itérateur peut à la fois référencer un conteneur et ne pas y avoir accès ?
Dans l'implémentation, un itérateur doit bien conserver des références vers le conteneur. Rien que pour pouvoir progresser dans la collection. Du coup, à l'instar d'un pointeur habile, il pourrait fournir une fonction membre vers le conteneur itéré ? Ou encore une fois c'est une question de découplage ?
En fait, j'ai trouvé cette réponse quelques minutes après avoir posé la question dans le bouquin (Effective STL, Scott Meyers) que je lis (et qui m'a mené à l'observation de std::transform). Mais ça ne répondait toujours pas à mon interrogation profonde.
| Je comprends que std::transform ne redimensionne pas mon std::vector | de destination. La raison est-elle qu'on paye pour ce qu'on utilises ?
Orthogonalité. La fonction de transform, c'est de transformer les éléments de la suite, pas de changer la taille de la destination.
Ok, c'est ce que je pensais : un problème de responsabilité. Bon, ben c'est le memcpy du C++ :)
En fait, j'ai trouvé cette réponse quelques minutes après avoir posé
la question dans le bouquin (Effective STL, Scott Meyers) que je lis (et
qui m'a mené à l'observation de std::transform). Mais ça ne répondait
toujours pas à mon interrogation profonde.
| Je comprends que std::transform ne redimensionne pas mon std::vector
| de destination. La raison est-elle qu'on paye pour ce qu'on utilises ?
Orthogonalité.
La fonction de transform, c'est de transformer les éléments de la suite,
pas de changer la taille de la destination.
Ok, c'est ce que je pensais : un problème de responsabilité. Bon, ben
c'est le memcpy du C++ :)
En fait, j'ai trouvé cette réponse quelques minutes après avoir posé la question dans le bouquin (Effective STL, Scott Meyers) que je lis (et qui m'a mené à l'observation de std::transform). Mais ça ne répondait toujours pas à mon interrogation profonde.
| Je comprends que std::transform ne redimensionne pas mon std::vector | de destination. La raison est-elle qu'on paye pour ce qu'on utilises ?
Orthogonalité. La fonction de transform, c'est de transformer les éléments de la suite, pas de changer la taille de la destination.
Ok, c'est ce que je pensais : un problème de responsabilité. Bon, ben c'est le memcpy du C++ :)
Comment le pourrait-il ? Tu ne lui passes pas le vector en question, mais juste un itérateur.
Justement, c'est un truc que je ne comprends toujours pas. Comment un itérateur peut à la fois référencer un conteneur et ne pas y avoir accès ?
Un iterator référence un élément du conteneur, pas le conteneur lui-même. Tu connais bien C si je ne m'abuse, ça ne te rappelle rien ?
Dans l'implémentation, un itérateur doit bien conserver des références vers le conteneur.
Ha bon ? Pourquoi ?
Rien que pour pouvoir progresser dans la collection.
Un pointeur a-t-il besoin de référencer le tableau contenant l'élément pointé pour progresser dans ce tableau ?
Du coup, à l'instar d'un pointeur habile, il pourrait fournir une fonction membre vers le conteneur itéré ?
Ca, c'est un pointeur très habile !
Ou encore une fois c'est une question de découplage ?
Comme pour un pointeur. La sémantique est d'ailleurs étrangement proche, non ? Itérateur ou pointeur, on dirait parfois le même objet, mais déclaré différemment...
-- Alex
On 08/08/2010 08:43 PM, Mickaël Wolff wrote:
Le 08/08/2010 06:38, Fabien LE LEZ a écrit :
Comment le pourrait-il ? Tu ne lui passes pas le vector en question,
mais juste un itérateur.
Justement, c'est un truc que je ne comprends toujours pas. Comment un
itérateur peut à la fois référencer un conteneur et ne pas y avoir accès ?
Un iterator référence un élément du conteneur, pas le conteneur
lui-même. Tu connais bien C si je ne m'abuse, ça ne te rappelle rien ?
Dans l'implémentation, un itérateur doit bien conserver des références
vers le conteneur.
Ha bon ? Pourquoi ?
Rien que pour pouvoir progresser dans la collection.
Un pointeur a-t-il besoin de référencer le tableau contenant l'élément
pointé pour progresser dans ce tableau ?
Du coup, à l'instar d'un pointeur habile, il pourrait fournir une
fonction membre vers le conteneur itéré ?
Ca, c'est un pointeur très habile !
Ou encore une fois c'est une question de découplage ?
Comme pour un pointeur. La sémantique est d'ailleurs étrangement proche,
non ? Itérateur ou pointeur, on dirait parfois le même objet, mais
déclaré différemment...
Comment le pourrait-il ? Tu ne lui passes pas le vector en question, mais juste un itérateur.
Justement, c'est un truc que je ne comprends toujours pas. Comment un itérateur peut à la fois référencer un conteneur et ne pas y avoir accès ?
Un iterator référence un élément du conteneur, pas le conteneur lui-même. Tu connais bien C si je ne m'abuse, ça ne te rappelle rien ?
Dans l'implémentation, un itérateur doit bien conserver des références vers le conteneur.
Ha bon ? Pourquoi ?
Rien que pour pouvoir progresser dans la collection.
Un pointeur a-t-il besoin de référencer le tableau contenant l'élément pointé pour progresser dans ce tableau ?
Du coup, à l'instar d'un pointeur habile, il pourrait fournir une fonction membre vers le conteneur itéré ?
Ca, c'est un pointeur très habile !
Ou encore une fois c'est une question de découplage ?
Comme pour un pointeur. La sémantique est d'ailleurs étrangement proche, non ? Itérateur ou pointeur, on dirait parfois le même objet, mais déclaré différemment...
Un iterator référence un élément du conteneur, pas le conteneur lui-même. Tu connais bien C si je ne m'abuse, ça ne te rappelle rien ?
Justement, les itérateurs ne sont pas des pointeurs. Sauf dans les cas particuliers de std::vector et std::string.
Dans l'implémentation, un itérateur doit bien conserver des références vers le conteneur.
Ha bon ? Pourquoi ?
En effet, en y réfléchissant, il n'y pas besoin. Si l'itérateur garde une référence vers la structure enveloppant la valeur, on a pas besoin de référencer le conteneur. Puisqu'on a accès au suivant ou précédent (selon le type d'élément). Du coup ça m'explique même pourquoi conteneur ne fournit pas forcément un itérateur à accès aléatoire.
Rien que pour pouvoir progresser dans la collection.
Un pointeur a-t-il besoin de référencer le tableau contenant l'élément pointé pour progresser dans ce tableau ?
Un pointeur sur un tableau référence une zone de mémoire contigüe sur laquelle ont peut appliquer l'algèbre sur les pointeurs. Un itérateur est un objet qui référence un objet dans une collection. Et une collection n'est pas forcément contigüe.
Ou encore une fois c'est une question de découplage ?
Comme pour un pointeur. La sémantique est d'ailleurs étrangement proche, non ? Itérateur ou pointeur, on dirait parfois le même objet, mais déclaré différemment...
Un iterator référence un élément du conteneur, pas le conteneur
lui-même. Tu connais bien C si je ne m'abuse, ça ne te rappelle rien ?
Justement, les itérateurs ne sont pas des pointeurs. Sauf dans les
cas particuliers de std::vector et std::string.
Dans l'implémentation, un itérateur doit bien conserver des références
vers le conteneur.
Ha bon ? Pourquoi ?
En effet, en y réfléchissant, il n'y pas besoin. Si l'itérateur garde
une référence vers la structure enveloppant la valeur, on a pas besoin
de référencer le conteneur. Puisqu'on a accès au suivant ou précédent
(selon le type d'élément). Du coup ça m'explique même pourquoi conteneur
ne fournit pas forcément un itérateur à accès aléatoire.
Rien que pour pouvoir progresser dans la collection.
Un pointeur a-t-il besoin de référencer le tableau contenant l'élément
pointé pour progresser dans ce tableau ?
Un pointeur sur un tableau référence une zone de mémoire contigüe sur
laquelle ont peut appliquer l'algèbre sur les pointeurs. Un itérateur
est un objet qui référence un objet dans une collection. Et une
collection n'est pas forcément contigüe.
Ou encore une fois c'est une question de découplage ?
Comme pour un pointeur. La sémantique est d'ailleurs étrangement proche,
non ? Itérateur ou pointeur, on dirait parfois le même objet, mais
déclaré différemment...
Un iterator référence un élément du conteneur, pas le conteneur lui-même. Tu connais bien C si je ne m'abuse, ça ne te rappelle rien ?
Justement, les itérateurs ne sont pas des pointeurs. Sauf dans les cas particuliers de std::vector et std::string.
Dans l'implémentation, un itérateur doit bien conserver des références vers le conteneur.
Ha bon ? Pourquoi ?
En effet, en y réfléchissant, il n'y pas besoin. Si l'itérateur garde une référence vers la structure enveloppant la valeur, on a pas besoin de référencer le conteneur. Puisqu'on a accès au suivant ou précédent (selon le type d'élément). Du coup ça m'explique même pourquoi conteneur ne fournit pas forcément un itérateur à accès aléatoire.
Rien que pour pouvoir progresser dans la collection.
Un pointeur a-t-il besoin de référencer le tableau contenant l'élément pointé pour progresser dans ce tableau ?
Un pointeur sur un tableau référence une zone de mémoire contigüe sur laquelle ont peut appliquer l'algèbre sur les pointeurs. Un itérateur est un objet qui référence un objet dans une collection. Et une collection n'est pas forcément contigüe.
Ou encore une fois c'est une question de découplage ?
Comme pour un pointeur. La sémantique est d'ailleurs étrangement proche, non ? Itérateur ou pointeur, on dirait parfois le même objet, mais déclaré différemment...