---

Jeg er i gang med at lave en lille menu, men når jeg trykker på "L"
bliver det (L'et) også skrevet ud på skærmen. Det er åbenbart cin der
er skyld i det, for det sker ikke når denne fjernes.

Koden kunne sikkert laves på en meget smartere måde. Men hvis man nu
gerne vil gøre det på denne her måde, er det så muligt at få slettet
det "L" fra den buffer det åbenbart ligger i (så man ikke får det ud
på skærmen) ?? Eller er det ikke muligt med cin/cout ? Og i så fald,
er der nogen tips til hvordan man så kan gøre det ?

--------------klip--------------------
#include "iostream.h"
#include "conio.h"

int main(int argc, char *argv[])
{
cout << "L Problem med bogstav\n";

char pressed_key = toupper(getch());
switch (pressed_key)
{
case 'L': {
clrscr();

cout << "Her kommer et \"l\" pga. cin. Det vil jeg
gerne undgå: " << endl;
char ind;
cin >> ind;
cout << endl << ind << "\n\n";
system("PAUSE");
}
}
}
--------------klip--------------------


Det skal lige siges at jeg er rimelig ny indenfor C++, så måske er det
bare en elementær fejl som alle (undtagen jeg) ved....

På forhånd tak. :)

---

Esben Piltoft wrote:
> Jeg er i gang med at lave en lille menu, men når jeg trykker på "L"
> bliver det (L'et) også skrevet ud på skærmen. Det er åbenbart cin der
> er skyld i det, for det sker ikke når denne fjernes.
>
> Koden kunne sikkert laves på en meget smartere måde. Men hvis man nu
> gerne vil gøre det på denne her måde, er det så muligt at få slettet
> det "L" fra den buffer det åbenbart ligger i (så man ikke får det ud
> på skærmen) ?? Eller er det ikke muligt med cin/cout ? Og i så fald,
> er der nogen tips til hvordan man så kan gøre det ?
>
> --------------klip--------------------
> #include "iostream.h"
> #include "conio.h"

conio.h er ikke en del af ISO/ANSI C++.

Og 'iostream.h' er 'deprecated', brug istedet 'iostream'. Brug iøvrigt
formen <iostream> istedet for "iostream". Læs mere om hvorfor i en bog
om ISO/ANSI C++.

/David

---

> > #include "iostream.h"
> > #include "conio.h"
>
> conio.h er ikke en del af ISO/ANSI C++.
>
> Og 'iostream.h' er 'deprecated', brug istedet 'iostream'. Brug iøvrigt
> formen <iostream> istedet for "iostream". Læs mere om hvorfor i en bog
> om ISO/ANSI C++.

Det kan så godt være. Men min compilere (en prøveversion af Borland
C++ Builder 5) vil have det på den måde (iostream.h og ikke iostream).
Hvis ikke, kommer der compiler-fejl (undefined symbol 'cout' osv).

Du har ikke et link til en side på nettet hvor problematikken "" ifht.
<> bliver forklaret (behøver ikke at være uddybende) ??

---

"Esben Piltoft" <synonym@sol.dk> wrote

>
> Det kan så godt være. Men min compilere (en prøveversion af Borland
> C++ Builder 5) vil have det på den måde (iostream.h og ikke iostream).
> Hvis ikke, kommer der compiler-fejl (undefined symbol 'cout' osv).

Det er kun fordi den er bagud compatibel.
I Standard C++ (som Borland C++Builder 5 i høj grad understøtter), er det
fulde navn for cout "std::cout" fordi den ligger i namespace std - i lighed
med alt andet i Standard Library.

Du kan derfor skrive:

std::cout << "blablabla";

eller

using std::cout;
cout << "blablabla";

eller

using namespace std;
cout << "blablabla";

Det kan godt betale sit at lære Standard C++.
Hvis du har en bog, der siger at det hedder "iostream.h" og at cout ikke
ligger i namespace std, er den enten gammel eller dårlig (måske begge dele),
og det kan måske svare sig at finde en mere moderne.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
> "Esben Piltoft" <synonym@sol.dk> wrote
>
> Det er kun fordi den er bagud compatibel.
> I Standard C++ (som Borland C++Builder 5 i høj grad understøtter), er det

Det ved jeg nu ikke...

>
> Det kan godt betale sit at lære Standard C++.
> Hvis du har en bog, der siger at det hedder "iostream.h" og at cout ikke
> ligger i namespace std, er den enten gammel eller dårlig (måske begge dele),
> og det kan måske svare sig at finde en mere moderne.
>

Enig.

/David

---

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote

> Mogens Hansen wrote:

> >
> > Det er kun fordi den er bagud compatibel.
> > I Standard C++ (som Borland C++Builder 5 i høj grad understøtter), er
det
>
> Det ved jeg nu ikke...
>

Hvad er det du ikke lige ved ?
* At "Det er kun fordi den er bagud compatibel"
* At "I Standard C++ er det fulde navn std::cout"
* At Borland C++Builder 5 i høj grad understøtter Standard C++ ?

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
> "David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
>
> Hvad er det du ikke lige ved ?
> * At "Det er kun fordi den er bagud compatibel"
> * At "I Standard C++ er det fulde navn std::cout"
> * At Borland C++Builder 5 i høj grad understøtter Standard C++ ?
>

At Borland C++Builder 5 i høj grad understøtter Standard C++. Den har
(som mange andre) problemer med templates og andre ting. Den er ikke
mindre compliant end MSVC++ 6 eller gcc 2.95.x, men den er mindre
compliant end MSVC++ 7 (.NET) og gcc 3.0.x for eksempel. Og den er meget
mindre compliant end f.eks. Comeau.

/David

---

Se
http://www.cuj.com/roundup/a.htm
for en seriøs sammenligning af hvor compliant forskellige compilere er.
Sammenligningen kræver dog en del arbejde at fortolke brugbart.

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote

> Mogens Hansen wrote:
> > "David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net>
wrote
> >
> > Hvad er det du ikke lige ved ?
> > * At "Det er kun fordi den er bagud compatibel"
> > * At "I Standard C++ er det fulde navn std::cout"
> > * At Borland C++Builder 5 i høj grad understøtter Standard C++ ?
> >
>
> At Borland C++Builder 5 i høj grad understøtter Standard C++. Den har
> (som mange andre) problemer med templates og andre ting.

Fra ovennævnte undersøgelse, findes bl.a. for Borland C++Builder V5.0:
Dinkumware score: 75 %
Perennial score: 63 % / 67 %
Plum Hall score: 89 % / 74 %

For koden til bogen "Accelerated C++", som indeholder moderne, pæn men
simpel C++ kræver
gcc 2.96: 13 betingede compileringer
MSVC 6.0 (mindst SP4 !): 101 betingede compileringer
MSVC 7.0: 0 betingede compileringer
Borland C++Builder V5.0: 1 betinget compilering
Borland C++Builder V6.0: 0 betingede compileringer

hvor hver betinget compilering er et udtryk for en fejl i compileren.
Færrest betingede compileringer er bedst.

Man skal have en ualmindelig stram fortolkning, for ikke at acceptere at
"Borland C++Builder 5 i høj grad understøtter Standard C++".
I det udsagn ligger der ikke, at den opfylder hele standarden perfekt, ikke
har nogen problemer og ingen andre gør det bedre.

> Den er ikke
> mindre compliant end MSVC++ 6

Det er svært at give et så absolut mål - forskellige egenskaber er væsentlig
for forskellige projekter og personer.
For den kode jeg skriver, må jeg sige tvært imod. MSVC V6.0 er væsentligt
mindre compliant .

> eller gcc 2.95.x, men den er mindre
> compliant end MSVC++ 7 (.NET) og gcc 3.0.x for eksempel.

Baseret på hvilke målinger ?
For mig er det væsentligt at MSVC 7 ikke har partial template
specialisation, og derfor har jeg væsentlig kode, som oversætter på Borland
C++Builder V5.0, Borland C++Builder V6.0, Intel C++ V5.0. og gcc 2.96 som
ikke oversætter med MSVC 7.
Der kommer formodentligt, hvad der for mig er væsentlige forbedringer af C++
implementering, til næste version af MSVC.

> Og den er meget
> mindre compliant end f.eks. Comeau.
>

Der er så vidt jeg ved ikke nogen compiler, der er mere compliant end Comeau
(bortset fra at den ikke har et komplet Standard Library - hvilket er
væsentligt).


Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
> Se
> http://www.cuj.com/roundup/a.htm
> for en seriøs sammenligning af hvor compliant forskellige compilere er.
> Sammenligningen kræver dog en del arbejde at fortolke brugbart.
>

Jeg kender den godt, men tak.

>
> Fra ovennævnte undersøgelse, findes bl.a. for Borland C++Builder V5.0:
> Dinkumware score: 75 %
> Perennial score: 63 % / 67 %
> Plum Hall score: 89 % / 74 %
>
> For koden til bogen "Accelerated C++", som indeholder moderne, pæn men
> simpel C++ kræver
> gcc 2.96: 13 betingede compileringer
> MSVC 6.0 (mindst SP4 !): 101 betingede compileringer
> MSVC 7.0: 0 betingede compileringer
> Borland C++Builder V5.0: 1 betinget compilering
> Borland C++Builder V6.0: 0 betingede compileringer
>
> hvor hver betinget compilering er et udtryk for en fejl i compileren.
> Færrest betingede compileringer er bedst.
>

Klart :)

