system("PAUSE"); uten "Trykk en tast..."

[Alex_2xA]

hmm, ok, har egentlig ikke tenkt over det før, men den funker jo i allefall. Men hvis det er noe bedre bør jeg jo kansje heller bruke det

[Steinbitglis]

Følgende kode ga ikke ønsket resultat:

#include <iostream>
#include <cstdlib>

using namespace std;

int main(int argc, char *argv[])
{
 int tall;
 cout << "Hello, world!" << endl;
 cin >> tall; cout << "vent...";
 cin.ignore(numeric_limits<int>::max(),'\n');

 return EXIT_SUCCESS;
}

 

Resultatet av cin.ignore var ikke at maskina ventet på et linjeskift.

cin.ignore må nødvendigvis brukes i kombinasjon med cin.get() ville jeg tro

[prebenl]

std::cin.ignore(std::numeric_limits<int>::max(), '\n');

 

Denne funket ikke for meg i Windows. Kompilert med Visual Studio .NET 2003.

Programmet hopper rett forbi og avslutter. Kan jeg ha gjort noe feil?

[☀ ❄]

Hmm. Prøvde koden nå, og den fungerte (selvfølgelig) ikke. Synes det er rart -- jeg er overbevist om at den har fungert tidligere. Vel, jeg har sikkert gjort en glipp ett eller annet sted. Skal se om jeg finner ut av det, og sier ifra om jeg gjør det (men tekstbasert programmering er ikke det jeg gjør mest av, så jeg lover ikke noe).

[knuto]

fungerer her...

[knuto]

EDIT: bobbeltpost

Endret 16. april 2005 av knuto

[dabear]

Følgende har alltid fungert for meg.

#include <iostream>
#include <cstdlib>

using namespace std;

int main()
{
int stopClose;
cout << "Hello, world!" << endl;

cin >> stopClose;
// så snart det kommer respons fra brukeren, avsluttes programmet

}

[knuto]

Følgende har alltid fungert for meg.

#include <iostream>
#include <cstdlib>

using namespace std;

int main()
{
int stopClose;
cout << "Hello, world!" << endl;

cin >> stopClose;
// så snart det kommer respons fra brukeren, avsluttes programmet

}

Koden din er tungvindt ettersom det blir oppretta ein temp-variabel (som òg vil bruke minne). Løysinga til Myubi må absolutt vere den beste!

[kjetil7]

Skal heller ikke skryte av at jeg er ekspert på iostream-delen av standardbiblioteket, men dette bør fungere:

void press_enter()
{
   if(!std::cin)
   {
       std::cin.clear();
       std::cin.ignore(std::numeric_limits<int>::max(), '\n');
   }

   std::cin.ignore(std::numeric_limits<int>::max(), '\n');
}


int main()
{
   int num;
   
   std::cin >> num;
   
   std::cout << "press enter.." << std::endl;
   press_enter();
}

[prebenl]

Denne koden funket for meg =) Flott å ha noe annet en system("pause") om jeg skal lage noe seriøst en dag..

[Rainer32]

Bare litt på siden:

jeg er ganske fersk i C++. Har programmert masse java, men begynte med c++ etter jul. Jeg ser at dere bruker std-namespacet mye i denne tråden, men allikevel ikke inkluderer det som namespace i begynnelsen av programmene deres. Forstår jeg det riktig, - at det ikke er god programmeringsskikk å skrive using namespace std først i programmet? Er det slik at denne inkluderingen vil få systemet til å jobbe så mye tregere at det ikke vil være lønnsomt? Eller det er bare slik at vi som leser forumet for enkelthets skyld skal se hvor vi har tilgang på disse funksjonene?

[kjetil7]

Det hadde ikke vært noe problem å skrive "using namespace std;" i begynnelsen av programmet. Men vi bruker det fordi som du sier, for vi for enkelthets skyld skal se hvor vi har tilgang på funksjonene. Hvis jeg skulle skrevet et lite program for eget bruk hadde jeg garantert gjort det selv for å slippe å skrive std:: x antall ganger. Vi kan også eventuelt skrive:

using std::cout;
using std::cin;
using std::endl;

 

Namespaces har ingen som helst innvirkning på hastighet under runtime.

 

Men du skal være veldig forsiktig med er å bruke using i header-filer.

Endret 17. april 2005 av kjetil7

[prebenl]

for mitt vedkommende virker det som om følgende funker fint:

 

#include <iostream>
using namespace std;

int main()
{
 cout << "Resultater fra programmet";
 cin.ignore(1, '\n');
}

 

