const or constant?

Discussion in 'C Programming' started by jacob navia, Apr 22, 2014.

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

    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

    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, Apr 23, 2014
    1. Advertisements

  2. jacob navia

    Stefan Ram Guest

    »constexpr« in C++ marks entities whose value is known or
    can be calculated at compile time.
    Stefan Ram, Apr 23, 2014
    1. Advertisements

  3. jacob navia

    Ian Collins Guest

    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, Apr 23, 2014
  4. jacob navia

    Stefan Ram Guest

    [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.
    Stefan Ram, Apr 23, 2014
  5. jacob navia

    Ian Collins Guest

    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, Apr 23, 2014
  6. 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.
    Malcolm McLean, Apr 24, 2014
  7. jacob navia

    David Brown Guest

    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.
    David Brown, Apr 24, 2014
  8. jacob navia

    James Kuyper Guest

    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.
    James Kuyper, Apr 24, 2014
  9. jacob navia

    David Brown Guest

    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

    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.
    David Brown, Apr 24, 2014
  10. (snip)
    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
    glen herrmannsfeldt, Apr 24, 2014
  11. 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.
    Malcolm McLean, Apr 25, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.