Jeg er godt klar over dette og lignende resultater. Men det stemmer ikke
overens med mine egne erfaringer.

>
>>eller gcc 2.95.x, men den er mindre
>>compliant end MSVC++ 7 (.NET) og gcc 3.0.x for eksempel.
>
>
> Baseret på hvilke målinger ?

Primært mine egne erfaringer. Men også hvad jeg hører fra forskellige sider.

> For mig er det væsentligt at MSVC 7 ikke har partial template
> specialisation, og derfor har jeg væsentlig kode, som oversætter på Borland
> C++Builder V5.0, Borland C++Builder V6.0, Intel C++ V5.0. og gcc 2.96 som
> ikke oversætter med MSVC 7.

Wow, jeg er overrasket over at 2.96 klarer. Der er meget den ikke
klarer. Mht. PTS, så kan hverken BCB 5 eller MSVC 6 eller 7 compile
f.eks. Alexandrescu's Loki library. Intel's compiler genererer rigtigt
god kode, og er på visse områder også (meget) mere compliant end f.eks.
MSVC 6 (og 7), så den overrasker mig heller ikke. Men jeg er nysgerrig:
Hvor meget "bedre" (compliance- og kodegenereringsmæssigt) er BCB 6? Jeg
har ikke selv prøvet den.

