---

Hej,

Jeg har en række strenge, og skal kalde en funktion der skal bruge en char**
til listen.

1. forsøg:
char val1[] = "asdf"
char val2[] = "abc";
char val3[] = "qwerty";
char* lst[] = { val1 , val2 , val3 };

Her er det tydeligt at der bliver allokeret hukommelse til hver streng.
Dette ser ud til at virke i koden.
(bør man egentlig caste fra char[] til char* ?)


2. forsøg:
char* lst[] = { "asdf", "abc", "qwerty"};
Dette ser også ud til at virke, men hvorfor?
I hver plads skal indsættes en pointer til noget der altså skal findes i
hukommelsen, men er der garanti for det?


Forøvrigt, hører flg til c/c++ sproget, eller er det en
compiler/preprocessor feature?

#define strFirst "Troels"
#define strLast "Thomsen"
char fullname[] = strFirst strLast;
// indeholder nu "TroelsThomsen"

mvh
Troels

---

> 1. forsøg:
> char val1[] = "asdf"
> char val2[] = "abc";
> char val3[] = "qwerty";
> char* lst[] = { val1 , val2 , val3 };
>
> Her er det tydeligt at der bliver allokeret hukommelse til hver streng.
> Dette ser ud til at virke i koden.
> (bør man egentlig caste fra char[] til char* ?)

Det der sker er, at compileren reserverer hukommelse til de tre strenge,
hvorefter den laver et array med pointers der peger på de tre strenge.

> 2. forsøg:
> char* lst[] = { "asdf", "abc", "qwerty"};
> Dette ser også ud til at virke, men hvorfor?
> I hver plads skal indsættes en pointer til noget der altså skal findes i
> hukommelsen, men er der garanti for det?

Det der sker er, at compileren reserverer hukommelse til de tre strenge,
hvorefter den laver et array med pointers der peger på de tre strenge. (
)

> Forøvrigt, hører flg til c/c++ sproget, eller er det en
> compiler/preprocessor feature?
>
> #define strFirst "Troels"
> #define strLast "Thomsen"
> char fullname[] = strFirst strLast;
> // indeholder nu "TroelsThomsen"

øhm, det er en pre-processor egenskab, men det er en del af C/C++ sproget -
ligesom f.eks. #include.

---

[ Rasmus Christian Kaae ]

[ ... ]

> > char val1[] = "asdf"
> > char val2[] = "abc";
> > char val3[] = "qwerty";
> > char* lst[] = { val1 , val2 , val3 };

[ ... ]

> Det der sker er, at compileren reserverer hukommelse til de tre
> strenge, hvorefter den laver et array med pointers der peger på de
> tre strenge.


I så fall en presisering -- kompilatoren reserverer hukommelsen til
tre strenger, reserverer hukommelsen til en kopi av hver av de tre
strengene, og lar lst[i] peke på en passende kopi...


> > 2. forsøg:
> > char* lst[] = { "asdf", "abc", "qwerty"};


.... i motsetning til denne situasjonen, der pekerne peker på
originalene.


> > Dette ser også ud til at virke, men hvorfor?


Det burde jo egentlig ikke det, men det gjør det av historiske
årsaker. Det burde heller ha stått:

const char *lst[] = { "asdf", "abc", "qwerty" };





ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---

(Jeg kom til at sende svar per mail til Igor (undskyld), men nu kommer i
andre lige med igen.)

Igor
>>> I så fall en presisering -- kompilatoren reserverer hukommelsen til
>>> tre strenger, reserverer hukommelsen til en kopi av hver av de tre
>>> strengene, og lar lst[i] peke på en passende kopi...
>>>

Troels
>> Kopi ? Hvis jeg ændrer val1, ser jeg det vel også i lst[0] ?

Igor
>Ja, men det var ikke det jeg mente. Det vil eksistere to objekter i minne
>for hver streng - ett under navnet "valN" og ett vil være navnløst. Det
>navnløset objektet er "originalen" av tekststrengen "asdf". val1 vil
>inneholde en kopi av dette objektet. Forandrer man på lst[0], vil man
>naturligvis forandre på val1 (siden lst[0] er en peker til det første
>elementet i val1). Men ikke på den navnløse originalen.
>Det er denne kopieringen som er den vesentlige forskjellen fra tilfellet 2
>under.

Ok, spisfindigt, tak

Men på en måde var det vel logisk at når linien starter med
char* q[antal]
kunne man jo tro at der kun skete noget med char-ptr arrayet
dvs. de første sizeof(char*) x antal bytes hukommelse.

mvh

---

[ Troels Thomsen ]

[ ... ]

> Men på en måde var det vel logisk at når linien starter med char*
> q[antal] kunne man jo tro at der kun skete noget med char-ptr
> arrayet dvs. de første sizeof(char*) x antal bytes hukommelse.


Det er mulig at jeg forteller det opplagte, men la oss prøve en gang
til:

Gitt følgende definisjoner:

char val1[] = "asdf"
char val2[] = "abc";
char val3[] = "qwerty";
char* lst[] = { val1 , val2 , val3 };

.... vil objektene bli plassert slik i hukommelsen[*]:

[ fixed-width font required ]

<original constants (may be in R/O memory)>
+------+ +-----+ +--------+
|asdf\0| |abc\0| |qwerty\0|
+------+ +-----+ +--------+


val1 val2 val3
+------+ +-----+ +--------+
|asdf\0| |abc\0| |qwerty\0|
+------+ +-----+ +--------+
^ ^ ^
| | |
| / |
| / |
| / __________|
\ / /
+-|-+-|-+-|-+
| * | * | * |
+---+---+---+
lst

[ /fixed width font ]

Dette er hovedpoenget i min presisering (i forhold til
<URL:news:b3ki6o$dt2$1@news.net.uni-c.dk>): array'ene val1, val2 og
val3 inneholder en (modifiserbar) _kopi_ av de originale strengene.

Siden, lst[N] og tilsvarende valM betegner det samme objektet i
hukommelsen, vil endringer gjort via den ene være synlige via den
andre. Mao.:

lst[0][0] = 'F';
/* val1[0] == 'F' */

Dette påvirker ikke de originale strengene.

Derimot, dersom man definerer ting slik:

char* lst[] = { "asdf", "abc", "qwerty"};

.... vil objektene bli plassert slik i hukommelsen:

[ fixed-width font required ]

<original constants (may be in R/O memory)>
+------+ +-----+ +--------+
|asdf\0| |abc\0| |qwerty\0|
+------+ +-----+ +--------+
^ ^ ^
| | |
| / |
| / |
| / __________|
\ / /
+-|-+-|-+-|-+
| * | * | * |
+---+---+---+
lst

[ /fixed-width font ]

.... og ethvert forsøk på å forandre på det lst[i] peker på vil
resultere i masse ulumskheter:

lst[0][0] = 'F'; /* error: modifying a constant through a non-const
pointer */





ivr
[*] Når jeg tenker meg om, så kan kompilatoren sikkert optimalisere
vekk de originale konstantene under visse omstendigheter. Men det er
ved siden av poenget mitt.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---

> Det er mulig at jeg forteller det opplagte, men la oss prøve en gang
> til:

(tak , jeg er jo ikke dum med vilje ....)

> char* lst[] = { "asdf", "abc", "qwerty"};
>
> lst[0][0] = 'F'; /* error: modifying a constant through a non-const
> pointer */


Holy moly,
Min compiler brokker sig først når jeg erklærer lst som const.
(Men det tror jeg du har kommenteret tidligere :)

>Det burde jo egentlig ikke det, men det gjør det av historiske
>årsaker. Det burde heller ha stått:
> const char *lst[] = { "asdf", "abc", "qwerty" };

altså char *lst[] = { "asdf", "abc", "qwerty" }
"burde" give en const / non-const compiler fejl?


Hvis nu det virker når man kører det på en pc er det vel fordi at koden
ligger i ram og kan modificeres?

I et embedded miljø, jeg har leget med havner begge versioner i const memory
Så det er lidt skræmmende at man kan 'forsøge' at skrive til strengen
alligevel.

Jeg burde kigge assembler koden igennem for at se hvad den tror den har gang
i...

tpt

---

[ Troels Thomsen ]

[ ... ]

> altså char *lst[] = { "asdf", "abc", "qwerty" }
> "burde" give en const / non-const compiler fejl?


Ja, og det vil være tilfellet for _alle_ andre typer enn char*. Av
historiske grunner er initialiseringen av char* med const char*
tillatt.


> Hvis nu det virker når man kører det på en pc er det vel fordi at
> koden ligger i ram og kan modificeres?


Det er vel ikke så veldig interessant? (Dessuten, PC og PC, fru Blom:

$ /local/snacks/bin/gcc -Wall -pedantic -ansi const.c
$ ./a.out
Segmentation fault
$ cat const.c
#include <stdio.h>

int
main()
{
char *args[] = { "foo", "bar", "baz" };

args[0][0] = 'z';
return 0;
}
$ uname -m
i686
$

)





ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---

Troels Thomsen <troels.thomsen@mail.tele.dk> skrev:

> altså char *lst[] = { "asdf", "abc", "qwerty" }
> "burde" give en const / non-const compiler fejl?

Det kommer an på hvad du mener med "burde".

Hvis oversætteren skal acceptere standard C (eller standard C++ for
den sags skyld) bør den ikke give en fejlmelding.

Hvis du mener at standarderne burde have været anderledes, så det et
synspunkt der findes gode argumenter for.

> Hvis nu det virker når man kører det på en pc er det vel fordi at koden
> ligger i ram og kan modificeres?

Det er generelt "udefineret adfærd" at forsøge at ændre i "string
literals". Dvs. at uanset hvad der sker, så er det tilladt adfærd.

---

Rasmus Christian Kaae wrote:
>>1. forsøg:
>>char val1[] = "asdf"
>>char val2[] = "abc";
>>char val3[] = "qwerty";
>>char* lst[] = { val1 , val2 , val3 };
>>
>>Her er det tydeligt at der bliver allokeret hukommelse til hver streng.
>>Dette ser ud til at virke i koden.
>>(bør man egentlig caste fra char[] til char* ?)
>
>
> Det der sker er, at compileren reserverer hukommelse til de tre strenge,
> hvorefter den laver et array med pointers der peger på de tre strenge.
>
>
>>2. forsøg:
>>char* lst[] = { "asdf", "abc", "qwerty"};
>>Dette ser også ud til at virke, men hvorfor?
>>I hver plads skal indsættes en pointer til noget der altså skal findes i
>>hukommelsen, men er der garanti for det?
>
>
> Det der sker er, at compileren reserverer hukommelse til de tre strenge,
> hvorefter den laver et array med pointers der peger på de tre strenge. (
> )
>
>
>>Forøvrigt, hører flg til c/c++ sproget, eller er det en
>>compiler/preprocessor feature?
>>
>>#define strFirst "Troels"
>>#define strLast "Thomsen"
>>char fullname[] = strFirst strLast;
>>// indeholder nu "TroelsThomsen"
>
>
> øhm, det er en pre-processor egenskab, men det er en del af C/C++ sproget -
> ligesom f.eks. #include.
>
>
Når du skriver flere strenge uden noget imellem bliver de fortolket som
én streng:

printf( "Hello, World\n"
"Another line\n"
"Goodbye world\n"
);

...og det er jo egentlig det du gør.

---

Robert Larsen skrev:

>>>1. forsøg:
>>>char val1[] = "asdf"
>>>char val2[] = "abc";
>>>char val3[] = "qwerty";
>>>char* lst[] = { val1 , val2 , val3 };

>Når du skriver flere strenge uden noget imellem bliver de fortolket som
>én streng:

>printf( "Hello, World\n"
> "Another line\n"
> "Goodbye world\n"
> );

>..og det er jo egentlig det du gør.

Nej.

Der vil være en nulterminering for hver eneste streng i det
citerede eksempel.

Om printf() slår de tre elementer sammen til én streng, ved jeg
ikke, men det har heller ikke noget med problemet at gøre.

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

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> skrev:
>>Når du skriver flere strenge uden noget imellem bliver de fortolket som
>>én streng:
>
>>printf( "Hello, World\n"
>> "Another line\n"
>> "Goodbye world\n"
>> );
>
>Nej.

Jo.

>Der vil være en nulterminering for hver eneste streng i det
>citerede eksempel.

Nej. Når en sourcefil fortolkes sker der - før selve parsningen af
programmet - en række transformationer. En af disse er, at konstante
strenge, der kun adskilles af whitespace, bliver slået sammen.

I eksemplet bliver det "Hello, World\nAnother line\nGoodbye world\n".

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

---

Robert Larsen skrev:

   Når du skriver flere strenge uden noget imellem bliver de
   fortolket som én streng:

>>Nej.

Richard Flamsholt skrev:

>Jo.

Og jeg skriver atter: Nej.

Påstanden blev skrevet som svar på følgende kode:

>>char val1[] = "asdf"
>>char val2[] = "abc";
>>char val3[] = "qwerty";
>>char* lst[] = { val1 , val2 , val3 };

Jeg må fastholde at det på den baggrund er et forkert udsagn -
uanset hvad printf() måtte gøre.

Lagde du ikke mærke til det her som jeg skrev:

>Om printf() slår de tre elementer sammen til én streng, ved jeg
>ikke, men det har heller ikke noget med problemet at gøre.

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

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> skrev:
>Robert Larsen skrev:
>
>   Når du skriver flere strenge uden noget imellem bliver de
>   fortolket som én streng:
>
> ...
>
>Og jeg skriver atter: Nej.

Du citerer eksplicit Roberts sætning og skriver atter nej?

Det er forkert. Roberts sætning og eksempel er helt korrekt.

Men jeg kan nu forstå at din kommentar gik på den oprindelige kode og
på, at hans eksempel var irrelevant i forbindelse med initialisering af
arrays. Det kan der til gengæld være noget om.

For at runde den af:

>Jeg må fastholde at det på den baggrund er et forkert udsagn -
>uanset hvad printf() måtte gøre.

Nej. Det var et korrekt, omend irrelevant, udsagn. Strengsammensætning
er en del af C.

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

---

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

[8<8<8<]
> Og jeg skriver atter: Nej.

Det hjælper ikke at gentage det - du tager fejl.

Fra C++ Standarden $2.13.4

<citat>
In translation phase 6 (2.1), adjacent narrow string literals are
concatenated and adjacent wide string literals are concatenated. If a narrow
string literal token is adjacent to a wide string literal token, the
behavior is undefined. Characters in concatenated strings are kept distinct.
[Example:
"\xA" "B"
contains the two characters '\xA' and 'B' after concatenation (and not the
single hexadecimal character
'\xAB'). ]
</citat>

og tilsvarende kan findes i C Standarden 6.4.5

Venlig hilsen

Mogens Hansen

---

Mogens Hansen skrev:

>Det hjælper ikke at gentage det - du tager fejl.

Siger du at disse tre strenge slås sammen til én?

   char val1[] = "asdf"
   char val2[] = "abc";
   char val3[] = "qwerty";

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

---

Bertel Lund Hansen wrote:
> Mogens Hansen skrev:
>
>
>>Det hjælper ikke at gentage det - du tager fejl.
>
>
> Siger du at disse tre strenge slås sammen til én?
>
>    char val1[] = "asdf"
>    char val2[] = "abc";
>    char val3[] = "qwerty";
>
Nej....det har ingen af os sagt.
Disse slåes til gengæld sammen:

char val[] = "blar" " bla " " baz";

Læg mærke til at det ikke er et array af strenge som:
char * val[] = "blar", " bla ", " baz";

....med kommaerne.
Og for lige at gentage Mogens Hansens udemærkede citat:

<citat>
In translation phase 6 (2.1), adjacent narrow string literals are
concatenated and adjacent wide string literals are concatenated. If a narrow
string literal token is adjacent to a wide string literal token, the
behavior is undefined. Characters in concatenated strings are kept distinct.
[Example:
"\xA" "B"
contains the two characters '\xA' and 'B' after concatenation (and not the
single hexadecimal character
'\xAB'). ]
</citat>

Mit printf havde også kun én parameter:

printf( "Hello, World\n"
"Another line\n"
"Goodbye world\n"
);

Bemærk igen....INGEN kommaer.

Robert

---

Robert Larsen wrote:
> Bertel Lund Hansen wrote:
>
>> Mogens Hansen skrev:
>>
>>
>>> Det hjælper ikke at gentage det - du tager fejl.
>>
>>
>>
>> Siger du at disse tre strenge slås sammen til én?
>>
>> char val1[] = "asdf"
>> char val2[] = "abc";
>> char val3[] = "qwerty";
>>
> Nej....det har ingen af os sagt.
> Disse slåes til gengæld sammen:
>
> char val[] = "blar" " bla " " baz";
>
> Læg mærke til at det ikke er et array af strenge som:
> char * val[] = "blar", " bla ", " baz";
>
> ...med kommaerne.
> Og for lige at gentage Mogens Hansens udemærkede citat:
>
> <citat>
> In translation phase 6 (2.1), adjacent narrow string literals are
> concatenated and adjacent wide string literals are concatenated. If a
> narrow
> string literal token is adjacent to a wide string literal token, the
> behavior is undefined. Characters in concatenated strings are kept
> distinct.
> [Example:
> "\xA" "B"
> contains the two characters '\xA' and 'B' after concatenation (and not the
> single hexadecimal character
> '\xAB'). ]
> </citat>
>
> Mit printf havde også kun én parameter:
>
> printf( "Hello, World\n"
> "Another line\n"
> "Goodbye world\n"
> );
>
> Bemærk igen....INGEN kommaer.
>
> Robert
>
Vi kunne jo f.eks. teste det:

---------------test.c------------------------
#include <string.h>
#include <stdio.h>

int main(int argc, char ** argv)
{
char * string = "Hello, World\n"
"Another line\n"
"Goodbye world\n";
int len = strlen(string);

printf("Length of string: %d\n",len);
printf("String:\n\"%s\"\n",string);

return 0;
}
---------------------------------------------
[rcl@sideshow rcl]$ gcc test.c -o test
[rcl@sideshow rcl]$ ./test
Length of string: 40
String:
"Hello, World
Another line
Goodbye world
"
[rcl@sideshow rcl]$


40 tegn i strengen. Det er selvfølgelig inklusive de tre newline karakterer.

Og forresten gik mit svar på følgende:
> #define strFirst "Troels"
> #define strLast "Thomsen"
> char fullname[] = strFirst strLast;
> // indeholder nu "TroelsThomsen"

som efter preprosesseringen skrives:

char fullname[] = "Troels" "Thomsen";

...som ifølge både C standarden og min compiler sættes sammen til:

char fullname[] = "TroelsThomsen";

Robert

---

Robert Larsen skrev:

>> Siger du at disse tre strenge slås sammen til én?

>>    char val1[] = "asdf"
>>    char val2[] = "abc";
>>    char val3[] = "qwerty";

>Nej....det har ingen af os sagt.
>Disse slåes til gengæld sammen:

Hvorfor skal det så blandes ind i en tråd der handler om den
slags? Og hvorfor er det ikke i orden at jeg fortæller at det
ikke har en skid med det at gøre?

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

---

Bertel Lund Hansen wrote:
> Robert Larsen skrev:
>
>
>>>Siger du at disse tre strenge slås sammen til én?
>>
>
>>>   char val1[] = "asdf"
>>>   char val2[] = "abc";
>>>   char val3[] = "qwerty";
>>
>
>>Nej....det har ingen af os sagt.
>>Disse slåes til gengæld sammen:
>
>
> Hvorfor skal det så blandes ind i en tråd der handler om den
> slags? Og hvorfor er det ikke i orden at jeg fortæller at det
> ikke har en skid med det at gøre?
>

Fordi der var to spørgsmål. Et gik på arrays af char arrays. Det andet
gik på compile time concatenering af strenge. Jeg citerer lige igen fra
det første indlæg:

<CITAT>
   Forøvrigt, hører flg til c/c++ sproget, eller er det en
   compiler/preprocessor feature?
   
   #define strFirst "Troels"
   #define strLast "Thomsen"
   char fullname[] = strFirst strLast;
   // indeholder nu "TroelsThomsen"
</CITAT>

Derfor havde min kommentar en del med spørgsmålet at gøre.

Robert

---

Robert Larsn skrev:

>Fordi der var to spørgsmål. Et gik på arrays af char arrays. Det andet
>gik på compile time concatenering af strenge.

Ahem ... det var pinligt. Du har fuldstændig ret, og undskyld
herfra. Jeg var så opslugt af det første spørgsmål at jeg helt
overså det andet.

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

---

Bertel Lund Hansen wrote:
> Robert Larsn skrev:
>
>
>>Fordi der var to spørgsmål. Et gik på arrays af char arrays. Det andet
>>gik på compile time concatenering af strenge.
>
>
> Ahem ... det var pinligt. Du har fuldstændig ret, og undskyld
> herfra. Jeg var så opslugt af det første spørgsmål at jeg helt
> overså det andet.
>

Helt i orden.

Robert

---

"Bertel Lund Hansen" <nospamfor@lundhansen.dk> wrote in message
news:<4l6u5v8pm618f6rr667uae0cc8v20pivv0@news.stofanet.dk>...
> Mogens Hansen skrev:
>
> >Det hjælper ikke at gentage det - du tager fejl.
>
> Siger du at disse tre strenge slås sammen til én?
>
> char val1[] = "asdf"
> char val2[] = "abc";
> char val3[] = "qwerty";


Nej, de slås bestemt ikke sammen til een - syntes du at jeg sagde det ?
Der vil ske præcist det, som Igor V. Rafienko forklarede i sin præcisering.

Mit indlæg gik på dit oprindelige svar til Robert Larsen:

<citat>
>Når du skriver flere strenge uden noget imellem bliver de fortolket som
>én streng:

>printf( "Hello, World\n"
> "Another line\n"
> "Goodbye world\n"
> );

>..og det er jo egentlig det du gør.

Nej.

Der vil være en nulterminering for hver eneste streng i det
citerede eksempel.

</citat>

med efterfølgende ja, atter nej ...

Flere string literals _uden_ _andre_ _tegn_ _imellem_, bliver opfattet som
een string literal.
Det er i overenstemmelse med hvad Robert Larsen skrev, og den opførsel står
specificeret i de referencer jeg henviste til.

Det drejer sig nok om at få alle til at være enige om hvorvidt vi snakker om
char val1[] = "asdf"
char val2[] = "abc";
char val3[] = "qwerty";
eller
printf( "Hello, World\n"
"Another line\n"
"Goodbye world\n"
);

Venlig hilsen

Mogens Hansen

---

Mogens Hansen skrev:

>Nej, de slås bestemt ikke sammen til een - syntes du at jeg sagde det ?

Jeg fatter ikke hvad den snak om printf's sammenlægninger har at
gøre med hvordan strengkonstanter og -arrays opfører sig.

Det er det jeg prøver at sige.

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

---

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

[8<8<8<]
> Jeg fatter ikke hvad den snak om printf's sammenlægninger har at
> gøre med hvordan strengkonstanter og -arrays opfører sig.

Det har ikke noget med printf at gøre.

Det drejer sig om at
const char* text = "asdfabcqwerty";
er det samme som
const char* text = "asdf" "abc" "qwerty";
som igen er det samme som
const char* text = "asdf"
"abc"
"qwerty";

som er noget _helt_ andet end
const char* val1 = "asdf";
const char* val2 = "abc";
const char* val3 = "qwerty";

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
> "Bertel Lund Hansen" <nospamfor@lundhansen.dk> wrote
>
> [8<8<8<]
>
>>Jeg fatter ikke hvad den snak om printf's sammenlægninger har at
>>gøre med hvordan strengkonstanter og -arrays opfører sig.
>
>
> Det har ikke noget med printf at gøre.
>
> Det drejer sig om at
> const char* text = "asdfabcqwerty";
> er det samme som
> const char* text = "asdf" "abc" "qwerty";
> som igen er det samme som
> const char* text = "asdf"
> "abc"
> "qwerty";
>
> som er noget _helt_ andet end
> const char* val1 = "asdf";
> const char* val2 = "abc";
> const char* val3 = "qwerty";
>

Det er til gengæld det samme som:

<CITAT fra det oprindelige spørgsmål>
   #define strFirst "Troels"
   #define strLast "Thomsen"
   char fullname[] = strFirst strLast;
   // indeholder nu "TroelsThomsen"
</CITAT>

Så det er efter min mening ikke helt malplaceret.

Robert

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> writes:

> Det er det jeg prøver at sige.

Måske, men det var ikke hvad folk kommenterede. Det du sagde var
forkert, og programmører har en tendens til at kommentere hvad der
blev sagt i stedet for hvad der var ment. Det er sikkert en
erhvervsskade, compilere har det også med at oversætte hvad man
skriver, ikke hvad man mener.