[C++] operator-> overloaden

[^Mo^]

Hoi,

Ik probeer in een programma hier de operator-> te overloaden, maar het wil niet werken als de instantie van het object al een pointer is. Klein voorbeeld:

C++:

class A
{
public:
    int i;

    A *operator->()
    {
        std::cout << "Operator-> called" << std::endl;
        return this;
    }
};

int main( int argc, char *argv[])
{
    A *p = new A();
    A a;
        
    p->i = 0;   // Doesn't work with the overloaded operator
    a->i = 0;   // Uses operator->()

    std::cin.get();

    return 0;
}

In dit voorbeeld krijg ik alleen de melding in het tweede geval, als de instantie dus op de stack staat. Is er een manier om dit voor alle situaties werkend te krijgen?

-Edit-
Ik compileer dit trouwens met zowel Visual C++ 6.0 als Visual C++ .NET 2003

[ Voor 11% gewijzigd door ^Mo^ op 04-11-2005 11:36 ]

[.oisyn]

Natuurlijk niet, alle voor T gedefinieerde operators werken op een T. Een T* is simpelweg geen T, en gelukkig kun je voor primitive types (dus ook pointers) geen operators overloaden.

Ik snap ook niet waarom je dat zou willen, hoe kom je anders ooit bij de i van een A* als je operator-> geen this returnt? En je kunt natuurlijk regel 18 in jouw code vervangen door

C++:

(*p)->i = 0;

// of:
A & aRef = *p;
aRef->i = 0;

[ Voor 21% gewijzigd door .oisyn op 04-11-2005 11:50 ]

[^Mo^]

.oisyn schreef op vrijdag 04 november 2005 @ 11:48:
Natuurlijk niet, alle voor T gedefinieerde operators werken op een T. Een T* is simpelweg geen T, en gelukkig kun je voor primitive types (dus ook pointers) geen operators overloaden.

Ik snap ook niet waarom je dat zou willen, hoe kom je anders ooit bij de i van een A* als je operator-> geen this returnt? En je kunt natuurlijk regel 18 in jouw code vervangen door

C++:

(*p)->i = 0;

// of:
A & aRef = *p;
aRef->i = 0;

Een van onze klanten heeft een probleem met onze software, we hebben alleen geen idee waar (tenminste, niet 100%). We hebben echter wel een potentiele kanidaat, maar dit loopt allemaal via pointers. En we wilden dus wat debug regeltjes inbouwen om zeker te weten dat al deze pointers geldig blijven.

Het is inderdaad logisch dat het niet werkt, helemaal niet bij stil gestaan. Zal ik denk ik toch alles langs moeten lopen Nou ja, als dat werkt, best...

[H!GHGuY]

C++:

p->i
is equivalent met
(*p).i

maw als je iets wil overloaden is het de . operator, maar voor zover ik weet kan dat niet.

[.oisyn]

_Mo_ schreef op vrijdag 04 november 2005 @ 12:00:
[...]

Een van onze klanten heeft een probleem met onze software, we hebben alleen geen idee waar (tenminste, niet 100%). We hebben echter wel een potentiele kanidaat, maar dit loopt allemaal via pointers. En we wilden dus wat debug regeltjes inbouwen om zeker te weten dat al deze pointers geldig blijven.

Dan pak je het verkeerd aan . Je moet een type maken dat een pointer simuleert, juist door de -> te overloaden. In plaats van een A* gebruikt men dan bijvoorbeeld een APtr (wat geen pointer is). Je zou evt. nog de & operator op A kunnen overloaden zodat ie zo'n APtr returnt ipv de A* die by default gereturnd wordt. En natuurlijk niet vergeten de * operator op APtr ook te overloaden zodat je weer een A& krijgt

[^Mo^]

.oisyn schreef op vrijdag 04 november 2005 @ 12:10:
[...]


Dan pak je het verkeerd aan . Je moet een type maken dat een pointer simuleert, juist door de -> te overloaden. In plaats van een A* gebruikt men dan bijvoorbeeld een APtr (wat geen pointer is). Je zou evt. nog de & operator op A kunnen overloaden zodat ie zo'n APtr returnt ipv de A* die by default gereturnd wordt. En natuurlijk niet vergeten de * operator op APtr ook te overloaden zodat je weer een A& krijgt

Aan zo'n soort constructie zat ik ook al te denken. Maar dat is denk ik niet echt haalbaar, want dat wordt nog meer werk dan eerst de pointer te dereferencen. Ik ga nog wel even prutsen en kijken of er nog andere opties zijn.

Bedankt in ieder geval

[curry684]

.oisyn schreef op vrijdag 04 november 2005 @ 12:10:
[...]

Je zou evt. nog de & operator op A kunnen overloaden zodat ie zo'n APtr returnt ipv de A* die by default gereturnd wordt.

Op dat moment ben je designtechnisch de verantwoordelijkheid voor het functioneren van een utility class in de main class aan het leggen, en da's natuurlijk foute boel. Correct is om dit af te vangen door APtr een operator=(A*) en eenzelfde constructor te geven, en vervolgens de conversion operator A* te implementeren op je smart pointer.

[.oisyn]

curry684 schreef op vrijdag 04 november 2005 @ 12:55:
[...]

Op dat moment ben je designtechnisch de verantwoordelijkheid voor het functioneren van een utility class in de main class aan het leggen, en da's natuurlijk foute boel.

De hele code moet toch veranderd worden als de pointer class gebruikt moet worden. En als je die APtr een typedef maakt afhankelijk van je buildsettings (zodat het een A* is in release bijvoorbeeld) maakt het geen zak uit.

Correct is om dit af te vangen door APtr een operator=(const A &) en eenzelfde constructor te geven

Que? Een pointer constructen uit een const reference? Dàn ben je pas designtechnisch fout bezig . En uiteraard moet de pointer class gewoon een operator=(A *) en gelijke constructor hebben, maar dat is inherent aan het feit dat het een pointer class is.

[ Voor 13% gewijzigd door .oisyn op 04-11-2005 13:21 ]

[curry684]

Erm ja, die const hoorde daar niet

[.oisyn]

Afgezien van dat, je moet een pointer niet kunnen constructen uit een non-pointer, dat gaat tegen het hele design van C++ in. Dit kan toch ook niet:

C++:

A a;
A * aPtr = a;

Als je een pointer class maakt moet je 'm ook laten gedragen als een pointer, imho


Daarnaast hoef je een operator& niet per se in je A class te definieren, het mag ook als losse functie . Dus dan hoef je de definitie A niet eens aan te passen

[ Voor 25% gewijzigd door .oisyn op 04-11-2005 13:30 ]

[curry684]

Ja die signature die ik gaf klopte voor geen meter Het gaat natuurlijk om operator=(A*) zodat je de & op A niet hoeft te overloaden om APtr terug te geven maar je gewoon native de pointereigenschappen die je met &A introduceert kunt behouden Dat was het hele punt van het betoog eilijk

* curry684 te kort geslapen vannacht en al te lang geen C++ meer gedaan

[ Voor 7% gewijzigd door curry684 op 04-11-2005 13:31 ]

[MSalters]

De aanname dat je een A::operator& wil hebben die een APtr terug geeft is best redelijk:

C++:

template<typename Ptr>
void foo(Ptr p)
{
  std::cout << *p;
}
A a;
foo(&a);