> Der kommer formodentligt, hvad der for mig er væsentlige forbedringer af C++
> implementering, til næste version af MSVC.
>

MS arbejder tilsyneladende på en helt ny C++ compiler. Jeg tror at
'infrastrukturen' er for gammel og for rodet. Lad os håbe at de laver en
bedre compiler så.

>
>>Og den er meget
>>mindre compliant end f.eks. Comeau.
>>
>
>
> Der er så vidt jeg ved ikke nogen compiler, der er mere compliant end Comeau
> (bortset fra at den ikke har et komplet Standard Library - hvilket er
> væsentligt).
>

Enig.

David

---

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
> Mogens Hansen wrote:

[snip]
> Jeg er godt klar over dette og lignende resultater. Men det stemmer ikke
> overens med mine egne erfaringer.
>

Det stemmer klart overens med mine erfaringer, at MSVC 6 har en C++
implementering, der ligger et god stykke under hvad de fleste andre kan
tilbyde.
Men sådan har forskellige personer og projekter forskellige behov.

[snip]
> > Baseret på hvilke målinger ?
>
> Primært mine egne erfaringer. Men også hvad jeg hører fra forskellige
sider.
>

Jeg er endnu ikke stødt på noget (væsentligt) som BCB5 og BCB 6 ikke kan,
som MSVC 7 kan - men jeg har heller ikke prøvet meget.
Hvilke områder drejer det sig om. Har du et eksempel ?
Derimod har jeg adskillige eksempler på væsentlig kode der compilerer med
BCB5 og BCB6 men ikke med MSVC 7. Som sagt er det partial template
specialisation i flere sammenhænge, der fejler.


[snip]
> Mht. PTS, så kan hverken BCB 5 eller MSVC 6 eller 7 compile
> f.eks. Alexandrescu's Loki library.

Da Loki blev lavet, var der _ingen_ compiler, der kunne oversætte hele Loki.
Forskellige compilere kunne oversætte forskellige dele.
Så vidt jeg ved brugte Andrei Alexandrescu primært Metrowerks under
udviklingen af Loki.

[snip]
> Intel's compiler genererer rigtigt
> god kode, og er på visse områder også (meget) mere compliant end f.eks.
> MSVC 6 (og 7), så den overrasker mig heller ikke.

