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

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

const or constant?

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

Contents

  const or constant? jacob navia <jacob@spamsink.net> - 2014-04-22 18:58 +0200
    Re: const or constant? "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-22 14:13 -0400
      Re: const or constant? Barry Schwarz <schwarzb@dqel.com> - 2014-04-22 15:59 -0700
    Re: const or constant? jt@toerring.de (Jens Thoms Toerring) - 2014-04-22 21:26 +0000
      Re: const or constant? James Kuyper <jameskuyper@verizon.net> - 2014-04-22 17:56 -0400
        Re: const or constant? Keith Thompson <kst-u@mib.org> - 2014-04-22 15:32 -0700
          Re: const or constant? James Kuyper <jameskuyper@verizon.net> - 2014-04-23 08:57 -0400
            Re: const or constant? David Brown <david.brown@hesbynett.no> - 2014-04-23 15:27 +0200
              Re: const or constant? Keith Thompson <kst-u@mib.org> - 2014-04-23 08:34 -0700
                Re: const or constant? David Brown <david.brown@hesbynett.no> - 2014-04-24 08:50 +0200
                  Re: const or constant? James Kuyper <jameskuyper@verizon.net> - 2014-04-24 07:58 -0400
                    Re: const or constant? David Brown <david.brown@hesbynett.no> - 2014-04-24 14:19 +0200
                      Re: const or constant? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 21:40 +0000
                        Re: const or constant? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-25 01:05 -0700
            Re: const or constant? "BartC" <bc@freeuk.com> - 2014-04-23 21:38 +0100
        Re: const or constant? jacob navia <jacob@spamsink.net> - 2014-04-23 00:51 +0200
      Re: const or constant? jacob navia <jacob@spamsink.net> - 2014-04-23 00:47 +0200
    Re: const or constant? Walter Banks <walter@bytecraft.com> - 2014-04-22 18:00 -0400
    Re: const or constant? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-22 23:12 +0100
      Re: const or constant? jacob navia <jacob@spamsink.net> - 2014-04-23 01:00 +0200
        Re: const or constant? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 14:48 +0100
          Re: const or constant? Keith Thompson <kst-u@mib.org> - 2014-04-23 08:40 -0700
            Re: const or constant? jacob navia <jacob@spamsink.net> - 2014-04-23 21:49 +0200
              Re: const or constant? Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 20:11 +0000
              [OT] Killfiles (was Re: const or constant?) Keith Thompson <kst-u@mib.org> - 2014-04-23 14:49 -0700
                Re: [OT] Killfiles (was Re: const or constant?) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-23 22:22 -0700
      Re: const or constant? James Kuyper <jameskuyper@verizon.net> - 2014-04-23 09:09 -0400
    Re: const or constant? Ian Collins <ian-news@hotmail.com> - 2014-04-24 09:35 +1200
      Re: const or constant? Ian Collins <ian-news@hotmail.com> - 2014-04-24 10:06 +1200
        Re: const or constant? Ian Collins <ian-news@hotmail.com> - 2014-04-24 10:52 +1200

Page 1 of 2  [1] 2  Next page →

#43309 — const or constant?

After reading some of the contrbutions to the "constant strings" thread, 
I think that what is needed is a clarification of the underlying issues.

There are TWO "uses" of const:

1) Declaring that a function will not modify its arguments
2) Declaring that an object resides in ROM (read only memory)

The first one is tied to a *scope*. It says that within a certain scope, 
no modifications are done to some object. I would propose that we name 
this property "constant" and we would declare:

char *strchr(constant char *buffer, int searchedChar);

This means: "The strchr functions receives a buffeer that will NOT be 
modified within the scope of the function". This implies that inner 
scopes are required to maintain this feature. It means also that when we 
exitthe scope where this "constant" declaration is done, the object 
becomes writable again. Hence it is normal that strchr returns a *plain* 
char pointer. "constant" objects can't be returned as constant.

