www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Do we really need const?

reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Jarrett Billingsley Wrote:


 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:fcl79k$18vu$1 digitalmars.com...
 

 It seems from the discussion here the past week, there is no real 
 multithreading benefit to be had from const/invariant.  'Pure' is where 
 it's at for that.  So maybe we're just better off without the complexities 
 of const.  I've certainly gotten used to the lack of const in Python, so 
 why not in a C++-ish language?



 I start to wonder how much of the "of COURSE we need const!" thinking comes 
 from "if all you have is a hammer, everything starts looking like a nail." 
 That is, I wonder how many people think we absolutely need const because 
 they're so used to using it in C and C++.
 
 Never having learned a const-correct language (started with various BASICs, 
 then on to very rudimentary C++, then D, and also a bit of Java and C#), I 
 simply don't see the overwhelming need.  Sure, there are a very few cases 
 where const could be useful in my code for efficiency's sake, but I've never 
 felt like I was missing any expressive power.  Furthermore, I have been 
 bitten exactly once by something that theoretically could have been 
 prevented by const.  It took me two minutes in the debugger to track down 
 the problem.  I'd say that those two minutes were a much better tradeoff 
 than the god-knows-how-long it'd take to write const and non-const overloads 
 of who-knows-how-many functions. 
 



The problem with this is it isn't easy to tell how many problems would have
been prevented if you are a regular user of const because they've been
prevented. One exercise to try would be to take a large project and replace
const with an empty string and see what the code looks like, then count the
number, type and severity of potential errors relating to this absence. The
problem is that doesn't take into account the dynamic nature of programming.
Far more mistakes occur during development than you might be able to find in a
finished product.

An example of one that catches me out quite often is:

strcpy(src,dest)   vs. strcpy(dest,src);

As soon as src is const and dest mustn't be this can be caught at compile time.
Granted that example is academic as I use std::string in
place of char*s whenever possible.

So that's one use case in favour of const parameters.

What happened to that "deconstructing the christmas tree" thread?
Gathering the useful use cases of constness together sounds like a good way
forward to me.

Regards,

Bruce.
Sep 17 2007
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Bruce Adams Wrote:

 The problem with this is it isn't easy to tell how many problems would have
been prevented if you are a regular user of const because they've been
prevented. One exercise to try would be to take a large project and replace
const with an empty string and see what the code looks like, then count the
number, type and severity of potential errors relating to this absence. The
problem is that doesn't take into account the dynamic nature of programming.
Far more mistakes occur during development than you might be able to find in a
finished product.
 
 



I think this is a similar argument to the one used to argue that static typing
prevents a lot of bugs that dynamic typing might introduce. Many people who
have worked in a dynamically-typed language (even on a bigger project) will
confess that the gain in productivity of not having to constantly specify
interfaces, being able to "blindly" pass things around, etc., create a better
cost-to-benefit ratio than static typing. In fact, it's the same argument used
to justify checked/specified exceptions in Java.

The potential for a bug doesn't mean that that potential will be used, and the
productivity benefits of NOT having const might be greater.

That strcpy thing _is_ a good example, though it won't catch that many bugs in
its usage, since src already needs to be const. But it does show a valid
use-case, which is better than I can provide for my argument ;-P.
Sep 17 2007
next sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Robert Fraser Wrote:


 Bruce Adams Wrote:

 The problem with this is it isn't easy to tell how many problems would have
been prevented if you are a regular user of const because they've been
prevented. One exercise to try would be to take a large project and replace
const with an empty string and see what the code looks like, then count the
number, type and severity of potential errors relating to this absence. The
problem is that doesn't take into account the dynamic nature of programming.
Far more mistakes occur during development than you might be able to find in a
finished product.
 
 



 I think this is a similar argument to the one used to argue that static typing
prevents a lot of bugs that dynamic typing might introduce. Many people who
have worked in a dynamically-typed language (even on a bigger project) will
confess that the gain in productivity of not having to constantly specify
interfaces, being able to "blindly" pass things around, etc., create a better
cost-to-benefit ratio than static typing. In fact, it's the same argument used
to justify checked/specified exceptions in Java.




Dynamic / scripting languages do let you write code faster but at the expense
of potentially being less reliable / robust. C++ is at the other end you over
engineer and get reliable robust code - slowly. In an ideal language we could
do both. "auto" almost gives us the best of both but we're currently missing an
"any" type that would implicitly convert itself as freely as its dynamic
language counterpart (at the expense of run-time performance).

 

 The potential for a bug doesn't mean that that potential will be used, and the
productivity benefits of NOT having const might be greater.



Though, I personally don't advocate that kind of style.
I think it is very important to get constness right in the design of
interfaces, under the bonnett it matters much less.
 

 That strcpy thing _is_ a good example, though it won't catch that many bugs in
its usage, since src already needs to be const. But it does show a valid
use-case, which is better than I can provide for my argument ;-P.



Your toadying will not go unrewarded when I am emperor ;)
Sep 17 2007
prev sibling parent 0ffh <spam frankhirsch.net> writes:
Robert Fraser wrote:

 Bruce Adams Wrote:

 The problem with this is it isn't easy to tell how many problems would
 have been prevented if you are a regular user of const because they've
 been prevented. [...]



 typing prevents a lot of bugs that dynamic typing might introduce. [...]



