"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d73o3h$14sr$1@digitaldaemon.com...
> Ownership (or owner) could be an attribute of chunk
> of memory in the heap. Only owner - object or module allocated
> the chunk can modify - write to it.
> Presumably ownership does not require notation change.
> Just new(owner) .... and someinstance.owner attribute.

The point of going to gc was to avoid having to keep track of ownership of memory. Down that lane leads to all the numbing complexity of C++ classes. Having to do an extra .dup now and then is a far lower cost than trying to keep track of ownership.

"Walter" <newshound@digitalmars.com> wrote in message news:d78dsk$2h4e$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d73o3h$14sr$1@digitaldaemon.com...
>> Ownership (or owner) could be an attribute of chunk
>> of memory in the heap. Only owner - object or module allocated
>> the chunk can modify - write to it.
>> Presumably ownership does not require notation change.
>> Just new(owner) .... and someinstance.owner attribute.
>
> The point of going to gc was to avoid having to keep track of ownership of memory. Down that lane leads to all the numbing complexity of C++ classes. Having to do an extra .dup now and then is a far lower cost than trying to keep track of ownership.

Depends how you measure cost. If it's in efficiency, simplicity, then you're right.

However, if it's in terms of robustness, confidence, then I think the case is anything but closed.

Matthew wrote:
> 
> Depends how you measure cost. If it's in efficiency, simplicity, then you're right.
> 
> However, if it's in terms of robustness, confidence, then I think the case is anything but closed.
> 

Two lines? TWO lines?

Wow! The new Matthew! ;-)

-JJR

"John Reimer" <brk_6502@yahoo.com> wrote in message news:d7a5g9$v8u$1@digitaldaemon.com...
> Matthew wrote:
>>
>> Depends how you measure cost. If it's in efficiency, simplicity, then you're right.
>>
>> However, if it's in terms of robustness, confidence, then I think the case is anything but closed.
>>
>
> Two lines? TWO lines?
>
> Wow! The new Matthew! ;-)

Sorry, mate. Just incredibly busy, all with C++-related things, atm. Am even not "lurking" on this ng. Just peeking in very infrequently. (I've now got 1892 unread messages on this ng. Probably be 4000 by the time I come back! <g>)

Matthew wrote:
> "John Reimer" <brk_6502@yahoo.com> wrote in message news:d7a5g9$v8u$1@digitaldaemon.com...
> 
>>Matthew wrote:
>>
>>>Depends how you measure cost. If it's in efficiency, simplicity, then you're right.
>>>
>>>However, if it's in terms of robustness, confidence, then I think the case is anything but closed.
>>>
>>
>>Two lines? TWO lines?
>>
>>Wow! The new Matthew! ;-)
> 
> 
> Sorry, mate. Just incredibly busy, all with C++-related things, atm. Am even not "lurking" on this ng. Just peeking in very infrequently. (I've now got 1892 unread messages on this ng. Probably be 4000 by the time I come back! <g>) 
> 
> 

No problem... I was just surprised that you showed such skill at brevity :-).  I noticed you haven't been around for awhile (I dare say you've even been missed ;-) ).

Life tends to get busy really fast, especially as things roll into summer.  It's the same here; it feels like I have a hundred things on the go right now.  Mixing work, family, and d is getting really challenging.  :-(

And where's Georg Wrede?  That good chap has been silent for awhile too.  I guess the sitution is the same for a lot of people.

-JJR

"Walter" <newshound@digitalmars.com> wrote in message news:d78dsk$2h4e$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d73o3h$14sr$1@digitaldaemon.com...
>> Ownership (or owner) could be an attribute of chunk
>> of memory in the heap. Only owner - object or module allocated
>> the chunk can modify - write to it.
>> Presumably ownership does not require notation change.
>> Just new(owner) .... and someinstance.owner attribute.
>
> The point of going to gc was to avoid having to keep track of ownership of memory. Down that lane leads to all the numbing complexity of C++ classes. Having to do an extra .dup now and then is a far lower cost than trying to keep track of ownership.
>

I understand the problem. And agree with you.

I am thinking about the 'owner' as sort of tag accessible through
ptr.owner or ptr.tag. D runtime does not need to account
it or interpret it in any way.
... some interesting idea is flying in the air, just need to catch it....

Andrew.

From C++ FAQs, 14.04:

"Does const allow the comiler to generate more efficient code?

Occasionally, but that's not the purpose of const. The purpose of const is correctness not optimization. That is, const helps the compiler find bugs, but it does not (normally) help the compiler generate more efficient code."


