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

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

Array sizes and const

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

Contents

  Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 15:43 -0500
    Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-03 08:56 +1200
    Re: Array sizes and const Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-02 16:59 -0400
      Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 16:35 -0500
        Re: Array sizes and const jgk@panix.com (Joe keane) - 2012-06-08 20:05 +0000
        Re: Array sizes and const jgk@panix.com (Joe keane) - 2012-06-09 21:36 +0000
      Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 16:43 -0500
    Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-02 14:59 -0700
      Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 17:12 -0500
        Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-02 18:27 -0700
          Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 22:27 -0500
        Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-03 11:24 +0100
          Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-03 13:51 -0700
            Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-04 12:20 +0100
              Re: Array sizes and const Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-04 13:54 +0200
              Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-04 14:32 -0700
    Re: Array sizes and const Nobody <nobody@nowhere.com> - 2012-06-02 23:50 +0100
      Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-03 10:53 +1200
        Re: Array sizes and const Nobody <nobody@nowhere.com> - 2012-06-03 14:35 +0100
      Re: Array sizes and const James Kuyper <jameskuyper@verizon.net> - 2012-06-02 21:11 -0400
        Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-03 07:39 -0700
          Re: Array sizes and const James Kuyper <jameskuyper@verizon.net> - 2012-06-03 16:03 -0400
          Re: Array sizes and const Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-03 21:49 +0100
            Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-03 14:49 -0700
            Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-03 15:02 -0700
              Re: Array sizes and const Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-04 01:21 +0100
          Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 09:08 +1200
            Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-03 15:08 -0700
              Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 10:37 +1200
                Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-03 23:47 +0100
                  Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 10:55 +1200
                    Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-03 16:04 -0700
                      Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 11:14 +1200
                        Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-04 00:23 +0100
                          Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 11:30 +1200
                            Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-04 00:52 +0100
                              Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 12:04 +1200
                          Re: Array sizes and const Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-04 01:39 +0100
                        Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-04 02:35 -0700
                    Re: Array sizes and const Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-04 01:33 +0100
                      Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 12:35 +1200
                  Re: Array sizes and const pacman@kosh.dhis.org (Alan Curry) - 2012-06-04 21:28 +0000
          Re: Array sizes and const James Kuyper <jameskuyper@verizon.net> - 2012-06-04 12:08 -0400
          Re: Array sizes and const jgk@panix.com (Joe keane) - 2012-06-04 22:49 +0000
      Re: Array sizes and const David Brown <david.brown@hesbynett.no> - 2012-06-03 15:46 -0500
    Re: Array sizes and const Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 02:08 -0700
      Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-08 06:45 -0500
        Re: Array sizes and const Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 10:49 -0700
          Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-08 18:05 -0500
      Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-08 13:31 -0700
        Re: Array sizes and const Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 20:30 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#21750

בתאריך יום ראשון, 3 ביוני 2012 02:11:15 UTC+1, מאת James Kuyper:
> On 06/02/2012 06:50 PM, Nobody wrote:
> ...
> > The main purpose of "const" is to tell the compiler to assume that the
> > value won't change.
> 
> I don't think that's the main purpose. In my opinion, the most important
> thing about 'const', and the reason why I use it where appropriate, is
> that it turns many dangerous constructs into constraint violations,
> making a diagnostic mandatory.
> 
I never use it. Part of the reason is that whilst int member(const FOO *obj) is clear enough in intention, in fact the constness of obj does not extend to its members. Another is the const-poisoning problem. You have to use const consistently, or you end up needing to pass a const pointer to a non-const subroutine which doesn't in fact alter the data.
Then C++ added mutable. This makes a member of a const class non-const. The fact that mutable was considered necessary is an argument against const.

But the main reason is simply visual clutter. You want to be able to see what a function does at a glance.

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

#21757

On 06/03/2012 10:39 AM, Malcolm McLean wrote:
...
> does not extend to its members. Another is the const-poisoning
> problem. You have to use const consistently, or you end up needing to
> pass a const pointer to a non-const subroutine which doesn't in fact
> alter the data.

