Beste svaret
Dette er et av favorittspørsmålene mine for å diskvalifisere C ++ eksperter .
Selvfølgelig betyr system («PAUSE») å opprette et OS-skall og la det utføre en «PAUSE» -kommando.
Egentlig at fungerer bare på windows, hvor det IKKE er et sikkerhetsproblem , siden» PAUSE «er en shell-intern kommando som ikke påkaller noe eksternt program (med mindre systemskallet selv er hacket … men enn du har et annet problem)
På Windows er det til og med ikke et stort «ytelsesproblem»: bildet av CMD.EXE er nesten helt sikkert allerede i RAM, CMD-datasegmentet er ganske lite og … vel … du ber om å PAUSE (ikke løpe så fort du kan!)
På systemer annet enn windows , dette fungerer ikke (det kan være ingen PAUSE-kommando) og er en sikkerhetslekkasje (noen ca n Lag et PAUSE-program for å gjøre sin egen oppgave i stedet for din).
Så med mindre du målretter mot din egen eneste maskin og ditt eget eneste operativsystem, vil det ikke være bærbart og kan til og med være farlig.
Men problemet blir nå “ hva skal jeg gjøre i stedet?”
Det er fantastisk å se hvordan det meste av svaret er… GALT , fordi… de kan ikke fungere!
La oss se hvorfor:
Programmet ditt cin -s to heltall, viser noen resultater og … må det vente eller avslutte?
La oss anta du vil vente: hvordan svarer du på cin >> a og cin >> b?
Din innspill vil se ut som
12\n
34\n
MÅ du skrive de f. .ing returnerer, fordi du må avslutte konsollinngangsmodus.
Nå vil cin >> a forbruke “12”. Returen vil forbli i bufferen.
cin >> b vil forbruke alle mellomrommene (inkluderer retur) til det første ikke-mellomrommet, enn alle sifrene. Det vil konsumere “\ n34” (og angi b = 34).
Det er inntil en f… ing avkastning i inngangsbufferen. Så la oss nå se hvordan alle ekspertene FAIL!
- bruker
cin.get(): GALT : Dette vil lese en tegning og fortsette. Og det er ett tegn i inngangsbufferen, så det vil ikke stoppe ! - bruk
cin.ignore(): GALT: Det er fremdeles at f… ing avkastning i bufferen. Du ignorerer det … og går lenger. Ingen pause .
Så hvordan skal du gjøre det?
I dette eksemplet, du må ignorere alt er i bufferen til og med retur, så be om noe annet å ignorere:
cin.clear(); // clear an eventual "bad read" flag
cin.ignore(BIG\_NUMBER,’\n’); // ignore all remaining pending input
cin.get(); //just read one more!
BIG\_NUMBER, er … noe større enn tegnene du kan skrive på konsollen før du trykker på enter.
Standard måten å få dette nummeret på er
numeric\_limits
(don t glem #include )
Så, til slutt …
void pause()
{
cin.clear();
cin.ignore(numeric\_limits
cin.get();
}
vil vær en skikkelig pause -funksjon.
Men fortell meg nå:
Hva om noen skriver
12abcd\n
??
Den første lesningen vil se» 12 «og den andre» a … «og vil mislykkes (ikke et siffer!). B blir ikke lest i det hele tatt.
Enn pause() vil fjerne «dårlig bit» og forkaste abcd\n les “1” og avslutt med glede.
Moral : når du leser tall, sjekk alltid at lesingen ikke mislyktes, og kast eventuell dårlig input:
while(!(cin >> b))
{ cin.clear(); cin.ignore(numeric\_limits
Men dette krever også administrasjon av instruksjoner og så videre … og fører for langt vekk fra det faktiske formålet.
Svar
Det er ikke en ren løsning. Noen mennesker kan kalle det «hack», noen kan kalle det «løsning».
Du skjønner, en av de fine egenskapene til C-språk er dens bærbarhet . Og med system (“PAUSE”) syntaks, mister du denne bærbarheten, fordi det avhenger av konsollen du bruker til å kjøre programmet.
Hva er alternativene nå? Dessverre er det ingen helt ren løsning. Jeg har sett folk som bruker denne syntaksen
std::cout << “Press any key to continue…”;
std::cin >> Some\_variable\_you\_declared\_in\_advance;
I utgangspunktet er dette bare nok en hack, ved hjelp av stream for å sette programmet på pause. Men du mister ikke bærbarheten din på denne måten.
En av de reneste løsningene jeg vet er denne (men den er veldig smakavhengig):
void pause () {
std::cin.ignore();
}
På denne måten kan du bruke din egen pausefunksjon . Det leser i utgangspunktet ett tegn og ignorerer det, som er akkurat det du vil oppnå. Men som sagt er det absolutt ikke den beste løsningen, bare min personlige favoritt.