September 11, 2007
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
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
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
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
> 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
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
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
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
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
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