I don't see that as a problem. Forcing consistent use of const is good
mental discipline; the casts that are needed to interface with libraries
that don't use it correctly helps document those library's faults.
-- 
James Kuyper

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

#21765

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> בתאריך יום ראשון, 3 ביוני 2012 02:11:15 UTC+1, מאת James Kuyper:
>> On 06/02/2012 06:50 PM, Nobody wrote:
>> ...
>> > The main purpose of "const" is to tell the compiler to assume that the
>> > value won't change.
>> 
>> I don't think that's the main purpose. In my opinion, the most important
>> thing about 'const', and the reason why I use it where appropriate, is
>> that it turns many dangerous constructs into constraint violations,
>> making a diagnostic mandatory.
>> 
> I never use it. Part of the reason is that whilst int member(const FOO
> *obj) is clear enough in intention, in fact the constness of obj does
> not extend to its members.

Can you say what you mean by this?  It contradicts what I thought was
the case (assuming you meant the members of *obj).

<snip>
-- 
Ben.

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

#21769

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> בתאריך יום ראשון, 3 ביוני 2012 02:11:15 UTC+1, מאת James Kuyper:
>>> On 06/02/2012 06:50 PM, Nobody wrote:
>>> ...
>>> > The main purpose of "const" is to tell the compiler to assume that the
>>> > value won't change.
>>> 
>>> I don't think that's the main purpose. In my opinion, the most important
>>> thing about 'const', and the reason why I use it where appropriate, is
>>> that it turns many dangerous constructs into constraint violations,
>>> making a diagnostic mandatory.
>>> 
>> I never use it. Part of the reason is that whilst int member(const FOO
>> *obj) is clear enough in intention, in fact the constness of obj does
>> not extend to its members.
>
> Can you say what you mean by this?  It contradicts what I thought was
> the case (assuming you meant the members of *obj).
>
> <snip>

Agreed.

typedef struct foo {
    int x;
} FOO;

int member(const FOO *obj) {
    obj->x = 42;
    return 43;
}

int main(void) {
    FOO foo_obj;
    int m = member(&foo_obj);
    return 0;
}

c.c: In function ‘member’:
c.c:6:5: error: assignment of member ‘x’ in read-only object

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#21770

בתאריך יום ראשון, 3 ביוני 2012 21:49:19 UTC+1, מאת Ben Bacarisse:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > I never use it. Part of the reason is that whilst int member(const FOO
> > *obj) is clear enough in intention, in fact the constness of obj does
> > not extend to its members.
> 
> Can you say what you mean by this?  It contradicts what I thought was
> the case (assuming you meant the members of *obj).
> 
typedef struct
{
  char *name;
} EMPLOYEE;

const char *getname(const EMPLOYEE *employee)
{
  strcpy(employee->name, "Fred");
  return employee->name;
}

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

#21788

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> בתאריך יום ראשון, 3 ביוני 2012 21:49:19 UTC+1, מאת Ben Bacarisse:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> > I never use it. Part of the reason is that whilst int member(const FOO
>> > *obj) is clear enough in intention, in fact the constness of obj does
>> > not extend to its members.
>> 
>> Can you say what you mean by this?  It contradicts what I thought was
>> the case (assuming you meant the members of *obj).
>> 
> typedef struct
> {
>   char *name;
> } EMPLOYEE;
>
> const char *getname(const EMPLOYEE *employee)
> {
>   strcpy(employee->name, "Fred");
>   return employee->name;
> }

What's that got to do with what you said?  The object being modified by
strcpy is not a member of *employee.

-- 
Ben.

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

#21767

