View mode: basic / threaded / horizontal-split · Log in · Help
September 11, 2007
Re: Const sucks
Steven Schveighoffer wrote:
> Second, I'm trying to understand what the real purpose of this is.  Could 
> someone define the different types of memory and why we need different 
> declarations to put things in those different types?  For example, "doesn't 
> consume memory" doesn't make sense to me.  The bytes gotta go somewhere!

For numeric constants which are known at compile time, there's not 
necessarily a location in the executable's data-sections where they are 
stored; they may just be incorporated as immediate values into the 
machine instructions, and/or folded into other expressions at compile 
time.  (For string constants known at compile time they are still going 
to have to be stored in the executable image.)

However, if you ever take the address of such a constant it needs to 
actually be stored.  For a regular declaration of a const variable, the 
compiler can optimize away the stored version if it can determine that 
the address is never taken, but this often isn't possible (think of 
class member variables - the compiler can't guarantee that no client 
code will ever take the address).  On the other hand it would be illegal 
to take the address of a macro.

Thanks,
Nathan Reed
September 11, 2007
Re: Const sucks
On 9/10/07, Walter Bright <newshound1@digitalmars.com> wrote:
> o  const/invariant declarations will always allocate memory (so their
> addresses can be taken)

I'd hadn't really thought about this before. But now I have.

I want to be able to *express the idea* that the value I am declaring
shall never change. To my mind:

const int NUM_DAYS_IN_WEEK = 7;

successfully expresses that idea, and frankly, I whether or not
NUM_DAYS_IN_WEEK consumes memory should not be my call. That is an
implementation detail, and should be the compiler's problem, not mine.


> o  So, we still need a method to declare a constant that will not
> consume memory. We'll co-opt the future macro syntax for that:

Isn't that a bit like "register" or "inline"? Those keywords went the
way of the dodo because it was decreed that the compiler could do a
better job at figuring out what to inline or put in registers than the
programmer ever could.

Isn't this the same? Surely, the compiler can make the decision as to
whether or not the value gets stored in memory. Why should I have to?

If the program does not take the address, and if sizeof the variable
is sufficiently small, then don't store in memory, otherwise do. If
it's a library and you don't know what the calling code will do, let
the compiler take its best guess. If it guesses wrongly, then either a
few bytes of memory will have been consumed, or some jiggery pokery
will be required at the call site. But either way, don't make the
programmer choose.


> macro x = 3;
> macro s = "hello";

And bang goes type safety, right there!
September 11, 2007
Re: Const sucks
On 9/11/07, Nathan Reed <nathaniel.reed@gmail.com> wrote:
> For a regular declaration of a const variable, the
> compiler can optimize away the stored version if it can determine that
> the address is never taken, but this often isn't possible (think of
> class member variables - the compiler can't guarantee that no client
> code will ever take the address).

Then just decree that it be illegal to take the address of a const
class member variable. Problem solved.

What's wrong with:

class C
{
    const int X = 42; /* not stored; address may not be taken */
    static int Y = 42; /* consumes memory; address may be taken */
}


I dislike your macro idea, because I want my consts to have a type. I
/like/ type safety, and I want to keep it. I want my constants to be
of the type I declare them to be, not just a piece of text.
September 11, 2007
Re: Const sucks
Janice Caron wrote:
> I dislike your macro idea, because I want my consts to have a type. I
> /like/ type safety, and I want to keep it. I want my constants to be
> of the type I declare them to be, not just a piece of text.

Hmmmm... if I got that right, macros will definitely *not* be "pieces
of text", but abstract syntax trees.
So, if you'd do "macro x=5;" (or whatever the macro syntax will be),
and you try `char[] s="abc"~x;` you'll get a nice, clean type error.

	As you liek it! :)

regards, Frank
September 11, 2007
Re: Const sucks
> Hmmmm... if I got that right, macros will definitely *not* be "pieces
> of text", but abstract syntax trees.

Macros have their place. I'm not knocking them. But they're not the
right mechanism for declaring constants. On the other hand,

const Type name = value;
is.

(replace const with static if necessary - see earlier in thread).

Of course, it really should be
invariant Type name = value;

with the current keywords, though if we switch from invariant/const to
const/readonly that mistake will likely disappear.


> So, if you'd do "macro x=5;" (or whatever the macro syntax will be),
> and you try `char[] s="abc"~x;` you'll get a nice, clean type error.

Looks the same as C to me.

