View mode: basic / threaded / horizontal-split · Log in · Help
September 10, 2007
Re: Const sucks
"Janice Caron" <caron800@googlemail.com> wrote in message 
news:mailman.136.1189453181.16939.digitalmars-d@puremagic.com...
> Wow! Well, I'm happy! :-)
>
> I think I'll wait for the documentation before I comment further,

Am I the only one who though it odd that the current documentation spends 
twice as much time talking about C++ than it does about D? It's almost feels 
like the coverage of final and invariant were last minute additions just 
before handing it in for marking.
September 10, 2007
Re: Const sucks
On 9/10/07, Jb <jb@nowhere.com> wrote:
> Am I the only one who though it odd that the current documentation spends
> twice as much time talking about C++ than it does about D?

As of the start of this thread, the current documentation is out the window. :-)
September 10, 2007
Re: Const sucks
Russell Lewis wrote:
> Walter Bright wrote:
>> What we are trying to achieve:
>>
>> a) utility for functional programming
>> b) better modularity by self-documenting interfaces better
>> c) be able to treat reference types as if they were value types (i.e. 
>> strings should behave to the user like value types, even though they 
>> are references)
> 
> Is there a way to express (for a pointer passed as a function parameter) 
> "the callee is allowed to modify this object through the pointer, but 
> the caller ensures that no other code will be modifying it at the same 
> time"?   Sort of a "you have exclusive write access" modifier?  Is that 
> a common enough case to even support?
> 
> Russ

It would probably be easy enough to add such a type modifier, but 
literally impossible to to hold that restriction, so I don't think it's 
worth it. There's no magic-bullet for concurrency.

 - Gregor Richards
September 10, 2007
Re: Const sucks
Carlos Santander Wrote:

> Walter Bright escribió:
> > Const, final, invariant, head const, tail const, it's grown into a 
> > monster. It tries to cover all the bases, but in doing so is simply not 
> > understandable.
> > 
[snip]
> 
> > 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:
> > 
> >     macro x = 3;
> >     macro s = "hello";
> 
> Am I the only one who doesn't like this syntax? I guess it kinda makes sense, 
> but I just don't like how it looks.
> 
> -- 
> Carlos Santander Bernal

I'm not clear why this is even needed.
Surely "static const" implies some level of don't consume any memory by virtue of meaning "available at compile time". 
If you need more than that, rather than trusting the compiler then I second "inline" rather than macro, but honestly I can't think of an example where this will give you a worthwhile performance gain (unlike an inline function).

Regards,
        Bruce.
September 10, 2007
Re: Const sucks
Bill Baxter wrote:
> Nathan Reed wrote:
>> Carlos Santander wrote:
>>> Walter Bright escribió:
>>>> 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:
>>>>
>>>>     macro x = 3;
>>>>     macro s = "hello";
>>>
>>> Am I the only one who doesn't like this syntax? I guess it kinda makes
>>> sense, but I just don't like how it looks.
>>>
>> 
>> Seems to me like this unnecessarily departs from the macro syntax
>> introduced at the conference:
>> 
>> macro foo(e) { e = 3; }
>> 
>> (On the other hand, in one of them the macro is for an expression while
>> in the other one it's a sequence of declarations/statements.  So maybe
>> it is reasonable to have the different syntax.)
> 
> It's not far off from things used in some functional programming
> languages, so it doesn't look to bad to me.  The word 'macro' typically
> implies a direct, maybe even textual, substitution.  It's also a lot
> like #define, just with an '=' there which I think is an improvement
> over #define.  '=' for the no-arg macros, '{ }' for the arg-ful macros.
>   Seems ok to me.

And let's take another step forward (might scare off some old C farts,
though, but I like it):

T sum(T)(T a, T b) = a + b;

For consistency's sake! :D
September 10, 2007
Re: Const sucks
On Mon, 10 Sep 2007 12:55:29 -0700, Gregor Richards wrote:

> Derek Parnell wrote:
>>> o  const and invariant now mean "fully const" and "fully invariant", 
>>> where fully means "head and tail combined":
>> 
>> Remind me again what the difference between 'const' and 'invariant' is.
> 
> const: I promise not to change this, but acknowledge that somebody else 
> might.
> 
> invariant: Neither I nor anyone else will change this.
> 
> const has a more limited use for optimization than invariant, since the 
> value could be changed by other threads/programs-with-shm/whatever from 
> under you.
> 
>   - Gregor Richards
> 
> PS: Or at least, this is my understanding :)

Thank you. I do rememeber now ... silly how I couldn't get that from the
keywords.

'const' is sort of a locally write protected.
'invariant' is globally write protected.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
September 10, 2007
Re: Const sucks
Janice Caron wrote:
>> const int* p = &x;  // neither p nor *p can be changed
>> const(int*) p = &x;  // neither p nor *p can be changed
> 
> Two ways of writing the same thing. I don't understand the need for
> the bracketless version. Could we not just insist that the brackets
> must always be there? Or does the lack of brackets actually mean
> something? (if it does, it's back to being confusing again).

The bracketless version is for two reasons:

1) it's what people expect to have to type, for example:

	void foo(const T t) { }

It will be the most common case.

2) it enables things like:

	const
	{
		int a = 3;
		int b = 4;
	}

which is nice for a grouped collection of them.
September 10, 2007
Re: Const sucks
Bruce Adams wrote:
>>> 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:
>>> 
>>> macro x = 3; macro s = "hello";
> I'm not clear why this is even needed. Surely "static const" implies
> some level of don't consume any memory by virtue of meaning
> "available at compile time". If you need more than that, rather than
> trusting the compiler then I second "inline" rather than macro, but
> honestly I can't think of an example where this will give you a
> worthwhile performance gain (unlike an inline function).

windows.h in all its terrifying glory has 10,000 macro declarations. If 
each one occupied 4 bytes of static data, there's 40K of bloat in every exe.
September 10, 2007
Re: Const sucks
Walter Bright wrote:
> Bruce Adams wrote:
>>>> 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:
>>>>
>>>> macro x = 3; macro s = "hello";
>> I'm not clear why this is even needed. Surely "static const" implies
>> some level of don't consume any memory by virtue of meaning
>> "available at compile time". If you need more than that, rather than
>> trusting the compiler then I second "inline" rather than macro, but
>> honestly I can't think of an example where this will give you a
>> worthwhile performance gain (unlike an inline function).
> 
> windows.h in all its terrifying glory has 10,000 macro declarations. If 
> each one occupied 4 bytes of static data, there's 40K of bloat in every 
> exe.

That sounds about right.  When we converted const values to enum values 
in the Tango Win32 headers, app size dropped by roughly 46k.  But there 
were issues with some of those enum values having the wrong type (-1 set 
to int instead of uint), which led to a few strange bugs.


Sean
September 10, 2007
Re: Const sucks
Derek Parnell wrote:
> Remind me again what the difference between 'const' and 'invariant'
> is.

'const' means a I can't change it (but someone else can, such as someone
in a different thread). 'invariant' means nuttin' can change it, not
no-how, not no-way.


> What do these below mean ...
> 
> const int (* p)

syntax error

> const int *(p)

syntax error

> const int (*) p

syntax error

Imagine if const were a template called Const, and we used that template
to form a new type that was const of the old type. We'd invoke it like:
	Const!(T) t;
Now, just s/Const!/const/, and the syntax should make sense.


>> o  tail const of a struct would have to be done by making the
>> struct a template:
>> 
>> struct S(T) { T member; } S!(int)   // tail mutable S!(const(int))
>> // tail const
> 
> But most structs contain multiple members, and usually of different
> types.

That's up to the struct designer.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home