On 06/ 4/12 02:39 AM, Malcolm McLean wrote:
> בתאריך יום ראשון, 3 ביוני 2012 02:11:15 UTC+1, מאת James Kuyper:
>> On 06/02/2012 06:50 PM, Nobody wrote:
>> ...
>>> The main purpose of "const" is to tell the compiler to assume that the
>>> value won't change.
>>
>> I don't think that's the main purpose. In my opinion, the most important
>> thing about 'const', and the reason why I use it where appropriate, is
>> that it turns many dangerous constructs into constraint violations,
>> making a diagnostic mandatory.

Please please wrap your lines!

> I never use it. Part of the reason is that whilst int member(const FOO *obj)
> is clear enough in intention, in fact the constness of obj does not extend
 > to its members.

Eh?  What if FOO is in read only memory?

> Another is the const-poisoning problem. You have to use const consistently,
 > or you end up needing to pass a const pointer to a non-const subroutine
 > which doesn't in fact alter the data.

So good coding discipline is bad?

> Then C++ added mutable. This makes a member of a const class non-const.
 > The fact that mutable was considered necessary is an argument against 
const.

Mutable is rarely used in C++.  Most of the cases in my own code are for 
internal state variables.

> But the main reason is simply visual clutter. You want to be able to see
 > what a function does at a glance.

Isn't whether the function modifies its arguments one of the most 
important things you want to see at a glance?

-- 
Ian Collins

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

#21773

בתאריך יום ראשון, 3 ביוני 2012 22:08:01 UTC+1, מאת Ian Collins:
> On 06/ 4/12 02:39 AM, Malcolm McLean wrote:
> 
> Isn't whether the function modifies its arguments one of the most 
> important things you want to see at a glance?
> 
Usually it's obvious

double mean(double *x, int N)

isn't going to modify x. 

What you might argue is that

double median(double *x, int N)

could reasonably sort x as a side-effect. Make it const, and you've documented that this isn't the case. I'd say this is sufficiently rare to make const non-useful as a documenting feature. 

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

#21776

On 06/ 4/12 10:08 AM, Malcolm McLean wrote:
> בתאריך יום ראשון, 3 ביוני 2012 22:08:01 UTC+1, מאת Ian Collins:
>> On 06/ 4/12 02:39 AM, Malcolm McLean wrote:
>>
>> Isn't whether the function modifies its arguments one of the most
>> important things you want to see at a glance?
>>
> Usually it's obvious
>
> double mean(double *x, int N)
>
> isn't going to modify x.
>
> What you might argue is that
>
> double median(double *x, int N)

Pretty please wrap your lines!

> could reasonably sort x as a side-effect. Make it const, and you've
> documented that this isn't the case. I'd say this is sufficiently
> rare to make const non-useful as a documenting feature.

But what isn't rare is something like

const double dd[] = { 1.0, 2.0, 3.1 };

mean(dd);

Which will trigger an appropriate diagnostic.

If a function doesn't modify a parameter, declare it const.  What's so 
hard about that?

-- 
Ian Collins

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

#21777

"Ian Collins" <ian-news@hotmail.com> wrote in message
news:a327a6F5maU3@mid.individual.net...
> On 06/ 4/12 10:08 AM, Malcolm McLean wrote:

>> could reasonably sort x as a side-effect. Make it const, and you've
>> documented that this isn't the case. I'd say this is sufficiently
>> rare to make const non-useful as a documenting feature.
>
> But what isn't rare is something like
>
> const double dd[] = { 1.0, 2.0, 3.1 };
>
> mean(dd);
>
> Which will trigger an appropriate diagnostic.
>
> If a function doesn't modify a parameter, declare it const.  What's so
> hard about that?

Because nineteen times out of twenty, it won't modify it, so it means loads
of const attributes cluttering up code.

Of course some parameter types can be harmlessly modified (ints for 
example), and const isn't necessary, but then you have to start thinking 
about about every parameter and whether it will be modified in the caller or 
in the callee.