As an aside, I think that people tend to use one bin for dynamic typing
and the auto-instatiation of variables that many dynamically typed
languages use (and which is, of course, very evil :-).


 The potential for a bug doesn't mean that that potential will be used,
 and the productivity benefits of NOT having const might be greater.



It might at least make things simpler, which is a gain in itself.
The question is if this outweighs the advantages of having const.
Maybe it really *is* time to deconstruct the christmas tree and
have a look what kinds of constness are important enough to justify
complicating the language by narrowing code freedom.

Regards, frank
Sep 17 2007
prev sibling parent reply renoX <renosky free.fr> writes:
Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



If it helps you'not the only one to have this kind of issue: some 
compilers even try to detect when people makes mistakes for 'memset'?
Both case show why function calls with passing the parameter by position 
instead of by keywords *sucks*.

Let's try it: do you think you would make the same mistake if you would 
call your function this way:
char[50] var_dest, my_src;
strcpy(dest: var_dest, src: my_src)

See?
1) much less risk of errors
2) better readability
3) in case of error, it's easy to see the error and correct it.

So there is a better way than const to prevent source/dest error, 
unfortunately D doesn't support it..

Regards,
RenoX
Sep 17 2007
next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 If it helps you'not the only one to have this kind of issue: some 
 compilers even try to detect when people makes mistakes for 'memset'?
 Both case show why function calls with passing the parameter by position 
 instead of by keywords *sucks*.
 
 Let's try it: do you think you would make the same mistake if you would 
 call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)



My eyes... aaarghh!

Regan
Sep 17 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Regan Heath wrote:

 renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 If it helps you'not the only one to have this kind of issue: some 
 compilers even try to detect when people makes mistakes for 'memset'?
 Both case show why function calls with passing the parameter by 
 position instead of by keywords *sucks*.

 Let's try it: do you think you would make the same mistake if you 
 would call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)



 My eyes... aaarghh!



Is it the particular syntax or the concept you object to?  I think 
named/keyword parameters can be quite useful.  Have you ever used a 
language that has them?

I think the problem with putting them into D is only that it becomes yet 
another way to do things.  We already have all the flavors of 
overloading inherited from C++.

--bb
Sep 17 2007
next sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Bill Baxter Wrote:


 Regan Heath wrote:

 renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 If it helps you'not the only one to have this kind of issue: some 
 compilers even try to detect when people makes mistakes for 'memset'?
 Both case show why function calls with passing the parameter by 
 position instead of by keywords *sucks*.

 Let's try it: do you think you would make the same mistake if you 
 would call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)



 My eyes... aaarghh!



 Is it the particular syntax or the concept you object to?  I think 
 named/keyword parameters can be quite useful.  Have you ever used a 
 language that has them?
 
 I think the problem with putting them into D is only that it becomes yet 
 another way to do things.  We already have all the flavors of 
 overloading inherited from C++.
 
 --bb