The second meaning of const is the usual one and it is tied to an 
*object* not a scope. It means that the object can't be modified at 
*any* scope, it is an intrinsic property of the object.

In my opinion many problems with "const" would disappear if we 
distinguish between these two usages of const.

Feedback welcome.

[toc] | [next] | [standalone]

#43324

jacob navia wrote:
> After reading some of the contrbutions to the "constant strings"
> thread, I think that what is needed is a clarification of the
> underlying issues.
> There are TWO "uses" of const:
>
> 1) Declaring that a function will not modify its arguments
> 2) Declaring that an object resides in ROM (read only memory)
>
> The first one is tied to a *scope*. It says that within a certain
> scope, no modifications are done to some object. I would propose that
> we name this property "constant" and we would declare:
>
> char *strchr(constant char *buffer, int searchedChar);

    It's const not constant

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

#43389

On Tue, 22 Apr 2014 14:13:53 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>jacob navia wrote:
>> After reading some of the contrbutions to the "constant strings"
>> thread, I think that what is needed is a clarification of the
>> underlying issues.
>> There are TWO "uses" of const:
>>
>> 1) Declaring that a function will not modify its arguments
>> 2) Declaring that an object resides in ROM (read only memory)
>>
>> The first one is tied to a *scope*. It says that within a certain
>> scope, no modifications are done to some object. I would propose that
>> we name this property "constant" and we would declare:
>>
>> char *strchr(constant char *buffer, int searchedChar);
>
>    It's const not constant

If you ever start reading for comprehension, you wouldn't make asinine
comments like this.

-- 
Remove del for email

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

#43360

jacob navia <jacob@spamsink.net> wrote:
> After reading some of the contrbutions to the "constant strings" thread, 
> I think that what is needed is a clarification of the underlying issues.

> There are TWO "uses" of const:

> 1) Declaring that a function will not modify its arguments
> 2) Declaring that an object resides in ROM (read only memory)

There's no requirement that a constant of type 2) is in ROM.
What about a function like

void foo( int v ) {
    const int d = v;
	...
}

Why should be 'd' in ROM? It only makes sure that the compiler
will get upset when you try to change its value sometime later
in the function.

And you also seem to be forgetting that 1) and 2) can be
combined as in

  const char * const s

i.e. a pointer that can't be changed to a region of memory
that also can't be modified.

> The first one is tied to a *scope*. 

I don't see that this has anything to do with scope. The pit-
fall, I guess, is that e.g.

  const char * s

doesn't mean that the value of 's' can't be changed (which
one might assume) but what it points to. I.e., for a func-
tion declared as 

   void bar( const char * s, const int d );

it is not really obvious for a beginner that the value of
'd' can't be changed within the function, but that of 's'
can (but not what 's' points to). It makes more sense when
one reads it out aloud as "s is a pointer to const char" -
you need to read it backwards. Reading it backword also

  const char * const s

makes sense: it's a "constant pointer to const chars".

> no modifications are done to some object. I would propose that we name 
> this property "constant" and we would declare:

> char *strchr(constant char *buffer, int searchedChar);

Not only is this unfeasible (it would break millions of
programs) but it doesn't really seem to make anything
much clearer. For that you would need a different way
of declaring/defining pointer. If you could write

  * char s;              <=> char * s;

for "pointer to char", and

  * const char s;        <=> const char * s;

for "pointer to constant char", and

  const * char s;        <=> char * const char;

for "constant pointer to char", and, finally

  const * const char s;  <=> const char * const s;

for "constant pointer to const char", then you'd avoid the
necessity to read it backwards for pointers which, in my
opinion, is what can be confusing.

Another idea would be to use the "address of" operator, '&'
in declarations/definitions instead of '*', which isn't really
very logical, e.g.

   &char s;              <=>   char * s';

would mean "s is the address of a char", i.e. a pointer to a
char, a would be nicely similar to a simple

  char s;

Then you'd have

  &const char s;         <=>   const char * s;