Maybe it would have been better for the modifiable parameters (where it
changes caller's data) to have an attribute instead, and everything else
assumed to be const.

-- 
Bartc 

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

#21778

On 06/ 4/12 10:47 AM, BartC wrote:
> "Ian Collins"<ian-news@hotmail.com>  wrote in message
> news:a327a6F5maU3@mid.individual.net...
>> On 06/ 4/12 10:08 AM, Malcolm McLean wrote:
>
>>> could reasonably sort x as a side-effect. Make it const, and you've
>>> documented that this isn't the case. I'd say this is sufficiently
>>> rare to make const non-useful as a documenting feature.
>>
>> But what isn't rare is something like
>>
>> const double dd[] = { 1.0, 2.0, 3.1 };
>>
>> mean(dd);
>>
>> Which will trigger an appropriate diagnostic.
>>
>> If a function doesn't modify a parameter, declare it const.  What's so
>> hard about that?
>
> Because nineteen times out of twenty, it won't modify it, so it means loads
> of const attributes cluttering up code.
>
> Of course some parameter types can be harmlessly modified (ints for
> example), and const isn't necessary, but then you have to start thinking
> about about every parameter and whether it will be modified in the caller or
> in the callee.

Isn't that part of the design process?  Naturally it's pointless 
declaring a value type parameter const, but pointer types should be. 
Not doing so in the past has given us the glorious mess of a language 
permitting a string literal to be passed to function with a char* parameter.

-- 
Ian Collins

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

#21779

בתאריך יום ראשון, 3 ביוני 2012 23:55:33 UTC+1, מאת Ian Collins:
> 
> Isn't that part of the design process?  Naturally it's pointless 
> declaring a value type parameter const, but pointer types should be. 
> Not doing so in the past has given us the glorious mess of a language 
> permitting a string literal to be passed to function with a char* parameter.
> 
One very common paradigm is the opaque pointer.
We might have a threedengine structure, and a member function for drawing
triangles. If we draw a triangle, the engine might add it to a draw list,
or it might pass it to the rendering hardware directly. It's none of caller's
business how it does it.
But if it sends the triangle to the rendering hardware directly, the ENGINE *
is a const. If it buffers it, it is mutable. 
  

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

#21780

On 06/ 4/12 11:04 AM, Malcolm McLean wrote:
> בתאריך יום ראשון, 3 ביוני 2012 23:55:33 UTC+1, מאת Ian Collins:
>>
>> Isn't that part of the design process?  Naturally it's pointless
>> declaring a value type parameter const, but pointer types should be.
>> Not doing so in the past has given us the glorious mess of a language
>> permitting a string literal to be passed to function with a char* parameter.
>>
> One very common paradigm is the opaque pointer.
> We might have a threedengine structure, and a member function for drawing
> triangles. If we draw a triangle, the engine might add it to a draw list,
> or it might pass it to the rendering hardware directly. It's none of caller's
> business how it does it.
> But if it sends the triangle to the rendering hardware directly, the ENGINE *
> is a const. If it buffers it, it is mutable.

There's a good example of the confusion, does it modify the triangle or 
not?  From the description you give, it looks like if does not in either 
case.

It is very much the callers business to know whether the triangle it 
passes will or will not be molested by the function.  What if it has a 
table of triangles in read only memory?

The constness of the parameter has nothing to do with how the function 
does its job.

-- 
Ian Collins

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

#21781

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:a329evF5maU5@mid.individual.net...
> On 06/ 4/12 11:04 AM, Malcolm McLean wrote:
>> בתאריך יום ראשון, 3 ביוני 2012 23:55:33 UTC+1, מאת Ian Collins:

>> But if it sends the triangle to the rendering hardware directly, the 
>> ENGINE *
>> is a const. If it buffers it, it is mutable.
>
> There's a good example of the confusion, does it modify the triangle or 
> not?  From the description you give, it looks like if does not in either 
> case.
>
> It is very much the callers business to know whether the triangle it 
> passes will or will not be molested by the function.  What if it has a 
> table of triangles in read only memory?
>
> The constness of the parameter has nothing to do with how the function 
> does its job.

Would a const attribute be any use here:

#include <stdio.h>
#include <string.h>

void changestr(char* s){
s[0]='?';
}

int main(void)
{
changestr("abcdef");
puts("abcdef");
}

I want to able to use changestr() to modify a string variable. But how can I 
stop a string literal being passed (which will either corrupt the literal, 
or will crash, on my tests)?

It's possible the new write-attribute I mentioned a couple of posts ago (eg. 
'var' to mean the opposite of 'const') could be useful here. Then the 
compiler knows passing the string literal is a mistake.

