---

Jeg sidder og læser i "The C++ Programming Language - Special Edition" (af
Bjarne Stroustrup).
Rigtig god bog ( i hvert fald, hvis man ikke kender C++, men godt kender til
andre sprog).
På side 92 nævnes der et eksempel ala følgende:

void f()
{
char a[] = "test";
char* p = a;
strlen(a);
strlen(p);
}

Det eneste jeg havde ved hånden var en C-kompiler, og der lader "strlen" at
være defineret: unsigned int strlen(const char *);
Så vidt så godt... Bjarne skriver "strlen" både kan tage min "a" og "p" som
argument (a og p er navnene på variablerne fra ovenover), idet min "a"
automatisk implicit vil blive konverteret til pointer. Nu til mine
spørgsmål:

Det lader til, at dette ikke er gjort ved overloadede "strlen", men er det
compileren, der gør det så?
Hvis det er det sidste, strider det lidt imod, hvad jeg troede om, at C++
overlader så meget som muligt til libraries i stedet for at lave hokus-pokus
ting i compileren (men selvfølgelig C++ har jo skulle holde C kompabilitet).
Jeg formoder det er compileren i og med, at AFAIK så er arrays i C++
konstrueret således, at første element i arrayet er på samme addresse som
selve arrayet. Hvis det er korrekt, så adskiller det sig jo netop fra en
pointer, som først skal derefereres. Derfor kan jeg ikke se, hvordan begge
ting kan blive brugt som parameter uden compiler "magi".
Jeg gætter på at compiler magien er, at alle steder hvor man kun alene
angiver array (og ikke noget med [] bagefter), bliver det implicit
konverteret til pointer, men er det rigtigt?

Jeg kunne ikke rigtigt selv finde frem til og konkludere svarene på de
sidste 2 ting, da jeg ikke kunne få følgende testkode til at virke:
#include <stdio.h>
int main()
{
// (pascal dummie | C newbie) trying to figure out implementation of C
arrays
char *a;
char p1[] = "compare_addr";
*a = (&p1 == &p1[0]) ? 'y' : 'n';
printf(a);
return 1;
}


mvh.
Thomas Schulz

---

Den Thu, 29 Mar 2001 16:53:39 +0200 skrev Thomas Schulz:
>Jeg sidder og læser i "The C++ Programming Language - Special Edition" (af
>Bjarne Stroustrup).
>Rigtig god bog ( i hvert fald, hvis man ikke kender C++, men godt kender til
>andre sprog).
>På side 92 nævnes der et eksempel ala følgende:
>
>void f()
>{
> char a[] = "test";
> char* p = a;
> strlen(a);
> strlen(p);
>}
>
>Det eneste jeg havde ved hånden var en C-kompiler, og der lader "strlen" at
>være defineret: unsigned int strlen(const char *);
>Så vidt så godt... Bjarne skriver "strlen" både kan tage min "a" og "p" som
>argument (a og p er navnene på variablerne fra ovenover), idet min "a"
>automatisk implicit vil blive konverteret til pointer. Nu til mine
>spørgsmål:
>
>Det lader til, at dette ikke er gjort ved overloadede "strlen", men er det
>compileren, der gør det så?

En pointer og et array er pr. definition det samme i C*

>Jeg kunne ikke rigtigt selv finde frem til og konkludere svarene på de
>sidste 2 ting, da jeg ikke kunne få følgende testkode til at virke:

>#include <stdio.h>
>int main()
>{
> // (pascal dummie | C newbie) trying to figure out implementation of C
>arrays
> char *a;

En pointer = NULL

> char p1[] = "compare_addr";

En streng

> *a = (&p1 == &p1[0]) ? 'y' : 'n';

Adresse 0 overskrives med 'y' eller 'n' med flg. resultat:

MS-DOS: Interrupttabellen er ødelagt, maskinen er død.
*nix: SIGSEGV: segmenation fault - core dumped.
Windows: Et sted mellem død maskine, blå skærm og "ulovlig handling",
afhængig af hvilken version.

> printf(a);
> return 1;
>}

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: bay.png

---

leeloo@mailandnews.com (Kent Friis) skrev:
>En pointer og et array er pr. definition det samme i C*

Per definition, ligefrem? Nej da. Så ville man jo fx kunne skrive

   extern char p[100];
   extern char *p;

- og den går ikke: et array og en pointer er absolut ikke det samme.

Men, en array-lvalue (dvs et array-navn, der optræder i et expression)
bliver stort set altid implicit konverteret til en pointer til det
første element i arrayet og derfor lider mange under den misforståelse,
at de er det samme. C-standarden (6.2.2.1) siger, at det sker undtagen
når array-variablen

- er en operand til sizeof, dvs sizeof(array)
- er en operand til &, dvs &array
- er en konstant streng (evt wide) brugt til initialisering
af et array, fx array[] = "hello world";

Bortset fra de tre tilfælde bliver et array altid konverteret til en
pointer til første element når det optræder i et expression. Men det
betyder altså ikke, at en array-variabel er det samme som en pointer-
variabel. Den forklaring besvarer i øvrigt også Thomas' oprindelige
spørgsmål.


>> char *a;
>> *a = (&p1 == &p1[0]) ? 'y' : 'n';
>
>Adresse 0 overskrives med 'y' eller 'n' [...]

Mjah, adresse 0 eller hvor den uinitialiserede a nu tilfældigvis peger
hen. Anyway, Thomas bør fjerne *'et foran a begge steder, for han har
kun behov for en char, ikke en pointer til en char.

>> printf(a);

- og så bruge printf("%d\n", a) i stedet.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

Den Thu, 29 Mar 2001 22:56:39 +0200 skrev Richard Flamsholt:
>leeloo@mailandnews.com (Kent Friis) skrev:
>>En pointer og et array er pr. definition det samme i C*
>
>Per definition, ligefrem? Nej da. Så ville man jo fx kunne skrive
>
>   extern char p[100];
>   extern char *p;
>
>- og den går ikke: et array og en pointer er absolut ikke det samme.
>
>Men, en array-lvalue (dvs et array-navn, der optræder i et expression)
>bliver stort set altid implicit konverteret til en pointer til det
>første element i arrayet og derfor lider mange under den misforståelse,
>at de er det samme. C-standarden (6.2.2.1) siger, at det sker undtagen
>når array-variablen
>
> - er en operand til sizeof, dvs sizeof(array)
> - er en operand til &, dvs &array
> - er en konstant streng (evt wide) brugt til initialisering
> af et array, fx array[] = "hello world";
>
>Bortset fra de tre tilfælde bliver et array altid konverteret til en
>pointer til første element når det optræder i et expression. Men det
>betyder altså ikke, at en array-variabel er det samme som en pointer-
>variabel. Den forklaring besvarer i øvrigt også Thomas' oprindelige
>spørgsmål.

Ok, det var en meget simplificeret udgave. Teknisk set har du ret.

>
>>> char *a;
>>> *a = (&p1 == &p1[0]) ? 'y' : 'n';
>>
>>Adresse 0 overskrives med 'y' eller 'n' [...]
>
>Mjah, adresse 0 eller hvor den uinitialiserede a nu tilfældigvis peger
>hen.

Jeg mener nu at have læst på LKML at C-standarden siger at variable
initialiseres til 0. Men det var måske kun globale variable?

>Anyway, Thomas bør fjerne *'et foran a begge steder, for han har
>kun behov for en char, ikke en pointer til en char.
>
>>> printf(a);
>
>- og så bruge printf("%d\n", a) i stedet.

Måske %c vil gøre det lidt mere læseligt

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: paris.png
Fedt - ferie helt til 1/5 :-þ

---

leeloo@mailandnews.com (Kent Friis) skrev:
>Ok, det var en meget simplificeret udgave. Teknisk set har du ret.

Jeg brokkede mig også kun fordi du sagde at de "per definition" var ens.

>Jeg mener nu at have læst på LKML at C-standarden siger at variable
>initialiseres til 0. Men det var måske kun globale variable?

Alle static variable initialiseres automatisk til 0. Alle andre variable
har en ukendt startværdi.
(For begge gælder naturligvis at man eksplicit kan initialisere dem til
en anden værdi)

>>- og så bruge printf("%d\n", a) i stedet.
>
>Måske %c vil gøre det lidt mere læseligt

Touché Ja, jeg glemte i skyndingen at han ville skrive et tegn ud,
og ikke en sand/falsk værdi.

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

---

Den Fri, 30 Mar 2001 01:49:30 +0200 skrev Richard Flamsholt:
>leeloo@mailandnews.com (Kent Friis) skrev:
>>Ok, det var en meget simplificeret udgave. Teknisk set har du ret.
>
>Jeg brokkede mig også kun fordi du sagde at de "per definition" var ens.

Jeg må kunne undskylde mig med at jeg sad og halvsov - det er nok ikke
nogen god ide at forsøge at lære folk C, når jeg havde opgivet at
programmere mere igår, fordi jeg var for træt...

>>Jeg mener nu at have læst på LKML at C-standarden siger at variable
>>initialiseres til 0. Men det var måske kun globale variable?
>
>Alle static variable initialiseres automatisk til 0. Alle andre variable
>har en ukendt startværdi.