and

  const &char s;         <=>   char * const s;

and, finally

  const &const char s;   <=>  const char * const s;

That way it would make a bit more sense since it could be
read left to right and the '&' seems to be more appropriate
in this context than the '*'.

But while you're at it: perhaps you've also an idea how to
make function pointers more accessible?;-)

                         Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#43376

On 04/22/2014 05:26 PM, Jens Thoms Toerring wrote:
> jacob navia <jacob@spamsink.net> wrote:
>> After reading some of the contrbutions to the "constant strings" thread, 
>> I think that what is needed is a clarification of the underlying issues.
> 
>> There are TWO "uses" of const:
> 
>> 1) Declaring that a function will not modify its arguments
>> 2) Declaring that an object resides in ROM (read only memory)
> 
> There's no requirement that a constant of type 2) is in ROM.

Correct. It would be more accurate to say that const-qualification of an
object allows it to reside in ROM; it doesn't mandate it.

> What about a function like
> 
> void foo( int v ) {
>     const int d = v;
> 	...
> }
> 
> Why should be 'd' in ROM? It only makes sure that the compiler
> will get upset when you try to change its value sometime later
> in the function.
> 
> And you also seem to be forgetting that 1) and 2) can be
> combined as in
> 
>   const char * const s
> 
> i.e. a pointer that can't be changed to a region of memory
> that also can't be modified.

I'm not sure how you concluded that he's forgotten that; his proposal
would convert that to "constant char * const s". Note that since 'const'
would now have only the second meaning, it wouldn't have to be in any
particular position relative to the '*'. It necessarily applies only to
the object whose identifier is being declared, regardless of position.

>> The first one is tied to a *scope*. 
> 
> I don't see that this has anything to do with scope. ...

The 'const' qualification within a function declaration has the first
meaning only within the scope of the identifier being declared. The
second meaning applies anywhere that an lvalue expression referring to
object can be found, whether or not the object's identifier is still in
scope. An unfortunate consequence of this fact is that violation of the
relevant restriction cannot be made a constraint violation, because the
information needed to identify it as such might reside in an entirely
different translation unit. Jacob's proposal does nothing to avoid that
problem.

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

#43384

James Kuyper <jameskuyper@verizon.net> writes:
> On 04/22/2014 05:26 PM, Jens Thoms Toerring wrote:
>> jacob navia <jacob@spamsink.net> wrote:
>>> After reading some of the contrbutions to the "constant strings" thread, 
>>> I think that what is needed is a clarification of the underlying issues.
>> 
>>> There are TWO "uses" of const:
>> 
>>> 1) Declaring that a function will not modify its arguments
>>> 2) Declaring that an object resides in ROM (read only memory)
>> 
>> There's no requirement that a constant of type 2) is in ROM.
>
> Correct. It would be more accurate to say that const-qualification of an
> object allows it to reside in ROM; it doesn't mandate it.

It doesn't always allow it:

    const time_t now = time(NULL);

Of course that can't appear at file scope.

-- 
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]

#43419

On 04/22/2014 06:32 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 04/22/2014 05:26 PM, Jens Thoms Toerring wrote:
>>> jacob navia <jacob@spamsink.net> wrote:
>>>> After reading some of the contrbutions to the "constant strings" thread, 
>>>> I think that what is needed is a clarification of the underlying issues.
>>>
>>>> There are TWO "uses" of const:
>>>
>>>> 1) Declaring that a function will not modify its arguments
>>>> 2) Declaring that an object resides in ROM (read only memory)
>>>
>>> There's no requirement that a constant of type 2) is in ROM.
>>
>> Correct. It would be more accurate to say that const-qualification of an
>> object allows it to reside in ROM; it doesn't mandate it.
> 
> It doesn't always allow it:
> 
>     const time_t now = time(NULL);
> 
> Of course that can't appear at file scope.

