[C++] betere istream operator>> voor eigen class

[Elijan9]

Ik hoop dat ik goed genoeg gezocht heb en er niet overheen heb gekeken, maar een bevredigend antwoord heb ik niet kunnen vinden.

Ik maak nog wel regelmatig gebruik van de mogelijkheid om een ostream operator<< te declareren voor eigen classes. Sinds kort wil ik nu ook graag streams in kunnen lezen.
Het declareren is geen probleem , maar bij het implementeren loop ik tegen problemen die bij ostream niet spelen. De istream input moet namelijk een bepaalde soort reeks zijn en soms weet ik pas na een x aantal karakters of iets helemaal, gedeeltelijk of niet helemaal geparsed zou moeten worden. Nu vraag ik me af of er een andere manier is, dan om in het laatste geval een x aantal keren unget() aan te roepen. Dat vind ik eigenlijk wat omslachtig.

Voor de rest kan ik überhaupt weinig vinden over hoe je istream operator>> functies het beste kunt programmeren, terwijl ostream operator<< uiteraard wel in elk C++ boek te vinden is. Zo neem ik maar aan dat de stream na afloop moet wijzen naar het eerstvolgende karakter dat niet geparsed wordt/niet voldeed aan de regels van de syntax. Of zou elk individueel element officiëel tussen whitespaces moeten staan?
Toch kan ik me ook weer niet voorstellen dat ik de eerste ben die zich dit allemaal afvraagt. Misschien kan iemand mij dus net dat ene stukje op weg helpen wat ik nodig heb.

[Soultaker]

Volgens mij valt er niet heel veel meer over te zeggen dan je al deed. Je hebt iets meer mogelijkheden als je de onderliggende filebuffer aanspreken inplaats van de input stream zelf, maar dan blijft het parsen en het overlaten van de juiste karakters in de buffer je eigen verantwoordelijkheid.

De standaardoperators slaan whitespace over, parsen allemaal zover ze kunnen en blijven verder overal vanaf. Als je dus een string "123abc" hebt, dan kun je daar eerst een int en vervolgens een string uithalen. [In mijn voorbeeld is '.' een spatie --> ] Als je uit "...123...456" een eerste int hebt gelezen, blijft er "...456" over (dat kan relevant zijn als je geen int maar een string gaat lezen). Het lijkt me handig om dit soort dingen (die je vast zelf ook al geconstateerd had ) over te nemen in je eigen implementaties. Of er verder nog officiële guidelines zijn, weet ik niet.

Hoe dan ook zou ik niet al te veel waarde hecten aan die stream operators. Je kunt ze meestal toch niet echt voor serieuze serialization gebruiken.

[ Voor 5% gewijzigd door Soultaker op 26-05-2004 00:15 ]

[.oisyn]

Basically komt het hier op neer:

C++:

std::istream & operator >> (std::istream & in, MijnType & t)
{
    std::ios::iostate state = std::ios::goodbit;
    std::istream::sentry sentry (in);
    if (sentry)
    {
        try
        {
            // doe het inlezen
            // zet ios::failbit in state indien mislukt
        }
        catch (...)
        {
            std::ios::iostate e = in.exceptions ();
            in.exceptions (e & ~std::ios::badbit);
            in.setstate (std::ios::badbit);
            in.exceptions (e);
            if (e & std::ios::badbit)
                throw;
        }
    }
    in.setstate (state);
    return in;
}

.edit: zo klopt ie beter

[ Voor 37% gewijzigd door .oisyn op 26-05-2004 18:09 ]

[Soultaker]

Wat doet die sentry precies? Ik neem aan dat je 'm gebruikt omdat 'ie iets met de state van 'in' doet en automisch gedestruct wordt als de functie verlaten wordt, maar wat...?!

[.oisyn]

sentry zorgt voor een goede synchronisatie tussen formatted input en unformatted output, door de aan de istream gekoppelde ostream (de tie () functie) te flushen. Verder doet ie ook iets met de states, hij zet failbit als good () false returned, en good () is eveneens de waarde die gereturned wordt bij een cast naar bool

[Elijan9]

Soultaker schreef op 26 mei 2004 @ 00:14:
Je hebt iets meer mogelijkheden als je de onderliggende filebuffer aanspreken inplaats van de input stream zelf, maar dan blijft het parsen en het overlaten van de juiste karakters in de buffer je eigen verantwoordelijkheid.

Dat is denk ik ook wat ik eigenlijk wil. Met de onderliggende filebuffer doel je waarschijnlijk op het gebruik maken van "rdbuf()"?
Zoals ik het nu lees zou ik rdbuf()->gptr() kunnen gebruiken om het eerstvolgende karakters te lezen zonder de pointer zelf meteen al op te hogen... Daarbij moet ik wel opletten dat het verschil met rdbuf()->egptr() groot genoeg is. Mooi zo, ik denk dat ik daar wel mee uit de voeten kan, vooral in combinatie met de code van .oisyn, bedankt allebei!

offtopic:
voor het eerst dat de search van P&W geen antwoord had op mijn vraag... (zelfs geen enkele hits).

[MisterData]

Elijan9 schreef op 26 mei 2004 @ 17:46:
[...]

offtopic:
voor het eerst dat de search van P&W geen antwoord had op mijn vraag... (zelfs geen enkele hits).

offtopic:
Zie mededelingen-forum, de search is/was kapot

[.oisyn]

offtopic:
overigens denk ik wel dat ie gelijk heeft, ik heb nog nooit een custom operator >> topic gezien in /14

[Soultaker]

offtopic:
Ik betwijfel of er ueberhaupt te zoeken valt op een term als "operator>>".