Actually I quite like the concept of keywords provided they're optional.
I prefer the Fortran-90 syntax:

copy(source=foo, dest=bar);

since its sort of an assignment.
Actually its just as ugly, but you can get used to almost anything
eventually.

That protects me from one kind of bug where I get source and dest confused. It
does not protect me from getting foo and bar confused. If the source is
required to be const and foo is not the const variable I am saved. 

i.e.
   myfunc( string alpha = var1, string beta = var2 )
   {
       stuff...
       copy(var2,var1);
   }

vs.
   myfunc( const string alpha , string beta )
   {
       stuff...
       copy(source=alpha,dest = beta);
   }


   string var1 = "source"
   string var2; //uninitialised oh no!
   myfunc(alpha=var1,beta=var2);

The const protects me from swapping args when the keywords hide some
implementaiton detail. However, agreed positional arguments are a bad thing in
general but sometimes necessary.
In the above it would be useful to say - must be initialised which in C++
is:  const var1 = "source";
Though, a ordinary clever compiler detect that var2 is not initialised without
const.

So cost benefit analysis so far. Keywords yes, maybe even before const but not
a replacement.

Regards,

Bruce.
Sep 17 2007
prev sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Bill Baxter wrote:

 Regan Heath wrote:

 renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 If it helps you'not the only one to have this kind of issue: some 
 compilers even try to detect when people makes mistakes for 'memset'?
 Both case show why function calls with passing the parameter by 
 position instead of by keywords *sucks*.

 Let's try it: do you think you would make the same mistake if you 
 would call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)



 My eyes... aaarghh!



 Is it the particular syntax or the concept you object to?  



Not sure, it just makes my skin crawl at the moment.  I've never really 
had a problem with passing arguments in the wrong order.  These days my 
IDE prompts me as I type, that feature seems to remove the need for this 
idea completely, to my mind.  Granted not every IDE has this.

It's a bit like the idea to use 'out'/'ref' 'inout' etc at call site.  I 
can understand the argument that it increases the information available 
to someone simply reading the code but I just don't want to have to type 
all that.

Again, an IDE could easily display this information for you.  But again, 
not every IDE will have such a feature and if you decided to diplay the 
source in another form (printed or something) you loose the information 
again.

I guess all I'm saying is that I'm on the other side of the fence, the 
gain from these additions are less than the cost, to me.


 I think
 named/keyword parameters can be quite useful.  Have you ever used a 
 language that has them?



To be fair, no, and I should probably try it before passing judgement.

My last post was a 'first impression' or rather, 'another first 
impression' because I recall this idea being posted before, perhaps 
several times.


 I think the problem with putting them into D is only that it becomes yet 
 another way to do things.  We already have all the flavors of 
 overloading inherited from C++.



That true.

Regan
Sep 18 2007
next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Janice Caron wrote:

 On 9/18/07, Regan Heath <regan netmail.co.nz> wrote:

 Bill Baxter wrote:

 Regan Heath wrote:

 renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 would call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)












 Of course, for copying strings in D, we already have the vastly superior syntax
 dst = src;
 
 :-)



You mean of course:

dst = src.dup

;O)
Sep 18 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Regan Heath wrote:

 Janice Caron wrote:

 On 9/18/07, Regan Heath <regan netmail.co.nz> wrote:

 Bill Baxter wrote:

 Regan Heath wrote:

 renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 would call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)












 Of course, for copying strings in D, we already have the vastly 
 superior syntax
 dst = src;

 :-)



 You mean of course:
 
 dst = src.dup
 
 ;O)



Or:
---
dst[] = src;
---
to copy to a preallocated buffer (like strcpy does).

