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 2 of 2 — ← Prev page 1 [2]

#43425

jacob navia <jacob@spamsink.net> writes:

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

It's a common shorthand, but it really confuses many people.  C's
argument passing is nice and simple: pass by value, always.  I'll still
say that you "pass a string to strlen" but in a detailed discussion
about language semantics that's all wrong!

>>> 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';

(that's not an lvalue expression, but I know what you mean -- an lvalue
expression ('*(p+5)') is being used to modify some objecet.)

> Now what does that mean in this context?

You said:

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

I was just making a correction.  In this silly example:

  static int total_count;

  void show_counters(const int *counter)
  {
      total_count += 1;
      printf("%d %d\n", *counter, total_count);
  }
  ...

     inc_counters(&total_count);

the object is modified in the scope of counter.  You just made too
general a remark: no modifications are done to some object using the
pointer whose target is const qualified, but other lvalue expressions
may be able to modify it, even in the same scope.  Rather that talk
about scope, I'd say your first form is a restriction on what you can do
with certain expressions.  There is no guarantee that the object pointed
to won't change in any particular scope.

>> Given that I disagree with the dichotomy you've set up, I don't really
>> want to comment on the conclusions you draw.

The confusion was significant here in that I completely missed what it
was you were saying.  Sorry about that.  Thanks to James's remark, I do
now see the distinction you want to make, though I am not sure you've
made a string case for enshrining it in a new keyword.

Presumably, your new 'constant' can also be used to qualify the target
of a pointer type.  That would introduce new possibilities that can't
easily be written with const.  void f(constant int *ip) would not be the
same as void f(const int *ip).

<snip>
-- 
Ben.

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

#43432

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> Presumably, your new 'constant' can also be used to qualify the target
> of a pointer type.  That would introduce new possibilities that can't
> easily be written with const.  void f(constant int *ip) would not be the
> same as void f(const int *ip).

I'm not entirely sure what distinction is being made (the person
making the suggestion is in my killfile), but I think adding a new
"constant" keyword in addition to the existing "const" would be a
bad way to express it.

There's already a great deal of confusion between "const" (meaning
read-only) and "constant" (meaning, in most cases, evaluated at
compile time).  Adding a "constant" keyword that *also* doesn't
mean the same thing as the word "constant" as used in the standard
would just make that worse.

I offer no opinion on whether there's a useful distinction here,
worth adding a new keyword.  I merely suggest using a different
keyword.

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

#43456

Le 23/04/2014 17:40, Keith Thompson a écrit :
> the person
> making the suggestion is in my killfile

At each of the threads I start, Kiki will repeat the same lie.

What is  the purpose of his killfile if he participates to all the 
threads I start?

BINGO!

To repeat that I am in his killfile of course!

I could forget that important fact.

Thanks kiki

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

#43459

On 2014-04-23, jacob navia <jacob@spamsink.net> wrote:
> Le 23/04/2014 17:40, Keith Thompson a écrit :
>> the person
>> making the suggestion is in my killfile
>
> At each of the threads I start, Kiki will repeat the same lie.

How does he know whether the person making the suggestion is in his killfile?

Must be that somehow the person is there, but not the suggestion.

Ah, but the "X" in "X in my killfile" is normally understood to be a metonymy
for "X's textual output".  Just like "I listen to Bach" actually means "I
listen to recordings of Bach's works", not that I have a channel into the
past that lets me listen to the man himself.

"The Usenet-published written works of that person who made the written
suggestion in a Usenet article are in my killfile. Err ..., I mean, *what*
suggestion? Someone made a suggestion?"

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

#43467 — [OT] Killfiles (was Re: const or constant?)