I've been told, on this newsgroup, that there exist systems where memory
can be switched during the run of a program from read/write to
read-only, and back again. I know nothing of the details about how that
works - but on a system where such a feature is supported, it may be
used in this case.
-- 
James Kuyper

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

#43424

On 23/04/14 14:57, James Kuyper wrote:
> On 04/22/2014 06:32 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> On 04/22/2014 05:26 PM, Jens Thoms Toerring wrote:
>>>> jacob navia <jacob@spamsink.net> wrote:
>>>>> After reading some of the contrbutions to the "constant strings" thread, 
>>>>> I think that what is needed is a clarification of the underlying issues.
>>>>
>>>>> There are TWO "uses" of const:
>>>>
>>>>> 1) Declaring that a function will not modify its arguments
>>>>> 2) Declaring that an object resides in ROM (read only memory)
>>>>
>>>> There's no requirement that a constant of type 2) is in ROM.
>>>
>>> Correct. It would be more accurate to say that const-qualification of an
>>> object allows it to reside in ROM; it doesn't mandate it.
>>
>> It doesn't always allow it:
>>
>>     const time_t now = time(NULL);
>>
>> Of course that can't appear at file scope.
> 
> I've been told, on this newsgroup, that there exist systems where memory
> can be switched during the run of a program from read/write to
> read-only, and back again. I know nothing of the details about how that
> works - but on a system where such a feature is supported, it may be
> used in this case.
> 

There are many ways in which memory can be mostly read-only, but
sometimes written.  On "big" systems, this can be done by changing
memory mapping permissions via the MMU.  On embedded systems, you get
things like flash memory with values that are unknown at compile time
(such as serial numbers that are burned in during production, and
accessed as "const volatile"), flash memory that is re-programmed at
run-time, and memory that is written during startup or configuration and
then locked in some way during normal runs.

In the case of local data, such as "const time_t now = time(NULL);", I
cannot imagine a system where this would actually be forced read-only.
In real-world systems, "now" will be either on the stack or in
registers, and these will never be read-only.

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

#43430

David Brown <david.brown@hesbynett.no> writes:
[...]
> In the case of local data, such as "const time_t now = time(NULL);", I
> cannot imagine a system where this would actually be forced read-only.
> In real-world systems, "now" will be either on the stack or in
> registers, and these will never be read-only.

I can certainly *imagine* it.

Given:

    const time_t now = time(NULL);

any attempt to modify "now", such as:

    *(time_t*)&now = -1;

has undefined behavior; that can include crashing because that memory
location has been (temporarily) marked read-only.

Doing so could be a way for an implementation to detect logical errors.
In most cases, it's going to be too expensive to be worthwhile, and I'd
be surprised to see a compiler that actually does this -- but perhaps on
some (current or future) hardware marking a memory location as read-only
is very cheap.

But the discussion was about ROM, a term that usually refers to memory
that physically cannot be modified (at least not by simply storing a
value to it).

-- 
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]

#43493

On 23/04/14 17:34, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> In the case of local data, such as "const time_t now = time(NULL);", I
>> cannot imagine a system where this would actually be forced read-only.
>> In real-world systems, "now" will be either on the stack or in
>> registers, and these will never be read-only.
> 
> I can certainly *imagine* it.
> 
> Given:
> 
>     const time_t now = time(NULL);
> 
> any attempt to modify "now", such as:
> 
>     *(time_t*)&now = -1;
> 
> has undefined behavior; that can include crashing because that memory
> location has been (temporarily) marked read-only.
> 
> Doing so could be a way for an implementation to detect logical errors.
> In most cases, it's going to be too expensive to be worthwhile, and I'd
> be surprised to see a compiler that actually does this -- but perhaps on
> some (current or future) hardware marking a memory location as read-only
> is very cheap.

I "could not imagine" such a system because I was thinking of real-world
systems, especially embedded systems (that's what James asked about, and
what I know about).