(And I can't find a gcc warning level to tell me that a string literal is 
being passed as a non-const char* parameter which could potentially 
overwrite it.)

-- 
Bartc 

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

#21782

On 06/ 4/12 11:23 AM, BartC wrote:
> "Ian Collins"<ian-news@hotmail.com>  wrote in message
> news:a329evF5maU5@mid.individual.net...
>> On 06/ 4/12 11:04 AM, Malcolm McLean wrote:
>>> בתאריך יום ראשון, 3 ביוני 2012 23:55:33 UTC+1, מאת Ian Collins:
>
>>> But if it sends the triangle to the rendering hardware directly, the
>>> ENGINE *
>>> is a const. If it buffers it, it is mutable.
>>
>> There's a good example of the confusion, does it modify the triangle or
>> not?  From the description you give, it looks like if does not in either
>> case.
>>
>> It is very much the callers business to know whether the triangle it
>> passes will or will not be molested by the function.  What if it has a
>> table of triangles in read only memory?
>>
>> The constness of the parameter has nothing to do with how the function
>> does its job.
>
> Would a const attribute be any use here:

Yes, change it and see:

void changestr(const char* s)

gcc x.c
x.c: In function ‘changestr’:
x.c:5:3: error: assignment of read-only location ‘*s’

> #include<stdio.h>
> #include<string.h>
>
> void changestr(char* s){
> s[0]='?';
> }
>
> int main(void)
> {
> changestr("abcdef");
> puts("abcdef");
> }
>
> I want to able to use changestr() to modify a string variable. But how can I
> stop a string literal being passed (which will either corrupt the literal,
> or will crash, on my tests)?

That's the "glorious mess" I mentioned up-thread.

C++ fixed this one, but I'm sure if the C committee tries, the fossils 
would pop up and whine about breaking existing (already broken) code.

-- 
Ian Collins

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

#21785

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:a32adaF5maU6@mid.individual.net...
> On 06/ 4/12 11:23 AM, BartC wrote:

>> Would a const attribute be any use here:
>
> Yes, change it and see:
>
> void changestr(const char* s)
>
> gcc x.c
> x.c: In function ‘changestr’:
> x.c:5:3: error: assignment of read-only location ‘*s’

But then I can't use changestr() for it's intended purpose!

> That's the "glorious mess" I mentioned up-thread.
>
> C++ fixed this one, but I'm sure if the C committee tries, the fossils 
> would pop up and whine about breaking existing (already broken) code.

In the meantime, coding seems simpler without bothering with 'const' all.

-- 
Bartc 

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

#21787

On 06/ 4/12 11:52 AM, BartC wrote:
>
>
> "Ian Collins"<ian-news@hotmail.com>  wrote in message
> news:a32adaF5maU6@mid.individual.net...
>> On 06/ 4/12 11:23 AM, BartC wrote:
>
>>> Would a const attribute be any use here:
>>
>> Yes, change it and see:
>>
>> void changestr(const char* s)
>>
>> gcc x.c
>> x.c: In function ‘changestr’:
>> x.c:5:3: error: assignment of read-only location ‘*s’
>
> But then I can't use changestr() for it's intended purpose!