Er dette en dårlig løsning, og i såfall hvorfor?

[hishadow]

http://www.cplusplus.com/

 

char* gets(char* buffer);

 

Get a string from stdin:

Reads characters from stdin and stores them into buffer until a newline (\n) or EOF character is encountered. The ending newline character (\n) is not included in the string returned, instead of that a null character (\0) is appended at the end of the resulting string. There is no limit on how many characters gets may read, so it's your job to determinate the length of the buffer you will need. Use this function to read complete lines including spaces (and any character). This function will return everything readed before the newline character (\n).

 

Parameters:

buffer

    pointer to a buffer where to receive the resulting string.

 

Return Value.

  On success, the buffer parameter is returned.

  On end-of-file or error, a null pointer is returned. Use ferror or feof to check what happened.

 

Denne kan dere jo bruke :!:

[☀ ❄]

Er dette en dårlig løsning, og i såfall hvorfor?

Ja, det er en dårlig løsning, fordi:

1) Om du bruker cin tidligere i programmet vil den ikke vente på interaksjon med brukeren (ser det ut til fra det lille jeg har testet).

2) Om det er flere LF-tegn i cins buffer vil den heller ikke vente på interaksjon (om jeg har forstått istream::ignore() rett).

 

 

hishadow: Jess! gets() er en så sikker funksjon at gcc advarer dersom man forsøker å bruke den...

/tmp/ccsT92Ry.o(.text+0x1d): In function `main':

: warning: the `gets' function is dangerous and should not be used.

[Alex_2xA]

MYUBI jeg bare tenkte iom at han brukte "pause", så var det store sjanser for bruk av borland eller vs (dermed burde vel getch være til hjelp og poenget er vel å hjelpe her), men jawohl herr fuhrer, skal ta det du sier til etterretning.

Selvfølgelig er det positivt å hjelpe. Jeg poengterer bare at system("pause") er en håpløs fremgangsmåte, og vi klarer bedre.

 

Jeg synes Scott Meyers sier det ganske fint:

 

Strive for portable code. It's not much harder to write portable programs than to write unportable ones, and only rarely will the difference in performance be significant enough to justify unportable constructs (see Item 16). Even programs designed for custom hardware often end up being ported, because stock hardware generally achieves an equivalent level of performance within a few years. Writing portable code allows you to switch platforms easily, to enlarge your client base, and to brag aabout supporting open systems. It also makes it easier to recover if you bet wrong in the operating system sweepstakes.

 

Degeim: Hvis ikke denne kodesnutten virker, anbefaler jeg å bytte kompilator.

 

#include <iostream>
#include <limits>

void wait()
{
   std::cin.ignore(std::numeric_limits<int>::max(), '\n');
}

int main()
{
   std::cout << "Hei.\n";
   wait();
}

Hva sakl jeg skrive for å fa den til å funke for alle tastene? den du skrev der funket bate for "enter", men jeg trenger en "any key" sak

[prebenl]

Myubi, finnes det ingen enkel funkjson for å tømme hele inn-bufferet før jeg kjører funksjonen min? Det burde vel gå an til å få det bra til uten å bruke limits-headeren..?

 

Alex_2xA: Er det ikke mulig å bruke cin.peek()?

Endret 18. april 2005 av Geofrank

[kjetil7]

Du kan ikke bare sjekke om inn-bufferet er tomt, men også om det er i en såkalt "fail state". Det er derfor jeg har brukt cin.clear() i eksemplet mitt.

Endret 18. april 2005 av kjetil7

[☀ ❄]

Så vidt jeg vet er istream::ignore() den eneste måten å tømme en innbuffer på. Uansett, hvorfor vil du unngå <limits>? Størrelsesforskjellen på binærfilen kompilert med og uten <limits> her var 300 byte -- neppe kritisk harddiskplass. Kallet til std::numeric_limits<int>::max() tar heller ikke nevneverdig tid -- om det har noen "overhead" i det hele tatt er det ubetydelig, fordi du tross alt skal vente på interaksjon med en bruker.

 

Alex_2xA: Hvis du vil bruke any-tasten på tastaturet ditt, må du nok bruke plattformspesifikke funksjoner, ja

[prebenl]

Jeg skjønner hva du mener. Tenkte bare <limits> og funksjonen (som var litt lengre enn min) ville få små testapplikasjoner til å se unødvendig avanserte ut. Men det kan man jo se an selv, til privat testbruk og opplæring er det vel ikke alt for kritisk at koden skal være portabel til alle plattformer (selv om det er lurt å venne seg til).