• Andrew Fedoniouk (43/43) May 25 2005 Constness is not only about possible bugs or ROM placement of variables ...
• Kris (13/56) May 25 2005 I'm a strong advocate for what you describe, but it may be better to tal...
• Andrew Fedoniouk (17/90) May 25 2005 Kris, I agree with you that "read-only" is better.
• Walter (6/11) May 27 2005 The point of going to gc was to avoid having to keep track of ownership ...
• Matthew (3/14) May 27 2005 Depends how you measure cost. If it's in efficiency, simplicity, then yo...
• John Reimer (4/9) May 28 2005 Two lines? TWO lines?
• Matthew (3/11) May 28 2005 Sorry, mate. Just incredibly busy, all with C++-related things, atm. Am ...
• John Reimer (11/29) May 28 2005 No problem... I was just surprised that you showed such skill at brevity...
• Andrew Fedoniouk (8/19) May 29 2005 I understand the problem. And agree with you.
• Derek Parnell (33/81) May 25 2005 One could consider this as just a syntax or implementation issue. The
• Andrew Fedoniouk (36/118) May 25 2005 Constantness is not about can I or cannot fool the compiler (I can full ...
• Derek Parnell (10/12) May 25 2005 Yeah, I know that Andrew.
• Kris (12/15) May 25 2005 Au Contraire, sir;
• Derek Parnell (15/32) May 26 2005 I agree that a compiler can catch 'normal' references. It was the absurd...
• Kris (5/12) May 26 2005 the
• Matthew (13/27) May 30 2005 From C++ FAQs, 14.04:
• Andrew Fedoniouk (5/45) May 30 2005 Walter is demonstrating const-no-const position.
• Brad Beveridge (15/15) May 31 2005 Firstly, I must admit that I haven't read this whole thread - so if this...
• Sean Kelly (3/15) May 31 2005 See my reply to the "Java String vs wchar[]" thread :)
• Brad Beveridge (4/28) May 31 2005 Your reply is much more concrete than mine.
• Matthew (11/28) May 31 2005 Unfortunately, one of the tenets of Contract Programming (formerly
• Sean Kelly (5/14) Jun 01 2005 But const correctness can be verified, somewhat, using DbC and a lot of
• Sam (9/9) May 26 2005 Come to think of it, 'const's were never always guaranteed in C++ becaus...

"Andrew Fedoniouk" <news terrainformatica.com> writes:

Constness is not only about possible bugs or ROM placement of variables as 
Kris rightly mentioned.
It is also about effectiveness and robustness of code and especially 
libraries - components.

Example:
I have a class:

class Url
{
    char[] _domain;
    char[] _filename;
    char[] _protocol;

    static Url parse( char[] url )
   {
       char[] buffer = unescape(url); // will always dup
       _domain = buffer[a..b];
       _filename = buffer[b..c];
       _protocol = buffer[c..d];
   }
   // current implementation
   char[] domain()        { return _domain.dup; }
   char[] filename()     { return _filename.dup; }
   char[] protocol()    { return _protocol.dup; }

   // this is extremely nice to have
   char[]:const  domain()      { return _domain; }
   char[]:const  filename()     { return _filename; }
   char[]:const  protocol()     { return _protocol; }
}

As you may see without const typical and robust library
implementation  approach follows to constant "joy of GC"
as  I ***must*** do 'dup' in
char[] domain()  { return _domain.dup; }
if I want my son to reuse my code.

If you think that this example is too abstract then
take a look into std/string.d  and comments in function:

char* toStrings(char[] s)
 /+ Unfortunately, this isn't reliable....

This is a typical example when "constness" will make


IMHO: without constness char[] cannot be considered
as a solutions for strings. I am pretty sure that without constness
it is just impossible to create reliable and consistent Phobos.

To D with love,

Andrew.

"Kris" <fu bar.com> writes:

I'm a strong advocate for what you describe, but it may be better to talk
about this particular aspect in terms of "read only" rather than "const".
The latter has a somewhat sour flavour for many, and covers such a broad
gamut that its very name send shivers throughout the forum.

On the other hand, a "read only" modifer for types is just a sliver compared
to C++ const ~ its worth keeping that in mind. Such a modifier would allow
us to do all kinds of efficient and defensive programming, some of which you
have pointed out.

- Kris


BTW; it can be awkward to get the syntax right when deal with function
return values; how does one specify a read-only return?



"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d73kfp$f72$1 digitaldaemon.com...
 Constness is not only about possible bugs or ROM placement of variables as
 Kris rightly mentioned.
 It is also about effectiveness and robustness of code and especially
 libraries - components.

 Example:
 I have a class:

 class Url
 {
     char[] _domain;
     char[] _filename;
     char[] _protocol;

     static Url parse( char[] url )
    {
        char[] buffer = unescape(url); // will always dup
        _domain = buffer[a..b];
        _filename = buffer[b..c];
        _protocol = buffer[c..d];
    }
    // current implementation
    char[] domain()        { return _domain.dup; }
    char[] filename()     { return _filename.dup; }
    char[] protocol()    { return _protocol.dup; }

    // this is extremely nice to have
    char[]:const  domain()      { return _domain; }
    char[]:const  filename()     { return _filename; }
    char[]:const  protocol()     { return _protocol; }
 }

 As you may see without const typical and robust library
 implementation  approach follows to constant "joy of GC"
 as  I ***must*** do 'dup' in
 char[] domain()  { return _domain.dup; }
 if I want my son to reuse my code.

 If you think that this example is too abstract then
 take a look into std/string.d  and comments in function:

 char* toStrings(char[] s)
  /+ Unfortunately, this isn't reliable....

 This is a typical example when "constness" will make


 IMHO: without constness char[] cannot be considered
 as a solutions for strings. I am pretty sure that without constness
 it is just impossible to create reliable and consistent Phobos.

 To D with love,

 Andrew.

"Andrew Fedoniouk" <news terrainformatica.com> writes:

Kris, I agree with you that "read-only" is better.
Other useful metaphor for the same entity would be also
'ownership'.  Ownership implies run-time support.
With ownership mechanism it is possible to make
constantness and "read-only-ness" across library/component
boundaries.

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.

I am skiping details of implementation intentionally as
this is just a wild idea tended to start sort of brain storming on the 
subject.

Any other ideas?

Andrew.





"Kris" <fu bar.com> wrote in message news:d73m38$omb$1 digitaldaemon.com...
 I'm a strong advocate for what you describe, but it may be better to talk
 about this particular aspect in terms of "read only" rather than "const".
 The latter has a somewhat sour flavour for many, and covers such a broad
 gamut that its very name send shivers throughout the forum.

 On the other hand, a "read only" modifer for types is just a sliver 
 compared
 to C++ const ~ its worth keeping that in mind. Such a modifier would allow
 us to do all kinds of efficient and defensive programming, some of which 
 you
 have pointed out.

 - Kris


 BTW; it can be awkward to get the syntax right when deal with function
 return values; how does one specify a read-only return?



 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d73kfp$f72$1 digitaldaemon.com...
 Constness is not only about possible bugs or ROM placement of variables 
 as
 Kris rightly mentioned.
 It is also about effectiveness and robustness of code and especially
 libraries - components.

 Example:
 I have a class:

 class Url
 {
     char[] _domain;
     char[] _filename;
     char[] _protocol;

     static Url parse( char[] url )
    {
        char[] buffer = unescape(url); // will always dup
        _domain = buffer[a..b];
        _filename = buffer[b..c];
        _protocol = buffer[c..d];
    }
    // current implementation
    char[] domain()        { return _domain.dup; }
    char[] filename()     { return _filename.dup; }
    char[] protocol()    { return _protocol.dup; }

    // this is extremely nice to have
    char[]:const  domain()      { return _domain; }
    char[]:const  filename()     { return _filename; }
    char[]:const  protocol()     { return _protocol; }
 }

 As you may see without const typical and robust library
 implementation  approach follows to constant "joy of GC"
 as  I ***must*** do 'dup' in
 char[] domain()  { return _domain.dup; }
 if I want my son to reuse my code.

 If you think that this example is too abstract then
 take a look into std/string.d  and comments in function:

 char* toStrings(char[] s)
  /+ Unfortunately, this isn't reliable....

 This is a typical example when "constness" will make


 IMHO: without constness char[] cannot be considered
 as a solutions for strings. I am pretty sure that without constness
 it is just impossible to create reliable and consistent Phobos.

 To D with love,

 Andrew.

 

"Walter" <newshound digitalmars.com> writes:

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

"Matthew" <admin.hat stlsoft.dot.org> writes:

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

John Reimer <brk_6502 yahoo.com> writes:

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

"Matthew" <admin.hat stlsoft.dot.org> writes:

"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>) 

John Reimer <brk_6502 yahoo.com> writes:

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

"Andrew Fedoniouk" <news terrainformatica.com> writes:

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

Derek Parnell <derek psych.ward> writes:

On Wed, 25 May 2005 21:48:41 -0700, Andrew Fedoniouk wrote:

 Constness is not only about possible bugs or ROM placement of variables as 
 Kris rightly mentioned.
 It is also about effectiveness and robustness of code and especially 
 libraries - components.
 
 Example:
 I have a class:
 
 class Url
 {
     char[] _domain;
     char[] _filename;
     char[] _protocol;
 
     static Url parse( char[] url )
    {
        char[] buffer = unescape(url); // will always dup
        _domain = buffer[a..b];
        _filename = buffer[b..c];
        _protocol = buffer[c..d];
    }
    // current implementation
    char[] domain()        { return _domain.dup; }
    char[] filename()     { return _filename.dup; }
    char[] protocol()    { return _protocol.dup; }
 
    // this is extremely nice to have
    char[]:const  domain()      { return _domain; }
    char[]:const  filename()     { return _filename; }
    char[]:const  protocol()     { return _protocol; }
 }
 
 As you may see without const typical and robust library
 implementation  approach follows to constant "joy of GC"
 as  I ***must*** do 'dup' in
 char[] domain()  { return _domain.dup; }
 if I want my son to reuse my code.

One could consider this as just a syntax or implementation issue. The
addition of the ".dup" causes your object's data to be effectively const;
that is 'not modifiable by the caller'. 

The mechanism to make it const is to provide a copy of the data that the
caller can freely mess about with if they want to. If instead, you want the
mechanism to be that the compiler detects these at compile time, then we
have a problem. From memory, I think the argument against that mechanism is
that because there are always some way to fool the compiler (eg. in line
assembler code) so if it does not report an error, the coder has a false
sense of security.

The current, runtime mechanism, does not rely on a foolproof compiler,
though at the cost of some performance, but it does guarantee const-ness.

I suppose one could argue for a syntax addition to more clearly state the
intention of the coder. The compiler would still implement const-ness as it
does now, via data copy, but the coder's desire for const would be more
visible to the reader.

So maybe 

   char[]:const funcA() { ... return a; }

could be identical to

   char[] funcA() { ... return a.dup; }

By the way, I notice that your class's member data is not marked private,
thus anyone can modify it directly. Is that desired? 

 If you think that this example is too abstract then
 take a look into std/string.d  and comments in function:
 
 char* toStrings(char[] s)
  /+ Unfortunately, this isn't reliable....

That isn't fair. The 'unreliable' code is commented out. You give the
impression that the unreliable code is actually in the library.

 This is a typical example when "constness" will make

 
 IMHO: without constness char[] cannot be considered
 as a solutions for strings. I am pretty sure that without constness
 it is just impossible to create reliable and consistent Phobos.

I've described that the .dup mechanism actually does implement the concept
of read-only strings, in so far as the calling functions are prevented from
modifying data you don't want them to. Given that, it is therefore possible
to create a reliable Phobos (with regards to strings anyhow).

-- 
Derek
Melbourne, Australia
26/05/2005 2:57:52 PM

"Andrew Fedoniouk" <news terrainformatica.com> writes:

Hi, Derek, please see below,

 Constness is not only about possible bugs or ROM placement of variables 
 as
 Kris rightly mentioned.
 It is also about effectiveness and robustness of code and especially
 libraries - components.

 Example:
 I have a class:

 class Url
 {
     char[] _domain;
     char[] _filename;
     char[] _protocol;

     static Url parse( char[] url )
    {
        char[] buffer = unescape(url); // will always dup
        _domain = buffer[a..b];
        _filename = buffer[b..c];
        _protocol = buffer[c..d];
    }
    // current implementation
    char[] domain()        { return _domain.dup; }
    char[] filename()     { return _filename.dup; }
    char[] protocol()    { return _protocol.dup; }

    // this is extremely nice to have
    char[]:const  domain()      { return _domain; }
    char[]:const  filename()     { return _filename; }
    char[]:const  protocol()     { return _protocol; }
 }

 As you may see without const typical and robust library
 implementation  approach follows to constant "joy of GC"
 as  I ***must*** do 'dup' in
 char[] domain()  { return _domain.dup; }
 if I want my son to reuse my code.

 One could consider this as just a syntax or implementation issue. The
 addition of the ".dup" causes your object's data to be effectively const;
 that is 'not modifiable by the caller'.

 The mechanism to make it const is to provide a copy of the data that the
 caller can freely mess about with if they want to. If instead, you want 
 the
 mechanism to be that the compiler detects these at compile time, then we
 have a problem. From memory, I think the argument against that mechanism 
 is
 that because there are always some way to fool the compiler (eg. in line
 assembler code) so if it does not report an error, the coder has a false
 sense of security.

 The current, runtime mechanism, does not rely on a foolproof compiler,
 though at the cost of some performance, but it does guarantee const-ness.

 I suppose one could argue for a syntax addition to more clearly state the
 intention of the coder. The compiler would still implement const-ness as 
 it
 does now, via data copy, but the coder's desire for const would be more
 visible to the reader.

Constantness is not about can I or cannot fool the compiler (I can full this
Turing machine in many ways) but rather about again efectiveness and
robustness. Yes, I can spread copy-on-write across *my*code.
But as a generic library designer I cannot force users to do this.
It is just not fair. Having my example in mind imagine how much memory
will take .dup approach for url "http://w3c.org"....
For given Url class (this is just a model - not a real one) when use cases
of modifications of its parts are rare, such memory allocation behavior
is not something I am considering as a good design.
And more - such Url is a short living class - parse-n-forget and
highly desireable to do not left traces in the sky after.

Yes, you can follow .NET way and say "memory is not a resource anymore" and
allocate memory on each sneeze but I hope here is a community of 
realists....

Either const/read-only/ownership/whatever
either .dup with copying GC and all consequences which .NET and
Java are facing now.


 So maybe

   char[]:const funcA() { ... return a; }

 could be identical to

   char[] funcA() { ... return a.dup; }

 By the way, I notice that your class's member data is not marked private,
 thus anyone can modify it directly. Is that desired?

This just a mockup...

 If you think that this example is too abstract then
 take a look into std/string.d  and comments in function:

 char* toStrings(char[] s)
  /+ Unfortunately, this isn't reliable....

 That isn't fair. The 'unreliable' code is commented out. You give the
 impression that the unreliable code is actually in the library.

Sorry, I did not have an intention to demonstrate unreliable code.
My point is inside comment itself and the solution which might be
implemented (code commented out).

Consider I need to draw components of the URL  on the screen.
So on each WM_PAINT I need to allocate new strings...
Or to store them in member variables thus effectively
increase number of objects  on GC controllable perimeter.

In Java simple applet with let's say red background is
12 objects allocated on each paint. Doh! And they even asking
why it is slow.... Application is just not working 20% of time,
is it good design?

 This is a typical example when "constness" will make


 IMHO: without constness char[] cannot be considered
 as a solutions for strings. I am pretty sure that without constness
 it is just impossible to create reliable and consistent Phobos.

 I've described that the .dup mechanism actually does implement the concept
 of read-only strings, in so far as the calling functions are prevented 
 from
 modifying data you don't want them to. Given that, it is therefore 
 possible
 to create a reliable Phobos (with regards to strings anyhow).

Sorry when I am speaking about reliable I am assuming that
effectivness and robustness is a primordial requirements.
Otherwise we will have a robust something which nobody will use.

Again, I am not agianst D, I am just trying to think of
how to make it even better.

Andrew.

Derek Parnell <derek psych.ward> writes:

On Wed, 25 May 2005 23:31:49 -0700, Andrew Fedoniouk wrote:


[snip]

 Again, I am not agianst D, I am just trying to think of
 how to make it even better.

Yeah, I know that Andrew. 

So how could read-only data be implemented differently in D? Any ideas,
given that a compiler can't catch all attempts to write to read-only data,
and we can't really rely on the underlying hardware to help us?

-- 
Derek
Melbourne, Australia
26/05/2005 4:35:10 PM

"Kris" <fu bar.com> writes:

"Derek Parnell" <derek psych.ward> wrote
 So how could read-only data be implemented differently in D? Any ideas,
 given that a compiler can't catch all attempts to write to read-only data,
 and we can't really rely on the underlying hardware to help us?

Au Contraire, sir;

The compiler *can* catch all /accidental/ or /incidental/ attempts to write
to data marked as read-only. If someone is hell-bent on circumventing that,
then they can do so via assembly, or via pointer aliasing, if they really
insist.

What, I believe, Andrew is getting at is where the intent of the designer is
clearly stated within the (enhanced) syntax ~ the compiler supports that by
flagging every instance whereby that explicit contract is implicitly broken.

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?

Derek Parnell <derek psych.ward> writes:

On Wed, 25 May 2005 23:56:29 -0700, Kris wrote:

 "Derek Parnell" <derek psych.ward> wrote
 So how could read-only data be implemented differently in D? Any ideas,
 given that a compiler can't catch all attempts to write to read-only data,
 and we can't really rely on the underlying hardware to help us?

 
 Au Contraire, sir;
 
 The compiler *can* catch all /accidental/ or /incidental/ attempts to write
 to data marked as read-only. If someone is hell-bent on circumventing that,
 then they can do so via assembly, or via pointer aliasing, if they really
 insist.

I agree that a compiler can catch 'normal' references. It was the absurd,
"hell-bent" methods that I was concerned with. If we can live with that,
*and* make that clear in documentation, then fine.

 What, I believe, Andrew is getting at is where the intent of the designer is
 clearly stated within the (enhanced) syntax ~ the compiler supports that by
 flagging every instance whereby that explicit contract is implicitly broken.

Yep, that's a position I can support. If a coder explicitly marks something
as read-only *and* the compiler detects an infringement of that then it
should report an error.

 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.

-- 
Derek
Melbourne, Australia
26/05/2005 4:59:36 PM

"Kris" <fu bar.com> writes:

"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> writes:

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>

 

"Andrew Fedoniouk" <news terrainformatica.com> writes:

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

 

Brad Beveridge <brad somewhere.net> writes:

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

Sean Kelly <sean f4.ca> writes:

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

Brad Beveridge <brad somewhere.net> writes:

Sean Kelly wrote:
 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
 
 

Your reply is much more concrete than mine.
If I were smart enough I would have provided code too :)

