je fait une collection d'article (std::vector<TArticle *> _pCoArt;)
le probleme quand je supprime un article ou quand il est le dernier et
que je veuille en ajouter un autre j'ai une violation d'acces
voici le code de la suppression :
bool __fastcall TCoArticles::DeleteArticle(TArticle& Art)
{//@CODE_347
bool bResúlse;
if(int max =Count()>0){
int i=0;
if(SearchArticle(Art,i)){
TArticle *_pArt=_pCoArt.at(i);
if(i==max || max==1){
_pCoArt.push_back();
}else{
_pCoArt.erase(&_pArt);
}
delete _pArt;
bRes=true;
}
}else{
TMyError Err(7,"Collection d'article est vide");
throw Err;
}
return bRes;
}//@CODE_347
le code SearchArticle
bool __fastcall TCoArticles::SearchArticle(TArticle& Art, int& i)
{//@CODE_357
bool bResúlse;
std::vector<TArticle*>::iterator i_end =_pCoArt.end();
int j=0;
for(std::vector<TArticle*>::iterator it=_pCoArt.begin();it!=i_end;++it){
if((*it)->NomArt==Art.NomArt && (*it)->Description==Art.Description &&
(*it)->Categorie==Art.Categorie && (*it)->Prix==Art.Prix){
i=j;
bRes=true;
break;
}
j++;
}
return bRes;
}//@CODE_357
ou est mon erreur ?
je fait une collection d'article (std::vector<TArticle *> _pCoArt;)
le probleme quand je supprime un article ou quand il est le dernier et
que je veuille en ajouter un autre j'ai une violation d'acces
voici le code de la suppression :
bool __fastcall TCoArticles::DeleteArticle(TArticle& Art)
{//@CODE_347
bool bResúlse;
if(int max =Count()>0){
int i=0;
if(SearchArticle(Art,i)){
TArticle *_pArt=_pCoArt.at(i);
if(i==max || max==1){
_pCoArt.push_back();
}else{
_pCoArt.erase(&_pArt);
}
delete _pArt;
bRes=true;
}
}else{
TMyError Err(7,"Collection d'article est vide");
throw Err;
}
return bRes;
}//@CODE_347
le code SearchArticle
bool __fastcall TCoArticles::SearchArticle(TArticle& Art, int& i)
{//@CODE_357
bool bResúlse;
std::vector<TArticle*>::iterator i_end =_pCoArt.end();
int j=0;
for(std::vector<TArticle*>::iterator it=_pCoArt.begin();it!=i_end;++it){
if((*it)->NomArt==Art.NomArt && (*it)->Description==Art.Description &&
(*it)->Categorie==Art.Categorie && (*it)->Prix==Art.Prix){
i=j;
bRes=true;
break;
}
j++;
}
return bRes;
}//@CODE_357
ou est mon erreur ?
je fait une collection d'article (std::vector<TArticle *> _pCoArt;)
le probleme quand je supprime un article ou quand il est le dernier et
que je veuille en ajouter un autre j'ai une violation d'acces
voici le code de la suppression :
bool __fastcall TCoArticles::DeleteArticle(TArticle& Art)
{//@CODE_347
bool bResúlse;
if(int max =Count()>0){
int i=0;
if(SearchArticle(Art,i)){
TArticle *_pArt=_pCoArt.at(i);
if(i==max || max==1){
_pCoArt.push_back();
}else{
_pCoArt.erase(&_pArt);
}
delete _pArt;
bRes=true;
}
}else{
TMyError Err(7,"Collection d'article est vide");
throw Err;
}
return bRes;
}//@CODE_347
le code SearchArticle
bool __fastcall TCoArticles::SearchArticle(TArticle& Art, int& i)
{//@CODE_357
bool bResúlse;
std::vector<TArticle*>::iterator i_end =_pCoArt.end();
int j=0;
for(std::vector<TArticle*>::iterator it=_pCoArt.begin();it!=i_end;++it){
if((*it)->NomArt==Art.NomArt && (*it)->Description==Art.Description &&
(*it)->Categorie==Art.Categorie && (*it)->Prix==Art.Prix){
i=j;
bRes=true;
break;
}
j++;
}
return bRes;
}//@CODE_357
ou est mon erreur ?
On Mon, 28 Jul 2003 15:10:09 +0200, Luc Hermitte
wrote:Hum ... pas d'accord. Si la classe est complexe, avec plein de
champs, sans constructeur sans arguments, opérateurs de recopie et
autres moyens de vérifier que l'objet manipulé est bien valide ... je
fais comme lui.
Etant donné que l'op parlait d'une collection d'articles et pas de
pointeurs, et étant donné son niveau présumé (d'après son post),
j'estime que la question "Es-tu bien sûr que c'est ce que tu veux ?"
est légitime.
On Mon, 28 Jul 2003 15:10:09 +0200, Luc Hermitte
<hermitte@free.fr.invalid> wrote:
Hum ... pas d'accord. Si la classe est complexe, avec plein de
champs, sans constructeur sans arguments, opérateurs de recopie et
autres moyens de vérifier que l'objet manipulé est bien valide ... je
fais comme lui.
Etant donné que l'op parlait d'une collection d'articles et pas de
pointeurs, et étant donné son niveau présumé (d'après son post),
j'estime que la question "Es-tu bien sûr que c'est ce que tu veux ?"
est légitime.
On Mon, 28 Jul 2003 15:10:09 +0200, Luc Hermitte
wrote:Hum ... pas d'accord. Si la classe est complexe, avec plein de
champs, sans constructeur sans arguments, opérateurs de recopie et
autres moyens de vérifier que l'objet manipulé est bien valide ... je
fais comme lui.
Etant donné que l'op parlait d'une collection d'articles et pas de
pointeurs, et étant donné son niveau présumé (d'après son post),
j'estime que la question "Es-tu bien sûr que c'est ce que tu veux ?"
est légitime.
On Mon, 28 Jul 2003 15:10:09 +0200, Luc Hermitte
wrote:Hum ... pas d'accord. Si la classe est complexe, avec plein de
champs, sans constructeur sans arguments, opérateurs de recopie et
autres moyens de vérifier que l'objet manipulé est bien valide ... je
fais comme lui.
Etant donné que l'op parlait d'une collection d'articles et pas de
pointeurs, et étant donné son niveau présumé (d'après son post),
j'estime que la question "Es-tu bien sûr que c'est ce que tu veux ?"
est légitime.Personnellement, j'utilise plus souvent des collections de pointeurs
que des collections de classes.
Qu'entends-tu par "utiliser plus souvent" ? Généralement, dans mes
programmes, j'ai très peu de collections de pointeurs (et la plupart
du temps il s'agit de pointeurs qui se "deletent" eux-mêmes) et
beaucoup de collections d'objets, mais comme les quelques collections
de pointeurs ont un rôle fondamentale (par exemple, l'ensemble des
fenêtres et sous-fenêtres de mon application est une collection de
pointeurs en forme d'arbre, et la quasi-totalité du code est dans ses
fonctions membres), on pourrait aussi dire que "j'utilise plus souvent
des collections de pointeurs" ;-)
On Mon, 28 Jul 2003 15:10:09 +0200, Luc Hermitte
<hermitte@free.fr.invalid> wrote:
Hum ... pas d'accord. Si la classe est complexe, avec plein de
champs, sans constructeur sans arguments, opérateurs de recopie et
autres moyens de vérifier que l'objet manipulé est bien valide ... je
fais comme lui.
Etant donné que l'op parlait d'une collection d'articles et pas de
pointeurs, et étant donné son niveau présumé (d'après son post),
j'estime que la question "Es-tu bien sûr que c'est ce que tu veux ?"
est légitime.
Personnellement, j'utilise plus souvent des collections de pointeurs
que des collections de classes.
Qu'entends-tu par "utiliser plus souvent" ? Généralement, dans mes
programmes, j'ai très peu de collections de pointeurs (et la plupart
du temps il s'agit de pointeurs qui se "deletent" eux-mêmes) et
beaucoup de collections d'objets, mais comme les quelques collections
de pointeurs ont un rôle fondamentale (par exemple, l'ensemble des
fenêtres et sous-fenêtres de mon application est une collection de
pointeurs en forme d'arbre, et la quasi-totalité du code est dans ses
fonctions membres), on pourrait aussi dire que "j'utilise plus souvent
des collections de pointeurs" ;-)
On Mon, 28 Jul 2003 15:10:09 +0200, Luc Hermitte
wrote:Hum ... pas d'accord. Si la classe est complexe, avec plein de
champs, sans constructeur sans arguments, opérateurs de recopie et
autres moyens de vérifier que l'objet manipulé est bien valide ... je
fais comme lui.
Etant donné que l'op parlait d'une collection d'articles et pas de
pointeurs, et étant donné son niveau présumé (d'après son post),
j'estime que la question "Es-tu bien sûr que c'est ce que tu veux ?"
est légitime.Personnellement, j'utilise plus souvent des collections de pointeurs
que des collections de classes.
Qu'entends-tu par "utiliser plus souvent" ? Généralement, dans mes
programmes, j'ai très peu de collections de pointeurs (et la plupart
du temps il s'agit de pointeurs qui se "deletent" eux-mêmes) et
beaucoup de collections d'objets, mais comme les quelques collections
de pointeurs ont un rôle fondamentale (par exemple, l'ensemble des
fenêtres et sous-fenêtres de mon application est une collection de
pointeurs en forme d'arbre, et la quasi-totalité du code est dans ses
fonctions membres), on pourrait aussi dire que "j'utilise plus souvent
des collections de pointeurs" ;-)
En revanche, je le trouve un peu curieux que personne n'a signalé
l'erreur fatale qu'il a fait -- le fait d'utiliser l'adresse d'une
variable locale comme itérateur dans un vector.
En revanche, je le trouve un peu curieux que personne n'a signalé
l'erreur fatale qu'il a fait -- le fait d'utiliser l'adresse d'une
variable locale comme itérateur dans un vector.
En revanche, je le trouve un peu curieux que personne n'a signalé
l'erreur fatale qu'il a fait -- le fait d'utiliser l'adresse d'une
variable locale comme itérateur dans un vector.
Et si j'ai un std::map< std::string, Class* >, est-ce une collection des
valeurs, ou une collection de pointeurs ?
Et si j'ai un std::map< std::string, Class* >, est-ce une collection des
valeurs, ou une collection de pointeurs ?
Et si j'ai un std::map< std::string, Class* >, est-ce une collection des
valeurs, ou une collection de pointeurs ?
writes:
| Je n'avais jamais considéré ce genre d'erreur, mais à mon avis,
| c'est encore un bon argument pour l'utilisation des classes comme
| itérateurs, et non des pointeurs.
Quelqu'un vient juste de proposer sur la liste de libstdc++-v3 qu'on
en revienne aux pointeurs bruts.
kanze@gabi-soft.fr writes:
| Je n'avais jamais considéré ce genre d'erreur, mais à mon avis,
| c'est encore un bon argument pour l'utilisation des classes comme
| itérateurs, et non des pointeurs.
Quelqu'un vient juste de proposer sur la liste de libstdc++-v3 qu'on
en revienne aux pointeurs bruts.
writes:
| Je n'avais jamais considéré ce genre d'erreur, mais à mon avis,
| c'est encore un bon argument pour l'utilisation des classes comme
| itérateurs, et non des pointeurs.
Quelqu'un vient juste de proposer sur la liste de libstdc++-v3 qu'on
en revienne aux pointeurs bruts.
je m'explique je voulais recherche "a la main" les object presents
dans la collection par le biais d'une boucle
la logique de suppresion en "pseudo" est
debut
entiet i=0
si objet[i] trouve alors file://searcharticle
si on est sur le prmier de la collection ou le dernier de la
collection alors
file://pop_back
sinon
supprimer l'article[i]
fin si
fin si
fin
Cepandant cette methode fait partie d'une classe
si je fais une surchage d'operateur tout mes autre operateur = dans
les autre fonction vont etre surcharge non ?
comment faire pour que ce soit fait a un fonction
Pour effacer le dernier article j'ai essaye avec pop_front()
BCB 6 me reponds
d'autre par sur le destrcuteur de ma classe collection
je detruit tout les objets.J' ai code par rapport a ma logique (je
viens de vb beurk!!!)
est plus performant de faire une surcharge d'operateur ?
je m'explique je voulais recherche "a la main" les object presents
dans la collection par le biais d'une boucle
la logique de suppresion en "pseudo" est
debut
entiet i=0
si objet[i] trouve alors file://searcharticle
si on est sur le prmier de la collection ou le dernier de la
collection alors
file://pop_back
sinon
supprimer l'article[i]
fin si
fin si
fin
Cepandant cette methode fait partie d'une classe
si je fais une surchage d'operateur tout mes autre operateur = dans
les autre fonction vont etre surcharge non ?
comment faire pour que ce soit fait a un fonction
Pour effacer le dernier article j'ai essaye avec pop_front()
BCB 6 me reponds
d'autre par sur le destrcuteur de ma classe collection
je detruit tout les objets.J' ai code par rapport a ma logique (je
viens de vb beurk!!!)
est plus performant de faire une surcharge d'operateur ?
je m'explique je voulais recherche "a la main" les object presents
dans la collection par le biais d'une boucle
la logique de suppresion en "pseudo" est
debut
entiet i=0
si objet[i] trouve alors file://searcharticle
si on est sur le prmier de la collection ou le dernier de la
collection alors
file://pop_back
sinon
supprimer l'article[i]
fin si
fin si
fin
Cepandant cette methode fait partie d'une classe
si je fais une surchage d'operateur tout mes autre operateur = dans
les autre fonction vont etre surcharge non ?
comment faire pour que ce soit fait a un fonction
Pour effacer le dernier article j'ai essaye avec pop_front()
BCB 6 me reponds
d'autre par sur le destrcuteur de ma classe collection
je detruit tout les objets.J' ai code par rapport a ma logique (je
viens de vb beurk!!!)
est plus performant de faire une surcharge d'operateur ?
writes:
| Gabriel Dos Reis wrote in message
| news:...
| > writes:
| > | Je n'avais jamais considéré ce genre d'erreur, mais à mon avis,
| > | c'est encore un bon argument pour l'utilisation des classes
| > | comme itérateurs, et non des pointeurs.
| > Quelqu'un vient juste de proposer sur la liste de libstdc++-v3
| > qu'on en revienne aux pointeurs bruts.
| Est-ce qu'ils ont pu donner des raisons ?
Oui : comme le compilateur (sur sa machine) est assez idiot pour ne
pas mettre une structure qui contient uniquement un pointeur dans un
registre, il préfère que nous renoncions à un type distinct de T*.
Le problème est que, si nous faisions ça, il nous faudrait logiquement
virer les objets fonctionnels car souffrant des mêmes idioties de la
part du compilateur.
Comme souvent, le problème est ailleurs et la solution effective est
d'enseigner au compilateur à inliner effectivement et virer les
junks. Car les opérations incriminées sont essentiellement
1) lire la valeur brute du pointeur
2) comparer les valeurs brutes de deux pointeurs.
Actuellement, dès que le compilateur voir "struct" il dit "Oh là,
celui là ne veut pas d'efficacité, allez hop dans le tas" sans
chercher à savoir si le "struct" en question sert just à distinguer
une valeur des autres et que cette distinction est purement
compile-time.
On voit que le compilateur est écrit essentiellement par des
programmeurs C.
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m3u193ykzf.fsf@uniton.integrable-solutions.net>...
| > kanze@gabi-soft.fr writes:
| > | Je n'avais jamais considéré ce genre d'erreur, mais à mon avis,
| > | c'est encore un bon argument pour l'utilisation des classes
| > | comme itérateurs, et non des pointeurs.
| > Quelqu'un vient juste de proposer sur la liste de libstdc++-v3
| > qu'on en revienne aux pointeurs bruts.
| Est-ce qu'ils ont pu donner des raisons ?
Oui : comme le compilateur (sur sa machine) est assez idiot pour ne
pas mettre une structure qui contient uniquement un pointeur dans un
registre, il préfère que nous renoncions à un type distinct de T*.
Le problème est que, si nous faisions ça, il nous faudrait logiquement
virer les objets fonctionnels car souffrant des mêmes idioties de la
part du compilateur.
Comme souvent, le problème est ailleurs et la solution effective est
d'enseigner au compilateur à inliner effectivement et virer les
junks. Car les opérations incriminées sont essentiellement
1) lire la valeur brute du pointeur
2) comparer les valeurs brutes de deux pointeurs.
Actuellement, dès que le compilateur voir "struct" il dit "Oh là,
celui là ne veut pas d'efficacité, allez hop dans le tas" sans
chercher à savoir si le "struct" en question sert just à distinguer
une valeur des autres et que cette distinction est purement
compile-time.
On voit que le compilateur est écrit essentiellement par des
programmeurs C.
writes:
| Gabriel Dos Reis wrote in message
| news:...
| > writes:
| > | Je n'avais jamais considéré ce genre d'erreur, mais à mon avis,
| > | c'est encore un bon argument pour l'utilisation des classes
| > | comme itérateurs, et non des pointeurs.
| > Quelqu'un vient juste de proposer sur la liste de libstdc++-v3
| > qu'on en revienne aux pointeurs bruts.
| Est-ce qu'ils ont pu donner des raisons ?
Oui : comme le compilateur (sur sa machine) est assez idiot pour ne
pas mettre une structure qui contient uniquement un pointeur dans un
registre, il préfère que nous renoncions à un type distinct de T*.
Le problème est que, si nous faisions ça, il nous faudrait logiquement
virer les objets fonctionnels car souffrant des mêmes idioties de la
part du compilateur.
Comme souvent, le problème est ailleurs et la solution effective est
d'enseigner au compilateur à inliner effectivement et virer les
junks. Car les opérations incriminées sont essentiellement
1) lire la valeur brute du pointeur
2) comparer les valeurs brutes de deux pointeurs.
Actuellement, dès que le compilateur voir "struct" il dit "Oh là,
celui là ne veut pas d'efficacité, allez hop dans le tas" sans
chercher à savoir si le "struct" en question sert just à distinguer
une valeur des autres et que cette distinction est purement
compile-time.
On voit que le compilateur est écrit essentiellement par des
programmeurs C.