However, thinking again I /can/ imagine a system that would allow such
possibilities, at least in theory - simulators.  Full simulators are
rare for "big" processors, except while they are being developed, but
are not uncommon for microcontrollers.  It is practical on simulators to
do things like mark memory as read-only or uninitialised on a
per-location basis, with a view to catching errors.  I haven't seen or
used a simulator that does this, and it would require co-operation
between the compiler and simulator together with extra code (something
like a "markReadonly(&now, sizeof(now));" after setting "now"), but it
is certainly possible.

> 
> But the discussion was about ROM, a term that usually refers to memory
> that physically cannot be modified (at least not by simply storing a
> value to it).
> 

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

#43501

On 04/24/2014 02:50 AM, David Brown wrote:
...
> I "could not imagine" such a system because I was thinking of real-world
> systems, especially embedded systems (that's what James asked about, and
> what I know about).

It would be more accurate to say that I commented about such systems
rather than asked about them. Unlike you, my primary interest is not in
"real world" systems, but in what the standard allows. Anything that the
standard allows might become real, sooner or later, even if it never has
been before. My code should continue functioning correctly if that happens.
-- 
James Kuyper

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

#43503

On 24/04/14 13:58, James Kuyper wrote:
> On 04/24/2014 02:50 AM, David Brown wrote:
> ...
>> I "could not imagine" such a system because I was thinking of real-world
>> systems, especially embedded systems (that's what James asked about, and
>> what I know about).
> 
> It would be more accurate to say that I commented about such systems
> rather than asked about them. Unlike you, my primary interest is not in
> "real world" systems, but in what the standard allows. Anything that the
> standard allows might become real, sooner or later, even if it never has
> been before. My code should continue functioning correctly if that happens.
> 

Fair enough.  Your code has to run on systems we will see in ten years
time - my code has to run on systems today, and keep running for the
next ten years.

My primary interest is first in the real-world systems that my company
uses at the moment, followed by those that we may use in the foreseeable
future, and then those real-world systems that we don't use.  So that
includes some "weird" platforms where there is only limited C support
(and perhaps non-quite-standard C), or where common assumptions (such as
8-bit chars) do not apply, but it does not include some other "weird"
platforms that support standard C but either don't exist, or are well
out of scope for my work (such as 36-bit chars or 1's complement signed
integers).

It's good to learn about the theory and the set of common rules for C,
and it's good to have a bit of real-life practicality too.  The variety
of interests and experiences is what keeps this group interesting.

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

#43528

David Brown <david.brown@hesbynett.no> wrote:

(snip)

> Fair enough.  Your code has to run on systems we will see in ten years
> time - my code has to run on systems today, and keep running for the
> next ten years.
 
> My primary interest is first in the real-world systems that my company
> uses at the moment, followed by those that we may use in the foreseeable
> future, and then those real-world systems that we don't use.  So that
> includes some "weird" platforms where there is only limited C support
> (and perhaps non-quite-standard C), or where common assumptions (such as
> 8-bit chars) do not apply, but it does not include some other "weird"
> platforms that support standard C but either don't exist, or are well
> out of scope for my work (such as 36-bit chars or 1's complement signed
> integers).

It is just about 50 years now since IBM S/360 came out.  (Depends a
little if you mean announce date or ship date.)

Interestingly, current 64 bit z/OS systems will still run programs
compiled (or assembled) and linked for OS/360 50 years ago.  
(The hardware supports 24 bit addressing modes to allow them to run.)

I can be pretty sure that those writing for 64K S/360 machines didn't
dream that the programs would ever run on 64GB (I don't know how big
they actually make z/) machines 50 years later.

Even so, while the address space of processors is still growing
about along with Moore's law, the actual machines that most people
use aren't increasing in RAM nearly as fast.

Machines 50 years ago were small because that is what people
could afford to buy. 

-- glen

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

#43546

