[c++] Type conversies *

woensdag 4 februari 2004 20:14

Het is niet gezegd dat de ingelezen string zero-terminated is, of wat er gebeurt als de karakters buiten de grenzen van de string opgevraagd worden, dus dat lusje op regel 14 kan in principe oneindig vaak uitgevoerd worden, of gewoon domweg crashen.

Als we er van uitgaan dat die string::operator[](lengte van string) wel 0 retourneert, dan wordt onterecht het karakter '0' meegeteld. Je komt dan 4*48 te hoog uit, plus 6, is een totaal van 198 (en dat is inderdaad net geen 200).

Dat is natuurlijk geen oplossing voor het probleem. Ik denk echter dat dit specifieke probleem oplossen weinig nut heeft, als ik de code zo zie. Een algemene introductie in de programmeertaal C++ lijkt me een stuk zinniger. Daar is dit topic natuurlijk niet geschikt voor, maar in de FAQ staan wel wat links.

[ Voor 8% gewijzigd door Soultaker op 04-02-2004 20:02 ]

Acties:

Eelis

[ Voor 129% gewijzigd door Eelis op 18-02-2015 19:49 ]

woensdag 4 februari 2004 21:58

Acties:

woensdag 4 februari 2004 22:06

Eelis schreef op 04 februari 2004 @ 20:14:
En dat verschil (dat overigens willekeurig groot is, op mijn systeem was het zojuist ongeveer 400 duizend) heeft natuurlijk alles te maken met het feit dat som niet geinitialiseerd wordt.

Oh, dat is ook nog eens waar; daar had ik zelfs helemaal overheen gelezen.

De string is in het geval van de TS niet const en er is dus inderdaad sprake van undefined behaviour. Iemand enig idee waarom er onderscheid wordt gemaakt tussen de const en nonconst versie?

Oeps; mijn uitspraak klopte blijkbaar niet (die was té restrictief). De tekst die je quotte heeft het over de const-versie van de operator[] member function, niet over de constness van de string. (Maar voor een const string is alleen de const member beschikbaar, natuurlijk).

De const-versie retourneert een const char&; de non-const-versie een char&. De reden dat de non-const versie ongedefinieerd is, is waarschijnlijk omdat het niet de bedoeling is dat je de afsluitende 0-karakter (die eigenlijk geen onderdeel uitmaakt van de inhoud van je string) gaat wijzigen. Methoden als c_str() werken dan namelijk niet meer goed (of ze moeten elke keer dat 0-karakter terugzetten, wat een beetje nodeloze overhead oplevert).

