const or constant?

[Keith Thompson]

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

Le 23/04/2014 17:40, Keith Thompson a écrit :

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.

 

[Stefan Ram]

That's what C++ constexpr supports.

»constexpr« in C++ marks entities whose value is known or
can be calculated at compile time.

 

[Ian Collins]

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

 

[Stefan Ram]

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.

 

[Ian Collins]

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

 

[Malcolm McLean]

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

 

[David Brown]

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.

 

[James Kuyper]

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.

 

[David Brown]

On 04/24/2014 02:50 AM, David Brown wrote:
...

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.

 

[glen herrmannsfeldt]

(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

 

[Malcolm McLean]

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.