That pretty much tallies with my opinion. const is _entirely_ about expressing design, and obliging the compiler to enforce some of that design. It's attractions have _absolutely nothing_ to do with code optimisation. All that is just Walterganda, which, even though we understand his perspective/bias as a compiler writer, is flat out wrong, and misleads the design of D, for the worse.

FTR: Walter's the only C++ guru that I've ever heard talk in this way, and the only one who thinks it's a bad concept (some would accept it's not the best expressed in C++). Although I don't necessarily equate unanimity with rightness, I think it holds in this case. (All of which I've been saying to him in various forums for the last few years, so hold not thine breath for change.)


"Kris" <fu@bar.com> wrote in message news:d73t78$1ton$1@digitaldaemon.com...
> "Derek Parnell" <derek@psych.ward>
>> > One can write *cast(void *) 0 = 0; and the compiler does not stop you ~
> yet
>> > the compiler goes out of its way to catch array indexing errors. Surely
> the
>> > same approach could be applied here; yes?
>>
>> Seems consistent to me. But it must be made clear to coders that if the compiler does not report a read-only access error, it does not absolutely guarantee that the application is free of such problems; it just means
> that
>> the compiler didn't find any.
>
> Aye, sir. Nor does it guarantee the algorithms are correct <g>
>
> 

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:d7eepv$1bu1$1@digitaldaemon.com...
> From C++ FAQs, 14.04:
>
> "Does const allow the comiler to generate more efficient code?
>
> Occasionally, but that's not the purpose of const. The purpose of const is correctness not optimization. That is, const helps the compiler find bugs, but it does not (normally) help the compiler generate more efficient code."
>
>
> That pretty much tallies with my opinion. const is _entirely_ about expressing design, and obliging the compiler to enforce some of that design. It's attractions have _absolutely nothing_ to do with code optimisation. All that is just Walterganda, which, even though we understand his perspective/bias as a compiler writer, is flat out wrong, and misleads the design of D, for the worse.
>
> FTR: Walter's the only C++ guru that I've ever heard talk in this way, and the only one who thinks it's a bad concept (some would accept it's not the best expressed in C++). Although I don't necessarily equate unanimity with rightness, I think it holds in this case. (All of which I've been saying to him in various forums for the last few years, so hold not thine breath for change.)

Walter is demonstrating const-no-const position.
I've got a proposal from him to use .dup as an ultimate solution ...
I am still trying to get his joke right :)


>
>
> "Kris" <fu@bar.com> wrote in message news:d73t78$1ton$1@digitaldaemon.com...
>> "Derek Parnell" <derek@psych.ward>
>>> > One can write *cast(void *) 0 = 0; and the compiler does not stop you ~
>> yet
>>> > the compiler goes out of its way to catch array indexing errors. Surely
>> the
>>> > same approach could be applied here; yes?
>>>
>>> Seems consistent to me. But it must be made clear to coders that if the
>>> compiler does not report a read-only access error, it does not
>>> absolutely
>>> guarantee that the application is free of such problems; it just means
>> that
>>> the compiler didn't find any.
>>
>> Aye, sir. Nor does it guarantee the algorithms are correct <g>
>>
>>
>
> 

Firstly, I must admit that I haven't read this whole thread - so if this is OT for the thread, please let me know.  At least the subject is on topic.

As I understand it, one of the primary reasons that D doesn't support constness is because it is hard (impossible) for the compiler to actually enforce constness.

Reading the "final vs const" post I had a flash of something (perhaps insipration, perhaps I was just hungry); D supports DBC very well.  DBC is far more flexible than mere constness, so one of the things that could be enforced by DBC _is_ constness - at least at function entry/exit.
So since true constness is hard/impossible to implement, should D programmers perhaps adopt the idea that any place you really want constness, enforce it with DBC?

Am I making any sense at all?  Perhaps not, but oh well :)

Thanks
Brad

In article <d7i8pv$2a4k$1@digitaldaemon.com>, Brad Beveridge says...
>
>Firstly, I must admit that I haven't read this whole thread - so if this is OT for the thread, please let me know.  At least the subject is on topic.
>
>As I understand it, one of the primary reasons that D doesn't support constness is because it is hard (impossible) for the compiler to actually enforce constness.
>
>Reading the "final vs const" post I had a flash of something (perhaps
>insipration, perhaps I was just hungry); D supports DBC very well.  DBC
>is far more flexible than mere constness, so one of the things that
>could be enforced by DBC _is_ constness - at least at function entry/exit.
>So since true constness is hard/impossible to implement, should D
>programmers perhaps adopt the idea that any place you really want
>constness, enforce it with DBC?

See my reply to the "Java String vs wchar[]" thread :)


Seab