September 10, 2007 Re: Const sucks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jb | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russell Lewis | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Carlos Santander | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruce Adams | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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. |
Copyright © 1999-2021 by the D Language Foundation