On Thursday, April 24, 2014 10:40:21 PM UTC+1, glen herrmannsfeldt wrote:
> 
> Even so, while the address space of processors is still growing
> about along with Moore's law, the actual machines that most people
> use aren't increasing in RAM nearly as fast.
> 
64 bits will do us for a long time.
> 
RAM is relatively cheap, about 10 pounds / 15 dollar a GB at retail. So
a consumer could easily install 32 or 64 GB. Few do, because the applications
to make use of that amount of memory haven't come out. However scientific
programmers and other big users will routinely have that much. 

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

#43460

"James Kuyper" <jameskuyper@verizon.net> wrote in message
news:lj8dca$k43$1@dont-email.me...
> On 04/22/2014 06:32 PM, Keith Thompson wrote:

>> It doesn't always allow it:
>>
>>     const time_t now = time(NULL);
>>
>> Of course that can't appear at file scope.
>
> I've been told, on this newsgroup, that there exist systems where memory
> can be switched during the run of a program from read/write to
> read-only, and back again. I know nothing of the details about how that
> works - but on a system where such a feature is supported, it may be
> used in this case.

(An early computer board I built had a physical toggle switch on one memory
bank, to inhibit any /write signal and thus completely protect the RAM as
though it was read-only memory, provided it was powered-up of course. (BTW
this is a more fool-proof technique than using 'const'!)

(This was to protect in-memory source code from a program going haywire; I
couldn't afford disks.)

That could also be trivially switched (with a couple of mods) from software,
although some care would be a needed, as an out-of-control program could
also re-enable the /write signal. In any case, it's not an impossibility to
take care of through software. I would, however, trust my toggle switch
rather more...)

-- 
Bartc 

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

#43388

Le 22/04/2014 23:56, James Kuyper a écrit :
> The
> second meaning applies anywhere that an lvalue expression referring to
> object can be found, whether or not the object's identifier is still in
> scope. An unfortunate consequence of this fact is that violation of the
> relevant restriction cannot be made a constraint violation, because the
> information needed to identify it as such might reside in an entirely
> different translation unit. Jacob's proposal does nothing to avoid that
> problem.

I just can't parse that, sorry. Can you provide an example?

My proposal wants to separate the usage of const to denote an 
unmodifiable object, and the usage of cost to say that the object will 
not be modified at the current scope but can be modified later, when it 
is returned to a higher scope. That's all.

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

#43386

Le 22/04/2014 23:26, Jens Thoms Toerring a écrit :
> There's no requirement that a constant of type 2) is in ROM.

Well, ROM is used here as READ ONLY memory.

For instance I can obtain a ROM under windows by manipulating the page 
properties and declare it read only. Under Unix there are equivalent 
system calls.

Even if physically they are not part of the ROM (as the addresses in the 
BIOS for instance) they *are* read only.

Of course, the compiler is free to leave that in RAM. The program should 
consider those objects as read only.

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

#43375

jacob navia wrote:

> After reading some of the contrbutions to the "constant strings" thread,
> I think that what is needed is a clarification of the underlying issues.
>
> There are TWO "uses" of const:
>
> 1) Declaring that a function will not modify its arguments
> 2) Declaring that an object resides in ROM (read only memory)
>
> The first one is tied to a *scope*. It says that within a certain scope,
> no modifications are done to some object. I would propose that we name
> this property "constant" and we would declare:
>
> char *strchr(constant char *buffer, int searchedChar);
>
> This means: "The strchr functions receives a buffeer that will NOT be
> modified within the scope of the function". This implies that inner
> scopes are required to maintain this feature. It means also that when we
> exitthe scope where this "constant" declaration is done, the object
> becomes writable again. Hence it is normal that strchr returns a *plain*
> char pointer. "constant" objects can't be returned as constant.
>
> The second meaning of const is the usual one and it is tied to an
> *object* not a scope. It means that the object can't be modified at
> *any* scope, it is an intrinsic property of the object.
>
> In my opinion many problems with "const" would disappear if we
> distinguish between these two usages of const.
>
> Feedback welcome.

I essentially agree with you on this. It has been a big problem in
embedded systems where you want to designate that some data
resides in ROM.