Intel C++ er baseret på EDG front-enden (ligesom Comeau og en række andre).
Intel C++ er klart bedre end MSVC 7, som selv om den er kraftigt forbedret,
ikke er hvad jeg opfatter som en State-of-art C++ implementering.
Hvis MSVC 7 var en State-of-art C++ implementering, her knap 4 år efter C++
Standarden blev vedtaget, ville det ikke være muligt at lave _væsentlige_
forbedringer. Jeg er sikker på at Microsoft vil fremhæve, at der er lavet
_væsentlige_ forbedringer i relation til overholdelse af C++ Standarden, når
de frigiver næste version.
Jeg har store forventninger til næste MSVC version, i relation til C++
compliance - men lad os vente og se.

[snip]
> Men jeg er nysgerrig:
> Hvor meget "bedre" (compliance- og kodegenereringsmæssigt) er BCB 6? Jeg
> har ikke selv prøvet den.
>

Så vidt jeg har lagt mærke til: ikke noget væsentligt, hverken compliance-
eller kodegenereringsmæssigt. Det virker ikke som om der er ændret ret meget
på selve compileren.
Den væsentligte forskel i compliance, som jeg har bemærket, er at Standard
Library implementeringen er skiftet fra RogueWave til STLPort.
Borland siger at de snart vil offentliggøre en compliance-måling, sådan som
de også gjorde for BCB 5.


[snip]
> > Der kommer formodentligt, hvad der for mig er væsentlige forbedringer af
C++
> > implementering, til næste version af MSVC.
> >
>
> MS arbejder tilsyneladende på en helt ny C++ compiler. Jeg tror at
> 'infrastrukturen' er for gammel og for rodet. Lad os håbe at de laver en
> bedre compiler så.
>

Jeg har ikke kendskab til hvorvidt det er en helt ny C++ compiler - har du ?
Jeg troede egentlig "blot" selve compileren var en videre udvikling, på det
eksisterende grundlag - men jeg har ingen konkret viden om det.
Jeg ved at Microsoft har en compiler internt, som kan compilere Loki
umodificeret - hvilket krævet partial template specialisation.
Jeg talte for nyligt med et par stykker, der implementerer Microsoft Visual
C++ - bl.a. ham der har implementeret partial template specialisation i den
kommende version.
Mit klare indtryk, fra de meldinger Microsoft offentligt er kommet med, er
at det nu er højt prioriteret at lave den bedste C++ compiler på MS-Windows
platformen, med implementering af hele Standarden og med tidlige
implementeringer af de ting, der med stor sandsynlighed kommer med i næste
standard, såsom "template typedef".
Denne prioritering er åbenlyst ny, og det forekommer mig at være det
væsentligste. Microsofts hidtidige fodslæbende holdning til overholdelse af
C++ standarden, i hvertfald til og med MSVC 6, skyldes naturligvis ikke at
de ikke har haft evnen eller kapaciteten til at implementere den tidligere.

Venlig hilsen

Mogens Hansen

---

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote

> Mht. PTS, så kan hverken BCB 5 eller MSVC 6 eller 7 compile
> f.eks. Alexandrescu's Loki library.

Prøv at se tråden "The ugly "::template" notation", som Andrei Alexandrescu
startede på comp.lang.c++.moderated i går.
Det drejede sig om en ændring til Loki, som var nødvendig for at BCB5 kunne
compilere det.
Svarende fra Daveed Vandevoorde (arbejder hos EDG) og Gabriel Dos Reis viser
at BCB5 havde ret, og der formodentlig var en fejl i Loki.
Det er ikke trivielt at sige hvem der har ret, og hvem der tager fejl.


Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote

> Svarende fra Daveed Vandevoorde (arbejder hos EDG) ...

Selvsamme Daveed Vandevoorde, der i dag på comp.lang.c++.moderated, har
annonceret at den ført fuldt ISO/ANSI C++ compliant compiler er blevet
frigivet af EDG!

Venlig hilsen

Mogens hansen

---

Mogens Hansen wrote:
> "Mogens Hansen" <mogens_h@dk-online.dk> wrote
>
>
>>Svarende fra Daveed Vandevoorde (arbejder hos EDG) ...
>
>
> Selvsamme Daveed Vandevoorde, der i dag på comp.lang.c++.moderated, har
> annonceret at den ført fuldt ISO/ANSI C++ compliant compiler er blevet
> frigivet af EDG!
>