(Or
---
dst[0..src.length] = src;
---
if src.length < dst.length...)
Sep 18 2007
prev sibling parent reply renoX <renosky free.fr> writes:
Regan Heath a écrit :

 Bill Baxter wrote:

 Regan Heath wrote:

 renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 If it helps you'not the only one to have this kind of issue: some 
 compilers even try to detect when people makes mistakes for 'memset'?
 Both case show why function calls with passing the parameter by 
 position instead of by keywords *sucks*.

 Let's try it: do you think you would make the same mistake if you 
 would call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)



 My eyes... aaarghh!



 Is it the particular syntax or the concept you object to?  



 Not sure, it just makes my skin crawl at the moment.  I've never really 
 had a problem with passing arguments in the wrong order.  These days my 
 IDE prompts me as I type, that feature seems to remove the need for this 
 idea completely, to my mind.  Granted not every IDE has this.
 
 It's a bit like the idea to use 'out'/'ref' 'inout' etc at call site.  I 
 can understand the argument that it increases the information available 
 to someone simply reading the code but I just don't want to have to type 
 all that.



The IDE can write these thing for you (assuming of course you write the 
function prototype before the call), and for maintained code, there is 
more reading/rereading than writing.


 Again, an IDE could easily display this information for you.  But again, 
 not every IDE will have such a feature and if you decided to display the 
 source in another form (printed or something) you loose the information 
 again.



Yes, that's why having the IDE writing additional information for you is 
better: everyone benefits from it, whereas if those information are 
displayed only when you have an IDE, only the users with the IDE will 
have those information..


 I guess all I'm saying is that I'm on the other side of the fence, the 
 gain from these additions are less than the cost, to me.



As said above, developers spend more time reading code (for debugging, 
for modifying) than writing code.


  > I think

 named/keyword parameters can be quite useful.  Have you ever used a 
 language that has them?



 To be fair, no, and I should probably try it before passing judgement.
 
 My last post was a 'first impression' or rather, 'another first 
 impression' because I recall this idea being posted before, perhaps 
 several times.
 

 I think the problem with putting them into D is only that it becomes 
 yet another way to do things.  We already have all the flavors of 
 overloading inherited from C++.






I don't follow you here, having keyword function call doesn't imply that 
you necessarily allow different a overloading mode..

Sure D could also use the name of the parameters as a disambiguator 
[which is nice IMHO sin(deg: 90) and sin(rad: pi) is better than sin_deg 
and sin_rad] but this is not *required*.

And IMHO, it wouldn't be wise to add this parameter name overloading at 
first, because as you said the interactions between this an normal 
function calls would be weird: in the above example, you wouldn't be 
able to call sin(5) as the compiler wouldn't be able to distinguish 
which function is called.

renoX


 
 That true.
 
 Regan
Sep 18 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
renoX wrote:

 Regan Heath a écrit :

 I guess all I'm saying is that I'm on the other side of the fence, the 
 gain from these additions are less than the cost, to me.



 As said above, developers spend more time reading code (for debugging, 
 for modifying) than writing code.



Which they do using what application ;)  The IDE, which can display the 
specific information each developer finds most useful and can do so 
without 'cluttering' the source with things another developer may not 
need/want.

Regan
Sep 19 2007
parent reply Ingo Oeser <ioe-news rameria.de> writes:
Regan Heath wrote:


 renoX wrote:

 As said above, developers spend more time reading code (for debugging,
 for modifying) than writing code.



 Which they do using what application ;)  The IDE, which can display the
 specific information each developer finds most useful and can do so
 without 'cluttering' the source with things another developer may not
 need/want.



Really, not every developer is using some kind of IDE.

A syntax highlighting editor is usually enough to feed
the compiler. I'm happy that D code is nothing but text,
instead of some "enriched" binary junk or junk appended
to databases.

Best Regards

Ingo Oeser
Sep 23 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Ingo Oeser Wrote:


 Regan Heath wrote:
 

 renoX wrote:

 As said above, developers spend more time reading code (for debugging,
 for modifying) than writing code.



 Which they do using what application ;)  The IDE, which can display the
 specific information each developer finds most useful and can do so
 without 'cluttering' the source with things another developer may not
 need/want.



 Really, not every developer is using some kind of IDE.
 
 A syntax highlighting editor is usually enough to feed
 the compiler. I'm happy that D code is nothing but text,
 instead of some "enriched" binary junk or junk appended
 to databases.
 
 Best Regards
 
 Ingo Oeser



