|
|
 | Underlig warning
Fra : Michael Rasmussen |
Dato : 23-07-06 19:35 |
|
Hej NG,
Givet følgende struktur i en header fil,
static gchar *browser_list[][2] = {
{"firefox", "-new-window"},
{"konqueror", NULL},
{"mozilla", "-new-window"},
{"epiphany", "-new-window"},
{NULL, NULL}
};
Resulterer altid i denne warning, når jeg oversætter med pedantic:
utils.h:18: warning: 'browser_list' defined but not used.
Nogen der har et bud på, hvordan jeg slipper for denne warning? (Og nej,
forslag som at droppe option pedantic tager jeg ikke seriøst!)
options til gcc: gcc -g -W -Wall -pedantic
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu Thread model: posix
gcc version 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
 Ivan Johansen (23-07-2006)
| Kommentar
Fra : Ivan Johansen |
Dato : 23-07-06 20:39 |
|
Michael Rasmussen wrote:
> Givet følgende struktur i en header fil,
>
> static gchar *browser_list[][2] = {
> {"firefox", "-new-window"},
> {"konqueror", NULL},
> {"mozilla", "-new-window"},
> {"epiphany", "-new-window"},
> {NULL, NULL}
> };
>
> Resulterer altid i denne warning, når jeg oversætter med pedantic:
>
> utils.h:18: warning: 'browser_list' defined but not used.
Det er normalt ikke nogen god ide at placere variabler i en header-fil.
Hver eneste c-fil som inkluderer din header-fil vil få sin egen kopi af
variablen, og din compiler advarer for hver c-fil som ikke bruger den. I
stedet bør du placere variablen i en enkelt c-fil.
Nu ved jeg ikke hvad en gchar er, men en string literal er altid const
og jeg går ud fra at du ikke vil ændre på pointerne i browser_list, så
din definition bør i stedet være:
static const char * const browser_list[][2] = {
Ivan Johansen
| |
Michael Rasmussen (23-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 23-07-06 21:26 |
|
On Sun, 23 Jul 2006 21:38:55 +0200, Ivan Johansen wrote:
>
> Det er normalt ikke nogen god ide at placere variabler i en header-fil.
> Hver eneste c-fil som inkluderer din header-fil vil få sin egen kopi af
> variablen, og din compiler advarer for hver c-fil som ikke bruger den. I
> stedet bør du placere variablen i en enkelt c-fil.
>
Hvis variablen findes i sin egen c-fil, hvordan gør jeg variablen, med
dens indhold, tilgængelig i andre c-filer?
Formålet er, at variablen skal være tilgængelig i en række funktioner
spredt ud på en række forskellige c-filer.
> Nu ved jeg ikke hvad en gchar er, men en string literal er altid const
gchar er en string literal defineret i glib - abstraktion over
værtsmaskinens char. Det har den fordel, at du ikke skal bekymre dig om
størrelsen på en char <=> fuld portabel char.
> og jeg går ud fra at du ikke vil ændre på pointerne i browser_list,
> så din definition bør i stedet være: static const char * const
> browser_list[][2] = {
Point taken 
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
 Mogens Hansen (23-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 23-07-06 21:39 |
|
"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.07.23.20.26.27.733057@miras.org...
[8<8<8<]
> Det har den fordel, at du ikke skal bekymre dig om
> størrelsen på en char <=> fuld portabel char.
Ikke forstået.
Der gælder pr. definition
sizeof(char) == 1
Venlig hilsen
Mogens Hansen
| |
Michael Rasmussen (23-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 23-07-06 22:16 |
|
On Sun, 23 Jul 2006 22:38:56 +0200, Mogens Hansen wrote:
>
> Ikke forstået.
> Der gælder pr. definition
> sizeof(char) == 1
>
Ifølge (K&R: 195), C99 og vist også POSIX "Objects declared as
characters (char) are large enough to store any member of the execution
character set. If a genuine character from that set is stored in a char
object, its value is equivalent to the integer code for the character, and
is non-negative." Dvs størrelsen af char afhænger af størrelsen af int.
Størrelsen på int er defineret som en logisk størrelse.
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
Mogens Hansen (23-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 23-07-06 22:30 |
|
"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.07.23.21.16.01.755944@miras.org...
> On Sun, 23 Jul 2006 22:38:56 +0200, Mogens Hansen wrote:
>
>>
>> Ikke forstået.
>> Der gælder pr. definition
>> sizeof(char) == 1
>>
> Ifølge (K&R: 195), C99
Ok - jeg snakker om C++.
Venlig hilsen
Mogens Hansen
| |
Bertel Brander (23-07-2006)
| Kommentar
Fra : Bertel Brander |
Dato : 23-07-06 22:50 |
|
Michael Rasmussen wrote:
> On Sun, 23 Jul 2006 22:38:56 +0200, Mogens Hansen wrote:
>
>> Ikke forstået.
>> Der gælder pr. definition
>> sizeof(char) == 1
>>
> Ifølge (K&R: 195), C99 og vist også POSIX "Objects declared as
> characters (char) are large enough to store any member of the execution
> character set. If a genuine character from that set is stored in a char
> object, its value is equivalent to the integer code for the character, and
> is non-negative." Dvs størrelsen af char afhænger af størrelsen af int.
> Størrelsen på int er defineret som en logisk størrelse.
Ikke forstået, sizeof(char) er pr. definition 1
også ifølge C standarden. Den har intet med
int at gøre.
/b
--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel
| |
Michael Rasmussen (23-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 23-07-06 23:07 |
|
On Sun, 23 Jul 2006 23:50:07 +0200, Bertel Brander wrote:
>
> Ikke forstået, sizeof(char) er pr. definition 1 også ifølge C
> standarden. Den har intet med int at gøre.
>
Ja, sizeof(char) = 1 = 1 tegn. På en IBM-PC anvendes ASCII for det
grundliggende tegnsæt, hvorfor et tegn har en numerisk værdi
mellem 1 og 255, en byte. På z/OS og flere UNIX varianter benyttes
EBCDIC som det grundliggende tegnsæt, hvorfor et tegn har en numerisk
værdi mellem 1 og 32767, altså ikke en byte.
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
Bertel Brander (23-07-2006)
| Kommentar
Fra : Bertel Brander |
Dato : 23-07-06 23:30 |
|
Michael Rasmussen wrote:
> On Sun, 23 Jul 2006 23:50:07 +0200, Bertel Brander wrote:
>
>> Ikke forstået, sizeof(char) er pr. definition 1 også ifølge C
>> standarden. Den har intet med int at gøre.
>>
> Ja, sizeof(char) = 1 = 1 tegn. På en IBM-PC anvendes ASCII for det
> grundliggende tegnsæt, hvorfor et tegn har en numerisk værdi
> mellem 1 og 255, en byte. På z/OS og flere UNIX varianter benyttes
> EBCDIC som det grundliggende tegnsæt, hvorfor et tegn har en numerisk
> værdi mellem 1 og 32767, altså ikke en byte.
Nej, en char er altid en byte og har altid størrelsen 1
Hvis OS-whatever har tegnsæt med værdier op til 32767
bruger de enten wide/multibyte/whatever -chars, eller
deres char er 16 bit.
--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel
| |
Michael Rasmussen (23-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 23-07-06 23:41 |
|
On Mon, 24 Jul 2006 00:29:48 +0200, Bertel Brander wrote:
>
> Nej, en char er altid en byte og har altid størrelsen 1
Nej og ja. Nej, en char har ikke altid størrelsen en byte, og ja, en char
har altid størrelsen 1, da en char er defineret til at indeholde eet
tegn. Hvor meget et tegn fylder i hukommelsen, bestemmes af det
underliggende OS, og ikke af C-kompileren!
Har du en reference til C-standarden der dokumenterer din påstand?
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
Bertel Brander (23-07-2006)
| Kommentar
Fra : Bertel Brander |
Dato : 23-07-06 23:54 |
|
Michael Rasmussen wrote:
> On Mon, 24 Jul 2006 00:29:48 +0200, Bertel Brander wrote:
>
>> Nej, en char er altid en byte og har altid størrelsen 1
> Nej og ja. Nej, en char har ikke altid størrelsen en byte, og ja, en char
> har altid størrelsen 1, da en char er defineret til at indeholde eet
> tegn. Hvor meget et tegn fylder i hukommelsen, bestemmes af det
> underliggende OS, og ikke af C-kompileren!
>
> Har du en reference til C-standarden der dokumenterer din påstand?
Fra en draft til C99:
"3.4
byte
addressable unit of data storage large enough to hold
any member of the basic character set of the
execution environment"
Og:
"3.5
character
bit representation that fits in a byte"
Der er ingen forskel på en byte og en char.
--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel
| |
Arne Vajhøj (24-07-2006)
| Kommentar
Fra : Arne Vajhøj |
Dato : 24-07-06 04:41 |
|
Bertel Brander wrote:
> Fra en draft til C99:
> "3.4
> byte
> addressable unit of data storage large enough to hold
> any member of the basic character set of the
> execution environment"
>
> Og:
>
> "3.5
> character
> bit representation that fits in a byte"
>
> Der er ingen forskel på en byte og en char.
Det er helt og aldeles korrekt.
Jeg mener at deres definition af byte er både
forkert og forældet.
Men selvom de opdaterede den definition, så
ville en char stadig være en byte.
Det som man i Java og C# kalder en byte kalder man
i C/C++ for en char.
Det som man i Java og C# kalde en char kalder man
i C/C++ for en wchar_t.
[Java og C# kræver at det er 8 og 16 bit, hvilket
C/C++ vist ikke gør, men ...]
Arne
| |
Arne Vajhøj (24-07-2006)
| Kommentar
Fra : Arne Vajhøj |
Dato : 24-07-06 04:22 |
|
Michael Rasmussen wrote:
> On Sun, 23 Jul 2006 23:50:07 +0200, Bertel Brander wrote:
>> Ikke forstået, sizeof(char) er pr. definition 1 også ifølge C
>> standarden. Den har intet med int at gøre.
> Ja, sizeof(char) = 1 = 1 tegn. På en IBM-PC anvendes ASCII for det
> grundliggende tegnsæt, hvorfor et tegn har en numerisk værdi
> mellem 1 og 255, en byte. På z/OS og flere UNIX varianter benyttes
> EBCDIC som det grundliggende tegnsæt, hvorfor et tegn har en numerisk
> værdi mellem 1 og 32767, altså ikke en byte.
ASCII er ikke 1-255 men 0-127.
Hvilke Unix varianter bruger EBCDIC ?
Alle EBCDIC Tabeller jeg har set har været 0-255.
Unicode har mere end 256 tegn.
Arne
| |
Ukendt (24-07-2006)
| Kommentar
Fra : Ukendt |
Dato : 24-07-06 16:21 |
|
> Der gælder pr. definition
> sizeof(char) == 1
>
For at det hele kan hænge sammen, vil det så ikke sige, at malloc(10) ikke
nødvendigvis allokerer 80 bits, men rettere et område stor nok til at kunne
skrive 10 chars , f.eks. 160 bits ?
"The malloc() function shall allocate unused space for an object whose size
in bytes is specified by size and whose value is unspecified."
Dette er så rigtigt fordi ordet byte ikke skal forstås i sin mest
almindelige betydning, 8 bits, men i en C/C++ kontekst ?
tpt
| |
Ukendt (24-07-2006)
| Kommentar
Fra : Ukendt |
Dato : 24-07-06 16:34 |
|
> For at det hele kan hænge sammen, vil det så ikke sige, at malloc(10) ikke
> nødvendigvis allokerer 80 bits, men rettere et område stor nok til at
> kunne
> skrive 10 chars , f.eks. 160 bits ?
(Hvis char størrelsen på en implementation er 16 bits)
| |
Bertel Brander (24-07-2006)
| Kommentar
Fra : Bertel Brander |
Dato : 24-07-06 18:59 |
|
Troels Thomsen wrote:
>> Der gælder pr. definition
>> sizeof(char) == 1
>>
>
> For at det hele kan hænge sammen, vil det så ikke sige, at malloc(10) ikke
> nødvendigvis allokerer 80 bits, men rettere et område stor nok til at kunne
> skrive 10 chars , f.eks. 160 bits ?
>
> "The malloc() function shall allocate unused space for an object whose size
> in bytes is specified by size and whose value is unspecified."
>
> Dette er så rigtigt fordi ordet byte ikke skal forstås i sin mest
> almindelige betydning, 8 bits, men i en C/C++ kontekst ?
En char/byte er ikke nødvendigvis 8 bit i C og/eller C++
Den kan godt være 16, 19, 32 bit. Den er mindst 8 bit.
CHAR_BIT fra limits.h fortæller hvor mange bits der er.
--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel
| |
Ukendt (25-07-2006)
| Kommentar
Fra : Ukendt |
Dato : 25-07-06 14:53 |
|
Jeg var bare overrasket over at ordet byte betyder noget lidt andet i C
terminologien, end sådan som man normalt går og bruger den.
tpt
| |
Soeren Sandmann (24-07-2006)
| Kommentar
Fra : Soeren Sandmann |
Dato : 24-07-06 19:49 |
|
Michael Rasmussen <mir@miras.org> writes:
> gchar er en string literal defineret i glib - abstraktion over
> værtsmaskinens char. Det har den fordel, at du ikke skal bekymre dig om
> størrelsen på en char <=> fuld portabel char.
En gchar fra glib er noejagtig det samme som char, ligesom gint er
noejagtig det samme som int. Ja, det er lidt uklart hvad deres
egentlige formaal er.
I gtypes.h:
typedef char gchar;
typedef short gshort;
typedef long glong;
typedef int gint;
typedef gint gboolean;
| |
Michael Rasmussen (24-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 24-07-06 20:16 |
|
On Mon, 24 Jul 2006 20:48:43 +0200, Soeren Sandmann wrote:
>
> En gchar fra glib er noejagtig det samme som char, ligesom gint er
> noejagtig det samme som int. Ja, det er lidt uklart hvad deres egentlige
> formaal er.
>
Portabilitet. En gint har altid samme størrelse uafhængigt af det
underliggende OS. GLib er ansvarlig for memory håndteringen. Betragt
derfor gint, gchar etc. som en højniveau API over simple datatyper.
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
Mogens Hansen (24-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 24-07-06 20:32 |
|
"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.07.24.19.15.39.146218@miras.org...
> On Mon, 24 Jul 2006 20:48:43 +0200, Soeren Sandmann wrote:
>
>>
>> En gchar fra glib er noejagtig det samme som char, ligesom gint er
>> noejagtig det samme som int. Ja, det er lidt uklart hvad deres egentlige
>> formaal er.
>>
> Portabilitet. En gint har altid samme størrelse uafhængigt af det
> underliggende OS.
Fra http://developer.gnome.org/doc/API/2.0/glib/glib-Basic-Types.html#gint :
gint
typedef int gint;
Corresponds to the standard C int type. Values of this type can range from
G_MININT to G_MAXINT.
Du opnår altså absolut _intet_ i relation til portabilitet - tværtimod du
får tilføjet en binding til glib.
Tilsvarende er værdier svarende G_MININT to G_MAXINT defineret i både
Standard C og Standard C++.
Er du sikker på at du ikke tænker på gint8 etc. for at få integere af kendt
størrelse ?
Venlig hilsen
Mogens Hansen
| |
Mogens Hansen (24-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 24-07-06 20:36 |
|
"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:44c52031$0$67259$157c6196@dreader2.cybercity.dk...
[8<8<8<]
> Er du sikker på at du ikke tænker på gint8 etc. for at få integere af
> kendt størrelse ?
De findes iøvrigt også i C99, uden yderligere afhængigheder:
int8_t, int16_t
og de kommer også med i næste C++ standard.
Venlig hilsen
Mogens Hansen
| |
Soeren Sandmann (24-07-2006)
| Kommentar
Fra : Soeren Sandmann |
Dato : 24-07-06 21:04 |
|
Michael Rasmussen <mir@miras.org> writes:
> > En gchar fra glib er noejagtig det samme som char, ligesom gint er
> > noejagtig det samme som int. Ja, det er lidt uklart hvad deres egentlige
> > formaal er.
> >
> Portabilitet. En gint har altid samme størrelse uafhængigt af det
> underliggende OS.
Nej, en gint har altid samme stoerrelse som en int, for det er den
samme type. Der er andre g-typer, som er mere brugbare:
guint32 unsigned 32 bits integer
gint32 signed 32 bits integer
guchar en forkortelse for "unsigned char".
gint8 signed 8 bits integer ("signed char"
hvis man lever i den virkelige
verden).
etc.
Men gint, gfloat, gdouble og gchar er ikke andet end synonymer for de
tilsvarende C-typer. Der er masser af brugbare ting i glib, men disse
typer er ikke saerlig nyttige.
Soren
| |
Ukendt (24-07-2006)
| Kommentar
Fra : Ukendt |
Dato : 24-07-06 22:01 |
|
Ivan Johansen skrev:
>
> Nu ved jeg ikke hvad en gchar er, men en string literal er altid const
> og jeg går ud fra at du ikke vil ændre på pointerne i browser_list, så
> din definition bør i stedet være:
> static const char * const browser_list[][2] = {
>
Lidt ved siden af spørgsmålet, men hvorfor mener du en string literal
altid er const? Det er den ikke.
Eksempelvis, hvis en string literal var const ville følgende ikke kunne
compilere:
char * p1 = "string literal";
og ejheller
p1[0] = 'S';
Claus
| |
Bertel Brander (24-07-2006)
| Kommentar
Fra : Bertel Brander |
Dato : 24-07-06 22:26 |
|
Claus Jensen wrote:
>
> Lidt ved siden af spørgsmålet, men hvorfor mener du en string literal
> altid er const? Det er den ikke.
> Eksempelvis, hvis en string literal var const ville følgende ikke kunne
> compilere:
> char * p1 = "string literal";
> og ejheller
> p1[0] = 'S';
Snakke vi C eller C++?
En string literal er en const char * i C++
Den er ikke (rigtig) const i C, da C ikke er
så typefast.
Men du må ikke ændre på indholdet af en
string literal hverken i C eller C++.
At du godt kan kompilere dit eksempel som
såvel C som C++ skyldes mest at man har
valgt nogen form for bagud-compatibilitet.
Første del af dit eksempel er "lovligt".
Anden del er ikke lovligt, men kan godt
kompileres da p1 ikke er const.
Havde p1 været const kunne det godt
oversættes som C (med en warning) men ikke
i C++.
--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel
| |
Kent Friis (24-07-2006)
| Kommentar
Fra : Kent Friis |
Dato : 24-07-06 22:37 |
|
Den Mon, 24 Jul 2006 23:26:05 +0200 skrev Bertel Brander:
> Claus Jensen wrote:
>>
>> Lidt ved siden af spørgsmålet, men hvorfor mener du en string literal
>> altid er const? Det er den ikke.
>> Eksempelvis, hvis en string literal var const ville følgende ikke kunne
>> compilere:
>> char * p1 = "string literal";
>> og ejheller
>> p1[0] = 'S';
>
> Første del af dit eksempel er "lovligt".
> Anden del er ikke lovligt, men kan godt
> kompileres da p1 ikke er const.
Men at det kan compiles er ikke nødvendigvis nok.
$ cat const.c
int main() {
char * p1 = "string literal";
p1[0] = 'S';
return 0;
}
$ make const
cc -g -Wall const.c -o const
$ ./const
Segmentation fault
$
Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).
| |
Bertel Brander (24-07-2006)
| Kommentar
Fra : Bertel Brander |
Dato : 24-07-06 23:07 |
|
Kent Friis wrote:
>>> Eksempelvis, hvis en string literal var const ville følgende ikke kunne
>>> compilere:
>>> char * p1 = "string literal";
>>> og ejheller
>>> p1[0] = 'S';
>> Første del af dit eksempel er "lovligt".
>> Anden del er ikke lovligt, men kan godt
>> kompileres da p1 ikke er const.
>
> Men at det kan compiles er ikke nødvendigvis nok.
Som jeg skrev er det ikke lovligt, men:
C:\Program>type pop.cpp
#include <iostream>
int main()
{
char * p1 = "string literal";
p1[0] = 'S';
std::cout << p1 << std::endl;
}
C:\Program>bcc32 pop.cpp
Borland C++ 5.5 for Win32 Copyright (c) 1993, 2000 Borland
pop.cpp:
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
C:\Program>pop
String literal
Og det beviser ingenting.
--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel
| |
Mogens Hansen (23-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 23-07-06 20:49 |
|
"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.07.23.18.35.25.24841@miras.org...
> Hej NG,
>
> Givet følgende struktur i en header fil,
>
> static gchar *browser_list[][2] = {
> {"firefox", "-new-window"},
> {"konqueror", NULL},
> {"mozilla", "-new-window"},
> {"epiphany", "-new-window"},
> {NULL, NULL}
> };
>
> Resulterer altid i denne warning, når jeg oversætter med pedantic:
>
> utils.h:18: warning: 'browser_list' defined but not used.
Bliver den brugt i alle filer der inkluderer header filen ?
Den er jo static, så hvis den ikke bliver brugt har compileren jo ret og den
kan slettes.
Problemet er vel at den står i en headerfil, når det ikke kun er en
erklæring. Du risikerer at unødvendigt teksten bliver lagt ud mange gange i
programmet.
For mig ser det ud som om den ikke skal være "static", men "const", og
erklæringen i headerfilen skal være noget i retningen af:
extern const char* const browser_list[][2];
og definitionen skal være
const char* const browser_list[][2] = {
{"firefox", "-new-window"},
{"konqueror", 0},
{"mozilla", "-new-window"},
{"epiphany", "-new-window"},
{0, 0}
};
Venlig hilsen
Mogens Hansen
| |
Michael Rasmussen (23-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 23-07-06 21:31 |
|
On Sun, 23 Jul 2006 21:48:52 +0200, Mogens Hansen wrote:
> For mig ser det ud som om den ikke skal være "static", men "const", og
> erklæringen i headerfilen skal være noget i retningen af: extern const
> char* const browser_list[][2];
>
> og definitionen skal være
> const char* const browser_list[][2] = {
> {"firefox", "-new-window"},
> {"konqueror", 0},
> {"mozilla", "-new-window"},
> {"epiphany", "-new-window"},
> {0, 0}
> };
Problemet, som beskrevet andet steds til Ivan, er, at erklæring samt
definition skal være tilgængelig i flere c-filer.
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
Mogens Hansen (23-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 23-07-06 21:40 |
|
"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.07.23.20.30.39.393873@miras.org...
[8<8<8<]
> Problemet, som beskrevet andet steds til Ivan, er, at erklæring samt
> definition skal være tilgængelig i flere c-filer.
Det er den også med den erklæring jeg nævnte, du skal skrive i header-filen:
extern const char* const browser_list[][2];
Venlig hilsen
Mogens Hansen
| |
Michael Rasmussen (23-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 23-07-06 22:19 |
|
On Sun, 23 Jul 2006 22:39:53 +0200, Mogens Hansen wrote:
> Det er den også med den erklæring jeg nævnte, du skal skrive i
> header-filen:
> extern const char* const browser_list[][2];
>
Det kan jeg ikke få til at hænge sammen
Header-filen, hvor browser_list er erklæret, skal også samtidigt
indeholde definitionen. Hvordan skal det kunne gøres?
For hver c-fil der inkluderer header-filen, skal jeg fra header-filen
kunne finde både erklæringen og definition af browser_list. Hver fil der
inkluderer header-filen, må ikke selv erklære browser_list.
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
Mogens Hansen (23-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 23-07-06 22:36 |
|
"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.07.23.21.19.12.858547@miras.org...
> On Sun, 23 Jul 2006 22:39:53 +0200, Mogens Hansen wrote:
>
>> Det er den også med den erklæring jeg nævnte, du skal skrive i
>> header-filen:
>> extern const char* const browser_list[][2];
>>
> Det kan jeg ikke få til at hænge sammen
> Header-filen, hvor browser_list er erklæret, skal også samtidigt
> indeholde definitionen.
Hvorfor er erklæringen ikke tilstrækkelig ?
Det giver muligvis "code bloat" og den warning du gerne vil af med når du
skriver definitionen i headerfilen som "static".
> Hvordan skal det kunne gøres?
Med erklæringen i headerfilen kan du ikke se definitionen, men du kan tilgå
indholdet, f.eks.
int i = 0;
while(browser_list[i][0]) {
// ...
}
Venlig hilsen
Mogens Hansen
| |
Michael Rasmussen (23-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 23-07-06 22:57 |
|
On Sun, 23 Jul 2006 23:36:25 +0200, Mogens Hansen wrote:
>
> Med erklæringen i headerfilen kan du ikke se definitionen, men du kan
> tilgå indholdet, f.eks.
> int i = 0;
> while(browser_list[i][0]) {
> // ...
> }
> }
Jeg forstår det stadigvæk ikke
util.h
extern const char* const browser_list[][2];
tilfældig.c
while(*browser_list) {
printf("%s\n", *browser_list++);
}
Hvor bliver browser_list så defineret? i util.c?
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
Michael Rasmussen (23-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 23-07-06 23:08 |
| | |
Mogens Hansen (24-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 24-07-06 00:10 |
|
"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.07.23.21.56.35.863503@miras.org...
[8<8<8<]
> tilfældig.c
> while(*browser_list) {
> printf("%s\n", *browser_list++);
Nej.
browser_list er konstant og kan ikke incrementeres.
Jeg holder fast i
int i = 0;
while(browser_list[i][0]) {
// ...
}
eventuelt med "i" af typen "size_t" i stedet for "int".
> }
>
> Hvor bliver browser_list så defineret? i util.c?
Ja, i "util.c" (selvom det ikke et særligt unikt navn for en source-fil):
const char* const browser_list[][2] = {
{"firefox", "-new-window"},
{"konqueror", 0},
{"mozilla", "-new-window"},
{"epiphany", "-new-window"},
{0, 0}
};
Venlig hilsen
Mogens Hansen
| |
Michael Rasmussen (24-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 24-07-06 02:00 |
|
On Mon, 24 Jul 2006 01:09:36 +0200, Mogens Hansen wrote:
>
> Nej.
> browser_list er konstant og kan ikke incrementeres.
>
Det giver ellers ingen warning eller error med pedantic?
>
> Ja, i "util.c" (selvom det ikke et særligt unikt navn for en source-fil):
Ok, det virker
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
| |
Michael Rasmussen (24-07-2006)
| Kommentar
Fra : Michael Rasmussen |
Dato : 24-07-06 02:04 |
| | |
Mogens Hansen (24-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 24-07-06 06:26 |
|
"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.07.24.01.04.17.647055@miras.org...
> On Mon, 24 Jul 2006 03:00:28 +0200, Michael Rasmussen wrote:
>
>> Det giver ellers ingen warning eller error med pedantic?
>>
> Det er også sådan, jeg gør:
> for (i = 0; *browser_list[i] != NULL; i++)
>
> Og det virker.
Ja - det er også noget helt andet end
browser_list++
hvor "browser_list" bliver ændret.
Venlig hilsen
Mogens Hansen
| |
Mogens Hansen (24-07-2006)
| Kommentar
Fra : Mogens Hansen |
Dato : 24-07-06 06:18 |
|
"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.07.24.01.00.26.654122@miras.org...
> On Mon, 24 Jul 2006 01:09:36 +0200, Mogens Hansen wrote:
>
>>
>> Nej.
>> browser_list er konstant og kan ikke incrementeres.
>>
> Det giver ellers ingen warning eller error med pedantic?
Det gør det hos mig med Borland C++Builder 6.0, Microsoft Visual C++ .NET
2005 og Comeau 4.3.3.
Det var også meningen med de const dekoreringer.
Hvis din compiler kan oversætte:
extern const char* const browser_list[][2];
int main()
{
++browser_list;
}
uden nogen form for brok vil jeg anse det for en fejl i compileren (indtil
andet er bevist).
Venlig hilsen
Mogens Hansen
| |
|
|