[This post is off-topic.  Feel free to skip if you're not interested]

jacob navia <jacob@spamsink.net> writes:
> Le 23/04/2014 17:40, Keith Thompson a écrit :
>> the person
>> making the suggestion is in my killfile
>
> At each of the threads I start, Kiki will repeat the same lie.
>
> What is  the purpose of his killfile if he participates to all the
> threads I start?
>
> BINGO!
>
> To repeat that I am in his killfile of course!
>
> I could forget that important fact.
>
> Thanks kiki

jacob, this is the first time I've responded to you here in several
years, and I expect it to be the last time for long while.  If you
wish to discuss anything with me, you can e-mail me; it's likely
I'll reply.

You appear to have misunderstood a few things.

I've chosen to respond just this once because your obsession
with me appears to be unabated, and perhaps I can clear up some
misconceptions.

Yes, you are in my killfile.  Strictly speaking, it's a scorefile,
the mechanism that my newsreader uses for the same purpose.
That doesn't necessarily mean I never read anything you post.
Whether I do so or not, and the circumstances in which I do so,
are not things I care to discuss at the moment.  Obviously I happen
to have read your above-quoted post.

My killfile/scorefile applies to your posts, not to all posts in
threads that you happen to start.  I feel free to participate in any
such threads or not, as I choose, regardless of who started them.
My reply was to a post by Ben Bacarisse, in which he mentioned
something that you had proposed.  I mentioned in passing that you
are in my killfile to explain why I was unfamiliar with the details
of what you had proposed.

I had no particular intention of reminding you that you're in
my killfile.  The purpose of my followup to Ben was to make
a technical point about something he said (that happened to be
related to something you had proposed).  I wasn't talking to you.

You may or may not post a followup to this.  I may or may not
read it.  Do not expect any further reply.

Everyone else: Sorry if I've wasted your time with this.

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

#43489 — Re: [OT] Killfiles (was Re: const or constant?)

On Wednesday, April 23, 2014 10:49:13 PM UTC+1, Keith Thompson wrote:
> [This post is off-topic.  Feel free to skip if you're not interested]
> 
Generally it's best to keep your killfile private.
If people know that they're in it, they might react by trying to get a response.
If you announce that a poster is killfiled, others may suspect that you are the
one trying to provoke a response. Then you might want to make an exception
for a particular post, or you might be using another interface to Usenet,
which can lead to the person killfiled proclaiming a triumph if he is
known to be read.

I'm not against killfiles. If someone is irritating or upsetting you, it's
often best to simply filter them out. But what you choose to read is
essentially your own business.

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

#43421

On 04/22/2014 06:12 PM, Ben Bacarisse wrote:
> 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.

It would be more accurate to say that when a function takes a parameter
of type "pointer to const T", the function cannot modify the things the
pointer points at, except by casting away the 'const'.
It would be more useful to point out that this applies to any "pointer
to const T", regardless of whether it is a function parameter.
With those modifications, Jacob has in fact identified an aspect of
'const' that is distinct from the other aspect (though he described it
poorly).

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

No, you're also declaring that the object's value cannot be modified
with defined behavior, not even by use of an lvalue that is not
const-qualified (6.7.3p6)

> But here are some other uses of const:
> 
>   double cube_root(const double x) { ... }

That's an example of Jacob's second case (covered by 6.7.3p6)

>   const int n_interations = atoi(argv[2]);
> 
>   struct atom {
>     const char *const name;

That is an example of Jacob's second meaning. It also is an example of
the same feature that Jacob's first meaning describes, except that it
occurs outside of a function parameter list.
-- 
James Kuyper

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

#43466

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)

That's what C++ constexpr supports.  Why invent yet another wheel when 
there is one already there?

-- 
Ian Collins

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

#43469

Stefan Ram wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>>> 1) Declaring that a function will not modify its arguments
>>> 2) Declaring that an object resides in ROM (read only memory)
>> That's what C++ constexpr supports.
>
>    »constexpr« in C++ marks entities whose value is known or
>    can be calculated at compile time.

Correct.  It goes further in guaranteeing the value is generated at 
compile time.  It is this guarantee that enables constexpr values to be 
stored in read only memory.

-- 
Ian Collins

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

#43472

Stefan Ram wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> Stefan Ram wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>>> 1) Declaring that a function will not modify its arguments
>>>>> 2) Declaring that an object resides in ROM (read only memory)
>>>> That's what C++ constexpr supports.
>>> »constexpr« in C++ marks entities whose value is known or
>>> can be calculated at compile time.
>> Correct.  It goes further in guaranteeing the value is generated at
>> compile time.  It is this guarantee that enables constexpr values to be
>> stored in read only memory.
>
>    [OT: this is about "constexpr" in C++]
>
>    Some constexpr values are not stored at runtime at all.
>
>    For example:
>
> #include <iostream>
> #include <ostream>
>
> constexpr int factorial( int const i )
> { return i > 0 ? i * factorial( i - 1 ): 1; }
>
> int main(){ constexpr int i = factorial( 5 );
>    if( i < 5 )::std::cout<< "alpha\n"; }
>
>    A C++ compiler with some optimizations enabled
>    should compile the above program to the same as:
>
> int main() {}
>
>    . There are variables and values in the source code,
>    but nothing is stored at runtime.

Well what else would you expect in that example?  All you have done with 
constexpr is helped the compiler with its optimisation.

If i were required to be visible outside of main, it would have to exist 
and would be in read only memory (which might be as a literal constant 
the in the executable code).

-- 
Ian Collins

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web