standard-erstatning til getch()

[knuto]

Hallo!

 

PS: Hopp gjerne ned til den "tjukke delen" om du har lita tid.

Eg har i det siste jobba ein del med console-programmering i windows for å setje meg litt inn i enkle brukarvennlege program, men som ikkje plent er kommandobaserte.

 

Eit problem eg har støytt på no er at eg prøver å lage ein tekstboks. I enkel console-bruk er jo det berre cin >> variabel, men no skal eg ha det "inn i ein boks", altså innanfor 4 hjørne.

 

Eg har studert dette litt, og sett i forskjellige kildekodar, ettersom eg ikkje fant noko emne om akkurat det på msdn, og har funne ut kor enkelt det eigentleg er.

 

Det er jo berre til å ha ei løkke gåande, og "ta imot" ein bokstav per "runde", og parse linjeskift, og når det har kome til enden av linja.

 

Teoretisk er jo dette lett, men alle plasser der denne metoden blir brukt blir det brukt funksjonen getch() til å "få tak i" ein enkelt bokstav frå brukaren.

 

Ettersom eg ikkje bruker borland eller microsoft sine kompilatorar finnes ikkje denne funksjonen, så eg må bruke noko tilsvarande.

 

Eg hadde eigentleg trudd at eg kunne ha brukt funksjonen cin.get(), men tydelegvis takler han det ikkje slik som eg vil. (forstår faktisk ikkje heilt kva som skjer, men det fungerer i alle fall tydeleg vis ikkje slik som eg vil ha det).

 

Spørsmålet (om du vil er det nok å lese dette):

Kva for ein standardfunksjon må eg bruke for å motta kun 1 bokstav frå brukaren før scriptet går vidare? Altså ikkje til mellomrom eller enter, men bare 1 bokstav. Og ikkje nok med det. Han må "ta i mot" både enter-klikk, og "piltast-klikk". Dette er akkurat kva funksjonen getch() gjer, men den er uaktuell (fordi kompilatoren ikkje støtter han, og fordi det er tåpeleg windowsprogrammering).

[prebenl]

cin.peek()?

 

mente man kunne gjøre noe sånt med den, men kan være det er jeg som husker feil..

[JBlack]

Det du ønsker er å lese av tastetrykk, og ikke lese fra stdin, ettersom når man leser fra stdin så får man ikke noe input fra consolen før det trykkes enter (eller inputbufferet tømmes av andre grunner.)

 

Edit: Jeg vet ikke om det er en del av standardbibliotekene til C/C++.

Endret 4. juli 2005 av JBlack

[JBlack]

peek() leser fra filen uten å fjerne tegnet, men du får ikke filen fra stdin noe fortere av den grunn. Du må fortsatt vente på at terminalen gir den til programmet ditt.

 

For mer om problemet, se: http://www.eskimo.com/~scs/C-faq/q19.1.html

 

Dersom jeg har misstolket deg, og du bare vil ha en rutine som parser samtlige tegn når de kommer fra stdin, bruk fread. Slik:

 

#include <unistd.h>

#include <stdio.h>

 

int main(){

char b;

void *buf=&b;

while(1){

  fread(buf,1,1,stdin);

  printf("%x ",b);

}

}

[knuto]

peek() leser fra filen uten å fjerne tegnet, men du får ikke filen fra stdin noe fortere av den grunn. Du må fortsatt vente på at terminalen gir den til programmet ditt.

 

For mer om problemet, se: http://www.eskimo.com/~scs/C-faq/q19.1.html

 

Dersom jeg har misstolket deg, og du bare vil ha en rutine som parser samtlige tegn når de kommer fra stdin, bruk fread. Slik:

 

#include <unistd.h>

#include <stdio.h>

 

int main(){

char b;

void *buf=&b;

while(1){

  fread(buf,1,1,stdin);

  printf("%x ",b);

}

}

Nei, du har ikkje misstolka meg. Eg har ikkje fått lest den artikkelen du linka til, så eg er kanskje litt lite oppdatert (tar det som sengelesing), men vil det seie at getch er det beste alternativet i denne samanhengen og at eg bør gå over til ein ikkje-standard kompilator? Getch er jo ekstremt enkelt... (Dette er kanskje rett anledning til å lære seg assemble)

 

Nei, den var litt dryg. Eg skal vedde på at det etter kvart kjem nokon her som har erfaring med det (optimistisk sett) Det må jo være mogleg å bruke tastaturet i C++. Viss ikkje dette går, synes eg at det må være eit av dei største mangla i C++.

[JBlack]

Skal du ha kontroll over tastaturets input direkte, så må du bruke et bibliotek tilpasset den plattformen du jobber på. (f.x curses, som inneholder getch() m.m.)

 

Problemet ligger ikke i språket, men i hvordan terminaler fungerer. I utgangspunktet rapporterer de ikke tastetrykk til programmet før man trykker enter.

 

Les linken jeg ga ovenfor.

 

curs_getch(3X)                                                  curs_getch(3X)



NAME
      getch, wgetch, mvgetch, mvwgetch, ungetch, has_key - get (or push back)
      characters from curses terminal keyboard

SYNOPSIS
      #include <curses.h>

      int getch(void);
      int wgetch(WINDOW *win);
      int mvgetch(int y, int x);
      int mvwgetch(WINDOW *win, int y, int x);
      int ungetch(int ch);
      int has_key(int ch);

..........

[Atypic]

Som JBlack sier.

 