Brad

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

Unfortunately, one of the tenets of Contract Programming (formerly 
known as DbC) is the principle of removability: code that is correct 
should not be affected by removal / insertion of contract 
enforcements.

Furthermore, Contract Programming enforcement is at runtime. While 
we can postulate that a compiler might be obliged to infer 
compile-time relationships from runtime contracts, this seems, at 
least at first thinking, to be a dubious notion, and likely to have 
only partial applicability.

"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d7i8pv$2a4k$1 digitaldaemon.com...
 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 

Sean Kelly <sean f4.ca> writes:

In article <d7iup8$5j2$1 digitaldaemon.com>, Matthew says...
Unfortunately, one of the tenets of Contract Programming (formerly 
known as DbC) is the principle of removability: code that is correct 
should not be affected by removal / insertion of contract 
enforcements.

Furthermore, Contract Programming enforcement is at runtime. While 
we can postulate that a compiler might be obliged to infer 
compile-time relationships from runtime contracts, this seems, at 
least at first thinking, to be a dubious notion, and likely to have 
only partial applicability.

But const correctness can be verified, somewhat, using DbC and a lot of
cooperation.  And since D currently offers us nothing in this regard, perhaps
it's an approach worth mentioning.


Sean

Sam <Sam_member pathlink.com> writes:

Come to think of it, 'const's were never always guaranteed in C++ because one
could do a 'const_cast<typename>(variable)' to remove the const-ness.

So

I guess....

Nothing is ever 'const' in this world.....
Everything changes........
'const' isn't what it used to be, or ever was????

Sam-
sam987883 yahoo.com