#define x 5
strcat(s,"abc");
strcat(s,x); /* compile error */

That doesn't count as strong typing.
September 11, 2007
Re: Const sucks
Janice Caron wrote:
>> Hmmmm... if I got that right, macros will definitely *not* be "pieces
>> of text", but abstract syntax trees.
> 
> Macros have their place. I'm not knocking them. But they're not the
> right mechanism for declaring constants. On the other hand,
> 
> const Type name = value;
> is.
> 
> (replace const with static if necessary - see earlier in thread).
> 
> Of course, it really should be
> invariant Type name = value;
> 
> with the current keywords, though if we switch from invariant/const to
> const/readonly that mistake will likely disappear.
> 
> 
>> So, if you'd do "macro x=5;" (or whatever the macro syntax will be),
>> and you try `char[] s="abc"~x;` you'll get a nice, clean type error.
> 
> Looks the same as C to me.
> 
> #define x 5
> strcat(s,"abc");
> strcat(s,x); /* compile error */
> 
> That doesn't count as strong typing.

You're jumping to conclusions here.  I doubt _very_ much that Walter 
plans to implement macro like #define in C.  Especially after all the 
trouble he went through to remove the preprocessor completely.

Regan
September 11, 2007
Re: Const sucks
Janice Caron wrote:
> On 9/11/07, Nathan Reed <nathaniel.reed@gmail.com> wrote:
>> For a regular declaration of a const variable, the
>> compiler can optimize away the stored version if it can determine that
>> the address is never taken, but this often isn't possible (think of
>> class member variables - the compiler can't guarantee that no client
>> code will ever take the address).
> 
> Then just decree that it be illegal to take the address of a const
> class member variable. Problem solved.

That places totally unnecessary restrictions on the programmer...there's 
absolutely no reason why you shouldn't be able to take the address of 
something const.

> I dislike your macro idea, because I want my consts to have a type. I
> /like/ type safety, and I want to keep it. I want my constants to be
> of the type I declare them to be, not just a piece of text.

It's not /my/ macro idea. :)  (For the record, I don't really like the 
idea of using the macro keyword for this, either.)  Although, as other 
people have pointed out, this doesn't break type safety, just makes the 
type not explicitly stated in the code.

Thanks,
Nathan Reed
September 11, 2007
Re: Const sucks
Janice Caron wrote:
> I want to be able to *express the idea* that the value I am declaring
> shall never change. To my mind:
> 
> const int NUM_DAYS_IN_WEEK = 7;
> 
> successfully expresses that idea, and frankly, I whether or not
> NUM_DAYS_IN_WEEK consumes memory should not be my call. That is an
> implementation detail, and should be the compiler's problem, not mine.

Agree.

Thanks,
Nathan Reed
September 11, 2007
Re: Const sucks
On 9/11/07, Janice Caron <caron800@googlemail.com> wrote:
> What's wrong with:
>
>  class C
>  {
>      const int X = 42; /* not stored; address may not be taken */
>      static int Y = 42; /* consumes memory; address may be taken */
> }

Of course, I actually meant:

class C
{
    const int X = 42; /* not stored; address may not be taken */
    static const int Y = 42; /* consumes memory; address may be taken */
}

The point being that for constant data to consume memory
*per-class-instance* is silly.
September 11, 2007
Re: Const sucks
Nathan Reed wrote:
> Janice Caron wrote:
>> On 9/11/07, Nathan Reed <nathaniel.reed@gmail.com> wrote:
>>> For a regular declaration of a const variable, the
>>> compiler can optimize away the stored version if it can determine that
>>> the address is never taken, but this often isn't possible (think of
>>> class member variables - the compiler can't guarantee that no client
>>> code will ever take the address).
>>
>> Then just decree that it be illegal to take the address of a const
>> class member variable. Problem solved.
> 
> That places totally unnecessary restrictions on the programmer...there's 
> absolutely no reason why you shouldn't be able to take the address of 
> something const.
> 
>> I dislike your macro idea, because I want my consts to have a type. I
>> /like/ type safety, and I want to keep it. I want my constants to be
>> of the type I declare them to be, not just a piece of text.
> 
> It's not /my/ macro idea. :)  (For the record, I don't really like the 
> idea of using the macro keyword for this, either.)  Although, as other 
> people have pointed out, this doesn't break type safety, just makes the 
> type not explicitly stated in the code.

In that way it's a bit like 'auto'

Regan
6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home