July 04, 2006 Re: so what exactly is const supposed to mean? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | Don Clugston wrote:
> Bruno Medeiros wrote:
>
>> D's const has two meanings. The usual meaning is from the form:
>> const int var = <some constant initializer>;
>> and it means that the variable is a compile-time constant and no storage is allocated for it, instead the value is substituted whenever the var is used (like #define, but safer).
>>
>> The second meaning is from the form:
>> const int var; // no initializer
>> and means that the var must be initialized once in a constructor, and then it becomes non-recursively immutable (meaning you can't change the value of the var, but you can change referenced values). The var has storage and as such is an lvalue.
>> This is basically the same as final in other languages (Java, C#), and I wonder why it isn't in D as well(?). Walter said he didn't want a const keyword overloaded with many different meanings.
>
>
> I agree. I think it's a mistake to have a 'const' that isn't actually const! 'final' seems far more appropriate.
>
We do have a 'final' keyword in D already. Applied to a class decleration it describes a class which may not be inherited from. Applied to class member function (method) declerations, it means a member which may not be overriden. So far as I am aware, it is meaningless anywhere else. Since 'final' in D currently means, in over-generalized terms, "this cannot be replaced," I don't think it would be much of a stretch to use 'final' to mean what 'const' currently does.
-- Chris Nicholson-Sauls
|
July 04, 2006 Re: so what exactly is const supposed to mean? | ||||
---|---|---|---|---|
| ||||
Posted in reply to kris | kris wrote:
>
> Yes, it does sounds very familiar -- to take full advantage of specific hardware you may need to step away from the 'norm'. Whatever that 'norm' may be. No surprise then, that it pays to keep an open mind?
>
> You won't hear any argument from me regarding the typical multithreading "paradigm" ... and there are most certainly more effective methods in one manner or another ... there have been for 30 years ... *shrug*
>
> If you intend to go on a crusade, to change the face of multithreading as we currently know and "love" it, I'll sign right up :D
>
> But, again, the state of immutability is *not* married to multithreading -- it just happens to be particularly useful there too :p
>
>
>
Crusade? LoL.
I can barely work on my own projects with my daughters(1 and 3 yrs).
My point was simply that const isn't the 'pot of gold' its made out to be(at least in the form espoused thus far).
1. Tiny multithreaded advantages.
2. Limited optimization benefits.
3. Some memory optimizations for structs(call by reference).
Changing the whole language for the above just does seem like good investment vs return.
Cheers
-David
|
July 04, 2006 Re: so what exactly is const supposed to mean? | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Medlock | David Medlock wrote: > kris wrote: >> >> Yes, it does sounds very familiar -- to take full advantage of specific hardware you may need to step away from the 'norm'. Whatever that 'norm' may be. No surprise then, that it pays to keep an open mind? >> >> You won't hear any argument from me regarding the typical multithreading "paradigm" ... and there are most certainly more effective methods in one manner or another ... there have been for 30 years ... *shrug* >> >> If you intend to go on a crusade, to change the face of multithreading as we currently know and "love" it, I'll sign right up :D >> >> But, again, the state of immutability is *not* married to multithreading -- it just happens to be particularly useful there too :p >> >> >> > Crusade? LoL. > I can barely work on my own projects with my daughters(1 and 3 yrs). What you mean? They can't code yet? ;) > > My point was simply that const isn't the 'pot of gold' its made out to be(at least in the form espoused thus far). > > 1. Tiny multithreaded advantages. > 2. Limited optimization benefits. > 3. Some memory optimizations for structs(call by reference). > > Changing the whole language for the above just does seem like good investment vs return. > > Cheers > -David I believe you downplay those points too much, particularly the multithreaded advantages. You did also forget the most important point, IMO: If you as a library writer or application writer care about the integrity of your data (very often you have to, as this might be necessary to guarantee correct operation), then you need to make sure that users of the library, or other threads don't modify the data in ways that breaks this integrity. Since D actually aims to make it easier to create safer software, strong immutability enforcement, however it is implemented (the logical const from C++ do seem like a somewhat dead end), is a must. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi |
July 04, 2006 Re: so what exactly is const supposed to mean? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | Bruno Medeiros wrote: > Sean Kelly wrote: >> Bruno Medeiros wrote: >>> >>> There is a slight difference from D's const and a const that places the data in ROM as you cannot get the address of a D const var (it's not an lvalue). >> >> Ever tried taking the address of a const string? That you can't take the address of other const types is simply a result of optimization. >> > > I tried it now, and the const string also can't be taken an address from: > > const char[] str = "ABC"; > > void func() > { > *(&str) = "123"; // : "ABC" is not an lvalue > } That's interesting. I would have expected all strings to live in a static data segment. And in fact they seem to, though initialization seems to happen in a slightly weird manner: const char[] str = "ABC"; void main() { printf( "%.*s\n", str ); } generates: _DATA segment db 041h,042h,043h,000h,000h,000h,000h,000h _D4test3strAa: db 003h,000h,000h,000h dd offset FLAT:_DATA db 041h,042h,043h,000h,000h,000h,000h,000h db 003h,000h,000h,000h dd offset FLAT:_D4test3strAa[8] db 025h,02eh,02ah,073h,00ah,000h _DATA ends CONST segment CONST ends _BSS segment _BSS ends __Dmain comdat assume CS:__Dmain L0: push dword ptr _D4test3strAa[014h] push dword ptr _D4test3strAa[010h] push offset FLAT:_D4test3strAa[018h] call near ptr _printf xor EAX,EAX add ESP,0Ch ret __Dmain ends Notice that "041h,042h,043h" exists both by itself as a literal and within the static initializer for 'str'. Notice also that 'str' does indeed live within a static data segment. I'm not entirely certain why the literal isn't optimized away, however, as it's only ever used for initializing 'str'. Sean |
July 04, 2006 Re: so what exactly is const supposed to mean? | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Medlock | David Medlock wrote: > kris wrote: >> >> Yes, it does sounds very familiar -- to take full advantage of specific hardware you may need to step away from the 'norm'. Whatever that 'norm' may be. No surprise then, that it pays to keep an open mind? >> >> You won't hear any argument from me regarding the typical multithreading "paradigm" ... and there are most certainly more effective methods in one manner or another ... there have been for 30 years ... *shrug* >> >> If you intend to go on a crusade, to change the face of multithreading as we currently know and "love" it, I'll sign right up :D >> >> But, again, the state of immutability is *not* married to multithreading -- it just happens to be particularly useful there too :p >> >> >> > Crusade? LoL. > I can barely work on my own projects with my daughters(1 and 3 yrs). > > My point was simply that const isn't the 'pot of gold' its made out to be(at least in the form espoused thus far). > > 1. Tiny multithreaded advantages. > 2. Limited optimization benefits. > 3. Some memory optimizations for structs(call by reference). > > Changing the whole language for the above just does seem like good investment vs return. > > Cheers > -David I'm assuming you meant "just doesn't seem like" up there. The form exposed so far isn't all, const isn't just for multithreading apps: An immutability mechanism is great for ownership management, better than CoW because, like Kris said, the program becomes more expressive and there is more that the compiler can check and enforce (and it prevents redundant duping/cloning). -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D |
July 05, 2006 Re: so what exactly is const supposed to mean? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | Sean Kelly wrote: > Bruno Medeiros wrote: >> Sean Kelly wrote: >>> Bruno Medeiros wrote: >>>> >>>> There is a slight difference from D's const and a const that places the data in ROM as you cannot get the address of a D const var (it's not an lvalue). >>> >>> Ever tried taking the address of a const string? That you can't take the address of other const types is simply a result of optimization. >>> >> >> I tried it now, and the const string also can't be taken an address from: >> >> const char[] str = "ABC"; >> >> void func() >> { >> *(&str) = "123"; // : "ABC" is not an lvalue >> } > > That's interesting. I would have expected all strings to live in a static data segment. And in fact they seem to, though initialization seems to happen in a slightly weird manner: > Yes, they have to live in a static data segment. But does that change anything? The value of "ABC" is already the address of the string, thus &"ABC" is not valid. (akin to &(&somevar) ) -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D |
Copyright © 1999-2021 by the D Language Foundation