But should language features be added to maker reading code easier?
Sep 23 2007
next sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 23 Sep 2007 17:58:34 -0400, Robert Fraser wrote:



 But should language features be added to maker reading code easier?



YES YES YES! (imnsho)

Code is examined via more than one method. An IDE is not the only way to
look at code. There is email, B&W printers, hand writting, plain text
editors, voice (over the telephone), telnet for Bob's sake, etc ...

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Sep 23 2007
prev sibling parent Ingo Oeser <ioe-news rameria.de> writes:
Robert Fraser wrote:


 But should language features be added to maker reading code easier?



Yes. Many projects use domain specific languages to make the code more
readable. Very common are table generators.

The Linux kernel project uses several enhancements to support checkers
while improving readability.

One example is endian annotation. You often get data from the
network or through some hardware in a specific endianess.

You only have to convert that when you start calculating with that stuff
or try to hand it out to user space with an API which is defined 
in native byte order. Since in some networking situations
most received stuff can be dropped (e.g. firewall in extremely unfriendly
environment), it is wise to defer endian conversion to latest possible.

To get all the situations right where we handle native or network 
byte order, the structure members and function arguments are endian 
annotated.

Now you just need to look at the function signature to get it right.
Or run a static checker (like sparse) to check correctness.

But really, that stuff is like medicine: The dose matters :-)


Best Regards

Ingo Oeser
Sep 24 2007
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 17 Sep 2007 22:57:05 +0100, Regan Heath wrote:


 renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 If it helps you'not the only one to have this kind of issue: some 
 compilers even try to detect when people makes mistakes for 'memset'?
 Both case show why function calls with passing the parameter by position 
 instead of by keywords *sucks*.
 
 Let's try it: do you think you would make the same mistake if you would 
 call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)



 My eyes... aaarghh!



Or ...

  copy(from: var_dest, to: my_src);

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/09/2007 9:50:52 AM
Sep 17 2007
parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 18 Sep 2007 09:52:46 +1000, Derek Parnell wrote:


 On Mon, 17 Sep 2007 22:57:05 +0100, Regan Heath wrote:
 

 renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 If it helps you'not the only one to have this kind of issue: some 
 compilers even try to detect when people makes mistakes for 'memset'?
 Both case show why function calls with passing the parameter by position 
 instead of by keywords *sucks*.
 
 Let's try it: do you think you would make the same mistake if you would 
 call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)



 My eyes... aaarghh!



 Or ...
 
   copy(from: var_dest, to: my_src);



P.S.
This still doesn't remove the usefulness of 'const' concept though. For
example ..

   copy(from: ExampleA, to: ExampleB);

This line by itself doesn't tell the reader if 'ExampleB' is writeable or
not.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/09/2007 11:04:23 AM
Sep 17 2007
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"renoX" <renosky free.fr> wrote in message 
news:fcmsmv$1drt$1 digitalmars.com...


 strcpy(dest: var_dest, src: my_src)



My eyes... ahhhh!  They feel so good having seen such self-explanatory code.

Code that reads close to natural language == win, as far as I'm concerned.
Sep 17 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 9/18/07, Regan Heath <regan netmail.co.nz> wrote:

 Bill Baxter wrote:

 Regan Heath wrote:

 renoX wrote:

 Bruce Adams a écrit :

 An example of one that catches me out quite often is:
 strcpy(src,dest) vs. strcpy(dest,src);



 Let's try it: do you think you would make the same mistake if you
 would call your function this way:
 char[50] var_dest, my_src;
 strcpy(dest: var_dest, src: my_src)



 My eyes... aaarghh!



 Is it the particular syntax or the concept you object to?



 Not sure, it just makes my skin crawl at the moment.



Of course, for copying strings in D, we already have the vastly superior syntax
dst = src;

:-)
Sep 18 2007
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 9/18/07, Regan Heath <regan netmail.co.nz> wrote:

 You mean of course:

 dst = src.dup

 ;O)



Oh yeah! Well spotted. :-)
Sep 18 2007