/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
Søger tutorials
Fra : Niels


Dato : 26-07-05 12:43

Søger gratis tutorials til C++.
Ikke bare sådan en start-guide, men noget med eksempler osv...

--
Mvh. Niels (http://niels.spoweb.dk)
http://niels.spoweb.dk/noop - Søgemaskine



 
 
Bertel Brander (26-07-2005)
Kommentar
Fra : Bertel Brander


Dato : 26-07-05 20:59

Niels wrote:
> Søger gratis tutorials til C++.
> Ikke bare sådan en start-guide, men noget med eksempler osv...

http://cplus.about.com/od/beginnerctutorial/l/blcplustut.htm
http://www.cprogramming.com/tutorial.html

--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel

Michael (27-07-2005)
Kommentar
Fra : Michael


Dato : 27-07-05 03:18

"Niels" <niels@spoweb.dk> skrev i en meddelelse
news:42e621d7$0$18640$14726298@news.sunsite.dk...
> Søger gratis tutorials til C++.
> Ikke bare sådan en start-guide, men noget med eksempler osv...
>
> --
> Mvh. Niels (http://niels.spoweb.dk)
> http://niels.spoweb.dk/noop - Søgemaskine
>
>

Lidt generelt om programmering og SE.

Teach Yourself Programming in Ten Years
http://www.norvig.com/21-days.html

Med venlig hilsen
Michael

--
"For a moment, nothing happened. Then, after a second or so, nothing
continued to happen."

- Hitchhikers guide to the galaxy.


Morten V Pedersen (27-07-2005)
Kommentar
Fra : Morten V Pedersen


Dato : 27-07-05 22:56

Michael wrote:
> "Niels" <niels@spoweb.dk> skrev i en meddelelse
> news:42e621d7$0$18640$14726298@news.sunsite.dk...
>
>>Søger gratis tutorials til C++.
>>Ikke bare sådan en start-guide, men noget med eksempler osv...
>>
>>--
>>Mvh. Niels (http://niels.spoweb.dk)
>>http://niels.spoweb.dk/noop - Søgemaskine
>>
>>
>
>
> Lidt generelt om programmering og SE.
>
> Teach Yourself Programming in Ten Years
> http://www.norvig.com/21-days.html
>
> Med venlig hilsen
> Michael
>
> --
> "For a moment, nothing happened. Then, after a second or so, nothing
> continued to happen."
>
> - Hitchhikers guide to the galaxy.
>
http://maz.spork.dk/

--

// Morten - www.mortenvp.dk

Mogens Hansen (27-07-2005)
Kommentar
Fra : Mogens Hansen


Dato : 27-07-05 22:56


"Morten V Pedersen" <mvpe04@aau.control.aau.dk.invalid> wrote in message
news:42e7e63d$0$18636$14726298@news.sunsite.dk...

[8<8<8<]
> http://maz.spork.dk/

Hvis det er hans bog "C++, Dataabstraktion og Objektorienteret
Programmering", så er den så gammel (1991) at det kun har historisk
interesse.

Venlig hilsen

Mogens Hansen



Arne Vajhøj (28-07-2005)
Kommentar
Fra : Arne Vajhøj


Dato : 28-07-05 06:50

Mogens Hansen wrote:
> "Morten V Pedersen" <mvpe04@aau.control.aau.dk.invalid> wrote in message
> news:42e7e63d$0$18636$14726298@news.sunsite.dk...
>>http://maz.spork.dk/
>
> Hvis det er hans bog "C++, Dataabstraktion og Objektorienteret
> Programmering", så er den så gammel (1991) at det kun har historisk
> interesse.

Det er jeg ikke helt enig i.

Hvis man lige skal igang med C++ er det nok generende
med gamle header navne, manglende using std og den slags.

Men til forståelse af virtual metoder, copy constructor,
assignment operator etc. synes jeg stadig at det er
en meget velskrevet bog.

Arne

Mogens Hansen (28-07-2005)
Kommentar
Fra : Mogens Hansen


Dato : 28-07-05 08:13


"Arne Vajhøj" <arne@vajhoej.dk> wrote in message
news:42e871e6$0$23217$edfadb0f@dread16.news.tele.dk...
> Mogens Hansen wrote:
>> "Morten V Pedersen" <mvpe04@aau.control.aau.dk.invalid> wrote in message
>> news:42e7e63d$0$18636$14726298@news.sunsite.dk...
>>>http://maz.spork.dk/
>>
>> Hvis det er hans bog "C++, Dataabstraktion og Objektorienteret
>> Programmering", så er den så gammel (1991) at det kun har historisk
>> interesse.
>
> Det er jeg ikke helt enig i.

Ok

>
> Hvis man lige skal igang med C++ er det nok generende
> med gamle header navne, manglende using std og den slags.

Det kan i værste fald forhindre programmerne i at oversætte, og hvordan skal
en begynder vide hvad der skal ændres for at få det til at virke.

>
> Men til forståelse af virtual metoder, copy constructor,
> assignment operator etc. synes jeg stadig at det er
> en meget velskrevet bog.

Ok - jeg har ikke læst bogen.
Hvordan skal en begynder vide hvilke dele af bogen der er gyldig og hvilke
dele der er udtryk for forældet tankegang ?

Alene det at den er skrevet i 1991 gør at store dele af Standard Library
ikke kan være være beskrevet.
Det betyder at meget væsentlige klasser som "std::string", "std::vector" og
"std::map" ikke benyttes. Det har en væsentlig indflydelse på
programmeringsstilen - nødvendigvis til det dårligere.
Desuden kan nyttig, moderne brug af templates ikke være indeholdt i bogen -
det har også en væsentlig, indflydelse på programmeringsstilen.


Jeg kiggede lige hurtigt i bogen, og læste starten på kapitel "2.4.4
Referencetyper".
Den beskriver slet ikke det som for mig er den vigtigste forskel mellem
pointere og referencer: i et gyldigt program vil en reference _altid_
referere til et objekt (kan alså ikke være 0) som referencen initialiseres
til og den kan _aldrig_ sættes til at referere til andre objekter.

Et andet eksemepel:
Forklaringen i "2.6.4 main()" af main siger at den kan have signaturen
void main(int argc, char** argv);
Det er ikke, og har aldrig være rigtigt - main returnerer _altid_ int

Endnu andet eksempel:
Forklaringen i "2.9.2 new og delete" af "new []" bruger "delete" til at
frigive med - der burde bruges "delete []".
Koden i bogen giver "undefined behaviour"

Ydermere virker bogen mere som en reference manual end en tutorial.
Den tager en syntaktisk indgangvinkel til beskrivelsen og der er meget langt
mellem eksemplerne.

Det er oplagt ikke tilrådeligt at benytte den bog som udgangspunkt for at
lære C++.


Personligt vil jeg anbefale og man køber en god bog. (eller låner den på
biblioteket) - husk at for mange er tid vigtigere end penge, og tid spildt
på at lære noget forkert er spildt. Derfor er det vigtigt at bruge tiden
fornuftigt på gode kilder.
Et par gode bud er:

Accelerated C++
Andrew Koenig, Barbara E. Moo
ISBN 0-201-70353-X

C++ Primer, 4 Edition
Stanley B. Lippman, Josée Lajoie, Barbara E. Moo
ISBN 0-201-72148-1

You Can Do It!
Francis Glassborow
ISBN 0-470-86398-6

Der er langt flere dårlige end gode kilder til at lære C++

Venlig hilsen

Mogens Hansen



Arne Vajhøj (28-07-2005)
Kommentar
Fra : Arne Vajhøj


Dato : 28-07-05 20:38

Mogens Hansen wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> wrote in message
> news:42e871e6$0$23217$edfadb0f@dread16.news.tele.dk...
>>Mogens Hansen wrote:
>>>"Morten V Pedersen" <mvpe04@aau.control.aau.dk.invalid> wrote in message
>>>news:42e7e63d$0$18636$14726298@news.sunsite.dk...
>>>>http://maz.spork.dk/
>>>Hvis det er hans bog "C++, Dataabstraktion og Objektorienteret
>>>Programmering", så er den så gammel (1991) at det kun har historisk
>>>interesse.

>>Hvis man lige skal igang med C++ er det nok generende
>>med gamle header navne, manglende using std og den slags.
> Det kan i værste fald forhindre programmerne i at oversætte, og hvordan skal
> en begynder vide hvad der skal ændres for at få det til at virke.

Det ved han ikke. Bogen er ikke egnet til begyndere idag.
Og var det sådan set heller ikke da den var brand ny.

> Hvordan skal en begynder vide hvilke dele af bogen der er gyldig og hvilke
> dele der er udtryk for forældet tankegang ?

Tankegangen i bogen den indsigt den giver i OOP i C++ er ikke
forældet og bliver det formentligt ikke de næste 20 år.

Det er kun et par syntaktiske småting som har ændret sig.

> Alene det at den er skrevet i 1991 gør at store dele af Standard Library
> ikke kan være være beskrevet.
> Det betyder at meget væsentlige klasser som "std::string", "std::vector" og
> "std::map" ikke benyttes. Det har en væsentlig indflydelse på
> programmeringsstilen - nødvendigvis til det dårligere.
> Desuden kan nyttig, moderne brug af templates ikke være indeholdt i bogen -
> det har også en væsentlig, indflydelse på programmeringsstilen.

Jeg tror at vi har en meget forskellig opfattelse af hvad
der er vigtigt i C++.

Prædefinerede klasser og funktioner kan man slå op i en
manual - og hvis man har forstået OOP og C++ er det normalt
lige ud af landevejen at bruge.

Hvis man ikke har forstået forskellen på virtuelle og ikke
virtuelle metoder, hvornår copy constructor og assignment operator
kaldes etc. så bliver man aldrig nogen god C++ programmør - og den
slags er 100 gange vanskeligere at lære end hvilke metoder der
er på FooBar klassen.

> Jeg kiggede lige hurtigt i bogen, og læste starten på kapitel "2.4.4
> Referencetyper".
> Den beskriver slet ikke det som for mig er den vigtigste forskel mellem
> pointere og referencer: i et gyldigt program vil en reference _altid_
> referere til et objekt (kan alså ikke være 0) som referencen initialiseres
> til og den kan _aldrig_ sættes til at referere til andre objekter.

Han kommer til detaljer om reference typer i afsnit 2.11.13 !

> Et andet eksemepel:
> Forklaringen i "2.6.4 main()" af main siger at den kan have signaturen
> void main(int argc, char** argv);
> Det er ikke, og har aldrig være rigtigt - main returnerer _altid_ int

Ja.

Men folk overlever nok.



> Endnu andet eksempel:
> Forklaringen i "2.9.2 new og delete" af "new []" bruger "delete" til at
> frigive med - der burde bruges "delete []".
> Koden i bogen giver "undefined behaviour"

Det er faktisk en alvorlig fejl. Det må jeg indrømme.

> Ydermere virker bogen mere som en reference manual end en tutorial.
> Den tager en syntaktisk indgangvinkel til beskrivelsen og der er meget langt
> mellem eksemplerne.

Nu har jeg læst bogen.

Min opfattelse er:
- den er meget lidt reference agtig
- den er meget lidt fokuseret på syntax
- den er netop en tutorial i OOP
- med nogle simple gennemgåend eksempler får
den faktisk forklaret en masse

> Det er oplagt ikke tilrådeligt at benytte den bog som udgangspunkt for at
> lære C++.

Helt enig.

Det er en lærebog i OOP i C++ ikke en lærebog i C++.

Jeg vil heller ikke anbefale den til begyndere.

Til gengæld vil jer godt anbefale den til dem som
vil lidt videre med OOP delen. Jeg synes at han på en
meget pædagogisk måde får forklaret mange vigtige ting.

Arne

Bertel Lund Hansen (28-07-2005)
Kommentar
Fra : Bertel Lund Hansen


Dato : 28-07-05 21:06

Arne Vajhøj skrev:

>Det ved han ikke. Bogen er ikke egnet til begyndere idag.
>Og var det sådan set heller ikke da den var brand ny.

Hvorfor anbefaler du den så til en nybegynder?

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

Arne Vajhøj (28-07-2005)
Kommentar
Fra : Arne Vajhøj


Dato : 28-07-05 21:34

Bertel Lund Hansen wrote:
> Arne Vajhøj skrev:
>>Det ved han ikke. Bogen er ikke egnet til begyndere idag.
>>Og var det sådan set heller ikke da den var brand ny.
>
> Hvorfor anbefaler du den så til en nybegynder?

Det gør jeg heller ikke.

Kronologien er:

Morten foreslog den.

Mogens hævdede at den kun havde historisk interesse.

Jeg påstod at selv om den er lidt gammel synes
jeg stadig et det er en glimrende bog, men til
"OOP i C++" ikke til "C++ for begyndere".

Arne

Mogens Hansen (29-07-2005)
Kommentar
Fra : Mogens Hansen


Dato : 29-07-05 07:05


"Arne Vajhøj" <arne@vajhoej.dk> wrote in message
news:42e94129$0$23233$edfadb0f@dread16.news.tele.dk...
> Bertel Lund Hansen wrote:
>> Arne Vajhøj skrev:
>>>Det ved han ikke. Bogen er ikke egnet til begyndere idag.
>>>Og var det sådan set heller ikke da den var brand ny.
>>
>> Hvorfor anbefaler du den så til en nybegynder?
>
> Det gør jeg heller ikke.

Prøv at læse dit oprindelige indlæg een gang til - det kan vanskeligt
forståes på andre måder end at du mener/mente at den er brugbar for folk der
"lige skal i gang med C++".

>
> Kronologien er:
>
> Morten foreslog den.
>
> Mogens hævdede at den kun havde historisk interesse.
>
> Jeg påstod at selv om den er lidt gammel synes
> jeg stadig et det er en glimrende bog, men til
> "OOP i C++" ikke til "C++ for begyndere".

Hvor i det oprindelige indlæg lavede du den skelnen - helt præcist ?

Venlig hilsen

Mogens Hansen



Arne Vajhøj (29-07-2005)
Kommentar
Fra : Arne Vajhøj


Dato : 29-07-05 07:53

Mogens Hansen wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> wrote in message
> news:42e94129$0$23233$edfadb0f@dread16.news.tele.dk...
>>Bertel Lund Hansen wrote:
>>>Hvorfor anbefaler du den så til en nybegynder?

>>Det gør jeg heller ikke.

> Prøv at læse dit oprindelige indlæg een gang til - det kan vanskeligt
> forståes på andre måder end at du mener/mente at den er brugbar for folk der
> "lige skal i gang med C++".

Hvis anbefale==brugbar og generende==brugbar, så har du ret ...

>>Kronologien er:
>>
>>Morten foreslog den.
>>
>>Mogens hævdede at den kun havde historisk interesse.
>>
>>Jeg påstod at selv om den er lidt gammel synes
>>jeg stadig et det er en glimrende bog, men til
>>"OOP i C++" ikke til "C++ for begyndere".
>
> Hvor i det oprindelige indlæg lavede du den skelnen - helt præcist ?

"Hvis man lige skal igang med C++"

og

"Men til forståelse af virtual metoder, copy constructor,
assignment operator etc."

(og der er ingen præmie for at gætte hvilken
der svarer til "C++ for begyndere" og hvilken der svarer
til "OOP i C++")

Arne

Morten V Pedersen (01-08-2005)
Kommentar
Fra : Morten V Pedersen


Dato : 01-08-05 02:02

Arne Vajhøj wrote:
> Bertel Lund Hansen wrote:
>
>> Arne Vajhøj skrev:
>>
>>> Det ved han ikke. Bogen er ikke egnet til begyndere idag.
>>> Og var det sådan set heller ikke da den var brand ny.
>>
>>
>> Hvorfor anbefaler du den så til en nybegynder?
>
>
> Det gør jeg heller ikke.
>
> Kronologien er:
>
> Morten foreslog den.
>
> Mogens hævdede at den kun havde historisk interesse.
>
> Jeg påstod at selv om den er lidt gammel synes
> jeg stadig et det er en glimrende bog, men til
> "OOP i C++" ikke til "C++ for begyndere".
>
> Arne
Nu ligger landet sådan at jeg selv er en begynder med C++, og jeg synes
som Arne siger at bogen forklarer mange OOP begreber godt. Derfor
postede jeg linket til den. Jeg vil da også anbefale en selektiv tilgang
til bogen, da den som også er blevet pointeret er ret gammel(og en del
information er outdated). Det skulle jeg nok have skrevet i mit første
post - beklager..

--

// Morten - www.mortenvp.dk

Mogens Hansen (01-08-2005)
Kommentar
Fra : Mogens Hansen


Dato : 01-08-05 05:59


"Morten V Pedersen" <mvpe04@aau.control.aau.dk.invalid> wrote in message
news:42ed57b7$0$18640$14726298@news.sunsite.dk...

[8<8<8<]
> Nu ligger landet sådan at jeg selv er en begynder med C++, og jeg synes
> som Arne siger at bogen forklarer mange OOP begreber godt.

Med al respekt (og tag det venligst ikke personligt), så er det begynderens
lod ikke at kunne vurdere om noget er nogenlunde godt eller rigtigt godt -
simpelthen fordi begynderen i sagens natur mangler referencepunkter at holde
informationen op imod. Begynderen kan "kun" se om informationen er
forståelig og umiddelbart virker fornuftigt.

Selv om du syntes at bogen forklarer OOP begreber godt, så ender den op med
et objekt-orienteret klassebibliotek der, som jeg har forklaret, indeholder
_alvorlige_ design problemer - fordi det er blevet for meget objekt
orienteret. I 1991 var det ikke almindeligt kendt hvordan man kunne gøre det
bedre, men det er det i dag. (Dertil kommer de faktuelle problemer omkring
C++ som jeg har nævnt eksempler på)
Derfor er grund til at søge informationen fra en mere nutidig kilde. Der er
jo ingen indbygget modstrid mellem at forklare begreberne godt og vise mere
moderne design.
De eneste fortrin den bog så har er:
* Den er på dansk
* Den er gratis
og det må man så holde op imod hvad man ønsker at bruge sin tid på og lære.

Venlig hilsen

Mogens Hansen



Mogens Hansen (28-07-2005)
Kommentar
Fra : Mogens Hansen


Dato : 28-07-05 21:48


"Arne Vajhøj" <arne@vajhoej.dk> wrote in message
news:42e933f9$0$85298$edfadb0f@dread16.news.tele.dk...
> Mogens Hansen wrote:

[8<8<8<]
> Tankegangen i bogen den indsigt den giver i OOP i C++ er ikke
> forældet og bliver det formentligt ikke de næste 20 år.

Mener du at single-root hieraky design af klasse biblioteker som man ser det
i bogen klassebibliotek XCL er nutidigt ?
På at se forskellen i designet af "std::string" og "String" klassen i bogen,
der arver fra Sortable der igen arver fra Object.

At String klassen i bogen arver fra Sortable i lighed med Complex, gør at
man syntaktisk kan spørge hvad der er størst af et String og Complex objekt
med "isGreater" funktionen.
Det giver simpelthen _ingen_ designmæssig mening, og er en designmæssig
tankegang der i C++ _er_ forældet og har været det mindst de sidste 10 år
(minimum siden STL blev udviklet i 1994) - hvis det overhovedet nogensinde
har været at opfatte som tidssvarende.
Det burde give en compile-time fejl i et statisk typet sprog som C++.

Det er blot eet eksempel.

Se klassen ContainerBase.
Det er en abstrak basisklasse, der indeholder datamedlemmer - det er normalt
et dårligt tegn.
Tilmed er datamedlemmerne protected - det er normalt et dårligt tegn.

Den er så basis-klasse for Container, der definerer et interface til at
indsætte og udtrække elementer af typen "Object".
Det er velkendt at det fører til de problemer der førte/fører til at Generic
bliver indført i Java og C#.

Det er design der ligger tæt på Smalltalk biblioteker (og i dag Java og
..NET - måske skulle man sige fra før Generics blev/bliver indført i de
sprog) og NIH.
Det er forholdvis langt designet af de klasser der findes i C++ Standard
Library.

Prøv at sammenligne med designet af "std::vector" - der er af gode grunde
væsentlig forskel.
"std::vector" er bestemt også objekt orienteret designet, selvom der ikke
indgår arv og runtime polymorphi.

>
> Det er kun et par syntaktiske småting som har ændret sig.

Nej - det er simpelthen forkert jvf. hvad jeg skrev ovenfor.

Bogen er også fra før design pattern bevægelsen, der for alvor startede i
1994 med GoF, hvilket jeg også vil anse for et alvorligt problem i
forbindelse med at lære objekt orienteret design.

>
>> Alene det at den er skrevet i 1991 gør at store dele af Standard Library
>> ikke kan være være beskrevet.
>> Det betyder at meget væsentlige klasser som "std::string", "std::vector"
>> og "std::map" ikke benyttes. Det har en væsentlig indflydelse på
>> programmeringsstilen - nødvendigvis til det dårligere.
>> Desuden kan nyttig, moderne brug af templates ikke være indeholdt i
>> bogen - det har også en væsentlig, indflydelse på programmeringsstilen.
>
> Jeg tror at vi har en meget forskellig opfattelse af hvad
> der er vigtigt i C++.

Givetvis.

>
> Prædefinerede klasser og funktioner kan man slå op i en
> manual - og hvis man har forstået OOP og C++ er det normalt
> lige ud af landevejen at bruge.

Jeg talte egentlig mest om hvordan kendskabet til klasser som "std::string",
"std::vector" og "std::map" påvirker _programmeringsstilen_ i retning af
hvad man ofte kalder "moderne C++" - ikke så meget om hvorvidt man kunne
forstå en given klasse enkeltstående.

>
> Hvis man ikke har forstået forskellen på virtuelle og ikke
> virtuelle metoder, hvornår copy constructor og assignment operator
> kaldes etc. så bliver man aldrig nogen god C++ programmør - og den
> slags er 100 gange vanskeligere at lære end hvilke metoder der
> er på FooBar klassen.

Hvorfor skulle man ikke kunne lære det fra en langt mere tidssvarende og
korrekt bog ?

[8<8<8<]
> Han kommer til detaljer om reference typer i afsnit 2.11.13 !

Jeps - det så jeg godt inden jeg skrev indlægget.
Men i 2.4.4 skriver han lidt introduktion til referencer, og jeg syntes det
ville være nærliggende at beskrive de væsentligte egenskaber, i stedet for
_fejlagtigt_ at skrive "Referencer opfører sig akkurat som pointere, med den
ene undtagelse, at de indirekte data ikke skal derefereres". Der er langt
flere forskelle mellem pointere og referencer, hvilket han også beskriver
senere.

>
>> Et andet eksemepel:
>> Forklaringen i "2.6.4 main()" af main siger at den kan have signaturen
>> void main(int argc, char** argv);
>> Det er ikke, og har aldrig være rigtigt - main returnerer _altid_ int
>
> Ja.
>
> Men folk overlever nok.
>
>

Givetvis - det er blot lettere at lade være med at blande rigtige og
forkerte ting sammen, og overlade det til læseren at sortere det senere.

[8<8<8<]
> Det er en lærebog i OOP i C++ ikke en lærebog i C++.

De design jeg har set i bogen er ikke et udtryk for moderne C++ design.
Der findes _langt_ bedre bøger der beskriver godt design i C++ - dem jeg
tænker på er blot ikke gratis tilgængelige.

Venlig hilsen

Mogens Hansen



Arne Vajhøj (29-07-2005)
Kommentar
Fra : Arne Vajhøj


Dato : 29-07-05 08:05

Mogens Hansen wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> wrote in message
> news:42e933f9$0$85298$edfadb0f@dread16.news.tele.dk...
>>Jeg tror at vi har en meget forskellig opfattelse af hvad
>>der er vigtigt i C++.
>
> Givetvis.
>
>>Prædefinerede klasser og funktioner kan man slå op i en
>>manual - og hvis man har forstået OOP og C++ er det normalt
>>lige ud af landevejen at bruge.
>
> Jeg talte egentlig mest om hvordan kendskabet til klasser som "std::string",
> "std::vector" og "std::map" påvirker _programmeringsstilen_ i retning af
> hvad man ofte kalder "moderne C++" - ikke så meget om hvorvidt man kunne
> forstå en given klasse enkeltstående.

For mig er valget af streng type (C nul termineret char array,
STL std::string, MFC CString, .NET System::String etc.) ca. lige
så vigtig for det færdige produkt som valget af indryking (3,4,8).

Jeg har meget svært ved at forstå at det skulle betyde noget
signifikant.

De skal selvfølgelig bruges korrekt. Og nogen af dem er bedre
end andre.

Men det må være nærmest definitorisk at en god C++ programmør
kan skrive korrekte programmer med dem alle.

>>Hvis man ikke har forstået forskellen på virtuelle og ikke
>>virtuelle metoder, hvornår copy constructor og assignment operator
>>kaldes etc. så bliver man aldrig nogen god C++ programmør - og den
>>slags er 100 gange vanskeligere at lære end hvilke metoder der
>>er på FooBar klassen.
>
> Hvorfor skulle man ikke kunne lære det fra en langt mere tidssvarende og
> korrekt bog ?

Det er der vist heller ikke nogen som har påstået.

Det ærger mig at Maz Spork ikke har udgivet en
ny revideret udgave med ANSI C++, STL etc..

Jeg synes at han har et sjældent talent for at
kunne forklare komplekse problem stillinger.

Jeg har aldrig læst en C++ bog som var lige så god
til forklare tingene.

Jeg har læst en del, men langtfra alle, så måske
er der guldklumper derude.

Jeg har f.eks. ikke læst dem du henviste til.

Arne

Mogens Hansen (29-07-2005)
Kommentar
Fra : Mogens Hansen


Dato : 29-07-05 08:10


"Arne Vajhøj" <arne@vajhoej.dk> wrote in message
news:42e9d4f5$0$76168$edfadb0f@dread16.news.tele.dk...

[8<8<8<]
> For mig er valget af streng type (C nul termineret char array,
> STL std::string, MFC CString, .NET System::String etc.) ca. lige
> så vigtig for det færdige produkt som valget af indryking (3,4,8).

Brugen af C nul termineret char array har vist først til væsentligt flere
buffer-overrun, med deraf følgende crash og sikkerhedshuller, end valget af
indrykning.

Det spiller faktisk en væsentlig forskel i programmeringsstilen.

Venlig hilsen

Mogens Hansen



Jacob Atzen (29-07-2005)
Kommentar
Fra : Jacob Atzen


Dato : 29-07-05 10:52

On 2005-07-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
> For mig er valget af streng type (C nul termineret char array, STL
> std::string, MFC CString, .NET System::String etc.) ca. lige så vigtig
> for det færdige produkt som valget af indryking (3,4,8).
>
> Jeg har meget svært ved at forstå at det skulle betyde noget
> signifikant.

Det kan betyde en del for læsbarheden af programmet. Hvorvidt man
opfatter læsbarhed som værende signifikant er nok et spørgsmål om
religion.

Med læsbarhed plejer dog at følge reducerede
vedligeholdelsesomkostninger, hvilket kan være et argument for, at det
er signifikant.

Jeg har i ovenstående kommentar set bort fra MFC og .NET da de svjv.
begge udelukkende eksisterer i Windows. Mit argument drejer sig altså om
C strenge overfor STL strenge.

--
Med venlig hilsen
- Jacob Atzen

Arne Vajhøj (30-07-2005)
Kommentar
Fra : Arne Vajhøj


Dato : 30-07-05 17:07

Jacob Atzen wrote:
> On 2005-07-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>For mig er valget af streng type (C nul termineret char array, STL
>>std::string, MFC CString, .NET System::String etc.) ca. lige så vigtig
>>for det færdige produkt som valget af indryking (3,4,8).
>>
>>Jeg har meget svært ved at forstå at det skulle betyde noget
>>signifikant.
>
> Det kan betyde en del for læsbarheden af programmet. Hvorvidt man
> opfatter læsbarhed som værende signifikant er nok et spørgsmål om
> religion.

Hvis man har frit valg mellem f.eks. char* og std::string,
så synes jeg da også absolut at man skal vælge den (men det
er formentligt ret normalt at man ikke har et valg fordi
gammel kode eller API eller lib kræver en bestemt type streng).

Og det vil normalt også være meget bedre at bruge std::map
fremfor ens egen hjemmebryggede hash tabel.

Det ser pænere ud. Og når der er en masse kompetente
folk som har brugt tid på at designe noget kvalitet
som kommer med ens compiler, så bør man da bruge det,
hvis man kan.

Jeg er ikke anti-STL på nogen måde.

Jeg mener bare ikke at brugen af STL betyder en stor
forskel for virkelige applikationer - der er normalt
meget sværere problem stillinger end ting som
C style char* og str funktioner.

Og jeg synes ikke at man skal betragte en C++
bog som forældet fordi den ikke gennemgår STL.

Hvis folk får den rigtige forståelse for C++, så
kan de slå både ANSI standard biblioteker og platform
specifikke biblioteker op i dokumentationen.

Arne


Mogens Hansen (30-07-2005)
Kommentar
Fra : Mogens Hansen


Dato : 30-07-05 18:57


"Arne Vajhøj" <arne@vajhoej.dk> wrote in message
news:42eba5a1$0$75699$edfadb0f@dread16.news.tele.dk...

[8<8<8<]
> Hvis man har frit valg mellem f.eks. char* og std::string,
> så synes jeg da også absolut at man skal vælge den (men det
> er formentligt ret normalt at man ikke har et valg fordi
> gammel kode eller API eller lib kræver en bestemt type streng).

Jeps.
Men man kan nøjes med at isolere det til overgangen til de biblioteker, og
så i det meste at sin kode benytte "std::string".
Iøvrigt er "std::string" og "std::vector" designet så de rimeligt kompatible
med ældre API'er.

[8<8<8<]
> Jeg mener bare ikke at brugen af STL betyder en stor
> forskel for virkelige applikationer - der er normalt
> meget sværere problem stillinger end ting som
> C style char* og str funktioner.

Det er jeg dybt enig i. Jeg har brugt STL eller C++ Standard Library siden
midt i 1995, og det har betydet en væsentlig forskel i produktiviteten og
måden som jeg skriver programmer på.
Det får ikke svære problemer som programmet egentlig skal løse i problem
domænet til at forsvinde, men det højere abstraktionsniveau gør at man
nemmere kan koncentrere sig om at løse dem i stedet for også at skulle
bekymre sig om bogholderi med allokering og bufferstørrelser.

Vi er formodentlig enige om at brugen af char*, og de tilhørende funktioner
som f.eks. strcpy har været årsag til mange problemer, som f.eks.
buffer-overrun med deraf følgende sikkerhedhuller og program crash.
Det er da en væsentlig forskel for virkelige applikationer om de er skrevet
med en progammeringsstil der let giver den type problemer.

Vi er formodentlig også enige om at programmer der eksplicit på
applikationsniveau håndterer strenge af varibel størrelse jævnligt har
problemer med memory-leak og lignende.
Det er da også en væsentlig forskel

>
> Og jeg synes ikke at man skal betragte en C++
> bog som forældet fordi den ikke gennemgår STL.

Det kommer da meget an på hvad bogen prøver at formidle og til hvem.

Hvis vi taler om en introduktion til C++ eller en bog der prøver at være
dækkende, så er jeg slet ikke i tvivl om at hvis den ikke beskriver
"std::string", "std::vector" og "std::map", så er det i sig selv grund til
at undgå den bog. Helst skal det indtroduceres tidligt og bruges som default
i eksemplerne.

Det gælder selv en bog som
The C++ Programming Language, Second Edition
Bjarne Stroustrup
ISBN 0-201-53992-6
fra 1991, der må betragtes som forældet og kun af historisk interesse. Der
findes heldigvis en ny og lang bedre udgave.

Hvis bogen derimod sigter på at formidlere avancerede ting, og hvis de ting
stadig er holdbare, så kan en bog fra før 1997-98 (C++ Standardens
vedtagelse) være interessant, men kun til læsere der har forståelse for
hvordan sproget set ud i dag.

Jeg mener klart at Maz Spork's bog falder ind under den kategori, af flere
grunde som jeg har været inde på tidligere i denne tråd. Dens design ligger
temmeligt langt fra hvad man finder i moderne C++ (Se eventuelt
http://www.two-sdg.demon.co.uk/curbralan/papers/TheMiseducationOfC++.pdf for
en klassifikation af moderne C++), og lider, som jeg har vist, af væsentlige
designproblemer, som man siden har fundet ud af hvordan man undgår.

Den eneste bog jeg umiddelbart kan komme i tanke om, som falder ind i den
kategori er
Advanced C++, Programming Styles and Idioms
James O. Coplien
ISBN 0-201-54855-0
som ikke sigter på at være en introduktion eller gennemgang af C++, men
derimod henvender sig til erfarne programmører. Selv den bør ledsages af
kommentarer om at den konkrete kode ikke altid er tidssvarende og ikke
nødvendigvis kan oversættes med moderne compilere.

>
> Hvis folk får den rigtige forståelse for C++,

Det kommer da meget an på hvad du forstår ved "den rigtige forståelse for
C++".

Jeg mener klart at der ikke er mange mennesker, der vil fange pointen ved
den opdeling i containere, iteratorer og algoritmer som STL introducerede
ved at kigge i en reference manual, ligesom man ikke nemt kan forstå hvordan
man effektivt bruger C++ ved at læse Standarden. De fleste har brug for en
introduktion til det med en gennemgang af principperne, for at få det fulde
udbytte.
STL og biblioteker som Boost bidrager både med konkret kode, men også i høj
grad med programmerings- og design-stil.

>så
> kan de slå både ANSI standard biblioteker og platform
> specifikke biblioteker op i dokumentationen.

Ja, det er godt at bruge når man har forstået principperne, men ikke lige
kan huske de præcise detaljer.

Venlig hilsen

Mogens Hansen



Arne Vajhøj (31-07-2005)
Kommentar
Fra : Arne Vajhøj


Dato : 31-07-05 15:14

Mogens Hansen wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> wrote in message
> news:42eba5a1$0$75699$edfadb0f@dread16.news.tele.dk...
>>Hvis man har frit valg mellem f.eks. char* og std::string,
>>så synes jeg da også absolut at man skal vælge den (men det
>>er formentligt ret normalt at man ikke har et valg fordi
>>gammel kode eller API eller lib kræver en bestemt type streng).
>
> Jeps.
> Men man kan nøjes med at isolere det til overgangen til de biblioteker, og
> så i det meste at sin kode benytte "std::string".

Afhænger af koden. Hvis koden bliver for mudret til af konverteringer,
så er der ikke meget pointe.

>>Jeg mener bare ikke at brugen af STL betyder en stor
>>forskel for virkelige applikationer - der er normalt
>>meget sværere problem stillinger end ting som
>>C style char* og str funktioner.
>
> Det er jeg dybt enig i. Jeg har brugt STL eller C++ Standard Library siden
> midt i 1995, og det har betydet en væsentlig forskel i produktiviteten og
> måden som jeg skriver programmer på.
> Det får ikke svære problemer som programmet egentlig skal løse i problem
> domænet til at forsvinde, men det højere abstraktionsniveau gør at man
> nemmere kan koncentrere sig om at løse dem i stedet for også at skulle
> bekymre sig om bogholderi med allokering og bufferstørrelser.

Jeg er altid uhyre skeptisk når XYZ forbedrer produktiviteten
voldsomt.

> Vi er formodentlig enige om at brugen af char*, og de tilhørende funktioner
> som f.eks. strcpy har været årsag til mange problemer, som f.eks.
> buffer-overrun med deraf følgende sikkerhedhuller og program crash.
> Det er da en væsentlig forskel for virkelige applikationer om de er skrevet
> med en progammeringsstil der let giver den type problemer.

Det argument betyder jo også at du vil anbefale skift til
Java/C#/Ada som slet ikke har det problem.



Nå ikke ...

>>Og jeg synes ikke at man skal betragte en C++
>>bog som forældet fordi den ikke gennemgår STL.
>
> Det kommer da meget an på hvad bogen prøver at formidle og til hvem.
>
> Hvis vi taler om en introduktion til C++ eller en bog der prøver at være
> dækkende, så er jeg slet ikke i tvivl om at hvis den ikke beskriver
> "std::string", "std::vector" og "std::map", så er det i sig selv grund til
> at undgå den bog. Helst skal det indtroduceres tidligt og bruges som default
> i eksemplerne.

Enig.

> Hvis bogen derimod sigter på at formidlere avancerede ting, og hvis de ting
> stadig er holdbare, så kan en bog fra før 1997-98 (C++ Standardens
> vedtagelse) være interessant, men kun til læsere der har forståelse for
> hvordan sproget set ud i dag.

Også enig.

> Den eneste bog jeg umiddelbart kan komme i tanke om, som falder ind i den
> kategori er
> Advanced C++, Programming Styles and Idioms
> James O. Coplien
> ISBN 0-201-54855-0
> som ikke sigter på at være en introduktion eller gennemgang af C++, men
> derimod henvender sig til erfarne programmører. Selv den bør ledsages af
> kommentarer om at den konkrete kode ikke altid er tidssvarende og ikke
> nødvendigvis kan oversættes med moderne compilere.

Lyder som en interessant bog.

Og folk opdager jo nok hvis deres compiler brokker sig.

Jeg synes bare at det er vigtigt at folk får noget input
mellem begynderbogen (data typer, operatorer, kontrol strukturer,
standard bibliotek) og design patterns.

C++ kan bruges på mange måder og de er ikke alle lige
gode. Og før folk slippes løs på en eller anden uskyldig
applikation bør de forstå nogle ting.

Jeg græder når jeg hører en datamatiker studerende
som er undervist i C++ mene at det er ligegyldigt om
der står virtual eller ej.

>>Hvis folk får den rigtige forståelse for C++,
>
> Det kommer da meget an på hvad du forstår ved "den rigtige forståelse for
> C++".
>
> Jeg mener klart at der ikke er mange mennesker, der vil fange pointen ved
> den opdeling i containere, iteratorer og algoritmer som STL introducerede
> ved at kigge i en reference manual, ligesom man ikke nemt kan forstå hvordan
> man effektivt bruger C++ ved at læse Standarden. De fleste har brug for en
> introduktion til det med en gennemgang af principperne, for at få det fulde
> udbytte.
> STL og biblioteker som Boost bidrager både med konkret kode, men også i høj
> grad med programmerings- og design-stil.

Der er jeg nok lidt uenig.

For mig er biblioteker "bare" nogen som er der og som man bruger.
Principielt kunne man lige så godt lave sine egne.

Det er efter min mening faktisk sundt at folk prøver at
lave deres egne mens de lærer C++. Det giver en god forståelse
for tingene.

Når vi så skal til at lave noget seriøst, så kan vi
godt pakke alle de hjemmestrikkede biblioteker væk
(hvis det er muligt), fordi standard biblioteket
og diverse platform specifikke biblioteker er så
godt som altid af bedre kvalitet.

Jeg synes også at det er karakteristisk at i
MFC/.NET/Java er collections/iteratorer/enumeratorer ikke
noget særligt bare endnu en biblioteks feature (ud af mange).

Arne

Kent Friis (31-07-2005)
Kommentar
Fra : Kent Friis


Dato : 31-07-05 15:31

Den Sun, 31 Jul 2005 16:14:04 +0200 skrev Arne Vajhøj:
> Mogens Hansen wrote:
>
>> Det får ikke svære problemer som programmet egentlig skal løse i problem
>> domænet til at forsvinde, men det højere abstraktionsniveau gør at man
>> nemmere kan koncentrere sig om at løse dem i stedet for også at skulle
>> bekymre sig om bogholderi med allokering og bufferstørrelser.
>
> Jeg er altid uhyre skeptisk når XYZ forbedrer produktiviteten
> voldsomt.

Så du skriver bare i assembler? Nå nej, rå maskinkode, du er vel også
skeptisk når assembler forbedrer produktiviteten i forhold til at sidde
og sætte bit'sne en ad gangen, og når C forbedrer produktiviteten i
forhold til ren assembler...

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

Arne Vajhøj (01-08-2005)
Kommentar
Fra : Arne Vajhøj


Dato : 01-08-05 21:17

Kent Friis wrote:
> Den Sun, 31 Jul 2005 16:14:04 +0200 skrev Arne Vajhøj:
>>Mogens Hansen wrote:
>>>Det får ikke svære problemer som programmet egentlig skal løse i problem
>>>domænet til at forsvinde, men det højere abstraktionsniveau gør at man
>>>nemmere kan koncentrere sig om at løse dem i stedet for også at skulle
>>>bekymre sig om bogholderi med allokering og bufferstørrelser.
>>
>>Jeg er altid uhyre skeptisk når XYZ forbedrer produktiviteten
>>voldsomt.
>
> Så du skriver bare i assembler? Nå nej, rå maskinkode, du er vel også
> skeptisk når assembler forbedrer produktiviteten i forhold til at sidde
> og sætte bit'sne en ad gangen, og når C forbedrer produktiviteten i
> forhold til ren assembler...

Assembler->Fortran var nok et af de tilfælde hvor det
hjalp lidt.

Jeg gætter på at hype ikke var opfundet i 1957 ...

Arne

Mogens Hansen (31-07-2005)
Kommentar
Fra : Mogens Hansen


Dato : 31-07-05 18:39


"Arne Vajhøj" <arne@vajhoej.dk> wrote in message
news:42ecdc96$0$19485$edfadb0f@dread16.news.tele.dk...

[8<8<8<]
> Jeg er altid uhyre skeptisk når XYZ forbedrer produktiviteten
> voldsomt.

Det kan jeg godt forstå - sådan har jeg det også.
Ikke desto mindre er det betød introduktionen til STL i 1995 en væsentlig
ændring og forbedring af min programmeringsstil og produktivitet.

[8<8<8<]
>> Den eneste bog jeg umiddelbart kan komme i tanke om, som falder ind i den
>> kategori er
>> Advanced C++, Programming Styles and Idioms
>> James O. Coplien
>> ISBN 0-201-54855-0
>> som ikke sigter på at være en introduktion eller gennemgang af C++, men
>> derimod henvender sig til erfarne programmører. Selv den bør ledsages af
>> kommentarer om at den konkrete kode ikke altid er tidssvarende og ikke
>> nødvendigvis kan oversættes med moderne compilere.
>
> Lyder som en interessant bog.

James Coplien's nyere bog
Multi-Paradigm DESIGN for C++
James O. Coplien
ISBN 0-201-82467-1
er måske endnu mere interessant i dag. Den er ikke nemt tilgængelig, men
besværet værd.

>
> Og folk opdager jo nok hvis deres compiler brokker sig.
>
> Jeg synes bare at det er vigtigt at folk får noget input
> mellem begynderbogen (data typer, operatorer, kontrol strukturer,
> standard bibliotek) og design patterns.

"Advanced C++" betegnes sommetider som den første bog om design patterns -
fra inden vi kendte det udtryk.
Coplien er en væsentlig person i design pattern bevægelsen.

Venlig hilsen

Mogens Hansen



Per Abrahamsen (28-07-2005)
Kommentar
Fra : Per Abrahamsen


Dato : 28-07-05 15:50

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> Den beskriver slet ikke det som for mig er den vigtigste forskel mellem
> pointere og referencer: i et gyldigt program vil en reference _altid_
> referere til et objekt (kan alså ikke være 0) som referencen initialiseres
> til og den kan _aldrig_ sættes til at referere til andre objekter.

Jeg er ikke sikker på at det var sandt i 1991, hvilket selvfølgelig
blot er endnu en grund til at vælge en nyere bog.

Per Abrahamsen (29-07-2005)
Kommentar
Fra : Per Abrahamsen


Dato : 29-07-05 13:40

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> "Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
> news:rj7jfb0yu3.fsf@sheridan.dina.kvl.dk...
>> "Mogens Hansen" <mogens_h@dk-online.dk> writes:
>>
>>> Den beskriver slet ikke det som for mig er den vigtigste forskel mellem
>>> pointere og referencer: i et gyldigt program vil en reference _altid_
>>> referere til et objekt (kan alså ikke være 0) som referencen
>>> initialiseres
>>> til og den kan _aldrig_ sættes til at referere til andre objekter.
>>
>> Jeg er ikke sikker på at det var sandt i 1991,
>
> Det er jeg
> I ARM *) fra 1990 kapitel 8.4.3 står det tydeligt at det var på samme måde
> den gang.

Ja, men ARM var ikke entydigt definitionen. Det var snarere "hvad den
seneste version af CFRONT accepterer".

Jeg husker det som at der var en del problemer med kode der brugte
*((Foo*)0) som en nul-reference konstant, da compilerne endelig
begyndte at håndhæve/udnytte den information. Og at det tog en del
tid før det synspunkt du advokerer (at forskellen på referencer og
pointere er evnen til at pege på et nul objekt) blev dominerende.

Så jeg er ikke overrasket over at det ikke er med i en bog fra 1991.

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408929
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste