Tri de tableau d'objets...

Question

Bonjour
J'ai un petit souci en Visual C++6?
Je détiens, après traitement, deux indices (i et j) d'un même tableau d'objet : m_oaBras[].
Je dois permuter ces deux objets.
Si je déclare x comme étant un objet (comme ceux dans le tableau) et si j'écris :
x=m_oaBras[j];m_oaBras[j]=m_oaBras[i];m_oaBras[i]=x , bien évidement cela ne fonctionne pas. Normal !
Es-ce que quelqu'un peux me dire comment procéder ?
Merci d'avance

luhtor · Answer

Red&#233;finie l'op&#233;rateur = dans ta classe:



class A

{

...

A & operator = (const A & _which)

{

    this->donne1 = _which.donne1;

    this->donne2 = _which.donne2;



    // tu fais ca pour toute ta classe, tu copies les membres de _which dans *this;

}

}

luhtor · Answer

oups pardon, n'oublies pas:



return *this;



&#224; la fin de la fonction.

vecchio56 · Answer

Il faut aussi faire attention à l'auto-affectation (dans ce cas, il n'y a rien a faire)

A & operator = (const A & _which)
{
  if(this != &_which)
  {
    this->donne1 = _which.donne1;
    this->donne2 = _which.donne2;
  }
  return *this
}

luhtor · Answer

C'est la premi&#232;re fois que je vois ca. L'auto affectation n'est en g&#233;n&#233;ral pas un probl&#232;me. Mais j'ai du le rencontrer une fois.

Dans les include du C++, ils font pas ce test. (il me s emble)

vecchio56 · Answer

Un autre problème important est celui de l'autoaffectation. Non seulement affecter un objet à lui-même est inutile et consommateur de ressources, mais en plus cela peut être dangereux. En effet, l'affectation risque de détruire les données membres de l'objet avant même qu'elles ne soient copiées, ce qui provoquerait en fin de compte simplement la destruction de l'objet !

http://casteyde.christian.free.fr/cpp/cours/online/x3244.html

luhtor · Answer

Ca "consommateur de ressources", c'est pas valable comme argument, deja
car copier un objet sur lui meme, ca doit pas etre fr&#233;quent, alors que
effectuer le test de comparaison a chaque fois que le constructeur de
copie est appel&#233;, ca c'est une perte de tps inutile. Par contre, pour
ce qu'il dit ensuite, je comprend pas pourquoi il d&#233;truirait l'objet
membre avant de copier la valeur.

Quand tu fais

int x = 2;

x = 4; <= ici x ne va pas est d&#233;truit. Donc pourquoi, ce serait le cas pour les membres de la classe ?


Et si le test &#233;tait vraiment vitale, il serait dans les includes du C++. Enfin je comprend pas bien.

vecchio56 · Answer

La comparaison est une comparaison d'adresse, c'est donc très vite fait, et ca vaut largement le coup de la faire. A mon avis c'est une optimisation intéressante.
Voici ce que j'ai trouvé dans le template list de VC++:
_Myt& operator=(const _Myt& _Right)
{	// assign _Right
  if (this != &_Right)
    assign(_Right.begin(), _Right.end());
  return (*this);
}

C'est exactement ca.

Je ne comprends pas non plus l'autre argument

vecchio56 · Answer

Voici un exemple donné par l'auteur, qui justifie qu'on doit vérifier l'auto-affectation

class A
{
  char *m_szData;
public:
  A &operator=(const A &source)
  {
    // Libération de m_szData :
    delete[] m_szData;
    // Copie :
    m_szData = new char[strlen(source.m_szData) + 1];
    strcpy(m_szData, source.m_szData);
    return *this;
  }
        ...
};

A a("hello");
a = a;        // Plantage.

En effet, a= a exécute, sans protection :

delete m_szData;
m_szData = new char[strlen(m_szData) + 1];        // m_szData n'est plus valide et
peut valoir n'importe quoi. Du coup strlen peut planter, ou la copie qui
suivra, etc.

luhtor · Answer

Oui ok, mais la c'est quand meme gros la plante potentielle :)

dbiare · Answer

C'est super sympa, merci... Mais la les mecs je suis un peu "largué". Je vais dépatouiller tout cela et voir ce que cela donne.
Grand merci

Tri de tableau d'objets...

10 réponses

Votre réponse

Discussions similaires