---

Er nedenstående bogtitel en anbefalelsesværdi C++ bog ?

Med venlig hilsen
Torben W. Hansen

C++ Grundbog
Jesse Liberty

ISBN: 87-7843-561-7
IDG Forlag
Oktober 2002
383 sider
Kr. 349,00

---

> Er nedenstående bogtitel en anbefalelsesværdi C++ bog ?

Well, jeg har endnu ikke set en anbefalelsesværdig titel fra IDG; men det
var bare min mening, jeg er ikke bekendt med den bog du omtaler. :)

/\/\\ads Orbesen Troest

---

"Torben W. Hansen" <mail@ins-intersoft.com> writes:

> Er nedenstående bogtitel en anbefalelsesværdi C++ bog ?
Jeg har ikke bogen, men har kigget lidt på kildekoden.(hvilket
så også er det eneste, som nedestående kommentar er baseret på)

Umiddelbart, så ser det ud som om han kan finde ud af hvad standard C++ er..
han har fattet at det nu hedder <iostream> og ikke <iostream.h>, og at cout ligger i std navnerummet.

Kildekoden indeholder så vidt jeg kan se ingen anvendelse af standardbiblioteket.
Søgning på "string","vector","list" og "map", gav ingen resultater, og disse må siges at være nogen af de simpleste og hyppigst anvendte dele af standardbiblioteket.

Iøvrigt afslørede søgningen på string, at der bliver benyttet string.h og strncpy,
en C-ting.

Baseret på den manglende behandling af standardbiblioteket, må rådet nok
være at tage den engelske bog - Iøvrigt, slipper du ikke for engelsk, der
er alt for lidt(læs:ingen) videregående litteratur om computere og den slags
på dansk.

Så.. lær dig selv engelsk, og køb så accelerated C++, så går du ikke forkert
i byen, og så kan du dit engelsk næste gang du vil lære mere :)

mvh Jonas

---

Jonas Meyer skrev:

>Iøvrigt afslørede søgningen på string, at der bliver benyttet string.h og strncpy,
>en C-ting.

Som før antydet så er C++'s stringhåndtering en væsentlig grund
til at foretrække det frem for C. En bog der ikke drager nytte af
den fordel, er ikke god. Strings er vel den mest fundamentale
datatype næst efter tal.

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

---

Tak for det fyldestgørende svar Jonas,

Lige et spørgsmål - har du haft tilgang til bogen eller har du søgt i de
kodeeksempler, der kunne downloades fra IDG ?

> Umiddelbart, så ser det ud som om han kan finde ud af hvad standard C++
er..
> han har fattet at det nu hedder <iostream> og ikke <iostream.h>, og at
cout ligger i std navnerummet.
Jeg kikkede selv på nogle af kodeeksemplerne og bemærkede netop "<iostream>"
og "std::", som f.eks ikke omtales i min "Kris Jamsa C++".

> Kildekoden indeholder så vidt jeg kan se ingen anvendelse af
standardbiblioteket.
> Søgning på "string","vector","list" og "map", gav ingen resultater, og
disse må siges at være nogen af de simpleste og hyppigst anvendte dele af
standardbiblioteket.
Jeg fik aldrig søgt efter "templates", fandt du ud af om dette omtales i
bogen ?

> Iøvrigt afslørede søgningen på string, at der bliver benyttet string.h og
strncpy,
> en C-ting.
OK - det har jeg overset.

> Så.. lær dig selv engelsk, og køb så accelerated C++, så går du ikke
forkert
> i byen, og så kan du dit engelsk næste gang du vil lære mere :)
Forleden dag ordrede jeg "Accelerated C++" ISBN: 0-201-70353-x fra GADS
Forlag, som du også anbefaler, og jeg taler samt skriver fornuftigt teknisk
engelsk, men ved den grundlæggende indlæring af OOP - og især ved
selvstudie - foretrækker jeg, om muligt, dansk.
I mit job har jeg programmeret mikroer i Ansi C (K&R) i nogle år og selvom
jeg har læst "Kris Jamsa C++" (som bekendt ej er en god C++ bog ), går det
lidt "trægt" med at gennemskue fordelene ved OOP. Jeg kan godt få øje på
fordelen ved "Klasser", men omvendt synes jeg f.eks "Polymorfisme" og "Arv"
virker ret komplekst således at det kan være svært at gennemskue sit
software-design. Dette beror sansynligvis på manglende og grundlæggende
indsigt i OOP samt C++, som jeg håber på at kunne råde bod på igennem
læsevenlig litteratur.
Hvis fordelene ved OOP kan nævnes umiddelbart, er din mening om dette meget
velkommen...

Med venlig hilsen
Torben W. Hansen

---