Ik vraag me trouwens af welke operator[] in dit geval gekozen wordt door de compiler. Zowel de const als de niet-const variant zijn beschikbaar. Volgens mij kiest GCC by default de meest specifieke (de niet-const variant in dit geval) maar je zou zeggen dat in deze situatie de const-variant beter zou zijn geweest. (GCC genereert ook wel eens warnings als 'ie vanwege optimalisaties kiest voor de const ipv. de non-const variant). Ik weet echter niet zeker of deze keuze door de standaard opgelegd wordt (en ik ben te lam om 't nu op te zoeken

[ Voor 70% gewijzigd door Soultaker op 04-02-2004 22:07 ]

Acties:

Tmr

Eelis schreef op 04 februari 2004 @ 20:14:
[...]
De string is in het geval van de TS niet const en er is dus inderdaad sprake van undefined behaviour. Iemand enig idee waarom er onderscheid wordt gemaakt tussen de const en nonconst versie?
[...]

Wellicht dat een constante tijdens compile-tijd (dwz hard-coded in de binary) wordt bepaald. Zo gebeurt dat volgens mij in ieder geval in C. Volgens mij komen die objecten dan ook op de stack, misschien dat het wat makkelijker te checken is dan.

Mbt tot het probleem van ridde100:

In de string staan de ASCII codes van de tekens opgeslagen. Dit kan je gebruiken om mee te rekenen maar de ASCII code van 1 is niet gelijk aan het getal 1. Waarschijnlijk moet je dan ook iets doen als:

som += (rij[i] - '0') /* let op de ' ' jes */

die haalt dan de char waarde van '0' eraf. Ik weet niet zeker hoe de volgorde van de ASCII codes is (0,1,2...9 of 1,2,3...9,0) maar het moet zoiets zijn.

Gebruik in de for-loop dan ook rij[i] != '0' (of liever nog i < rij.length()-1) want ander vergelijk je characters met int waardes wat, zoals je gemerkt hebt, niet het gewenste resultaat oplevert,

woensdag 4 februari 2004 22:53

Acties:

Verwijderd

gebruik gewoon een counter.

C++:

int som=0, rij, counter;
bool continue=true;

for(int i=0; continue; i++)
{
   cin>>rij;
   int tempsom = som;
   som += rij;
   tempsom == som ? continue = false : continue = true;
}

niet getest ofzo, maar zoiets lijkt me makkelijker dan met strings werken

woensdag 4 februari 2004 23:09

Acties:

woensdag 4 februari 2004 23:10

Wtf? Die code is echt té lelijk!

Niet lullig bedoelt, maar was dit het beste wat je kon verzinnen? Zo leert de topic starter het nooit, natuurlijk.

_{Ik denk ook dat het niet compilet met die 'continue' als identifier.}

Acties:

Tmr

Verwijderd schreef op 04 februari 2004 @ 22:53:

niet getest ofzo, maar zoiets lijkt me makkelijker dan met strings werken

Natuurlijk. cin direct gebruiken om ints in te lezen zou wél makkelijker zijn. ALS het doet wat hij wil...

Helaas is de 'string' 1234 maar één int, terwijl hij in zijn programma juist alle characters apart als cijfers wilde gebruiken. (verschil cijfer/getal is subtiel)

Een keer cin >> rij doen heeft dus als resultaat dat de hele ingevoerde string als 1 int in de variabele staat en je bent je individuele characters kwijt... ALS cin tenminste doet wat ik denk dat ie doet. Ik neem aan dat cin >> int niet 1 character tegelijk leest.

Toch maar even vantevoren testen voortaan??

woensdag 4 februari 2004 23:15

Acties:

donderdag 5 februari 2004 00:45

Als het je daar om gaat: met istream::get() kun je gewoon een karakter per keer uitlezen. Je krijgt je karakter dan natuurlijk nog wel in de vorm van een ASCII code terug (en die moet je dus nog converteren naar een getal).

Acties:

Verwijderd

Hoewel ik betwijfel of dit ook maar enig praktisch nut heeft, heb ik een poging gewaagd. Als ik jou was zou ik toch de getallen (heel) anders invoeren. Maarja, genoeg geleuter, cood

C++:

#include <iostream>

using namespace std;

int main(int argc, char * argv[])
{
    cout << "Getallen, afsluiten met regeleinde" << endl;
    
    //Hier je teller voor het aantal cijfers
    int count=0;
    int totaal=0;
    unsigned char digit=0;

    while((digit=cin.get()) != '\n'){
        count++;
        totaal += digit-'0';
    }
    cout << "Totaal = " << totaal << endl;
    cout << "Gedeeld door = " << count << endl;
    cout << "Gemiddelde van = " << ((float)totaal/(float)count) << endl;

    cin.get();

    return 0;
}

donderdag 5 februari 2004 02:30

Acties:

donderdag 5 februari 2004 10:59

Jeroen_Paul: wat nu als ik als dissidente gebruiker direct op end-of-file ram?

Acties:

Shadowman

Soultaker schreef op 05 februari 2004 @ 02:30:
Jeroen_Paul: wat nu als ik als dissidente gebruiker direct op end-of-file ram?

Dan kun je op de volgende regel doorgaan met getallen in te voeren

Jeroen_Paul: Het initialiseren van de variabelen kun je beter aan het begin van de functie doen (eventueel commentaar er voor maar geen regels code).

Verder is het ook handig om wat error checking te doen, zoals te controleren of de invoer een getal is en de variabele count niet 0 is.

donderdag 5 februari 2004 12:39

Acties:

Eelis

[ Voor 99% gewijzigd door Eelis op 18-02-2015 19:49 ]

donderdag 5 februari 2004 12:52

Acties:

Creepy

Tactical Espionage Splatterer

Eelis: Heb je het nu over initialiseren of declareren?

Initialiseren wanneer je ze nodig hebt, ok. Maar declareren ergens midden in een lap code lijkt me juist een stuk schadelijker voor de leesbaarheid.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

donderdag 5 februari 2004 19:30

Acties:

donderdag 5 februari 2004 19:52

Shadowman schreef op 05 februari 2004 @ 10:59:
Dan kun je op de volgende regel doorgaan met getallen in te voeren

Nee hoor, dan kom je echt in een oneindige lus terecht!

Creepy schreef op 05 februari 2004 @ 12:52:
Initialiseren wanneer je ze nodig hebt, ok. Maar declareren ergens midden in een lap code lijkt me juist een stuk schadelijker voor de leesbaarheid.

Ik vind dat een kwestie van smaak. Apart initialiseren is inderdaad vervelend omdat je dan niet direct verband ziet tussen de initialisatie en de code waarin de variabelen worden gebruikt. Maar eerst declareren en later pas initialiseren vind ik ook niets; dan weet je op een gegeven moment niet meer welke variabelen nu wel of niet geinitialiseerd waren. Door op hetzelfde moment te declareren als te initialiseren, garandeerd je compiler je dat als je de variabele kunt gebruiken (omdat 'ie in scope is) 'ie ook geinitialiseerd is.

Evenwel blijft het een beetje een kwestie van smaak of stijl. Om nou te zeggen dat het ene of het andere fout is, vind ik wel erg ver gaan.

Acties:

Shadowman

Soultaker schreef op 05 februari 2004 @ 19:30:
[...]

Nee hoor, dan kom je echt in een oneindige lus terecht!

Dan zou die dus altijd in een oneindige loop moeten komen of niet alles controleren. Met een keer een enter levert die toch bij die while een '\n' af. Verder heb ik het hier ff geprobeerd en dan komt die ook niet in een loop terecht.

Vraagt trouwens ook niet op de volgende regel om meer getallen.

edit:

quote:
.oisyn schreef op 05 februari 2004 @ 20:02:
Wat Soultaker je subtiel probeert duidelijk te maken is dat een ^Z (end of file) ook een end of file is, en dat je dus verder niets meer kunt inlezen. istream::get () geeft dan ios::traits_type::eof () (meestal -1 oid), en dat is ongelijk aan \n, dus je loop blijft oneindig doorgaan

ergo: error-checking!

End quote.

geeft hier geen EOF. Ligt waarschijnlijk aan dat ik hier geen dev-c++ gebruik. Een '\n' geeft toch niet direct aan dat er niet meer kan komen en die cin is een stream, dus die wacht tot er meer komt lijkt me.

[ Voor 44% gewijzigd door Shadowman op 05-02-2004 20:30 ]

donderdag 5 februari 2004 20:02

Acties:

vrijdag 6 februari 2004 23:28

Moderator Devschuur®

Demotivational Speaker

Wat Soultaker je subtiel probeert duidelijk te maken is dat een ^Z (end of file) ook een end of file is, en dat je dus verder niets meer kunt inlezen. istream::get () geeft dan ios::traits_type::eof () (meestal -1 oid), en dat is ongelijk aan \n, dus je loop blijft oneindig doorgaan

ergo: error-checking!

[ Voor 7% gewijzigd door .oisyn op 05-02-2004 20:04 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

vrijdag 6 februari 2004 23:35

Eelis schreef op 04 februari 2004 @ 19:03:
Je lus loopt waarschijnlijk wel precies door alle ingevoerde karakters heen^* (inclusief een laatste '0' karakter als de invoer daarmee afgesloten wordt), omdat de [ ] operator van string als de gegeven index gelijk is aan de lengte van de string een karakter returned waarvan de waarde op jouw systeem hoogstwaarschijnlijk 0 is (om historische redenen ).

_{* Disclaimer: mits er geen char() karakters ingevoerd worden.}

char() = 0 is de enige char die naar bool false gecast wordt. Dat maakt de klassieke strcpy( char *p, char*q) { while (*p++=*q++ ); } mogelijk. Dit is vrij snel op veel CPUs.

Dat char& std::string::operator[ ]( ) een char(0) teruggeeft is toeval/implementatiedetail.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

Acties:

vrijdag 6 februari 2004 23:40

Eelis schreef op 04 februari 2004 @ 20:14:
[...]

Hmm, interessant. Met betrekking tot basic_string::operator[] zegt de standaard:
[...]
De string is in het geval van de TS niet const en er is dus inderdaad sprake van undefined behaviour. Iemand enig idee waarom er onderscheid wordt gemaakt tussen de const en nonconst versie (van operator[] - ms ) ?

Ja, alhoewel er een consensus is dat het een slechte reden is.

char& operator[](length) kan geen reference naar een 0 teruggeven, omdat het een reference zou moeten zijn naar voorbij het laatste karakter, wat bovendien dan gemodified zou moeten kunnen worden. Daarmee zou een std::string implementatie die intern een \0-terminated string gebruikt ernstig in de problemen komen. Die wijziging vindt pas plaats na de return van operator[], en de string groei kan dus niet op tijd plaats vinden.

char operator[](length) const; kan wel een constante 0 teruggeven, omdat het op geen enkele manier consequenties heeft voor de string. De returnvalue is een rvalue, en is niet meer dan een leeg register.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

Acties:

zondag 8 februari 2004 19:39

Creepy schreef op 05 februari 2004 @ 12:52:
Eelis: Heb je het nu over initialiseren of declareren?

Initialiseren wanneer je ze nodig hebt, ok. Maar declareren ergens midden in een lap code lijkt me juist een stuk schadelijker voor de leesbaarheid.

Natuurlijk niet midden in een lap willekeurige code, maar voor het eerste gebruik. Daardoor is het voor een lezer later meteen duidelijk dat de code ervoor die variabelen niet gebruikt. Het eerste gebruik is natuurlijk niet het assignen van een dummy waarde, maar de eerste read of waar je het resultaat van een functiecall kwijt moet oid.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

Acties:

zondag 8 februari 2004 22:24

Moderator Devschuur®

Demotivational Speaker

MSalters schreef op 06 februari 2004 @ 23:35:
char operator[](length) const; kan wel een constante 0 teruggeven, omdat het op geen enkele manier consequenties heeft voor de string. De returnvalue is een rvalue, en is niet meer dan een leeg register.

het punt is alleen dat operator[] () const een const_reference teruggeeft, dus een const char &, en dat die '\0' dus ook ergens in het geheugen moet staan (voor of na de buffer, of ergens in std::string zelf)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

zondag 8 februari 2004 22:37

Het mag een shared (static member) char zijn; hij hoeft niet in elke std::string te staan.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

Acties:

zondag 8 februari 2004 22:39

@MSalters: waarom mag die char opeens wel shared zijn? Als je zomaar een willekeurige geheugenlocatie gebruikt dan geldt weer niet &str[str.size()] < &str[str.size()-1]; ik geloof dat dat ook het bezwaar was bij de non-const implementatie.

Als de geheugenlocatie van die char irrelevant is, kan de non-const-versie ook wel een reference char geven naar een static member die elke keer (voor het retourneren) expliciet op nul wordt gezet.

edit:
En nu ik je toch aan het uithoren ben; wie bepaalt of de const of non-const operator[] gebruikt wordt? Zegt de C++ standaard daar iets over of mag de compiler dat zelf uitzoeken?

[ Voor 22% gewijzigd door Soultaker op 08-02-2004 22:39 ]

Acties:

curry684

left part of the evil twins

Soultaker schreef op 08 februari 2004 @ 22:37:
edit:
En nu ik je toch aan het uithoren ben; wie bepaalt of de const of non-const operator[] gebruikt wordt? Zegt de C++ standaard daar iets over of mag de compiler dat zelf uitzoeken?

Afhankelijk van de const-heid van het object waarop je 'm uitvoert en zo?

Professionele website nodig?

maandag 9 februari 2004 00:35

Acties:

maandag 9 februari 2004 14:25

Moderator Devschuur®

Demotivational Speaker

Soultaker: dat lijkt me toch vrij duidelijk

Het gaat hier om een Qualification Conversion

Je keuze bestaat uit:
[list]• basic_string::operator [] ()
• basic_string::operator [] () constJe hebt hier een non-const reference. De non-const functie zal dus boven de const-functie worden gekozen, omdat die meer cv-qualified is dan de const-functie.
Er treedt pas een ambigue-error op als er geen non-const functie was geweest, maar wel ook nog een volatile functie (ze zijn dan beide net zo cv-qualified, namelijk dat er slechts 1 qualifier bij is gekomen)

[ Voor 63% gewijzigd door .oisyn op 09-02-2004 00:44 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

maandag 9 februari 2004 18:05

Ah zo, bedankt voor de uitleg. Ik wist niet zeker of het return type er ook wat mee te maken had; zo van: je hebt niet meer dan een 'const char &' nodig, dus de const operator[] is meer specifiek geschikt. Blijkbaar heeft dat er niets mee te maken.

In het algemeen ga ik er eigenlijk vanuit dat de const en non-const versies van een member function hetzelfde effect hebben. (Helaas gaat dat -blijkbaar- niet altijd op).

Acties:

maandag 9 februari 2004 21:08

Moderator Devschuur®

Demotivational Speaker

Nee, er wordt niets bepaald op basis van return-type (ook logisch als je redeneert dat er geen 2 dezelfde functies mogen zijn met slechts verschillende return-typen, waardoor 2 functies dus altijd verschillen qua signature, en dan gekeken wordt naar de parameters van de verschillende functies. Overigens moet je het object waar je de functie op aanroept zien als een impliciete extra parameter)

Ik vind het ook maar raar dat de const-versie een reference naar een char (0) retourneert, zeker als je ervan uitgaat dat die reference helemaal niet aan het eind van de buffer hoeft te staan (waardoor de optimalisatie voor c_str () ook wegvalt). c_str () hoeft ook niet een pointer naar dezelfde buffer te geven, het is slechts gedefinieerd dat de pointer geldig is tot de eerstvolgende non-const operatie op de string, dus een implementatie zou er ook voor kunnen kiezen om de buffer te dupliceren en er een 0 achter te plakken, die in de toekomst weer een keer wordt vrijgegeven door de string zelf.

Goed, het optimaliseert het zaakje natuurlijk wel om die 0 er altijd achter te hebben zodat je niet eens een buffer hoeft te alloceren bij c_str (), maar dat kan met een definitie dat operator [length ()] const undefined is natuurlijk ook wel. Ik snap dan ook niet waarom het zo is gedefinieerd

[ Voor 14% gewijzigd door .oisyn op 09-02-2004 18:07 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties: