Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #109469 > unrolled thread

error: initializer element is not constant|

Back to article view | Back to comp.lang.c

Contents

  error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-08 09:55 +0200
    Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-08 10:05 +0200
    Re: error: initializer element is not constant| Noob <root@127.0.0.1> - 2017-05-08 10:38 +0200
      Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-08 11:55 +0200
        Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 11:01 +0100
          Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-08 12:18 +0200
            Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 12:02 +0100
              Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 09:00 -0700
                Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 17:50 +0100
                  Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 11:37 -0700
                    Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 19:49 +0100
                      Re: error: initializer element is not constant| Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-08 20:13 +0100
                      Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 12:44 -0700
                      Re: error: initializer element is not constant| scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 20:24 +0000
              Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 09:54 +0200
                Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 10:15 +0200
                Re: error: initializer element is not constant| GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-09 12:12 +0200
                Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-09 11:47 +0100
                  Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 19:06 +0200
                    Re: error: initializer element is not constant| scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 17:10 +0000
                      Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 19:20 +0200
                        Re: error: initializer element is not constant| Barry Schwarz <schwarzb@dqel.com> - 2017-05-09 10:35 -0700
                          Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 20:04 +0200
                            Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-09 11:57 -0700
                              Re: error: initializer element is not constant| supercat@casperkitty.com - 2017-05-09 12:50 -0700
                                Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-09 12:54 -0700
                            Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-09 20:15 +0100
                          Re: error: initializer element is not constant| "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-09 14:13 -0400
                          Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-09 11:41 -0700
                Re: error: initializer element is not constant| Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-09 12:16 +0100
                Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-09 08:11 -0700
            Re: error: initializer element is not constant| Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-08 12:12 +0100
              Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 13:45 +0100
                Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 09:04 -0700
                Re: error: initializer element is not constant| Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-08 19:53 +0100
                  Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 20:44 +0100
                    Re: error: initializer element is not constant| Noob <root@127.0.0.1> - 2017-05-09 09:27 +0200
                Re: error: initializer element is not constant| Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-09 07:10 -0700
              Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 09:30 -0700
    Re: error: initializer element is not constant| John Bode <jfbode1029@gmail.com> - 2017-05-08 08:05 -0700

Page 1 of 2  [1] 2  Next page →

#109469 — error: initializer element is not constant|

Hello to all,
Is there any way, in standard C, to write something like this without 
getting an error?

static char *Date = "2017-05-08";

static char *Phrase[] =
{
   "Date: ",
   Date,
   "\r\n"
};

[toc] | [next] | [standalone]

#109470

Il 08/05/2017 09:55, jak ha scritto:
> Hello to all,
> Is there any way, in standard C, to write something like this without
> getting an error?
>
> static char *Date = "2017-05-08";
>
> static char *Phrase[] =
> {
>   "Date: ",
>   Date,
>   "\r\n"
> };
>

... of course, if 'Date' becomes a #define everything works well but I 
would change its value at runtime.

[toc] | [prev] | [next] | [standalone]

#109472

On 08/05/2017 09:55, jak wrote:

> Is there any way, in standard C, to write something like this without 
> getting an error?
> 
> static char *Date = "2017-05-08";
> 
> static char *Phrase[] =
> {
>    "Date: ",
>    Date,
>    "\r\n"
> };

Define 'Date' as an array.

static const char Date[] = "2017-05-08";

On an unrelated subject, have a look at the __DATE__ macro.
Obviously, embedding time-related strings in a program makes
builds non-deterministic (compiling the same source on different
days will produce different binaries).

Regards.

[toc] | [prev] | [next] | [standalone]

#109482

Il 08/05/2017 10:38, Noob ha scritto:
> On 08/05/2017 09:55, jak wrote:
>
>> Is there any way, in standard C, to write something like this without
>> getting an error?
>>
>> static char *Date = "2017-05-08";
>>
>> static char *Phrase[] =
>> {
>>    "Date: ",
>>    Date,
>>    "\r\n"
>> };
>
> Define 'Date' as an array.
>
> static const char Date[] = "2017-05-08";
>
> On an unrelated subject, have a look at the __DATE__ macro.
> Obviously, embedding time-related strings in a program makes
> builds non-deterministic (compiling the same source on different
> days will produce different binaries).
>
> Regards.
>

Thank you for your answer and I take this opportunity to ask another 
question:

char *Date = "01-01-80";

typedef char * ch;

ch foo;
foo = "01-01-80";  <-- this line

warning: data definition has no type or storage class
warning: type defaults to 'int' in declaration of 'foo'-Wimplicit-int
error: conflicting types for 'foo'
warning: initialization makes integer from pointer without a cast

What am I not understanding?
thanks in advance

[toc] | [prev] | [next] | [standalone]

#109483

On 08/05/2017 10:55, jak wrote:
> Il 08/05/2017 10:38, Noob ha scritto:
>> On 08/05/2017 09:55, jak wrote:
>>
>>> Is there any way, in standard C, to write something like this without
>>> getting an error?
>>>
>>> static char *Date = "2017-05-08";
>>>
>>> static char *Phrase[] =
>>> {
>>>    "Date: ",
>>>    Date,
>>>    "\r\n"
>>> };
>>
>> Define 'Date' as an array.
>>
>> static const char Date[] = "2017-05-08";
>>
>> On an unrelated subject, have a look at the __DATE__ macro.
>> Obviously, embedding time-related strings in a program makes
>> builds non-deterministic (compiling the same source on different
>> days will produce different binaries).
>>
>> Regards.
>>
>
> Thank you for your answer and I take this opportunity to ask another
> question:
>
> char *Date = "01-01-80";
>
> typedef char * ch;
>
> ch foo;
> foo = "01-01-80";  <-- this line
>
> warning: data definition has no type or storage class
> warning: type defaults to 'int' in declaration of 'foo'-Wimplicit-int
> error: conflicting types for 'foo'
> warning: initialization makes integer from pointer without a cast
>
> What am I not understanding?
> thanks in advance
>

Have you put those lines inside a function? Try:

int main (void) {

  ch foo;

  foo = "01-01-80";
}

Otherwise, the assignment to foo probably looks like a new declaration 
of something called 'foo', which is assumed to be an 'int' type. In C, 
declaring the type of a variable is optional, so the compiler thought it 
was this:

ch foo;
int foo = "01-01-80";

(Pretty stupid of the language to allow that, but no compiler has wanted 
to be the first to ban it outright, it case some ancient code no longer 
works.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#109484

Il 08/05/2017 12:01, bartc ha scritto:
> On 08/05/2017 10:55, jak wrote:
>> Il 08/05/2017 10:38, Noob ha scritto:
>>> On 08/05/2017 09:55, jak wrote:
>>>
>>>> Is there any way, in standard C, to write something like this without
>>>> getting an error?
>>>>
>>>> static char *Date = "2017-05-08";
>>>>
>>>> static char *Phrase[] =
>>>> {
>>>>    "Date: ",
>>>>    Date,
>>>>    "\r\n"
>>>> };
>>>
>>> Define 'Date' as an array.
>>>
>>> static const char Date[] = "2017-05-08";
>>>
>>> On an unrelated subject, have a look at the __DATE__ macro.
>>> Obviously, embedding time-related strings in a program makes
>>> builds non-deterministic (compiling the same source on different
>>> days will produce different binaries).
>>>
>>> Regards.
>>>
>>
>> Thank you for your answer and I take this opportunity to ask another
>> question:
>>
>> char *Date = "01-01-80";
>>
>> typedef char * ch;
>>
>> ch foo;
>> foo = "01-01-80";  <-- this line
>>
>> warning: data definition has no type or storage class
>> warning: type defaults to 'int' in declaration of 'foo'-Wimplicit-int
>> error: conflicting types for 'foo'
>> warning: initialization makes integer from pointer without a cast
>>
>> What am I not understanding?
>> thanks in advance
>>
>
> Have you put those lines inside a function? Try:
>
> int main (void) {
>
>  ch foo;
>
>  foo = "01-01-80";
> }
>
> Otherwise, the assignment to foo probably looks like a new declaration
> of something called 'foo', which is assumed to be an 'int' type. In C,
> declaring the type of a variable is optional, so the compiler thought it
> was this:
>
> ch foo;
> int foo = "01-01-80";
>
> (Pretty stupid of the language to allow that, but no compiler has wanted
> to be the first to ban it outright, it case some ancient code no longer
> works.)
>
Thanks a lot for responding but the 'very stupid' is me, because I did 
the copy/paste the wrong lines :(

I would like to create an array of pointers, of pointers to strings. In 
this way I can have the pointers as constant and I wrote this:

char *Date = "01-01-80";

typedef char * ch;
typedef ch * p_ch;

p_ch foo[] =
{
   &Date,
   (p_ch)&"Date"
};

This works but I do not know how to declare foo without using typedef.

[toc] | [prev] | [next] | [standalone]

#109488

On 08/05/2017 11:18, jak wrote:

> I would like to create an array of pointers, of pointers to strings. In
> this way I can have the pointers as constant and I wrote this:
>
> char *Date = "01-01-80";
>
> typedef char * ch;
> typedef ch * p_ch;
>
> p_ch foo[] =
> {
>   &Date,
>   (p_ch)&"Date"
> };
>
> This works but I do not know how to declare foo without using typedef.

Those types would look like this without typedefs:

char *  str;
char *  array_of_str[];
char ** ptr_to_str;
char ** array_of_ptr_to_str[];

(The arrays will need a dimension, or need to be initialised.)

But arrays of pointers to strings would be unusual, and be harder to 
initialise as you can't just have "ABC", but need to set up a named 
string: char* abc="ABC", then use &abc.

I don't think you can apply a cast to "ABC" to get the pointer you need. 
(Well, you can cast it, but it won't be a proper pointer to string, 
it'll just be a string, and will crash when you apply the dereference 
below.)

Using the array would be harder too as you'll need an extra dereference 
to extract the string:

    puts(*array_of_ptr_to_str[0]);

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#109504

bartc <bc@freeuk.com> writes:
[...]
> Those types would look like this without typedefs:
>
> char *  str;
> char *  array_of_str[];
> char ** ptr_to_str;
> char ** array_of_ptr_to_str[];
>
> (The arrays will need a dimension, or need to be initialised.)
>
> But arrays of pointers to strings would be unusual, and be harder to 
> initialise as you can't just have "ABC", but need to set up a named 
> string: char* abc="ABC", then use &abc.

I think you meant that arrays of pointers to arrays would be unusual.

A "pointer to a string" is by definition a pointer to the initial
character of a string.  Arrays of pointers to strings are quite common;
for example, argv points to the initial element of such an array.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#109514

On 08/05/2017 17:00, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> Those types would look like this without typedefs:
>>
>> char *  str;
>> char *  array_of_str[];
>> char ** ptr_to_str;
>> char ** array_of_ptr_to_str[];
>>
>> (The arrays will need a dimension, or need to be initialised.)
>>
>> But arrays of pointers to strings would be unusual, and be harder to
>> initialise as you can't just have "ABC", but need to set up a named
>> string: char* abc="ABC", then use &abc.
>
> I think you meant that arrays of pointers to arrays would be unusual.


No, I mean arrays of pointers to strings, with a string meaning char*. 
The variable names I've chosen should make it clear that:

   str (ie. string) is a char*
   ptr_to_str is char**

and so on.

Since it is impossible to work with an actual string itself, it's more 
useful I think for 'string' to be a synonym for 'char*'.

> A "pointer to a string" is by definition a pointer to the initial
> character of a string.

AFAIK C has no such concept. It only has pointer to char. Or, rarely, a 
pointer to an entire array, of which the contents may contain a 
zero-terminated string.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#109523

bartc <bc@freeuk.com> writes:
> On 08/05/2017 17:00, Keith Thompson wrote:
[...]
>> I think you meant that arrays of pointers to arrays would be unusual.
>
> No, I mean arrays of pointers to strings, with a string meaning char*. 
> The variable names I've chosen should make it clear that:
>
>    str (ie. string) is a char*
>    ptr_to_str is char**
>
> and so on.

Then you are using terminology that is clearly defined by the C standard
in a manner inconsistent with the way the standard uses it.

> Since it is impossible to work with an actual string itself, it's more 
> useful I think for 'string' to be a synonym for 'char*'.

Whether it would have been more useful or not, the standard clearly
defines the terms "string" and "pointer to string" in 7.1.1p1, which
I've recently quoted elsewhere in this thread.

>> A "pointer to a string" is by definition a pointer to the initial
>> character of a string.
>
> AFAIK C has no such concept.

Well now you know that it does.

>                              It only has pointer to char. Or, rarely, a 
> pointer to an entire array, of which the contents may contain a 
> zero-terminated string.

One more time, N1570 7.1.1p1 (with asterisks to represent italics, which
denote a definition of a term):

    A *string* is a contiguous sequence of characters terminated
    by and including the first null character. The term *multibyte
    string* is sometimes used instead to emphasize special processing
    given to multibyte characters contained in the string or to
    avoid confusion with a wide string. A *pointer to a string*
    is a pointer to its initial (lowest addressed) character.

Feel free to dislike those definitions, but at least consider
acknowledging their existence in the C standard.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#109527

On 08/05/2017 19:37, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 08/05/2017 17:00, Keith Thompson wrote:
> [...]
>>> I think you meant that arrays of pointers to arrays would be unusual.
>>
>> No, I mean arrays of pointers to strings, with a string meaning char*.
>> The variable names I've chosen should make it clear that:
>>
>>    str (ie. string) is a char*
>>    ptr_to_str is char**
>>
>> and so on.
>
> Then you are using terminology that is clearly defined by the C standard
> in a manner inconsistent with the way the standard uses it.
>
>> Since it is impossible to work with an actual string itself, it's more
>> useful I think for 'string' to be a synonym for 'char*'.
>
> Whether it would have been more useful or not, the standard clearly
> defines the terms "string" and "pointer to string" in 7.1.1p1, which
> I've recently quoted elsewhere in this thread.

So you call a 'pointer to char', a 'pointer to string'.

OK.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#109531

bartc <bc@freeuk.com> writes:

> On 08/05/2017 19:37, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 08/05/2017 17:00, Keith Thompson wrote:
>> [...]
>>>> I think you meant that arrays of pointers to arrays would be unusual.
>>>
>>> No, I mean arrays of pointers to strings, with a string meaning char*.
>>> The variable names I've chosen should make it clear that:
>>>
>>>    str (ie. string) is a char*
>>>    ptr_to_str is char**
>>>
>>> and so on.
>>
>> Then you are using terminology that is clearly defined by the C standard
>> in a manner inconsistent with the way the standard uses it.
>>
>>> Since it is impossible to work with an actual string itself, it's more
>>> useful I think for 'string' to be a synonym for 'char*'.
>>
>> Whether it would have been more useful or not, the standard clearly
>> defines the terms "string" and "pointer to string" in 7.1.1p1, which
>> I've recently quoted elsewhere in this thread.
>
> So you call a 'pointer to char', a 'pointer to string'.

Only if it points to a character in a string.  Not all char *s do that.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#109535

bartc <bc@freeuk.com> writes:
> On 08/05/2017 19:37, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 08/05/2017 17:00, Keith Thompson wrote:
>> [...]
>>>> I think you meant that arrays of pointers to arrays would be unusual.
>>>
>>> No, I mean arrays of pointers to strings, with a string meaning char*.
>>> The variable names I've chosen should make it clear that:
>>>
>>>    str (ie. string) is a char*
>>>    ptr_to_str is char**
>>>
>>> and so on.
>>
>> Then you are using terminology that is clearly defined by the C standard
>> in a manner inconsistent with the way the standard uses it.
>>
>>> Since it is impossible to work with an actual string itself, it's more
>>> useful I think for 'string' to be a synonym for 'char*'.
>>
>> Whether it would have been more useful or not, the standard clearly
>> defines the terms "string" and "pointer to string" in 7.1.1p1, which
>> I've recently quoted elsewhere in this thread.
>
> So you call a 'pointer to char', a 'pointer to string'.

I call a char* value a "pointer to a string" if and only if it points to
the initial character of a string.  A null char* pointer is not a
pointer to a string.

Do you find the definitions I quoted unclear?

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#109538

bartc <bc@freeuk.com> writes:
>On 08/05/2017 19:37, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 08/05/2017 17:00, Keith Thompson wrote:
>> [...]
>>>> I think you meant that arrays of pointers to arrays would be unusual.
>>>
>>> No, I mean arrays of pointers to strings, with a string meaning char*.
>>> The variable names I've chosen should make it clear that:
>>>
>>>    str (ie. string) is a char*
>>>    ptr_to_str is char**
>>>
>>> and so on.
>>
>> Then you are using terminology that is clearly defined by the C standard
>> in a manner inconsistent with the way the standard uses it.
>>
>>> Since it is impossible to work with an actual string itself, it's more
>>> useful I think for 'string' to be a synonym for 'char*'.
>>
>> Whether it would have been more useful or not, the standard clearly
>> defines the terms "string" and "pointer to string" in 7.1.1p1, which
>> I've recently quoted elsewhere in this thread.
>
>So you call a 'pointer to char', a 'pointer to string'.

"char *" defines a pointer to a character in the same fashion as
"int *" defines a pointer to an integer.   The use of the autoincrement
operator to step sequentially through contiguous char values until
some terminal value is encountered doesn't change the fact that a
"char *" points to a character, not a string.

Strings are just a character array with the convention that it
is terminated by a char with the value zero.

[toc] | [prev] | [next] | [standalone]

#109566

Il 08/05/2017 13:02, bartc ha scritto:
> On 08/05/2017 11:18, jak wrote:
>
>> I would like to create an array of pointers, of pointers to strings. In
>> this way I can have the pointers as constant and I wrote this:
>>
>> char *Date = "01-01-80";
>>
>> typedef char * ch;
>> typedef ch * p_ch;
>>
>> p_ch foo[] =
>> {
>>   &Date,
>>   (p_ch)&"Date"
>> };
>>
>> This works but I do not know how to declare foo without using typedef.
>
> Those types would look like this without typedefs:
>
> char *  str;
> char *  array_of_str[];
> char ** ptr_to_str;
> char ** array_of_ptr_to_str[];
>
> (The arrays will need a dimension, or need to be initialised.)
>
> But arrays of pointers to strings would be unusual, and be harder to
> initialise as you can't just have "ABC", but need to set up a named
> string: char* abc="ABC", then use &abc.
>
> I don't think you can apply a cast to "ABC" to get the pointer you need.
> (Well, you can cast it, but it won't be a proper pointer to string,
> it'll just be a string, and will crash when you apply the dereference
> below.)
>
> Using the array would be harder too as you'll need an extra dereference
> to extract the string:
>
>    puts(*array_of_ptr_to_str[0]);
>
Ok ok. Bugs have also been put in the middle. The first time I wrote the 
declaration in this way:

char *Date = "01-01-80";
char **Phrases[]
{
    &Date
}

and gcc gave me a lot of errors. For this reason I chosed the way of 
typedefs. Later closed CodeBlocks and reopened it, and also this 
statement worked. :(

Now I'm using this work around:


char *Phrases[]
{
    "Date: ",
    NULL,
    "\r\n"
};
char **DatePos = Phrases[1];

foo()
{
    *DatePos = ctime(&t);
    *DatePos[strlen(Date) - 1] = '\0';
}

But I still do not understand why the compiler does not allow me this:

char *Date = NULL;
char *Phrases[]
{
    "Date: ",
    Date,
    "\r\n"
};

In the end I'm just asking him to allocate space to write in an address 
exactly as it happens when I write NULL instead of 'Date'.

[toc] | [prev] | [next] | [standalone]

#109567

> char *Phrases[]
> {
>    "Date: ",
>    NULL,
>    "\r\n"
> };
> char **DatePos = Phrases[1];
>
> foo()
> {
>    *DatePos = ctime(&t);
>    *DatePos[strlen(Date) - 1] = '\0';
> }

Oops:

char *Phrases[]
{
    "Date: ",
    NULL,
    "\r\n"
};
char *DatePos = Phrases[1];

foo()
{
    DatePos = ctime(&t);
    DatePos[strlen(Date) - 1] = '\0';
}

[toc] | [prev] | [next] | [standalone]

#109572

On Tue, 9 May 2017 09:54:23 +0200
jak <please@nospam.tnx> wrote:

> char *Phrases[]
> {
>     "Date: ",
>     NULL,
>     "\r\n"
> };

What kind of object is this? An array or a structure?

[toc] | [prev] | [next] | [standalone]

#109574

On 09/05/2017 08:54, jak wrote:
> Il 08/05/2017 13:02, bartc ha scritto:
>> On 08/05/2017 11:18, jak wrote:
>>
>>> I would like to create an array of pointers, of pointers to strings. In
>>> this way I can have the pointers as constant and I wrote this:
>>>
>>> char *Date = "01-01-80";
>>>
>>> typedef char * ch;
>>> typedef ch * p_ch;
>>>
>>> p_ch foo[] =
>>> {
>>>   &Date,
>>>   (p_ch)&"Date"
>>> };
>>>
>>> This works but I do not know how to declare foo without using typedef.
>>
>> Those types would look like this without typedefs:
>>
>> char *  str;
>> char *  array_of_str[];
>> char ** ptr_to_str;
>> char ** array_of_ptr_to_str[];
>>
>> (The arrays will need a dimension, or need to be initialised.)
>>
>> But arrays of pointers to strings would be unusual, and be harder to
>> initialise as you can't just have "ABC", but need to set up a named
>> string: char* abc="ABC", then use &abc.
>>
>> I don't think you can apply a cast to "ABC" to get the pointer you need.
>> (Well, you can cast it, but it won't be a proper pointer to string,
>> it'll just be a string, and will crash when you apply the dereference
>> below.)
>>
>> Using the array would be harder too as you'll need an extra dereference
>> to extract the string:
>>
>>    puts(*array_of_ptr_to_str[0]);
>>
> Ok ok. Bugs have also been put in the middle. The first time I wrote the
> declaration in this way:
>
> char *Date = "01-01-80";
> char **Phrases[]
> {
>    &Date
> }
>
> and gcc gave me a lot of errors.

Not surprising as you've left out "=" after "[]", and ";" after "}". You 
should try and post exact code.

After fixing that, it seemed to compile. Date has type char*; &Date has 
type char**; Phrases has type char**[], and each element needs to be 
type char**, so &Date matches (also surprising as it looked wrong).

Then this works:

  puts(*Phrases[0]);

> But I still do not understand why the compiler does not allow me this:
>
> char *Date = NULL;
> char *Phrases[]
> {
>    "Date: ",
>    Date,
>    "\r\n"
> };
>
> In the end I'm just asking him to allocate space to write in an address
> exactly as it happens when I write NULL instead of 'Date'.

Does it say it an initialiser is not constant?

NULL is just 0.

Date requires a memory access to get the NULL stored in it. Memory 
accesses only take place at runtime.

You can make this work by putting it inside a function. But then those 
memory accesses needed to build Phrases will happen every time you call 
the function. (Maybe, you can call the function once to set up a version 
of Phrases[] which is then copied to the Phrases declared outside the 
functions.)

But it's still not clear what you're trying to achieve.

Here's a normal list of strings:

char *List1[] = {"one", "two", "three"};

Here's an indirect one (list of pointers to strings):

char *A="uno", *B="due", *C="tre";
char **List2[] = {&A, &B, &C};

And you access them like this:

  puts(List1[0]);
  puts(List1[1]);
  puts(List1[2]);

  puts(*List2[0]);
  puts(*List2[1]);
  puts(*List2[2]);

What do you want to do that is different?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#109604

Il 09/05/2017 12:47, bartc ha scritto:
> On 09/05/2017 08:54, jak wrote:
>> Il 08/05/2017 13:02, bartc ha scritto:
>>> On 08/05/2017 11:18, jak wrote:
>>>
>>>> I would like to create an array of pointers, of pointers to strings. In
>>>> this way I can have the pointers as constant and I wrote this:
>>>>
>>>> char *Date = "01-01-80";
>>>>
>>>> typedef char * ch;
>>>> typedef ch * p_ch;
>>>>
>>>> p_ch foo[] =
>>>> {
>>>>   &Date,
>>>>   (p_ch)&"Date"
>>>> };
>>>>
>>>> This works but I do not know how to declare foo without using typedef.
>>>
>>> Those types would look like this without typedefs:
>>>
>>> char *  str;
>>> char *  array_of_str[];
>>> char ** ptr_to_str;
>>> char ** array_of_ptr_to_str[];
>>>
>>> (The arrays will need a dimension, or need to be initialised.)
>>>
>>> But arrays of pointers to strings would be unusual, and be harder to
>>> initialise as you can't just have "ABC", but need to set up a named
>>> string: char* abc="ABC", then use &abc.
>>>
>>> I don't think you can apply a cast to "ABC" to get the pointer you need.
>>> (Well, you can cast it, but it won't be a proper pointer to string,
>>> it'll just be a string, and will crash when you apply the dereference
>>> below.)
>>>
>>> Using the array would be harder too as you'll need an extra dereference
>>> to extract the string:
>>>
>>>    puts(*array_of_ptr_to_str[0]);
>>>
>> Ok ok. Bugs have also been put in the middle. The first time I wrote the
>> declaration in this way:
>>
>> char *Date = "01-01-80";
>> char **Phrases[]
>> {
>>    &Date
>> }
>>
>> and gcc gave me a lot of errors.
>
> Not surprising as you've left out "=" after "[]", and ";" after "}". You
> should try and post exact code.
>
> After fixing that, it seemed to compile. Date has type char*; &Date has
> type char**; Phrases has type char**[], and each element needs to be
> type char**, so &Date matches (also surprising as it looked wrong).
>
> Then this works:
>
>  puts(*Phrases[0]);
>
>> But I still do not understand why the compiler does not allow me this:
>>
>> char *Date = NULL;
>> char *Phrases[]
>> {
>>    "Date: ",
>>    Date,
>>    "\r\n"
>> };
>>
>> In the end I'm just asking him to allocate space to write in an address
>> exactly as it happens when I write NULL instead of 'Date'.
>
> Does it say it an initialiser is not constant?
>
> NULL is just 0.
>
> Date requires a memory access to get the NULL stored in it. Memory
> accesses only take place at runtime.
>
> You can make this work by putting it inside a function. But then those
> memory accesses needed to build Phrases will happen every time you call
> the function. (Maybe, you can call the function once to set up a version
> of Phrases[] which is then copied to the Phrases declared outside the
> functions.)
>
> But it's still not clear what you're trying to achieve.
>
> Here's a normal list of strings:
>
> char *List1[] = {"one", "two", "three"};
>
> Here's an indirect one (list of pointers to strings):
>
> char *A="uno", *B="due", *C="tre";
> char **List2[] = {&A, &B, &C};
>
> And you access them like this:
>
>  puts(List1[0]);
>  puts(List1[1]);
>  puts(List1[2]);
>
>  puts(*List2[0]);
>  puts(*List2[1]);
>  puts(*List2[2]);
>
> What do you want to do that is different?
>

No, I do not want anything different. Only I can not understand the 
reason why the compiler wants the initializer to be constant. When I 
write this:

char *Phrase[] =
{
    NULL, /*1*/
    NULL, /*2*/
    NULL, /*3*/
    NULL  /*4*/
};

I ask the compiler to allocate for me 4 contiguous memory areas, each 
large to contain a pointer. Each pointer is char type and then uses this 
step in its arithmetic. If at runtime I can modify, with new values, 
each of the 4 pointers I have declared; Why does the compiler want it to 
be constant during the definition? Is there a real reason, or is it just 
the imagination of those who have thought about grammar and syntax?

Please, excuse my English.

[toc] | [prev] | [next] | [standalone]

#109605

jak <please@nospam.tnx> writes:
>Il 09/05/2017 12:47, bartc ha scritto:

>
>No, I do not want anything different. Only I can not understand the 
>reason why the compiler wants the initializer to be constant. When I 
>write this:
>
>char *Phrase[] =
>{
>    NULL, /*1*/
>    NULL, /*2*/
>    NULL, /*3*/
>    NULL  /*4*/
>};
>
>I ask the compiler to allocate for me 4 contiguous memory areas, each 
>large to contain a pointer. Each pointer is char type and then uses this 
>step in its arithmetic. If at runtime I can modify, with new values, 
>each of the 4 pointers I have declared; Why does the compiler want it to 
>be constant during the definition?

Because you're defining file-scope static data, which must
be fully resolved at compile time since it will be stored in
the executable (ELF, PE/COFF), long before run-time.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web