> det [går] lidt "trægt" med at gennemskue fordelene ved OOP. Jeg
> kan godt få øje på fordelen ved "Klasser", men omvendt synes jeg
> f.eks "Polymorfisme" og "Arv" virker ret komplekst således at det kan
> være svært at gennemskue sit software-design. Dette beror
> sansynligvis på manglende og grundlæggende indsigt i OOP samt C++,
> som jeg håber på at kunne råde bod på igennem læsevenlig litteratur.
> Hvis fordelene ved OOP kan nævnes umiddelbart, er din mening om dette
> meget velkommen...

Kender du "Objektorienteret analyse og design"?

http://www.metodica.dk/boeger.htm

--
Jens Axel Søgaard

---

"Jens Axel Søgaard" <usenet@soegaard.net> skrev i en meddelelse
news:DwFr9.119755>
Kender du "Objektorienteret analyse og design"?

Nej , men tak for tippet...

Hvilken læserækkefølge bør man vælge... C++ eller OOP først ?

Med venlig hilsen
Torben W. Hansen

---

Torben W. Hansen wrote:
> "Jens Axel Søgaard" <usenet@soegaard.net> skrev i en meddelelse
> news:DwFr9.119755>
> Kender du "Objektorienteret analyse og design"?
>
> Nej , men tak for tippet...
>
> Hvilken læserækkefølge bør man vælge... C++ eller OOP først ?

Jeg foreslår samtidig - så støtter det hinanden. Ellers læs det, du synes
er mest spændende først.

--
Jens Axel Søgaard

---

"Torben W. Hansen" <mail@ins-intersoft.com> wrote in message news:<aon6h6$1jhe$1@news.cybercity.dk>...
> Tak for det fyldestgørende svar Jonas,
>
> Lige et spørgsmål - har du haft tilgang til bogen eller har du søgt i de
> kodeeksempler, der kunne downloades fra IDG ?

Jeg har _ikke_ haft adgang til bogen, og mine kommentarer var kun
baseret på koden til bogen

>
> > Umiddelbart, så ser det ud som om han kan finde ud af hvad standard C++
> er..
> > han har fattet at det nu hedder <iostream> og ikke <iostream.h>, og at
> cout ligger i std navnerummet.
> Jeg kikkede selv på nogle af kodeeksemplerne og bemærkede netop "<iostream>"
> og "std::", som f.eks ikke omtales i min "Kris Jamsa C++".
>
> > Kildekoden indeholder så vidt jeg kan se ingen anvendelse af
> standardbiblioteket.
> > Søgning på "string","vector","list" og "map", gav ingen resultater, og
> disse må siges at være nogen af de simpleste og hyppigst anvendte dele af
> standardbiblioteket.
> Jeg fik aldrig søgt efter "templates", fandt du ud af om dette omtales i
> bogen ?

Jeg kunne ikke finde noget template kode i filerne

>
> > Iøvrigt afslørede søgningen på string, at der bliver benyttet string.h og
> strncpy,
> > en C-ting.
> OK - det har jeg overset.
>
> > Så.. lær dig selv engelsk, og køb så accelerated C++, så går du ikke
> forkert
> > i byen, og så kan du dit engelsk næste gang du vil lære mere :)
> Forleden dag ordrede jeg "Accelerated C++" ISBN: 0-201-70353-x fra GADS
> Forlag, som du også anbefaler, og jeg taler samt skriver fornuftigt teknisk
> engelsk, men ved den grundlæggende indlæring af OOP - og især ved
> selvstudie - foretrækker jeg, om muligt, dansk.
> I mit job har jeg programmeret mikroer i Ansi C (K&R) i nogle år og selvom
> jeg har læst "Kris Jamsa C++" (som bekendt ej er en god C++ bog ), går det
> lidt "trægt" med at gennemskue fordelene ved OOP. Jeg kan godt få øje på
> fordelen ved "Klasser", men omvendt synes jeg f.eks "Polymorfisme" og "Arv"
> virker ret komplekst således at det kan være svært at gennemskue sit
> software-design. Dette beror sansynligvis på manglende og grundlæggende
> indsigt i OOP samt C++, som jeg håber på at kunne råde bod på igennem
> læsevenlig litteratur.
> Hvis fordelene ved OOP kan nævnes umiddelbart, er din mening om dette meget
> velkommen...

Den abstraktion klasser giver alene er en klar fordel - se bare
std::string klassen.

Polymorfi er et værktøj til at abstrahere - en hjælp således at du kan
genbruge
din kode. Altså at du kan programmere den fælles kode for alle dyr i
"dyr" klassen, og derefter nedarver, og overskriver de metoder hvorved
det enkelte dyr udskiller sig fra massen.
Arv er et vigtigt værktøj til at opnå polymorfi. Folk siger også at
arv er med for at fremme genbrug, men jeg må indrømme at jeg endnu
ikke har set nogen anvende koden således.

Når man så har fattet hvordan de tekniske aspekter fungerer, så er det
man skal tilpasse det til sit eget projekt, hvilket ofte er det
sværeste.

Prøv:
Design Patterns
0201633612

Den indeholder en masse eksempler på praktiske anvendelser af
klasser,polymorfi og arv.

mvh Jonas

---

Jonas Meyer skrev:

>Den abstraktion klasser giver alene er en klar fordel - se bare
>std::string klassen.

Isoleret set kan jeg nu ikke se at det skulle være en fordel. I
TP findes der alle de metoder til at håndtere strenge som man kan
ønske sig, og der er ingen klasser.

   navn=fornavn+efternavn;
   WriteLn(copy(navn,1,10));
   osv.

>Arv er et vigtigt værktøj til at opnå polymorfi. Folk siger også at
>arv er med for at fremme genbrug, men jeg må indrømme at jeg endnu
>ikke har set nogen anvende koden således.

Det tror jeg du har - mange gange.

class Animal {
   int legs;
   int eyes;
   bool tail, tired, angry;

   void wagTail () {...}
   void run () {...}
   void sleep (int time) {...}
}

Hvis man nu instantierer en hund og en ulv, så har man genbrugt
koden.

Du tænker måske på tværs af programmer? Så kan man bare tage alle
de færdige klasser som eksempel.

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

---

Den Fri, 18 Oct 2002 13:17:58 +0200 skrev Bertel Lund Hansen:
>Jonas Meyer skrev:
>
>>Den abstraktion klasser giver alene er en klar fordel - se bare
>>std::string klassen.
>
>Isoleret set kan jeg nu ikke se at det skulle være en fordel. I
>TP findes der alle de metoder til at håndtere strenge som man kan
>ønske sig, og der er ingen klasser.
>
>   navn=fornavn+efternavn;
>   WriteLn(copy(navn,1,10));
>   osv.

Som jeg læser det, mener han at se std::string som eksempel. Ja, TP har
en string også, men har den også en brøk? Nope. Med klasser er det nemt
at skrive en, der fungerer præcis som enhver anden tal-type.

Iøvrigt har TP fået klasser, de kalder dem bare "object" i stedet for
"class".

Mvh
Kent
--
"Handlingen blev afbrudt pga. computerens begrænsede effekt"
- Windows NT på en Pentium III 550 MHz

---

> Iøvrigt har TP fået klasser, de kalder dem bare "object" i stedet for
> "class".

Hvilket jo var en lidt pinlig ting at gøre, men de har rettet det i seneste
"Pascal" revisioner (som Delphi), her hedder det godt nok class.

/\/\\

---

Bertel Lund Hansen <nospam@lundhansen.dk> wrote in message news:<02rvqusb4l9vr48uhev05qa4mjbs5qdhqi@news.telia.dk>...
> Jonas Meyer skrev:
>
> >Den abstraktion klasser giver alene er en klar fordel - se bare
> >std::string klassen.
>
> Isoleret set kan jeg nu ikke se at det skulle være en fordel. I
> TP findes der alle de metoder til at håndtere strenge som man kan
> ønske sig, og der er ingen klasser.
>
>    navn=fornavn+efternavn;
>    WriteLn(copy(navn,1,10));
>    osv.

Der har du jo netop abstraktion med klasser.

I C++, har vi brug for klasser for at opnå det samme.
C++ kunne også have lavet en speciel sprogfeature til strings,
men det ville være fjollet
da det er oplagt at benytte klasser til formålet.
og nemmere.. ikke noget med nye overvejelser om syntaks/semantik,
det er allerede overvejet.


> >Arv er et vigtigt værktøj til at opnå polymorfi. Folk siger også at
> >arv er med for at fremme genbrug, men jeg må indrømme at jeg endnu
> >ikke har set nogen anvende koden således.
>
> Det tror jeg du har - mange gange.
>
> class Animal {
>    int legs;
>    int eyes;
>    bool tail, tired, angry;
>
>    void wagTail () {...}
>    void run () {...}
>    void sleep (int time) {...}
> }
>
> Hvis man nu instantierer en hund og en ulv, så har man genbrugt
> koden.

Jeg har set sådanne eksempler adskillige gange, men det har
altid været i bøger.
Udover de gange hvor man benytte "template method" mønstret, så
er jeg ikke stødt på genbrug på den måde.

Det minder mig om mit introducerende datalogi kursus, hvor
vi blev beordret at lave 3 iterationer af vores
program og genbruge koden ved at benytte arv - Der
var ingen(jeg kendte til) som opnåede det, og læreren
er ikke på kurset mere(!)..

Men - Det er en begrænset mængde projekter jeg har set på/arbejdet
med,
så tag det blot som min mening, og sig endelig hvis du selv har
oplevet noget andet...

mvh Jonas

---

On 19 Oct 2002 02:18:18 -0700,
Jonas Meyer <meyer@diku.dk> wrote:

> Det minder mig om mit introducerende datalogi kursus, hvor
> vi blev beordret at lave 3 iterationer af vores
> program og genbruge koden ved at benytte arv - Der
> var ingen(jeg kendte til) som opnåede det, og læreren
> er ikke på kurset mere(!)..

dat0 i 1998?

--
Vil du afspille de CDere og DVDere du køber nu på dine fremtidige afspillere
uden at bryde loven så skriv under:

http://www.digitalforbruger.dk

---

Anders Bo Rasmussen <fuzz01@spamfilter.dk> wrote in message news:<slrnar298u.lgr.fuzz01@0xc2ffa6c1.osd01.dsl.telianet.dk>...
> On 19 Oct 2002 02:18:18 -0700,
> Jonas Meyer <meyer@diku.dk> wrote:
>
> > Det minder mig om mit introducerende datalogi kursus, hvor
> > vi blev beordret at lave 3 iterationer af vores
> > program og genbruge koden ved at benytte arv - Der
> > var ingen(jeg kendte til) som opnåede det, og læreren
> > er ikke på kurset mere(!)..
>
> dat0 i 1998?
Ja.

---

Jonas Meyer skrev:

>> >arv er med for at fremme genbrug, men jeg må indrømme at jeg endnu
>> >ikke har set nogen anvende koden således.

>> Det tror jeg du har - mange gange.

>> class Animal {

>Jeg har set sådanne eksempler adskillige gange, men det har
>altid været i bøger.

Jeg bruger klasser og arv i alle de Javaprogrammer jeg skriver.
Selv om man kun ét sted angiver at der skal arves, kan der jo
godt optræde et hav af instanser når først programmet kører.

Jeg har lige fået et program færdigt der skal modellere et
simpelt banksystem. Hver bruger arver alle sine egenskaber fra en
brugerklasse, og deres kontosæt arves fra en kontoklasse, og da
jeg lagde en GUI ovenpå, extendede den hele det basale
brugerinterface så jeg kunne genbruge de metoder der før blev
brugt til det primitive tekstskærminterface.

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

---

"Jonas Meyer" <meyer@diku.dk> wrote in message
news:b9ec8234.0210190118.5d13dfc@posting.google.com...

> C++ kunne også have lavet en speciel sprogfeature til strings,
> men det ville være fjollet
> da det er oplagt at benytte klasser til formålet.
> og nemmere.. ikke noget med nye overvejelser om syntaks/semantik,
> det er allerede overvejet.

Jeg er enig i at man skal holde sprog-kernen minimal, og fx implementere så
meget streng-semantik som muligt i standard-librariet. Men jeg mener at det
er forkert at påstå at det er fjollet af have en speciel sprogfeature til
strenge. Det ville fx være usselt at skulle leve uden en sprogdefineret
syntaks for strenge.
Og C++ har da også en sprog-feature til strenge (med syntaksen "foo"), men
desværre er "foo" et udtryk der evaluerer til en C-streng, med den uheldige
semantik der følger med (autokonvertering til pointer til char,
nulterminering, udefineret effekt at skrive til den, osv.).
Jeg synes det er ærgerligt at "foo" ikke er en std::string (eller
std::wstring?). Selv Java kan finde ud af at gøre "foo" til en
java.lang.String.

Mvh. Bjarke

---

"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote:

> Og C++ har da også en sprog-feature til strenge (med syntaksen "foo"), men
> desværre er "foo" et udtryk der evaluerer til en C-streng, med den uheldige
> semantik der følger med
> ([...] udefineret effekt at skrive til den, osv.).

Jeg mener strenge af den slags altid er konstanter i C++ ifølge Stroustrup
3, men jeg har ikke bogen længere, og MSDN-dokumentationen siger
udefineret, men den er sikkert ældre.

Men i virkeligheden er konstant og udefineret forhåbentligt det samme, for
man udnytter vel ikke noget, der har udefinerede effekter.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

"Niels Teglsbo" <Niels@fabel.dk> wrote in message
news:fg9brugd1q3l4nrhhcq6eurgnororhpcdo@news.image.dk...
> "Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote:
>
> > Og C++ har da også en sprog-feature til strenge (med syntaksen "foo"),
men
> > desværre er "foo" et udtryk der evaluerer til en C-streng, med den
uheldige
> > semantik der følger med
> > ([...] udefineret effekt at skrive til den, osv.).
>
> Jeg mener strenge af den slags altid er konstanter i C++ ifølge Stroustrup
> 3, men jeg har ikke bogen længere, og MSDN-dokumentationen siger
> udefineret, men den er sikkert ældre.

Ja, vist er de konstante, i den betydning at man ikke dynamisk må tildele
dem en værdi.
Men grundet historiske ulykker, er det lovligt på compiletime at sige
char* p = "foo";
*p = 'F';

> Men i virkeligheden er konstant og udefineret forhåbentligt det samme, for
> man udnytter vel ikke noget, der har udefinerede effekter.

Nu har en implementation jo lov til at garantere noget semantik for kode som
standarden ellers kun giver udefineret effekt. Det kan man så udnytte, hvis
man skal bruge den semantik, og ikke behøver at være portabel.
Men bortset fra det, siger du så ikke at man ikke har brug for typecheck?
"For man bryder vel ikke typereglerne".


Mvh. Bjarke

---

Den Tue, 22 Oct 2002 22:14:26 +0200 skrev Bjarke Dahl Ebert:
>"Niels Teglsbo" <Niels@fabel.dk> wrote in message
>news:fg9brugd1q3l4nrhhcq6eurgnororhpcdo@news.image.dk...
>> "Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote:
>>
>> > Og C++ har da også en sprog-feature til strenge (med syntaksen "foo"),
>men
>> > desværre er "foo" et udtryk der evaluerer til en C-streng, med den
>uheldige
>> > semantik der følger med
>> > ([...] udefineret effekt at skrive til den, osv.).
>>
>> Jeg mener strenge af den slags altid er konstanter i C++ ifølge Stroustrup
>> 3, men jeg har ikke bogen længere, og MSDN-dokumentationen siger
>> udefineret, men den er sikkert ældre.
>
>Ja, vist er de konstante, i den betydning at man ikke dynamisk må tildele
>dem en værdi.
>Men grundet historiske ulykker, er det lovligt på compiletime at sige
> char* p = "foo";
> *p = 'F';

Er det ikke undefined behaviour? Er der noget der forhindrer compileren
i at lave en mprotect() på "foo", så en skrivning resulterer i en
segmentation fault?

Mvh
Kent
--
Gilthoniel, A Elbereth
Aiya elenion ancalima!
- Tolkien, "The Lord of the Rings"

---

"Kent Friis" <leeloo@phreaker.net> wrote in message
news:ap4c73$86l$1@sunsite.dk...
> Den Tue, 22 Oct 2002 22:14:26 +0200 skrev Bjarke Dahl Ebert:
> >"Niels Teglsbo" <Niels@fabel.dk> wrote in message
> >news:fg9brugd1q3l4nrhhcq6eurgnororhpcdo@news.image.dk...
> >> Jeg mener strenge af den slags altid er konstanter i C++ ifølge
Stroustrup
> >> 3, men jeg har ikke bogen længere, og MSDN-dokumentationen siger
> >> udefineret, men den er sikkert ældre.
> >Ja, vist er de konstante, i den betydning at man ikke dynamisk må tildele
> >dem en værdi.
> >Men grundet historiske ulykker, er det lovligt på compiletime at sige
> > char* p = "foo";
> > *p = 'F';
> Er det ikke undefined behaviour? Er der noget der forhindrer compileren
> i at lave en mprotect() på "foo", så en skrivning resulterer i en
> segmentation fault?

Jo, jeg tror vi måske roder to forskellige betydninger af "konstant" sammen.
Ifølge standarden har det undefined behavior at skrive til en litteral
string.
Det er det jeg mener med at man ikke "må" assigne til dem. (Under antagelse
af at man ikke må lave programmer med undefined behavior . Og derfor kan
man godt sige at strengen er "konstant".

Men på compiletime SKAL C++-implementationen acceptere
char* p = "foo";
Så i den forstand er "foo" ikke konstant (i forhold til C++ typer).

Bjarke

---

Kent Friis <leeloo@phreaker.net> skrev:
> Den Tue, 22 Oct 2002 22:14:26 +0200 skrev Bjarke Dahl Ebert:

>>Ja, vist er de konstante, i den betydning at man ikke dynamisk må tildele
>>dem en værdi.
>>Men grundet historiske ulykker, er det lovligt på compiletime at sige
>> char* p = "foo";
>> *p = 'F';
>
> Er det ikke undefined behaviour?

Jo, det er det. Men Bjarke har alligevel ret i at det er lovligt
"på compiletime". Med andre ord, en oversætter må ikke nægte at
oversætte det.

Men hvad som helst må ske hvis man forsøger på at udføre den
oversatte kode da det ganske rigtigt medfører udefineret adfærd.

--
Skal musik- og edb-industrien have ret til fratage forbrugerne deres
rettigheder i henhold til Ophavsretloven, begrænse konkurrencen og
fremme monopoldannelse ved hjælp af tekniske midler? Sig nej! Nu!
Støt underskriftsindsamlingen på http://www.digitalforbruger.dk

---

leeloo@phreaker.net (Kent Friis) wrote:

> Er det ikke undefined behaviour? Er der noget der forhindrer compileren
> i at lave en mprotect() på "foo", så en skrivning resulterer i en
> segmentation fault?

På Linux giver det i hvert fald en segmentation fault.

Selv valgrind laver segmentation fault når jeg kører
valgrind ./strengkonstant
Gad vide om det er en bug i valgrind?

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

"Niels Teglsbo" <Niels@fabel.dk> wrote in message
news:rtlgruo4sniq3knll3itr8evdb4059m5k6@news.image.dk...

> På Linux giver det i hvert fald en segmentation fault.

På det punkt har Linux det præcist som MS-Windows:
Det afhænger af hvilken compiler man bruger (og måske hvilke options man
bruger), hvilket er i overensstemmelse med C++ standarden.
Det er ikke en egenskab ved operativ-systemet - det er en egenskab ved
compiler implementeringen.

Det er træls at det er tilladt at skrive
char* p = "foo";
når nu en string literal er "array of const char" - men sådan er det.

Man kan lige så godt have vanen at skrive
const char* p = "foo";
men det havde været rart (bortset fra bagud kompatibilitet - som man ikke
kan set bort fra) hvis compileren krævede det.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen <mogens_h@dk-online.dk> skrev:
>
> Det er træls at det er tilladt at skrive
> char* p = "foo";
> når nu en string literal er "array of const char" - men sådan er det.

Med gcc kan man undgå runtime-fejl hvis man skal oversætte gamle
programmer (sådanne programmer skriver man naturligvis ikke selv!)
som skriver til string literals. Tilvalget -fwritable-strings
betyder:

Store string constants in the writable data segment and don't
uniquize them


Og man kan fange fejlene på oversættelsestidspunktet med brug af
tilvalget -Wwrite-strings som betyder:

Give string constants the type `const char[LENGTH]' so that
copying the address of one into a non-`const' `char *' pointer
will get a warning.


> Man kan lige så godt have vanen at skrive
> const char* p = "foo";
> men det havde været rart (bortset fra bagud kompatibilitet - som man ikke
> kan set bort fra) hvis compileren krævede det.

Man kan som sagt få gcc at give en advarsel hvis man gør det.

--
Skal musik- og edb-industrien have ret til fratage forbrugerne deres
rettigheder i henhold til Ophavsretloven, begrænse konkurrencen og
fremme monopoldannelse ved hjælp af tekniske midler? Sig nej! Nu!
Støt underskriftsindsamlingen på http://www.digitalforbruger.dk

---

Byrial Jensen <bjensen@nospam.dk> wrote:

> > Man kan lige så godt have vanen at skrive
> > const char* p = "foo";
> > men det havde været rart (bortset fra bagud kompatibilitet - som man ikke
> > kan set bort fra) hvis compileren krævede det.
> Man kan som sagt få gcc at give en advarsel hvis man gør det.

Det ville være rart hvis den så ved compile-time kunne opdage fejl som:

char* p = "foo";
*p = 'F';

.... ved at lade p være const char* og lade det flyde rundt ved alle kald og
tildelinger. Så kunne man sikkert finde en del fejl, også uden at skulle
ændre gammel kode.

Men det skulle nok være noget man skulle slå til selv, for der kan jo
sagtens være kode, hvor flere forskellige char-arrays kan tildeles en
pointer, hvor oversætteren ikke på forhånd kan afgøre hvilke der er mulige.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

"Niels Teglsbo" <Niels@fabel.dk> wrote in message
news:8jejrugjincljdp2lr1pfi1l8pjq5bnh6b@news.image.dk...

> Det ville være rart hvis den så ved compile-time kunne opdage fejl som:
>
> char* p = "foo";
> *p = 'F';
>
> ... ved at lade p være const char* og lade det flyde rundt ved alle kald
og
> tildelinger. Så kunne man sikkert finde en del fejl, også uden at skulle
> ændre gammel kode.
>
> Men det skulle nok være noget man skulle slå til selv, for der kan jo
> sagtens være kode, hvor flere forskellige char-arrays kan tildeles en
> pointer, hvor oversætteren ikke på forhånd kan afgøre hvilke der er
mulige.

Jep, du beder jo om statisk dataflow-analyse. Det er generelt uafgørligt.
Og selv i mere specielle tilfælde ville det sætte compileren på en større
opgave end de fleste compilerleverandører er villige til (i stand til) at
levere.

Tænk også på
struct foo
{
char* p;
};

// ...
struct foo *f = ...
f.p = "hello";
dosomething(f);

Hver kan man har en compiler der kan klare sådan noget, skruer man bare lidt
op for kompleksiteten, så har compileren igen tabt. Man kommer nemt ud i
datastrukturer som compileren ikke kan gennemskue. Det er, som du selv er
inde på, umuligt i det generelle tilfælde for compileren at afgøre om en
given "char *" kan pege på en const char[n].

Mvh. Bjarke

---

Niels Teglsbo <Niels@fabel.dk> skrev:
>
> Selv valgrind laver segmentation fault når jeg kører
> valgrind ./strengkonstant
> Gad vide om det er en bug i valgrind?

valgrind kan ikke forhindre det i at ske, men den burde vel lave en
notits om fejlen før den indtræffer. Skriv evt. om det til Julian.

Oversæt med -fwritable-strings hvis du vil undgå en segfault.

--
Skal musik- og edb-industrien have ret til fratage forbrugerne deres
rettigheder i henhold til Ophavsretloven, begrænse konkurrencen og
fremme monopoldannelse ved hjælp af tekniske midler? Sig nej! Nu!
Støt underskriftsindsamlingen på http://www.digitalforbruger.dk

---

Byrial Jensen <bjensen@nospam.dk> wrote:

> valgrind kan ikke forhindre det i at ske, men den burde vel lave en
> notits om fejlen før den indtræffer. Skriv evt. om det til Julian.

Yep, jeg troede den simulerede CPU i valgrind skulle opdage, at skrivningen
ville give en segmentation fault og forhindre den. Men nu får vi se hvad
Julian siger.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Niels Teglsbo <Niels@fabel.dk> skrev:
>
> Yep, jeg troede den simulerede CPU i valgrind skulle opdage, at skrivningen
> ville give en segmentation fault

Der er ikke noget til hinder for at valgrind opdager det - altså
bortset fra at den ikke i øjeblikket tjekker om et lagersegment er
read-only.

> og forhindre den.

Nej. Valgrind forhindrer aldrig noget i at ske. Den kan som regel
sige til hvis noget vil gå galt, men alt hvad der er i programmet
bliver udført. Det gælder også for et program som dette:

int main()
{
return *(char *)0; // UPS - dereference af NULL-pointer
}

Hvad skulle dette program returnere hvis valgrind ville forhindre
en lagersegmentfejl? Nej, valgrind ændrer ikke i et program selv
når det opdager at det vil gå ned.

--
Skal musik- og edb-industrien have ret til fratage forbrugerne deres
rettigheder i henhold til Ophavsretloven, begrænse konkurrencen og
fremme monopoldannelse ved hjælp af tekniske midler? Sig nej! Nu!
Støt underskriftsindsamlingen på http://www.digitalforbruger.dk

---

Byrial Jensen <bjensen@nospam.dk> wrote:

> valgrind kan ikke forhindre det i at ske, men den burde vel lave en
> notits om fejlen før den indtræffer. Skriv evt. om det til Julian.

Problemet er, at valgrind kun ser om hukommelse må bruges. Den forstår
ikke, at et hukommelsesområde godt må læses, men ikke skrives. Det var ikke
sikkert han ville fikse det.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Niels Teglsbo <Niels@fabel.dk> skrev:
> Byrial Jensen <bjensen@nospam.dk> wrote:
>
>> valgrind kan ikke forhindre det i at ske, men den burde vel lave en
>> notits om fejlen før den indtræffer. Skriv evt. om det til Julian.
>
> Problemet er, at valgrind kun ser om hukommelse må bruges. Den forstår
> ikke, at et hukommelsesområde godt må læses, men ikke skrives. Det var ikke
> sikkert han ville fikse det.

Sagen kompliceres af at hukommelsesområder kan have enhver
kombination af læse-, skrive- og udførelsestilladelser. En generel
løsning skal f.eks. også kunne håndtere hukommelsesområder som kun
må skrives, men ikke må læses.

--
Skal musik- og edb-industrien have ret til fratage forbrugerne deres
rettigheder i henhold til Ophavsretloven, begrænse konkurrencen og
fremme monopoldannelse ved hjælp af tekniske midler? Sig nej! Nu!
Støt underskriftsindsamlingen på http://www.digitalforbruger.dk

---

"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote:

> Ja, vist er de konstante, i den betydning at man ikke dynamisk må tildele
> dem en værdi.

Jeg mindes så at have set, at de også ved compilering måtte opfattes som
const char*, men det er i en bog jeg ikke længere har og jeg bliver mere og
mere i tvivl, så medmindre andre kan bekræfte det er det jo ikke meget
værd.

> Men bortset fra det, siger du så ikke at man ikke har brug for typecheck?
> "For man bryder vel ikke typereglerne".

Man har som regel ikke lyst til at bryde typereglerne.

Derfor er en typechecker en rigtig god ting, der kan hjælpe en med ikke at
komme til at bryde typereglerne.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

"Torben W. Hansen" <mail@ins-intersoft.com> wrote in message
news:aon6h6$1jhe$1@news.cybercity.dk...

[8<8<8<]
> Forleden dag ordrede jeg "Accelerated C++" ISBN: 0-201-70353-x

Det lyder som et glimrende valg.
Husk at lave øvelserne!

"Accelerated C++" beskæftiger sig egentlig ikke ret meget med OOP, selvom
den naturligvis forklarer hvordan man laver klasser osv.
I stor udstrækning bruger den bare klasser (som std::string, std::vector)
uden at gøre et større nummer ud af det.
Kapitel 15 indeholder dog et ualmindeligt elegant eksempel på
objekt-orienteret design og implementering i C++.
Det er ikke rent objekt orienteret, men en smagfuld kombination af objekter
og globale metoder og nydelig, simpel håndtering af ejerskab.

[8<8<8<]
> ... men ved den grundlæggende indlæring af OOP - og især ved
> selvstudie - foretrækker jeg, om muligt, dansk.

I tillæg til "Objektorienteret analyse og design", som Jens Axel Søgaard
nævnte, og som flere af mine kollegaer har stående og så vidt jeg ved er
tilfredse med, vil jeg også lige nævnte 2 forholdsvis nye bøger fra
Ingeniøren|bøger:

Introduktion til struktureret og objektorienteret programmering
Helmer Hansen
ISBN 87-571-2220-2

Objektorienteret systemudvikling med UML
Therese Vendelhaven
ISBN 87-571-2432-9

Jeg har ikke læst dem endnu, selvom jeg har dem stående.


Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:aopslr$1v0h$1@news.cybercity.dk...

> ...vil jeg også lige nævnte 2 forholdsvis nye bøger fra
> Ingeniøren|bøger:

Ups jeg glemte:
se http://bog.ing.dk/

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:aopslr$1v0h$1@news.cybercity.dk...
> I tillæg til "Objektorienteret analyse og design", som Jens Axel Søgaard
> nævnte, og som flere af mine kollegaer har stående og så vidt jeg ved er
> tilfredse med, vil jeg også lige nævnte 2 forholdsvis nye bøger fra
> Ingeniøren|bøger:
>
> Introduktion til struktureret og objektorienteret programmering
> Helmer Hansen
> ISBN 87-571-2220-2
>
> Objektorienteret systemudvikling med UML
> Therese Vendelhaven
> ISBN 87-571-2432-9
>
> Jeg har ikke læst dem endnu, selvom jeg har dem stående.

OK og tak - Dem vil jeg lige tage et kik på. Da jeg var inde
Ingeniøren|bøger på et tidligere tidspunkt fandt jeg iøvrigt følgende :

C/C++ grundbog i programmering
Forfatter: Henrik Kressner
ISBN: 87-571-2270-9

C++ - videregående programmering
Forfatter: Jeff Alger
ISBN: 87-571-2216-4

Jeg tror egentlig at disse er diskuteret tidligere i gruppen, og da jeg var
inde og kikke på kodeeksempler til den første af ovennævnte, mener jeg at
huske, at der f.eks. ikke blev anvendt "namespace". Du kender sansynligvis
bøgerne og jeg formoder at du havde anbefalet dem, hvis de var gode.

Har du kendskab til bogen som jeg startede tråden med ?

C++ Grundbog
Jesse Liberty
ISBN: 87-7843-561-7

Med venlig hilsen
Torben W. hansen

---

"Torben W. Hansen" <mail@ins-intersoft.com> wrote in message
news:ap0alv$12kp$1@news.cybercity.dk...
> "Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
> news:aopslr$1v0h$1@news.cybercity.dk...

[8<8<8<]
> Har du kendskab til bogen som jeg startede tråden med ?
>
> C++ Grundbog
> Jesse Liberty
> ISBN: 87-7843-561-7

Nej, den kender jeg ikke.

Ud fra indholdsfortegnelsen ligner det en oversættelse af
Teach Yourself C++ in 24 Hours
Jesse Liberty

Jeg kan ikke finde nogen anmeldelse af den bog på www.accu.org.

Du har allerede har bestilt "Accelerated C++".
Det er forhåbenligt et valg du ikke vil fortryde. Koncentrer dig om at
arbejde den grundigt igennem. Bagefter kan man altid finde nogle bøger der
rækker videre.


Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:ap1kld$2lir$1@news.cybercity.dk...

> Ud fra indholdsfortegnelsen ligner det en oversættelse af
> Teach Yourself C++ in 24 Hours
> Jesse Liberty
Og den er ?

> Jeg kan ikke finde nogen anmeldelse af den bog på www.accu.org.
Anmeldes der også danske bøger her da ?

> Du har allerede har bestilt "Accelerated C++".
> Det er forhåbenligt et valg du ikke vil fortryde. Koncentrer dig om at
> arbejde den grundigt igennem. Bagefter kan man altid finde nogle bøger der
> rækker videre.
Jeg føler mig da også overbevist om, at denne bog bliver omdrejningspunktet
i det næste stykke tid.


Med venlig hilsen
Torben W. Hansen

---

"Torben W. Hansen" <mail@ins-intersoft.com> wrote in message
news:ap2pr9$ksf$1@news.cybercity.dk...
> "Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
> news:ap1kld$2lir$1@news.cybercity.dk...
>
> > Ud fra indholdsfortegnelsen ligner det en oversættelse af
> > Teach Yourself C++ in 24 Hours
> > Jesse Liberty
> Og den er ?
>
> > Jeg kan ikke finde nogen anmeldelse af den bog på www.accu.org.
> Anmeldes der også danske bøger her da ?

Nej, det tror jeg ikke.
Men det var en mulighed at den engelske original version var anmeldt -
hvilket jeg dog ikke kan se er tilfældet.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:ap4517$28b6$3@news.cybercity.dk...

> > > Ud fra indholdsfortegnelsen ligner det en oversættelse af
> > > Teach Yourself C++ in 24 Hours
> > > Jesse Liberty
> > Og den er ?

Hvordan er "Teach Yourself C++ in 24 Hours" ?

Med venlig hilsen
Torben W. Hansen

---

Tak for hjælpen allesammen !

Jeg vil nu forsøge at følge nogle af jeres råd og anbefalinger...

Med venlig hilsen
Torben Winther Hansen