Ah, I see your point.  The rest of my reply still applies!

>> That's the "glorious mess" I mentioned up-thread.
>>
>> C++ fixed this one, but I'm sure if the C committee tries, the fossils
>> would pop up and whine about breaking existing (already broken) code.
>
> In the meantime, coding seems simpler without bothering with 'const' all.

Or find a compiler option that does the check.  -Wwrite-strings does the 
trick for gcc.

-- 
Ian Collins

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

#21791

"BartC" <bc@freeuk.com> writes:
<snip>
> Would a const attribute be any use here:
>
> #include <stdio.h>
> #include <string.h>
>
> void changestr(char* s){
> s[0]='?';
> }
>
> int main(void)
> {
> changestr("abcdef");
> puts("abcdef");
> }
>
> I want to able to use changestr() to modify a string variable. But how
> can I stop a string literal being passed (which will either corrupt
> the literal, or will crash, on my tests)?
>
> It's possible the new write-attribute I mentioned a couple of posts
> ago (eg. 'var' to mean the opposite of 'const') could be useful
> here. Then the compiler knows passing the string literal is a mistake.
>
> (And I can't find a gcc warning level to tell me that a string literal
> is being passed as a non-const char* parameter which could potentially
> overwrite it.)

"gcc -Wwrite-strings" makes string literals const (and thus the
resulting pointer becomes a const char *).  This is how C++ treats
strings.

It has the curious side effect of making gcc non-conforming even with
all the right other options (-std=c99 -pedantic).  The reason is far too
obscure to worry about in practice.  I find it a very useful option.

-- 
Ben.

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

#21796

בתאריך יום שני, 4 ביוני 2012 00:14:38 UTC+1, מאת Ian Collins:
> On 06/ 4/12 11:04 AM, Malcolm McLean wrote:
> 
> There's a good example of the confusion, does it modify the triangle or 
> not?  From the description you give, it looks like if does not in either 
> case.
> 
> It is very much the callers business to know whether the triangle it 
> passes will or will not be molested by the function.  What if it has a 
> table of triangles in read only memory?
> 
I didn't tell you how the triangle was passed, whether as a structure, buffer,
or set of separate parameters.
Generally you know whether the triangle will be molested or not. If the engine
 needs some temporay state, then the triangle structure will have members with
 names like "reserved_flag" and so on. What's much more likely is that the 
 engine doesn't buffer the triangle vertices independently. It just keeps a
 pointer to them. If you over-write the vertices before you call the frame
 synch, you'll get the wrong triangle. But const won't help you with that.

With the ENGINE parameter, you don't know whether drawing a triangle affects
 the state or not, nor should you. And that's a common paradigm. const breaks
 the paradigm here. 

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

#21789

Ian Collins <ian-news@hotmail.com> writes:

> On 06/ 4/12 10:47 AM, BartC wrote:
>> "Ian Collins"<ian-news@hotmail.com>  wrote in message
<snip>
>>> If a function doesn't modify a parameter, declare it const.  What's so
>>> hard about that?
>>
>> Because nineteen times out of twenty, it won't modify it, so it means loads
>> of const attributes cluttering up code.
>>
>> Of course some parameter types can be harmlessly modified (ints for
>> example), and const isn't necessary, but then you have to start thinking
>> about about every parameter and whether it will be modified in the caller or
>> in the callee.
>
> Isn't that part of the design process?  Naturally it's pointless
> declaring a value type parameter const, but pointer types should
> be.

A minor point...

You keep talking about declaring parameters const when a function does
not modify them (and now BartC has taken you at your word) but you are
not, I think, talking about const parameters, nor about pointer
parameters being const, (as above), but about parameters that are
pointers to const types.

I know that "a const pointer" is a commonly used phrase, but it can be
really confusing because it's literally not what is usually meant.

<snip>
-- 
Ben.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web