Det du leter etter er en ANSI-måte å få unbuffered input på. Svaret er at det finst ikke. Ulike plattformer behandler inndata på ulike måter, derfor finst det ingen standard.

[knuto]

Nei, eg har forstått at det ikkje finnes nokon standard, men betyr det at getch er den _einaste_ metoden å gjere det på? Går det ann å installere biblioteket med getch i DEV-C++?

[atlepe]

Du trenger et bibliotek som gjør det du trenger, og header-filer som du kan include. Det kan installeres uten problem. Hva som allerede er på, og hva du må installere selv for windows får noen windowsbrukere bidra med.

 

Godt og konkret skrevet Atypic!

[knuto]

Obs. Feilen ligg på mi side. Biblioteket conio.h (der getch() ligger) er visst allereie installert i DEV-C++, noko som eg trudde eg hadde funne ut at det ikkje var før. Beklager alt styret, så då kan eg jo berre bruke denne funksjonen

[Duronator]

prøvd getchar() ?

[DarkSlayer]

skal man lese tastatur direkte så må man bruke operativsystemets sine kommandoer ...

 

std biblioteket til c++ er ok i opplæringsøyemed og generellt ellers, men når det gjelder kommunikasjon mot hardware/operativsystem så duger det dårligt, nettopp fordi bibliotekene ble forsåvidt lagt for lenge siden. Så de fungerer på sett og vis.

 

men ikke tenk på det. Kan man ikke så kan man ikke. Når du har lært deg såpass med vanlig c++ så er tiden inne for å ta steget videre, nettopp mot api bibliotek for å gjøre litt avanserte ting.

 

std biblioteket passer for eksempel bedre mot linux siden all kommunikasjon i os skjer med filer. Der leser man bare tastaturfila med fopen og disse, og derfor så blir dette lettere, enn mot windows ...

 

...det er alltid en snagg et sted

[☀ ❄]

std biblioteket til c++ er ok i opplæringsøyemed og generellt ellers, men når det gjelder kommunikasjon mot hardware/operativsystem så duger det dårligt, nettopp fordi bibliotekene ble forsåvidt lagt for lenge siden. Så de fungerer på sett og vis.

Det har ingenting med alder å gjøre (standardbiblioteket er faktisk ganske moderne). Som Atypic sier: Grunnen til at slik behandling av inndata ikke finnes i standardbiblioteket er at forskjellige plattformer behandler inndata på forskjellig måte. Husk på at C++ er et generelt programmeringsspråk. Det betyr at alt som utføres av standardbiblioteket i utgangspunktet skal kunne utføres på en hvilken som helst plattform som støtter C++, med likt resultat. Når man da tar i betraktning at C++ brukes på plattformer man knapt nok kunne tenke seg at innebærer programmering i det hele tatt (f.eks. en døråpner), sier det seg selv at spesialiserte oppgaver som den getch() utfører ikke hører hjemme i standardbiblioteket.

 

 

std biblioteket passer for eksempel bedre mot linux siden all kommunikasjon i os skjer med filer. Der leser man bare tastaturfila med fopen og disse, og derfor så blir dette lettere, enn mot windows ...

Det er forskjell mulighet og hensiktsmessig bruk. Du skal nok lete lenge etter en vanlig utvikler som bruker fd 0 direkte, fremfor iostreams, under Linux.

[DarkSlayer]

std biblioteket kan brukes til mye, men moderne er å dra det litt langt...

Det fungerer fint for å bygge opp funksjonalitet, men helt ærlig... det kunne godt ha blitt kraftigt modernisert på veldig mange områder.

 

Men når man lager progs med litt ok funksjonalitet, så må man fort ty til andre bibliotek av ymse slag, enten for å lese tastatur, få noe på skjermen, bruke .... you name it. Men det er ok det.

 

Ideelt sett burde std. biblioteket vært mye bedre, men ... så burde mye annet også.

[☀ ❄]

std biblioteket kan brukes til mye, men moderne er å dra det litt langt...

Det fungerer fint for å bygge opp funksjonalitet, men helt ærlig... det kunne godt ha blitt kraftigt modernisert på veldig mange områder.

Hva mener du burde vært annerledes?

[DarkSlayer]

nå er det vanskeligt å lage et bibliotek som støtter alle platformer fullt ut, og kan brukes til mye mer...

 

men..

bedre støtte for å lese input og sende output til div ting som har eksistert lenge. Idag så bruker jeg win32 funksjoner for å kommunisere med win. Linux er litt enklere her og spesielt om man lager ting for skallet til linux.

 

Bedre støtte for ting som unicode (ingen støtte i std), og manipulering av dette.

 

Bedre støtte for filbehandling.

 

osv osv ... det er sikkert mye mer av ting som noenlunde kunne vært standardisert, men idag så henter vi bare ned bibliotek av ymse slag for å få ting gjort. Enten opens. ting, eller kommersielle pakker som qt

 

så et stort probleme er det ikke, for c++ har myyyyye av ting og tang du kan bruke. Men std.biblioteket syns jeg selv er akterutseilt som en "komplett" pakke som skal være moderne.

 

Tar du java, delhi, vb, c# så er disse langt mer moderne pakker, men har også store mangler på ulike områder.

[☀ ❄]

Men std.biblioteket syns jeg selv er akterutseilt som en "komplett" pakke som skal være moderne.

 

Du misforstår hensikten med standardbiblioteket. Standardbiblioteket skal ikke være "komplett". Det skal ikke gjøre alt, det skal gjøre det viktigste.

 

For øvrig er det stor forskjell på ukomplett og umoderne.