Yep, det læste jeg! Det er fedt. Desværre er der ikke nogen af os der
har råd til det... Og det er vel kun en front-end, og ikke en hel compiler?


/David

---

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote

> > "Mogens Hansen" <mogens_h@dk-online.dk> wrote
> > Selvsamme Daveed Vandevoorde, der i dag på comp.lang.c++.moderated, har
> > annonceret at den ført fuldt ISO/ANSI C++ compliant compiler er blevet
> > frigivet af EDG!
> >
>
> Yep, det læste jeg! Det er fedt. Desværre er der ikke nogen af os der
> har råd til det... Og det er vel kun en front-end, og ikke en hel
compiler?
>

Ja, men Comeau forventes at frigive sin compiler, baseret på nyeste EDG, i
løbet af denne måned. Den koster $50, hvis man ikke i forvejen har en
licens. Hvis man har en forholdsvis ny licens, får man opdateringen gratis,
og har allerede en beta udgave.
Intel C++ vil forhåbentlig også frigive en, der er baseret på den version
front-end (de har dog netop frigivet V6.0, så man kan gætte på at der går
lidt tid endnu).
Desuden giver det alle konkurenterne noget at leve op til.

Venlig hilsen

Mogens Hansen

---

Esben Piltoft wrote:
>>>#include "iostream.h"
>>>#include "conio.h"
>>
>>conio.h er ikke en del af ISO/ANSI C++.
>>
>>Og 'iostream.h' er 'deprecated', brug istedet 'iostream'. Brug iøvrigt
>>formen <iostream> istedet for "iostream". Læs mere om hvorfor i en bog
>>om ISO/ANSI C++.
>
>
> Det kan så godt være. Men min compilere (en prøveversion af Borland
> C++ Builder 5) vil have det på den måde (iostream.h og ikke iostream).
> Hvis ikke, kommer der compiler-fejl (undefined symbol 'cout' osv).

Det er fordi at cout og andre symboler i standardbiblioteket er i sit
eget namespace, kaldet std. Dvs. at du enten bliver nødt til at kalde
cout for std::cout eller du kan bringe de relevante dele i scope:

using namespace std; // Bringer hele std i scope, ikke nødvendigvis en
// god ide.

eller f.eks.

using std::cout;

>
> Du har ikke et link til en side på nettet hvor problematikken "" ifht.
> <> bliver forklaret (behøver ikke at være uddybende) ??

Mm. Ikke lige ved hånden. Men det burde stå i enhver tutorial. Der er en
god gratis bog om C++ til download på:

http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html

Kort forklaring: "whatever.h" kigger kun efter filen i "current
directory" (hvad det så end er på den pågældende implementation),
hvorimod <iostream> kigger i den implementationsafhængige sti som
indeholder alle predefinerede filer, f.eks. standardbiblioteket.

Med andre ord: når du skal include en fil du selv har lavet bruger du
"", hvis du skal include noget fra standardbiblioteket bruger du <>.

/David

---

> conio.h er ikke en del af ISO/ANSI C++.


Fik vist ikke kommenteret dette.