Makes sence. Det er alle dem der kun oprettes en gang. Variable på
stakken (og ditto malloc'ede) er kun 0, hvis programmet ikke har brugt
det område før. (og kun hvis OS'et rent faktisk ryder et hukommelses-
område før man får det tildelt).

Correct me if i'm wrong.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: paris.png
Fedt - ferie helt til 1/5 :-þ

---

Richard Flamsholt <richard@flamsholt.dk> skrev:
>leeloo@mailandnews.com (Kent Friis) skrev:
>
>>Jeg mener nu at have læst på LKML at C-standarden siger at variable
>>initialiseres til 0. Men det var måske kun globale variable?
>
>Alle static variable initialiseres automatisk til 0. Alle andre variable
>har en ukendt startværdi.

Nej, ikke alle andre variable. Globale, ikke-statiske variable
initialiseres også til 0.

---

Den Sun, 01 Apr 2001 15:35:13 GMT skrev Byrial Jensen:
>Richard Flamsholt <richard@flamsholt.dk> skrev:
>>leeloo@mailandnews.com (Kent Friis) skrev:
>>
>>>Jeg mener nu at have læst på LKML at C-standarden siger at variable
>>>initialiseres til 0. Men det var måske kun globale variable?
>>
>>Alle static variable initialiseres automatisk til 0. Alle andre variable
>>har en ukendt startværdi.
>
>Nej, ikke alle andre variable. Globale, ikke-statiske variable
>initialiseres også til 0.

Er globale variable ikke statiske?

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: paris.png
Fedt - ferie helt til 1/5 :-þ

---

Kent Friis <leeloo@mailandnews.com> skrev:
>Den Sun, 01 Apr 2001 15:35:13 GMT skrev Byrial Jensen:
>>Richard Flamsholt <richard@flamsholt.dk> skrev:
>>>Alle static variable initialiseres automatisk til 0. Alle andre variable
>>>har en ukendt startværdi.
>>
>>Nej, ikke alle andre variable. Globale, ikke-statiske variable
>>initialiseres også til 0.
>
>Er globale variable ikke statiske?

Ikke nødvendigvis. (Ordforklaring: Med statiske variable mener jeg
variable som er erklæret med brug af ordet "static". Med globale
variable mener jeg variable som ikke er erklæret inden i en funktion
og dermed ikke begrænset til at bruges inden for en enkelt
funktion).

En statisk global variabel kan, i modsætning til ikke-statiske
globale variable, kun bruges i den fil hvori den erklæret.

---

* Byrial Jensen

> En statisk global variabel kan, i modsætning til ikke-statiske
> globale variable, kun bruges i den fil hvori den erklæret.


s/fil/translation unit/;





ivr
--
Death by snoo-snoo

---

Igor V. Rafienko <igorr@ifi.uio.no> skrev:
>* Byrial Jensen
>
>> En statisk global variabel kan, i modsætning til ikke-statiske
>> globale variable, kun bruges i den fil hvori den erklæret.
>
>s/fil/translation unit/;

Ja, klart. Tak for rettelsen. (En "oversættelsesenhed" er resultatet
når en c-fil har gennemgået al præprocessing inkl. brug af
#include-direktiver).

---

* Kent Friis

[snip]

> En pointer og et array er pr. definition det samme i C*


Dette er _feil_. P. van der Linden snakker om alle tilfellene der en
array og en pointer er like og ulike i "Expert C Programming: Deep C
Secrets". Ta en titt.


> >#include <stdio.h>
> >int main()
> >{
> > // (pascal dummie | C newbie) trying to figure out implementation of C
> >arrays
> > char *a;
>
> En pointer = NULL


Nei.


> > char p1[] = "compare_addr";
>
> En streng


En array.


> > *a = (&p1 == &p1[0]) ? 'y' : 'n';
>
> Adresse 0


Nei. En vilkårlig adresse som ikke trenger å være NULL (hint: a er
automatisk).

[snip]





ivr
--
Death by snoo-snoo

---

"Kent Friis" <leeloo@mailandnews.com> wrote in message
news:99vop8$gcn$1@sunsite.dk...
> Den Thu, 29 Mar 2001 16:53:39 +0200 skrev Thomas Schulz:
>
> En pointer og et array er pr. definition det samme i C*
>
En ikke ualmindelig misforståelse, men følgende er en god illustration af at
det rent faktisk ikke er tilfældet.
---
char streng[] = "en streng";
char *p = streng;

sizeof(streng) = 10;
sizeof(p) = 4 // 32-bit addressering.

p = streng; // lovligt
streng = p; // ulovligt
---

Når et char array bruges i udtryk fungerer den i realiteten som en "char *
const", hvilket (læst bagfra) er en konstant pointer til char, alså en
pointer hvor pointer-adressen er konstant (og ikke det den peger på).

Claus

---

Den Fri, 30 Mar 2001 01:00:58 +0200 skrev Claus Brinch Jensen:
>
>"Kent Friis" <leeloo@mailandnews.com> wrote in message
>news:99vop8$gcn$1@sunsite.dk...
>> Den Thu, 29 Mar 2001 16:53:39 +0200 skrev Thomas Schulz:
>>
>> En pointer og et array er pr. definition det samme i C*
>>
>En ikke ualmindelig misforståelse, men følgende er en god illustration af at
>det rent faktisk ikke er tilfældet.
>---
>char streng[] = "en streng";
>char *p = streng;
>
>sizeof(streng) = 10;
>sizeof(p) = 4 // 32-bit addressering.
>
>p = streng; // lovligt
>streng = p; // ulovligt
>---
>
>Når et char array bruges i udtryk fungerer den i realiteten som en "char *
>const", hvilket (læst bagfra) er en konstant pointer til char, alså en
>pointer hvor pointer-adressen er konstant (og ikke det den peger på).

Jeg kan kun give dig ret. Selvom jeg faktisk engang havde en lærer (på
datamatiker) der var helt sikker på at det var en forkert opsætning
i compileren der gjorde at flg. galv lvalue-fejl:

char streng[25];
streng++;

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: paris.png
Fedt - ferie helt til 1/5 :-þ

---

* Thomas Schulz


> void f()
> {
> char a[] = "test";
> char* p = a;
> strlen(a);
> strlen(p);
> }
>
> Det eneste jeg havde ved hånden var en C-kompiler, og der lader "strlen" at
> være defineret: unsigned int strlen(const char *);


Det er en pussig definisjon, men ok, la gå.


> Så vidt så godt... Bjarne skriver "strlen" både kan tage min "a" og
> "p" som argument (a og p er navnene på variablerne fra ovenover),
> idet min "a" automatisk implicit vil blive konverteret til pointer.
> Nu til mine spørgsmål:
>
> Det lader til, at dette ikke er gjort ved overloadede "strlen", men er det
> compileren, der gør det så?


I C familien settes det noen ganger likhetstegn mellom 2 _meget_
forskjellige begreper: en array og en pointer. Bl.a. idet man sender
en array som argument til en funskjon (fx. strlen) blir array'en
implisitt konvertert til en peker til det første elementet. Dette
heter "array to pointer conversion", iirc.


> Hvis det er det sidste, strider det lidt imod, hvad jeg troede om,
> at C++ overlader så meget som muligt til libraries i stedet for at
> lave hokus-pokus ting i compileren (men selvfølgelig C++ har jo
> skulle holde C kompabilitet).


For å si det på den pene måten: det er _mye_ dyp magi i en C++
kompilator. Implisitt konvertering kombinert med fx. templates gir
veldig innviklede regler ang. valg av funksjoner som skal kalles. Jeg
prøvde for en stund tilbake å forstå hvordan man _egentlig_ skulle
finne ut hvilken funksjon ble kallt gitt uttrykket "foo( expr1 )", men
jeg gav opp forholdsvis fort.


> Jeg formoder det er compileren i og med, at AFAIK så er arrays i C++
> konstrueret således, at første element i arrayet er på samme
> addresse som selve arrayet.


Generelt er arrays et litt mer komplisert begrep enn en rå adresse
til det første elementet. I en del språk er arrays egne objekter med
bl.a. dimensjoner, størrelser, index ranges og lignenede snacks pakket
inn i det objektet.

I C++ er det ingen slike krav i standarden og man velger (av en rekke
årsaker) å oversette alle referanser til en array direkte til
referanser til hukommelsen der elementene i array'en ligger.

Man kan gjerne si at 1. element i arrayen er på samme adresse som
selve arrayen (dog, jeg har aldri hørt noen si dette før).


> Hvis det er korrekt, så adskiller det sig jo netop fra en pointer,
> som først skal derefereres.


C++ har dessverre arvet en rekke uheldige egenskaper fra C. Implisitt
array to pointer conversion er en av disse.


> Derfor kan jeg ikke se, hvordan begge ting kan blive brugt som
> parameter uden compiler "magi". Jeg gætter på at compiler magien er,
> at alle steder hvor man kun alene angiver array (og ikke noget med
> [] bagefter), bliver det implicit konverteret til pointer, men er
> det rigtigt?


IIRC er dette riktig (orker ikke å lete i standarden etter alle
referanser). Dette gjelder definitivt for argumenter til funksjoner
(8.3.5, p 3).


> Jeg kunne ikke rigtigt selv finde frem til og konkludere svarene på de
> sidste 2 ting, da jeg ikke kunne få følgende testkode til at virke:
> #include <stdio.h>
> int main()
> {
> // (pascal dummie | C newbie) trying to figure out implementation
> // of C arrays
> char *a;
> char p1[] = "compare_addr";
> *a = (&p1 == &p1[0]) ? 'y' : 'n';
> printf(a);
> return 1;
> }


Dette er ikke helt riktig av flere grunner:

1. Legg merke til at variabelen a ikke peker på noe som helst. Og du
prøver å skrive en verdi på det stedet som a peker på (Kent Friis
påpekte feilaktig at a vil være NULL. Det trenger slettes ikke være
tilfellet)

2. Selv om du kunne skrive til et tilfeldig sted i minne (a inneholder
jo fremdeles søppel), ville ikke det hjelpe: man må avslutte
strenger med '\0' for printf/puts sitt vedkommende.

Det du vil skrive er typisk dette:


int
main()
{
char *a;
char p1[] = "flabba la dabba";

puts( &p1 == &p1[0] ? "yes" : "no" );
}   
   
Om du _insisterer_ på å skrive noe til a, så burde du allokere litt
plass først:


a = malloc( 10 );
if ( !a )
exit( 1 );

if ( &p1 == &p1[0] )
strcpy( a, "yes" );
else
strcpy( a, "no" );

puts( a );
free( a );


BTW, leker du først med C++, bør du droppe char* så fort som mulig til
fordel for std::string. B. Stroustrup er ikke akkurat flink til å
fokusere på dette punktet (strings er vel kap. 20 (21?)).





ivr
--
Death by snoo-snoo

---

igorr@ifi.uio.no (Igor V. Rafienko) writes:

> BTW, leker du først med C++, bør du droppe char* så fort som mulig til
> fordel for std::string. B. Stroustrup er ikke akkurat flink til å
> fokusere på dette punktet (strings er vel kap. 20 (21?)).

En bog jeg har gavn af for tiden, er »Accelerated C++« af Andrew
Koenig og Barbara Moo. Forfatterne skriver selv at de fokuserer på de
mest brugbare dele af C++ fra starten. De mere bizarre
C-overleveringer bliver næsten ikke nævnt.

---

"Soeren Sandmann" <sandmann@daimi.au.dk> wrote in message
news:ye8zoe3pgz3.fsf@vocta1.daimi.au.dk...
> En bog jeg har gavn af for tiden, er »Accelerated C++« af Andrew
> Koenig og Barbara Moo. Forfatterne skriver selv at de fokuserer på de
> mest brugbare dele af C++ fra starten. De mere bizarre
> C-overleveringer bliver næsten ikke nævnt.

I det hele taget er det en rigtig god bog. Den kan kun anbefales.


--
Morten Boysen

---

"Igor V. Rafienko" <igorr@ifi.uio.no> wrote in message
news:xjv66gs1d49.fsf@kaldabras.ifi.uio.no...
> * Thomas Schulz
>
> BTW, leker du først med C++, bør du droppe char* så fort som mulig til
> fordel for std::string. B. Stroustrup er ikke akkurat flink til å
> fokusere på dette punktet (strings er vel kap. 20 (21?)).

Jeg er helt enig i at man bør bruge std::string i stedet for char*, men jeg
synes nu også at Stroustrup i høj grad lægger op til dette i sin bog.
I min udgave (3. udgave) starter han med at bruge std::string ret konsekvent
fra og med kapitel 3 (side 45) efter "notes to the reader" og et indledende
kapitel om de de forskellige konstruktioner i sproget.

Claus

---

* Claus Brinch Jensen

[snip]

> Jeg er helt enig i at man bør bruge std::string i stedet for char*,
> men jeg synes nu også at Stroustrup i høj grad lægger op til dette i
> sin bog.


[labbe på lesesalen og hente TC++PL3ed]


> I min udgave (3. udgave) starter han med at bruge std::string ret
> konsekvent fra og med kapitel 3 (side 45) efter "notes to the
> reader" og et indledende kapitel om de de forskellige konstruktioner
> i sproget.


Kapittel 3 (såvel som 2) har imvho en veldig begrenset verdi for en
som ikke kan språket. Da jeg leste TC++PL3ed for første gang, kjente
jeg fx. ikke begrepet "iterator", og iterators, templates og deres
like falt ikke helt i smak. Etter å ha dillet litt med språket en
stund, falte behovet vekk fra å lese disse kapitlene.

Jeg begriper ærlig talt ikke hvorfor BS tok dem med.

Skikkelig behandling av std::string kommer ikke før kapittel 20. Det
er imvho litt sent (et annet meget godt spørsmål er hvordan man skulle
servere std::string, tatt i betraktning at dette ikke er en basaltype
(hvilket er synd)).





ivr
--
Death by snoo-snoo

---

>..

Tak til alle for svarene :)
Jeg forstår begge ting nu (en "lidt" lam fejl i min sourcekode, det må_ være
fordi, at jeg ikke er vant til at se på C syntaks :).

mvh.
Thomas Schulz