Community

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

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!

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.

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

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

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

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

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

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