The second embedded system issue is it is possible to have
volatile ROM space where the contents is not known at
compile time but is fixed at run time. An example of this is
system calibration constants programmed in ROM or
serial numbers.

w..

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

#43378

jacob navia <jacob@spamsink.net> writes:

> After reading some of the contrbutions to the "constant strings"
> thread, I think that what is needed is a clarification of the
> underlying issues.
>
> There are TWO "uses" of const:
>
> 1) Declaring that a function will not modify its arguments

That's not well-worded.  No C function can modify it's arguments (as you
know) so const can't be used to mean that.  I know it seems fussy, but
if you are trying to clarify the issues, writing clearly is not a luxury.

> 2) Declaring that an object resides in ROM (read only memory)

I think "declaring" is the wrong word.  Some implementations make take
the fact that an object is declared "const" as a prompt to try to put it
in ROM, but all you are actually declaring (in the simplest case) is
that the name of the object is not a modifiable lvalue expression.

But here are some other uses of const:

  double cube_root(const double x) { ... }

  const int n_interations = atoi(argv[2]);

  struct atom {
    const char *const name;
    struct property *plist;
  };

These don't fit into either of your two cases.

> The first one is tied to a *scope*. It says that within a certain
> scope, no modifications are done to some object.

No, it's tied to the lvalue expression.  Other lvalue expressions may
permit the object to be modified in the same scope.  That would
certainly be unusual but, again, you are trying to be clear here.

Given that I disagree with the dichotomy you've set up, I don't really
want to comment on the conclusions you draw.  All the uses of const in C
look similar enough to be to be covered by the same keyword.

<snip>
-- 
Ben.

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

#43390

Le 23/04/2014 00:12, Ben Bacarisse a écrit :
> jacob navia <jacob@spamsink.net> writes:
>
>> After reading some of the contrbutions to the "constant strings"
>> thread, I think that what is needed is a clarification of the
>> underlying issues.
>>
>> There are TWO "uses" of const:
>>
>> 1) Declaring that a function will not modify its arguments
>
> That's not well-worded.  No C function can modify it's arguments (as you
> know) so const can't be used to mean that.  I know it seems fussy, but
> if you are trying to clarify the issues, writing clearly is not a luxury.
>

Well, if I pass a pointer (or an array) to a function, that function can 
modify its arguments and const is usually not used with scalar arguments 
since they are const anyway! <they are just copies of the data.

But yes, in principle you are right.

>> 2) Declaring that an object resides in ROM (read only memory)
>
> I think "declaring" is the wrong word.  Some implementations make take
> the fact that an object is declared "const" as a prompt to try to put it
> in ROM, but all you are actually declaring (in the simplest case) is
> that the name of the object is not a modifiable lvalue expression.
>
> But here are some other uses of const:
>
>    double cube_root(const double x) { ... }
>
>    const int n_interations = atoi(argv[2]);
>
>    struct atom {
>      const char *const name;
>      struct property *plist;
>    };
>
> These don't fit into either of your two cases.
>

In my opinion

double cube_root(const double x) { ... }

should be replaced with
double cube_root(constant double x) { ... }

meaning that within "cube_root" x will not be modified but outside it it 
can be modified.

The second example should also be "constant" since a value obtained from 
non constant data is not really const, just constant.

>> The first one is tied to a *scope*. It says that within a certain
>> scope, no modifications are done to some object.
>
> No, it's tied to the lvalue expression.  Other lvalue expressions may
> permit the object to be modified in the same scope.  That would
> certainly be unusual but, again, you are trying to be clear here.
>

Can't parse that. Can you provide an example?

An lvalue expression could be

*(p+5) = 'a';

Now what does that mean in this context?

> Given that I disagree with the dichotomy you've set up, I don't really
> want to comment on the conclusions you draw.  All the uses of const in C
> look similar enough to be to be covered by the same keyword.
>
> <snip>
>

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web