|
| cin + cin.getline - sidstnævnte springes o~ Fra : Morten Jørgensen |
Dato : 26-04-03 13:46 |
|
Jeg er her for nogle uger siden begyndt på C++, hvor jeg programmerer i
Debian GNU/Linux med compileren g++.
Èt problem jeg dog har opdaget, er, at laver man en cin for senere i
programmet at benytte en cin.getline, så springes sidstnævnte simpelthen
over.
Jeg har forhørt mig på en IRC kanal og fundet ud af at jeg ikke er den
eneste med dette problem og fik så forklaret at laver man en ekstra
cin.getline før den man egentlig skal bruges, så springes kun den første
over - dette virker dog ikke umiddelbart som en speciel god løsning.
I håb om at nogen kan hjælpe med dette,
--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk
| |
Socketd (26-04-2003)
| Kommentar Fra : Socketd |
Dato : 26-04-03 14:04 |
|
On Sat, 26 Apr 2003 14:45:58 +0200
"Morten Jørgensen" <admin@startlinket.dk> wrote:
> Èt problem jeg dog har opdaget, er, at laver man en cin for senere i
> programmet at benytte en cin.getline, så springes sidstnævnte simpelthen
> over.
> Jeg har forhørt mig på en IRC kanal og fundet ud af at jeg ikke er den
> eneste med dette problem og fik så forklaret at laver man en ekstra
> cin.getline før den man egentlig skal bruges, så springes kun den første
> over - dette virker dog ikke umiddelbart som en speciel god løsning.
>
> I håb om at nogen kan hjælpe med dette,
Det er fordi cin ikke smider \n væk og når du så kalder cin.getline() læser den til første \n, hvilket er det første char den læser. Du fixer dette ved fx kun at bruge cin.getline() eller cin.ingore() (tror jeg den hedder).
mvh
socketd
| |
Morten Jørgensen (26-04-2003)
| Kommentar Fra : Morten Jørgensen |
Dato : 26-04-03 15:13 |
|
"Socketd" <db@traceroute.dk> skrev i en meddelelse
news:20030426150348.14ffc0c1.db@traceroute.dk...
Det er fordi cin ikke smider \n væk og når du så kalder cin.getline() læser
den til første \n, hvilket er det første char den læser. Du fixer dette ved
fx kun at bruge cin.getline() eller cin.ingore() (tror jeg den hedder).
Smider hvilken \n væk? Hvor kommer den fra?
Men kan det virkelig passe at programmører, f.eks., som programmerer store
programmer, simpelthen ikke bruger en normal cin eller hvad? Altså forstår
det umiddelbart som om man aldrig skal bruge cin, trods man ellers har læst
om det i mange bøger og steder...
Men vil du forklare hvad cin.ignore() er for noget?
--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk
| |
Mogens Hansen (27-04-2003)
| Kommentar Fra : Mogens Hansen |
Dato : 27-04-03 08:46 |
|
"Morten Jørgensen" <admin@startlinket.dk> wrote
[8<8<8<]
> Men kan det virkelig passe at programmører, f.eks., som programmerer store
> programmer, simpelthen ikke bruger en normal cin eller hvad?
Nej, det kan absolut ikke passe.
Men "cin" er naturligvis ikke velegnet i alle situationer - f.eks. hvis man
laver et program med grafisk brugergrænseflade.
Mere generelt er IO-stream utilstrækkeligt, hvis man skal lave mere
avanceret processering af input.
Det er ikke ualmindeligt at man får brug for at have en reel parser til at
behandle input.
Venlig hilsen
Mogens Hansen
| |
Igor V. Rafienko (26-04-2003)
| Kommentar Fra : Igor V. Rafienko |
Dato : 26-04-03 14:16 |
|
[ Morten Jørgensen ]
[ ... ]
> Èt problem jeg dog har opdaget, er, at laver man en cin for senere i
> programmet at benytte en cin.getline, så springes sidstnævnte
> simpelthen over.
Eh?
Også, hvorfor bruker du cin.getline, heller enn std::getline? Er det
noen bestemte grunner til at du foretrekker char* framfor std::string
fpr å representere linjer internt i programmet?
> Jeg har forhørt mig på en IRC kanal og fundet ud af at jeg ikke er
> den eneste med dette problem og fik så forklaret at laver man en
> ekstra cin.getline før den man egentlig skal bruges, så springes kun
> den første over - dette virker dog ikke umiddelbart som en speciel
> god løsning.
Jeg forstår fortsatt ikke problemet. Du skal lese en byte stream
linjevis, men hva "springes over"?
$ /local/snacks/bin/g++ -Wall getline.cpp
$ ./a.out < getline.cpp
next line is |#include <iostream>|
next line is |#include <string>|
next line is |#include <vector>|
next line is ||
next line is |int|
next line is |main() |
next line is |{|
next line is | using namespace std;|
next line is | char buf[ 100 ];|
next line is | vector< string > data;|
next line is ||
next line is | while ( cin.getline( buf, sizeof buf, '\n' ) )|
next line is | data.push_back( buf );|
next line is ||
next line is | for ( vector< string > :: iterator i = data.begin(); i != data.end(); ++i )|
next line is | cout << "next line is |" << *i << "|\n";|
next line is |}|
$ cat getline.cpp
#include <iostream>
#include <string>
#include <vector>
int
main()
{
using namespace std;
char buf[ 100 ];
vector< string > data;
while ( cin.getline( buf, sizeof buf, '\n' ) )
data.push_back( buf );
for ( vector< string > :: iterator i = data.begin(); i != data.end(); ++i )
cout << "next line is |" << *i << "|\n";
}
$
Standarden for språket inneholder et interessant eksempel på bruken av
basic_istream::getline. Kanskje du kan titte på den for en mer
omstendig omtale av emnet?
Legg også merke til at basic_istream::getline krever kjennskap til
maksimal linjelengde (dvs. at man er nødt til å behandle veldig
"lange" linjer på en spesiell måte) -- kanskje det skaper problemer i
koden din? Dersom du poster det minste eksempelet samt en liten
datafil som illustrerer problemet, ville det ha hjulpet betydelig.
ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
| |
Morten Jørgensen (26-04-2003)
| Kommentar Fra : Morten Jørgensen |
Dato : 26-04-03 15:09 |
|
"Igor V. Rafienko" <igorr@ifi.uio.no> skrev i en meddelelse
news:xjvof2t1jsn.fsf@riva.ifi.uio.no...
> [ Morten Jørgensen ]
>
> [ ... ]
>
> > Èt problem jeg dog har opdaget, er, at laver man en cin for senere i
> > programmet at benytte en cin.getline, så springes sidstnævnte
> > simpelthen over.
>
>
> Eh?
>
> Også, hvorfor bruker du cin.getline, heller enn std::getline? Er det
> noen bestemte grunner til at du foretrekker char* framfor std::string
> fpr å representere linjer internt i programmet?
>
>
> > Jeg har forhørt mig på en IRC kanal og fundet ud af at jeg ikke er
> > den eneste med dette problem og fik så forklaret at laver man en
> > ekstra cin.getline før den man egentlig skal bruges, så springes kun
> > den første over - dette virker dog ikke umiddelbart som en speciel
> > god løsning.
>
>
> Jeg forstår fortsatt ikke problemet. Du skal lese en byte stream
> linjevis, men hva "springes over"?
>
>
> $ /local/snacks/bin/g++ -Wall getline.cpp
> $ ./a.out < getline.cpp
> next line is |#include <iostream>|
> next line is |#include <string>|
> next line is |#include <vector>|
> next line is ||
> next line is |int|
> next line is |main() |
> next line is |{|
> next line is | using namespace std;|
> next line is | char buf[ 100 ];|
> next line is | vector< string > data;|
> next line is ||
> next line is | while ( cin.getline( buf, sizeof buf, '\n' ) )|
> next line is | data.push_back( buf );|
> next line is ||
> next line is | for ( vector< string > :: iterator i = data.begin(); i
!= data.end(); ++i )|
> next line is | cout << "next line is |" << *i << "|\n";|
> next line is |}|
> $ cat getline.cpp
> #include <iostream>
> #include <string>
> #include <vector>
>
> int
> main()
> {
> using namespace std;
> char buf[ 100 ];
> vector< string > data;
>
> while ( cin.getline( buf, sizeof buf, '\n' ) )
> data.push_back( buf );
>
> for ( vector< string > :: iterator i = data.begin(); i != data.end();
++i )
> cout << "next line is |" << *i << "|\n";
> }
> $
>
> Standarden for språket inneholder et interessant eksempel på bruken av
> basic_istream::getline. Kanskje du kan titte på den for en mer
> omstendig omtale av emnet?
>
> Legg også merke til at basic_istream::getline krever kjennskap til
> maksimal linjelengde (dvs. at man er nødt til å behandle veldig
> "lange" linjer på en spesiell måte) -- kanskje det skaper problemer i
> koden din? Dersom du poster det minste eksempelet samt en liten
> datafil som illustrerer problemet, ville det ha hjulpet betydelig.
Doh! Det var noget af et indlæg... Må desværre indrømme at jeg ikke rigtig
ved om du er inde på det rigtige - er som sagt rimelig nybegynder, så fik
ikke noget ud af koden dér. :/
Men problemet ligger i at jeg engang først i programmet ønsker at brugeren
skal kunne indtaste Y eller N, alt efter om den ønsker at læse eller skrive
en fil. Det fungerer fint.
Men når så man vælger at skrive en fil, så bruger jeg cin.getline, så hele
linien kommer med og ikke bare indtil det første punktum. Problemet er dog
bare, som Socketd rigtig nok besvarer, at denne cin.getline simpelthen
springes over og går direkte videre til de næste ting og sager, så man
simpelthen ikke får mulighed for at skrive noget tekst ind. :(
Men er som sagt et af mine første små programmer, så lad venligst være med
at kommentere brugen af cin.getline til indtastning af tekst - jeg ved godt
at en normal texteditor ikke kun giver mulighed for indtastning af én linie.
:P
--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk
| |
Mogens Hansen (26-04-2003)
| Kommentar Fra : Mogens Hansen |
Dato : 26-04-03 15:33 |
|
"Morten Jørgensen" <admin@startlinket.dk> wrote
[8<8<8<]
> Èt problem jeg dog har opdaget, er, at laver man en cin for senere i
> programmet at benytte en cin.getline, så springes sidstnævnte simpelthen
> over.
Ikke forstået...
F.eks. hvordan "laver man en cin" ?
Post en lille stump kode, der viser hvad du har gjort og hvilke problemer du
har.
Det vil øge din sandsynligheden for at få et nyttigt svar.
Venlig hilsen
Mogens Hansen
| |
Ivan Johansen (26-04-2003)
| Kommentar Fra : Ivan Johansen |
Dato : 26-04-03 15:56 |
|
Morten Jørgensen wrote:
> Èt problem jeg dog har opdaget, er, at laver man en cin for senere i
> programmet at benytte en cin.getline, så springes sidstnævnte simpelthen
> over.
> Jeg har forhørt mig på en IRC kanal og fundet ud af at jeg ikke er den
> eneste med dette problem og fik så forklaret at laver man en ekstra
> cin.getline før den man egentlig skal bruges, så springes kun den første
> over - dette virker dog ikke umiddelbart som en speciel god løsning.
Jeg tror at dit problem er at du ikke har forstået hvordan streams
fungerer. Det er dog ikke fordi at jeg selv har voldsomt meget styr på det.
Hvis jeg forstår dig rigtigt har noget lignende:
char Str[10];
cin >> Str;
Brugeren taster så en tekst ind. Dette kunne f.eks. være "Yes". Denne
tekst lægges over i Str, men brugeren lave jo også et linieskift(hedder
\n i C++). Dette linieskift bliver ikke lagt over i Str men bliver
liggende i input bufferen, så du kan læse det senere.
Når du senere kalder cin.getline flyttes tekst fra input bufferen over i
den angivne variabel, indtil den støder på \n og \n fjernes fra bufferen.
Dette betyder at kaldet til cin.getline giver dig en tom streng, da der
ligger et \n i bufferen i forvejen. Dette er der ikke nogen mærkeligt
eller forkert i.
Hvis brugeren i stedet havde skrevet "Yes No" ville kaldet til
cin.getline have give dig "No", da det ligger tilbage i bufferen. Det er
derfor du først skal tømme bufferen med et kald til cin.getline eller
cin.ignore.
Som Igor siger bør du bruge std::string i stedet for char[] fordi der
praktisk talt ikke er nogen grænse for hvor meget en std::string kan
indeholde. Kaldet til cin>>Str er direkte farligt, da du ikke på nogen
måde kan sikre dig at brugeren ikke taster for meget ind.
Ivan Johansen
| |
LDOTS (26-04-2003)
| Kommentar Fra : LDOTS |
Dato : 26-04-03 16:07 |
|
Det er rigtigt, det Socketd siger. Jeg går ud fra, at du til det første
Y/N-spørgsmål bruger noget i retning af:
char answer;
cin >> answer;
Når brugeren skriver noget på linien, vil "cin >> answer;" først
returnere, når der er trykket på enter. Da answer er af typen char, vil
det første (og kun det) tegn blive læst fra cin's buffer og gemt i
variablen answer. Men hvis brugeren har skrevet mere end ét tegn på
linien, vil de resterende tegn stadig være i input bufferen. Imidlertid
vil der altid være et "ny linie"-tegn, da brugeren jo slutter med enter-
tasten. Hvis du fx skriver:
char a, b;
cin >> a >> b;
Og når du kører programmet skriver fx "x" og trykker på <enter>, vil a
indeholde tegnet 'x', mens b indeholder "ny linie", som skrives som
'\n'. Hvis du i stedet skriver "xy", vil a indeholde 'x', mens b
indeholder 'y'. Der vil således stadig være en '\n' tilbage i input
bufferen, som ikke er blevet læst endnu. Det er her det går galt for
cin.getline. cin.getline læser nemlig indtil første '\n'-tegn. Se dette
eksempel:
char answer;
char line[255];
cin >> answer;
if (asnwer == 'Y')
// do something...
cin.getline(line, sizeof(line));
Hvis brugeren på første linje skriver "y" og trykker <enter>, smides
'y' ind i answer, mens der stadig er '\n' tilbage i bufferen. Senere
kaldes cin.getline, men da '\n' er først i bufferen, vil strengen line
blive tom. Hvis brugeren derimod skrev "yz" og trykkede <enter>, ville
answer indeholde 'y', mens line ville indeholde "z", da både 'z' og
'\n' ventede i input bufferen.
Løsningen på problemet er altså, at alt skramlet fra "cin >> answer;"-
kaldet skal fjernes før en cin.getline. Det gøres nemmest ved at kalde
cin.getline, som du allerede gør, fordi det vil fjerne alle tegn til og
med '\n' fra input bufferen.
| |
Morten Jørgensen (26-04-2003)
| Kommentar Fra : Morten Jørgensen |
Dato : 26-04-03 18:17 |
|
"LDOTS" <none@none.none> skrev i en meddelelse
news:Xns9369AE32224ELDOTS@62.243.74.162...
> Det er rigtigt, det Socketd siger. Jeg går ud fra, at du til det første
> Y/N-spørgsmål bruger noget i retning af:
>
> char answer;
> cin >> answer;
>
> Når brugeren skriver noget på linien, vil "cin >> answer;" først
> returnere, når der er trykket på enter. Da answer er af typen char, vil
> det første (og kun det) tegn blive læst fra cin's buffer og gemt i
> variablen answer. Men hvis brugeren har skrevet mere end ét tegn på
> linien, vil de resterende tegn stadig være i input bufferen. Imidlertid
> vil der altid være et "ny linie"-tegn, da brugeren jo slutter med enter-
> tasten. Hvis du fx skriver:
>
> char a, b;
> cin >> a >> b;
>
> Og når du kører programmet skriver fx "x" og trykker på <enter>, vil a
> indeholde tegnet 'x', mens b indeholder "ny linie", som skrives som
> '\n'. Hvis du i stedet skriver "xy", vil a indeholde 'x', mens b
> indeholder 'y'. Der vil således stadig være en '\n' tilbage i input
> bufferen, som ikke er blevet læst endnu. Det er her det går galt for
> cin.getline. cin.getline læser nemlig indtil første '\n'-tegn. Se dette
> eksempel:
>
> char answer;
> char line[255];
>
> cin >> answer;
> if (asnwer == 'Y')
> // do something...
>
> cin.getline(line, sizeof(line));
>
> Hvis brugeren på første linje skriver "y" og trykker <enter>, smides
> 'y' ind i answer, mens der stadig er '\n' tilbage i bufferen. Senere
> kaldes cin.getline, men da '\n' er først i bufferen, vil strengen line
> blive tom. Hvis brugeren derimod skrev "yz" og trykkede <enter>, ville
> answer indeholde 'y', mens line ville indeholde "z", da både 'z' og
> '\n' ventede i input bufferen.
>
> Løsningen på problemet er altså, at alt skramlet fra "cin >> answer;"-
> kaldet skal fjernes før en cin.getline. Det gøres nemmest ved at kalde
> cin.getline, som du allerede gør, fordi det vil fjerne alle tegn til og
> med '\n' fra input bufferen.
Jeg nøjes bare med at skrive videre her, hvis det er okay. :)
Men nu tror jeg faktisk jeg er ved at have styr på det. Du siger det er helt
korrekt at lave en cin.getline ekstra, men:
1: findes der ikke nogen helt specifik funktion som netop har til opgave et
tømme input bufferen?
2: hvis jeg bare vælger at sætte en ekstra cin.getline ind, skal den så pege
på en variabel og have << med eller kan dette undlades?
3: cin.ignore nævner I også, men hvad gør denne så? Har den netop kun til
opgave at tømme bufferet eller bruges den som brugte man cin.getline?
--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk
| |
Mogens Hansen (26-04-2003)
| Kommentar Fra : Mogens Hansen |
Dato : 26-04-03 20:21 |
|
"Morten Jørgensen" <admin@startlinket.dk> wrote
[8<8<8<]
> 1: findes der ikke nogen helt specifik funktion som netop har til opgave
et
> tømme input bufferen?
cin.ignore(cin.rdbuf()->in_avail());
som finder ud af hvor mange tegn der er tilgængelige i læsebufferen, og
fjerner det antal.
> 2: hvis jeg bare vælger at sætte en ekstra cin.getline ind, skal den så
pege
> på en variabel og have << med eller kan dette undlades?
ja, men ovenstående er nok mere direkte
> 3: cin.ignore nævner I også, men hvad gør denne så? Har den netop kun til
> opgave at tømme bufferet eller bruges den som brugte man cin.getline?
Funktionen (vi ser bort fra lidt template detaljer)
istream::ignore(streamsize n = 1, int_type delim = traits::eof());
tager tegn ud af streamen og smider dem væk.
Det sker indtil:
- hvis n != numeric_limits<int>::max(), når der er taget n tegn ud
- der ikke er flere tegn. (setsate(eofbit) bliver kaldt)
- c == delim (c tages ud)
Venlig hilsen
Mogens Hansen
| |
Morten Jørgensen (26-04-2003)
| Kommentar Fra : Morten Jørgensen |
Dato : 26-04-03 22:03 |
|
"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:b8elrq$2op9$1@news.cybercity.dk...
> > 1: findes der ikke nogen helt specifik funktion som netop har til opgave
> et
> > tømme input bufferen?
>
> cin.ignore(cin.rdbuf()->in_avail());
>
> som finder ud af hvor mange tegn der er tilgængelige i læsebufferen, og
> fjerner det antal.
Fandt ud af at cin.ignore() virkede fint uden nogen parametre, så er det
korrekt forstået at det ikke er påkrævet?
> > 2: hvis jeg bare vælger at sætte en ekstra cin.getline ind, skal den så
> pege
> > på en variabel og have << med eller kan dette undlades?
>
> ja, men ovenstående er nok mere direkte
"ja" til hvilken af delene? Min compiler brokkede sig da jeg ikke gav den
nogen parametre...
> > 3: cin.ignore nævner I også, men hvad gør denne så? Har den netop kun
til
> > opgave at tømme bufferet eller bruges den som brugte man cin.getline?
>
> Funktionen (vi ser bort fra lidt template detaljer)
> istream::ignore(streamsize n = 1, int_type delim = traits::eof());
> tager tegn ud af streamen og smider dem væk.
> Det sker indtil:
> - hvis n != numeric_limits<int>::max(), når der er taget n tegn ud
> - der ikke er flere tegn. (setsate(eofbit) bliver kaldt)
> - c == delim (c tages ud)
Dette synes jeg virkede fint, trods din lidt indviklede og uddybede
beskrivelse for en nybegynder som mig :P Men umiddelbart står jeg mest til
at bruge denne...
--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk
| |
Mogens Hansen (27-04-2003)
| Kommentar Fra : Mogens Hansen |
Dato : 27-04-03 08:46 |
|
"Morten Jørgensen" <admin@startlinket.dk> wrote
[8<8<8<]
> Fandt ud af at cin.ignore() virkede fint uden nogen parametre, så er det
> korrekt forstået at det ikke er påkrævet?
ja, det er korrekt forstået.
Det skyldes at "ignore" har default værdier for de 2 parametre den tager.
Når man kalder "ignore" uden parametre fjerner den eet tegn, idet default
værdien for første parameter er 1.
[8<8<8<]
> "ja" til hvilken af delene? Min compiler brokkede sig da jeg ikke gav den
> nogen parametre...
ok, jeg kan godt se tvetydigheden.
Ja til at hvis du kalder cin.getline skal den have en parameter, der peger
på en variabel.
Du kalder i givet fald en af funktionerne
istream& istream::getline(char_type* s, streamsize n);
istream& istream::getline(char_type* s, streamsize n, char_type delim);
Alternativt kan du, som flere fornuftigt har anbefaldet kalde
istream& getline(istream& is, string& str, charT delim);
istream& getline(istream& is, string& str);
så arbejder du med string objekter i stedet for char array og char pointer.
[8<8<8<]
> Dette synes jeg virkede fint, trods din lidt indviklede og uddybede
> beskrivelse for en nybegynder som mig :P
Du havde gentagne gange efterlyst en beskrive af hvad "ignore" gør ...
Prøv at læse beskrivelsen een gang til, eventuelt skrevet ud på et stykke
papir.
Venlig hilsen
Mogens Hansen
| |
Morten Jørgensen (27-04-2003)
| Kommentar Fra : Morten Jørgensen |
Dato : 27-04-03 09:29 |
|
"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:b8g1gs$11g5$1@news.cybercity.dk...
> ja, det er korrekt forstået.
> Det skyldes at "ignore" har default værdier for de 2 parametre den tager.
> Når man kalder "ignore" uden parametre fjerner den eet tegn, idet default
> værdien for første parameter er 1.
Så det vil sige at den kun fjernet det første tegn i bufferen og ikke alle?
> ok, jeg kan godt se tvetydigheden.
> Ja til at hvis du kalder cin.getline skal den have en parameter, der peger
> på en variabel.
Oki.
> Du havde gentagne gange efterlyst en beskrive af hvad "ignore" gør ...
> Prøv at læse beskrivelsen een gang til, eventuelt skrevet ud på et stykke
> papir.
Ja, jeg ved godt jeg efterlyste en "beskrivelse", men da havde jeg så ikke
regnet med at du ville komme med en masse nye ting og sager som f.eks.:
istream& istream::getline(char_type* s, streamsize n, char_type delim);
Dette forstår jeg nemlig ikke meget af, især det første istream&
istream::getline. Jeg plejer nemlig kun at skrive cin.getline(), men nu ikke
gå så meget i dybden med det her, da jeg som sagt først begyndte på C++ for
et par uger siden og stadig kun har lavet nogle meget små programmer.
--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk
| |
Bertel Lund Hansen (27-04-2003)
| Kommentar Fra : Bertel Lund Hansen |
Dato : 27-04-03 10:46 |
|
Morten Jørgensen skrev:
>Ja, jeg ved godt jeg efterlyste en "beskrivelse", men da havde jeg så ikke
>regnet med at du ville komme med en masse nye ting og sager som f.eks.:
>istream& istream::getline(char_type* s, streamsize n, char_type delim);
Det er en generel beskrivelse af en funktion og derfor praktisk -
når man lige ved hvad det betyder.
Opdelt i elementer er det:
<type> <udvidet navn> ( <prm1>, <parm2>, <parm3> ) ;
Typen er istream (glem indtil videre &-tegnet).
Det udvidede navn fortæller at funktionen er beskrevet i modulet
istream og hedder getline (modul::navn).
Paramtrene er specificeret med deres type og navn.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Morten Jørgensen (27-04-2003)
| Kommentar Fra : Morten Jørgensen |
Dato : 27-04-03 13:06 |
|
"Bertel Lund Hansen" <nospamfor@lundhansen.dk> skrev i en meddelelse
news:4d9navkudme2qd07dasj6sdk5emrmj1jpg@news.stofanet.dk...
> Det er en generel beskrivelse af en funktion og derfor praktisk -
> når man lige ved hvad det betyder.
>
> Opdelt i elementer er det:
>
> <type> <udvidet navn> ( <prm1>, <parm2>, <parm3> ) ;
>
> Typen er istream (glem indtil videre &-tegnet).
>
> Det udvidede navn fortæller at funktionen er beskrevet i modulet
> istream og hedder getline (modul::navn).
>
> Paramtrene er specificeret med deres type og navn.
Ja, det var egentlig også det jeg regnede med at det var, men vidste ikke
lige hvordan jeg skulle beskrive det :(
--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk
| |
Mogens Hansen (27-04-2003)
| Kommentar Fra : Mogens Hansen |
Dato : 27-04-03 12:01 |
|
"Morten Jørgensen" <admin@startlinket.dk> wrote
[8<8<8<]
> Så det vil sige at den kun fjernet det første tegn i bufferen og ikke
alle?
Ja.
[8<8<8<]
> Ja, jeg ved godt jeg efterlyste en "beskrivelse", men da havde jeg så ikke
> regnet med at du ville komme med en masse nye ting og sager som f.eks.:
>
> istream& istream::getline(char_type* s, streamsize n, char_type delim);
>
> Dette forstår jeg nemlig ikke meget af, især det første istream&
> istream::getline.
Ok.
Er du med på skelnen mellem klasser (typer) og objekter ?
Man ved at "cin" er et objekt af typen "istream" (input-stream).
Det vil (bortset fra lidt detaljer) at der findes en klasse
class istream;
og der findes et objet
istream cin;
Klassen istream er (nogenlunde) erklæret ved
class istream /* don't care about base classes */
{
public:
// ...
// slightly incorrect signature
istream& getline(char* s, unsigned n, char delim);
};
Den har således (bl.a.) en member-funktion "getline", som
* returnerer en reference til et objekt af typen "istream".
Det er iøvrigt en reference til objektet selv - altså f.eks. "cin"
* hedder "getline"
* som tager 3 parametre:
1. En pointer til et char array, hvor den læste linie skal placeres
2. En angivele af hvor det char array er
3. Et tegn der angiver hvilket tegn, der angiver at linien er slut.
Det er typisk linie-skift tegnet.
Når en sådan funktion skal skrives skriver man:
istream& istream::getline(char* s, unsigned n, char delim)
{
// ...
}
Jeg håber at det gjorde det lidt tydligere for dig.
> Jeg plejer nemlig kun at skrive cin.getline(), men nu ikke
> gå så meget i dybden med det her, da jeg som sagt først begyndte på C++
for
> et par uger siden og stadig kun har lavet nogle meget små programmer.
Der er 4 væsentlige ting der kan hjælpe med at lære C++
1. Brug det - som du gør
2. Hav en _god_ kilde til information.
Jeg anbefaler normalt bogen:
Accelerated C++
Andrew Koenig, Barbare E. Moo
ISBN 0-201-70353-X
3. Brug en moderne compiler
4. Hav nogen der kender C++ som man kan spørge, når man er i tvivl.
Problemet er naturligvis at sikre sig at den man spørger faktisk
giver gode råd.
Denne nyhedsgruppe er ofte et glimrende sted at spørge, idet dårlige
råd ofte vil blive korrigeret.
Venlig hilsen
Mogens Hansen
| |
Morten Jørgensen (27-04-2003)
| Kommentar Fra : Morten Jørgensen |
Dato : 27-04-03 13:22 |
|
"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:b8gcuj$1fgs$1@news.cybercity.dk...
> > Så det vil sige at den kun fjernet det første tegn i bufferen og ikke
> alle?
>
> Ja.
Det vil vel også i de fleste tilfælde være nok? Eller?... Men hvordan får
jeg den så til at slette alt, eller i så fald bare noget mere?
> Ok.
> Er du med på skelnen mellem klasser (typer) og objekter ?
>
> Man ved at "cin" er et objekt af typen "istream" (input-stream).
> Det vil (bortset fra lidt detaljer) at der findes en klasse
> class istream;
> og der findes et objet
> istream cin;
>
> Klassen istream er (nogenlunde) erklæret ved
> class istream /* don't care about base classes */
> {
> public:
> // ...
> // slightly incorrect signature
> istream& getline(char* s, unsigned n, char delim);
> };
>
> Den har således (bl.a.) en member-funktion "getline", som
> * returnerer en reference til et objekt af typen "istream".
> Det er iøvrigt en reference til objektet selv - altså f.eks. "cin"
> * hedder "getline"
> * som tager 3 parametre:
> 1. En pointer til et char array, hvor den læste linie skal placeres
> 2. En angivele af hvor det char array er
> 3. Et tegn der angiver hvilket tegn, der angiver at linien er slut.
> Det er typisk linie-skift tegnet.
>
> Når en sådan funktion skal skrives skriver man:
> istream& istream::getline(char* s, unsigned n, char delim)
> {
> // ...
> }
>
> Jeg håber at det gjorde det lidt tydligere for dig.
Det var faktisk også sådan jeg egentlig gik ud fra at cin osv. var
opbygget... Altså fra PHP er jeg jo vant til at setcookie() f.eks. kaldes en
funktion, men det var jeg så lidt i tvivl om om man i C++ kunne kalde cout,
cin osv. sådan også. I starten gik jeg jo ud fra at det var noget som bare
altid var dér, men nu kan jeg jo se at det faktisk bare er en ganske normal
klasse liggende i iostream filen (ved ikke lige om det er så enkelt, men en
sådan opfattelse har jeg fået).
> Der er 4 væsentlige ting der kan hjælpe med at lære C++
> 1. Brug det - som du gør
> 2. Hav en _god_ kilde til information.
> Jeg anbefaler normalt bogen:
> Accelerated C++
> Andrew Koenig, Barbare E. Moo
> ISBN 0-201-70353-X
Har lånt sådan et "C++" hæfte på biblioteket fra IDG af forfatteren Kris
Jamsa, som jeg har læst. Deri synes jeg at langt det meste kendte jeg fra
PHP, så det var jo bare dejligt ;) og så var der selvfølgelig det med
klasser osv., som jeg ret hurtigt fik styr på. Pointere og referencer har
jeg dog ikke helt så meget styr på, da jeg endnu kun har læst om det og ikke
prøvet at bruge det, men det er jeg sikker på kommer hurtigt.
Så har jeg endvidere også lånt bogen "C++ Grundbog" også fra IDG af
forfatteren Jesse Liberty. Den kan jeg se er en dansk oversættelse af "Sams
Teach Yourself C+++ in 24 Hours" på ca. 350 sider, hvor hæftet "kun" var på
omkring de 130.
Men så jeg regner da med det vil gå rimelig "glidende" fremad, nu jeg på
forhånd har programmeret PHP i snart 2 år og samtidig så tror jeg egentlig
jeg venter lidt med at læse sidstnævnte bog, da den som sagt er ret lang og
samtidig synes jeg også jeg har fået en hel del ud af hæftet, så jeg skal jo
bare igang med at få programmeret noget :P
> 3. Brug en moderne compiler
Hvordan vil du betegne g++ compileren som "følger med" Debian GNU/Linux
3.0r1 woody?
> 4. Hav nogen der kender C++ som man kan spørge, når man er i tvivl.
> Problemet er naturligvis at sikre sig at den man spørger faktisk
> giver gode råd.
> Denne nyhedsgruppe er ofte et glimrende sted at spørge, idet
dårlige
> råd ofte vil blive korrigeret.
Kender faktisk ingen programmører eller andet, men har stor erfaring med
både nyhedsgrupper og www.eksperten.dk
--
Med venlig hilsen / Best regards
Morten Jørgensen
http://www.startlinket.dk
| |
Mogens Hansen (27-04-2003)
| Kommentar Fra : Mogens Hansen |
Dato : 27-04-03 16:39 |
|
"Morten Jørgensen" <admin@startlinket.dk> wrote
[8<8<8<]
> Har lånt sådan et "C++" hæfte på biblioteket fra IDG af forfatteren Kris
> Jamsa, som jeg har læst.
Søg eventuelt på google hvad der tidligere er blevet sagt om pågældende bog.
Jeg har kigget på de eksempler, der er tilgængelige som download.
Jeg har f.eks. endnu til gode at se blot et eneste eksempel fra den bog, der
helt banalt er formelt korrekt.
Dertil kommer at den så vidt jeg husker ikke behandler meget vigtige klasser
i C++ Standard biblioteket som vector, map og string.
Endvidere ....
Drop den.
[8<8<8<]
> Så har jeg endvidere også lånt bogen "C++ Grundbog" også fra IDG af
> forfatteren Jesse Liberty.
Den lille smule jeg har set fra Jesse Liberty's bog tyder på at den er langt
mere korrekt end Kris Jamsa's.
Jeg opretholder dog min tidligere anbefaling. Den er iøvrigt på knap 300
sider.
> Den kan jeg se er en dansk oversættelse af "Sams
> Teach Yourself C+++ in 24 Hours" på ca. 350 sider, hvor hæftet "kun" var
på
> omkring de 130.
Det er mere væsentligt at indholdet er godt, end at bogen er lille.
> Men så jeg regner da med det vil gå rimelig "glidende" fremad, nu jeg på
> forhånd har programmeret PHP i snart 2 år og samtidig så tror jeg egentlig
> jeg venter lidt med at læse sidstnævnte bog, da den som sagt er ret lang
og
> samtidig synes jeg også jeg har fået en hel del ud af hæftet, så jeg skal
jo
> bare igang med at få programmeret noget :P
Hmm...
[8<8<8<]
> Hvordan vil du betegne g++ compileren som "følger med" Debian GNU/Linux
> 3.0r1 woody?
g++ er normalt glimrende, dog vil jeg almindeligvis anbefale at man bruger
en version 3.x i stedet for de lidt ældre 2.9x.
Skriv eventuelt
g++ --version
for at finde ud af hvilken version du bruger.
Venlig hilsen
Mogens Hansen
| |
Torben W. Hansen (28-04-2003)
| Kommentar Fra : Torben W. Hansen |
Dato : 28-04-03 14:57 |
|
"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:b8gt9q$24c2$1@news.cybercity.dk...
>
> > Har lånt sådan et "C++" hæfte på biblioteket fra IDG af forfatteren Kris
> > Jamsa, som jeg har læst.
> Drop den.
Enig - den er virkelig ringe...
> > Så har jeg endvidere også lånt bogen "C++ Grundbog" også fra IDG af
> > forfatteren Jesse Liberty.
> Den lille smule jeg har set fra Jesse Liberty's bog tyder på at den er
langt
> mere korrekt end Kris Jamsa's.
Jeg er også nybegynder (på 4-5 måned) - efter min vurdering er "C++
Grundbog" seriøs og fornuftig skrevet, men har lidt skønhedsfejl hist og
pist.
1. Personligt synes jeg at eksemplerne er lidt for lange, hvor det man
ønsker at vise, nogle gange drukner i uvæsentlige detaljer.
2. Er lidt uklar omkring virtuelle funktioner i kapitel 17, hvor gruppen og
især Mogens Hansen har været behjælpelig.
3. Man har forklaret "using namespace" men overset at forklare selve
"namespace erklæringen".
4. Bogen behandler ikke direkte klasserne i C++ Standard biblioteket som
vector, map og string, men kun nogle forenklede selvfabrikerede klasser med
strenge, linkede lister samt træer.
> Jeg opretholder dog min tidligere anbefaling. Den er iøvrigt på knap 300
sider.
Jeg har endnu denne tilgode selvom jeg faktisk har den stående på hylden -
men "Accelerated C++" har fået mange gode anbefalinger med den accelererede
indlæringsmetodik, som bogen bl.a. er kendt for.
Som opslagsbog har jeg desuden gjort brug af "Thinking in C++, Vol.1 og
Vol.2" som gratis kan hentes på http://mindview.net/Books ...
Med venlig hilsen
Torben W. Hansen
| |
Socketd (26-04-2003)
| Kommentar Fra : Socketd |
Dato : 26-04-03 16:23 |
|
On Sat, 26 Apr 2003 16:12:37 +0200
"Morten Jørgensen" <admin@startlinket.dk> wrote:
> Smider hvilken \n væk? Hvor kommer den fra?
Det har LDOTS svaret ganske godt på, så den lader jeg lige stå.
> Men kan det virkelig passe at programmører, f.eks., som programmerer store
> programmer, simpelthen ikke bruger en normal cin eller hvad? Altså forstår
> det umiddelbart som om man aldrig skal bruge cin, trods man ellers har læst
> om det i mange bøger og steder...
Tja, jeg vil anbefale at du indlæser alt med getline til en string.
> Men vil du forklare hvad cin.ignore() er for noget?
Jeg mener den fjerner alt i inputbufferen til og med det første '\n'.
Ligesom med getline() kan du selv bestemme hvad den skal læse til,
('\n' er default).
mvh
socketd
| |
|
|