OK. Men "getch" og "clrscr" ligger (åbenbart) begge i conio.h. Så
fjerner jeg den, er der intet der virker :(
Hvis det ikke er C++, så er det måske C ?? Da det kan compileres i
BCB5 må det vel være noget ;)
Men man kan måske slet ikke undgå at få skrevet bogstavet "L" med ud
:(

---

Den 7 May 2002 21:57:55 -0700 skrev Esben Piltoft:
>> conio.h er ikke en del af ISO/ANSI C++.
>
>
>Fik vist ikke kommenteret dette.
>
>OK. Men "getch" og "clrscr" ligger (åbenbart) begge i conio.h. Så
>fjerner jeg den, er der intet der virker :(
>Hvis det ikke er C++, så er det måske C ?? Da det kan compileres i
>BCB5 må det vel være noget ;)

Ja, Borland libraries.

Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds

---

Esben Piltoft wrote:
>>conio.h er ikke en del af ISO/ANSI C++.
>
> Fik vist ikke kommenteret dette.
>
> OK. Men "getch" og "clrscr" ligger (åbenbart) begge i conio.h. Så
> fjerner jeg den, er der intet der virker :(
> Hvis det ikke er C++, så er det måske C ?? Da det kan compileres i
> BCB5 må det vel være noget ;)
> Men man kan måske slet ikke undgå at få skrevet bogstavet "L" med ud
> :(

En ting som at hente et enkelt bogstav (uden tryk af enter) er platform
specifikt. conio.h er en Windows(DOS?) specifik header. Den funktion som
som getch() har, kan ikke opnås med headers i standard C eller
standard C++.

- Morten.

---

Esben Piltoft wrote:
> --------------klip--------------------
> #include "iostream.h"

#include <iostream> - intet der hedder iostream.h i C++ standarden, og
hvis du includer med gåseøjne udenom leder den vist kun i current dir.

- Morten.

---

Esben Piltoft skrev:

>Jeg er i gang med at lave en lille menu, men når jeg trykker på "L"
>bliver det (L'et) også skrevet ud på skærmen. Det er åbenbart cin der
>er skyld i det, for det sker ikke når denne fjernes.

Nej. Det er ikke rutinernes skyld.

> char pressed_key = toupper(getch());

Her beder du om et tastetryk og omsætter det til et stort
bogstav.

> cin >> ind;

Her beder du om et nyt tastetryk uden at omsætte det. Det er det
sidste du skriver ud. Det er uklart hvorfor du gør det.

> cout << endl << ind << "\n\n";

Jeg vil råde dig til at vælge enten "\n" eller endl.

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/

---

"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote

> Esben Piltoft skrev:
>

> > cout << endl << ind << "\n\n";
>
> Jeg vil råde dig til at vælge enten "\n" eller endl.
>

Forskellen mellem endl og "\n" er at endl flusher streamen efter at have
skrevet '\n' ud til streamen.
Man skal bruge det man har brug for.
Ofte bruger man endl til sidst, når man har skrevet alt det man ønsker.

Venlig hilsen

Mogens Hansen

---

Jeg takker mange gange for alle de (lærerige) svar jeg fik.

Min viden (som jo er på et begynderniveau) om C++ stammer bla. fra
"C++" af Kris Jamsa (knap så god og åbenbart ikke meget at gøre med
C++) og fra en bog der hedder "Teach Yourself C++ in 21 Days" (kan
ikke huske forfatteren) som jeg synes er meget god. Men som åbenbart
heller ikke indeholder ægte C++. Og så fra et C++ kursus på
www.netskole.dk jeg er i gang med lige nu (C++ programmering i niveau
C), som heller ikke underviser i ægte C++ (hvilket jo egenlig ikke er
så hensigtsmæssig).

Det giver unægtelig problemer når hovedparten af det man får proppet i
hovedet ikke er ajourført :(

MEN har bestilt den bog der altid bliver anbefalet i denne NG
("Accelerated C++") - indtil den kommer må jeg jo leve i stenalderen
;)

---

Esben Piltoft wrote:
> Jeg takker mange gange for alle de (lærerige) svar jeg fik.
>
> Min viden (som jo er på et begynderniveau) om C++ stammer bla. fra
> "C++" af Kris Jamsa (knap så god og åbenbart ikke meget at gøre med
> C++) og fra en bog der hedder "Teach Yourself C++ in 21 Days" (kan
> ikke huske forfatteren) som jeg synes er meget god. Men som åbenbart
> heller ikke indeholder ægte C++. Og så fra et C++ kursus på
> www.netskole.dk jeg er i gang med lige nu (C++ programmering i niveau
> C), som heller ikke underviser i ægte C++ (hvilket jo egenlig ikke er
> så hensigtsmæssig).
>
> Det giver unægtelig problemer når hovedparten af det man får proppet i
> hovedet ikke er ajourført :(
>

Du har ret, men du skal ikke være ked af det. Den C++-undervisning jeg
har modtaget på universitetet har heller aldrig været compliant. Det har
for det meste været noget forældet vrøvl.

> MEN har bestilt den bog der altid bliver anbefalet i denne NG
> ("Accelerated C++") - indtil den kommer må jeg jo leve i stenalderen
> ;)

Accelerated C++ er en sublim bog. Man kan som begynder lære stort set
alt det vigtige ved at læse den (jo mere energi og tid man investerer,
jo mere får man ud). Men samtidig er det en bog der er værd at læse
mange gange. Det køb fortryder du ikke. Men _husk_: lad være med at
springe over opgaverne. Man har tit lyst til at læse videre (som med en
god roman), men stoffet synker først rigtigt ind når man prøver at bruge
det. Evt. kan man læse hele bogen først uden opgaver, og så læse den
igen med opgaver.

/David