[C++] Probleem met ostream en << overloaden

[Coca-Cola]

Ik zit met een hele rare (denk ik) bug in mijn programma. Ik heb een aantal classes met een overloaded << operator alsvolgt:

C++:

//in de class:
class A
{
public:
    friend ostream& operator<<(ostream& output_stream, A &r);
};

//functie:
ostream& operator<<(ostream& output_stream, A &r)
{
    for(int i = 0; i < r.size; i++)
        output_stream << r.member[i] << endl;
}

Dus ik heb een class A met een array met members van type B en beide hebben diezelfde overloaded operator (maar dan met B &r). Je zou dus zeggen dat als ik nu doe:

C++:

int main(int argc, char *argv[])
{
    int size = 10;
    A Ding(size);
    cout << Ding << endl;
}

dat dan alle B's netjes onder elkaar op het scherm komen. Het probleem is nu dat dit crashed als ik het run. En als ik het dan debug kom ik op de volgende plek terecht:
in _ostream.h op regel 4

C++:

template <class _CharT, class _Traits>
inline basic_ostream<_CharT, _Traits>& _STLP_CALL
endl(basic_ostream<_CharT, _Traits>& __os) {
  __os.put(__os.widen('\n'));
  __os.flush();
  return __os;
}

Het rare is dat als ik een extra std::cout (dus niet de ostream output_stream) in de operator<< van Class B zet (na de for lus) dan crashed het niet.

Mijn vraag is nu. Doe ik iets fout (is het bv onhandig om dit soort genestte operator<< 's te hebben, in mijn echte code gaat dit namelijk 4 niveau's diep ipv 2 in het voorbeeld hier) Of klopt er ergens anders iets niet.

Edit: code trouwens gecompiled en getest met dev-cpp 4.9.9.1 en borland builder 6

[ Voor 17% gewijzigd door Coca-Cola op 10-03-2005 15:03 ]

[Zoijar]

Het idee is juist prima, die geneste stream outputs. Ik denk dat je ergens je stack corrupt, want het zou wel moeten werken. Post anders even al die functies.

[.oisyn]

C++:

    A iets();

Dat is een functiedefinitie, geen variabeledefinitie. Haal de haakjes maar eens weg. Daarnaast wil je je A& in de << operator const maken, of ga je 'm in die functie aanpassen?

[Coca-Cola]

Dit is alle relevante code. Ik heb er een hele berg uitgesloopt en de boel een beetje vereenvoudigd. Het zou idd wel kunnen dat ik m'n stack ergens verprutst, maar ik heb bij borland builder zo'n guard optie aanstaan tijdens het debuggen en die meldt het als ik ergens out of bounds etc ga en die zegt er niks over.

C++:

class TParameter
{
public:    
    TParameter(int NofBits); 
    friend ostream& operator<<(ostream& output_stream, TParameter &r);
private:
    int NofBits;
    short* bits;
};

class TParameter_set
{
public:
    TParameter_set(int parameters);
    friend ostream& operator<<(ostream& output_stream, TParameter_set &r);
private:
    int NofParameters;
    TParameter** parameters;
};

class TPopulation
{
public:
    TPopulation(int size);
    friend ostream& operator<<(ostream& output_stream, TPopulation &r);
private:
    int pop_size;
    TParameter_set** population;
};

//functies
//constructors, allemaal hetzelfde idee:
TPopulation::TPopulation(int size): pop_size(size)
{
    population = new TParameter_set*[pop_size];
    for(int i = 0; i < pop_size; i++)
    {
        population[i] = new TParameter_set(parameter_info);
    }
}

//overloaded<< 's:
ostream& operator<<(ostream& output_stream, TPopulation &r)
{
    for(int i = 0; i < r.pop_size; i++)
    {
        output_stream << *(r.population[i]) << endl;
    }
// met deze cout erin werkt het wel zonder crash 
//    cout << "-----------------------" << endl;
}

[Coca-Cola]

.oisyn schreef op donderdag 10 maart 2005 @ 14:57:

C++:

    A iets();

Dat is een functiedefinitie, geen variabeledefinitie. Haal de haakjes maar eens weg. Daarnaast wil je je A& in de << operator const maken, of ga je 'm in die functie aanpassen?

Hehe je hebt gelijk. Ik had in mijn post ff een foutje gemaakt, dat zou nu goed moeten zijn (dat was overigens natuurlijk niet de fout )
En ze moeten idd eigenlijk const zijn! (maakt dat trouwens nog iets uit? Je geeft toch alleen aan dat je in die functie het object niet gaat veranderen?)

[ Voor 16% gewijzigd door Coca-Cola op 10-03-2005 15:08 ]

[Eelis]

.

[ Voor 98% gewijzigd door Eelis op 18-02-2015 19:07 ]

[Coca-Cola]

Eelis schreef op donderdag 10 maart 2005 @ 16:53:
Compileer met warnings enabled. Als je compiler niet compleet braindead is zal hij je dan vertellen dat je operator<< een return statement mist.

Jezus, dat ik dat over het hoofd heb gezien... mijn god... Naja mijn compiler is niet het enige dat braindead is Ik compilede trouwens in full debug mode, dus vaag dat er dan niet standaard dit soort warnings gegeven worden... Nog vager dat 'ie zo crashed trouwens!
Ik zal morgen eens kijken of dit het oplost, maar ik ga er wel vanuit

[MrBucket]

Coca-Cola schreef op donderdag 10 maart 2005 @ 17:17:
[...]


Jezus, dat ik dat over het hoofd heb gezien... mijn god... Naja mijn compiler is niet het enige dat braindead is Ik compilede trouwens in full debug mode, dus vaag dat er dan niet standaard dit soort warnings gegeven worden... Nog vager dat 'ie zo crashed trouwens!
Ik zal morgen eens kijken of dit het oplost, maar ik ga er wel vanuit

Waarschijnlijk heeft de compiler de warning 1 keertje aangegeven, maar omdat het geen error is, de code wel gewoon gecompiled.

Als je daarna de code voor die functie niet meer hebt veranderd, kan het zijn dat hij die code niet opnieuw hoeft te compilen, en dus ook geen warning meer geeft. Weet niet of het precies zo werkt, maar naar mijn eigen ervaring lijkt het er wel op.

Na een full rebuild zal de warning iig wel (eenmaal) gegeven worden.

[MSalters]

Je mist idd een const op je A&. De operator>> is de versie zonder const&
Dat maakt uit als je dit probeert:

C++:

std::cout << A(10);

[farlane]

MrBucket schreef op donderdag 10 maart 2005 @ 17:34:
Waarschijnlijk heeft de compiler de warning 1 keertje aangegeven, maar omdat het geen error is, de code wel gewoon gecompiled.

Geen return value geven is geen error? Dat zal toch bij C++ niet meer zo zijn ( itt tot C ) ?

[MSalters]

't Is geen error, omdat er functies zijn die dat by design niet doen. Een typisch voorbeeld is een errorhandler die std::exit aanroept.

[.oisyn]

Dat typische voorbeeld gebruikt over het algemeen void als return-type, dus waarom zou dat een argument zijn om 'niets returnen uit een functie die wel een return-type gedefinieerd heeft' toe te laten?

[farlane]

.oisyn schreef op donderdag 10 maart 2005 @ 22:34:
Dat typische voorbeeld gebruikt over het algemeen void als return-type, dus waarom zou dat een argument zijn om 'niets returnen uit een functie die wel een return-type gedefinieerd heeft' toe te laten?

psies.