www.digitalmars.com         C & C++   DMDScript  

D - const member functions and new numeric types

reply hellcatv hotmail.com writes:
Hello, I've been completely enthusiastic by what I've seen about D, and am
considering porting some of my projects to D.

However, one thing does come to mind that I wished to ask about: Const member
functions.

As a C++ programmer I have found it extremely useful to have const member
functions.  For instance I once wrote a destructive member function that swapped
certain values between two classes.
Years later I realized that the function was a bottleneck and that I needed to
cache the classes to be swapped from... i.e. I needed to make the function into
a nondestructive partial assign, rather than a destructive swap.

I simply changed the member function to be CONST and the compiler helped me
track down every time I did a destructive operation or called a destructive
member function (I had to propogate the consts around)

Once I got it compiling, the program worked with the caching.

Could I have performed the same were my program written in D? 
Is there some way to have done this with templates that I haven't thought about,
or is the const feature missing and I would have not had the compiler's
assistance here.
Compile time type safety and const-ness is a very useful feature for fixing
legacy/someone else's code. Of course that brings the mutable can of worms back
into the picture too.


Another question (less important): Could I make a special quaternion or vector3
class that acted just like a float (multiply, gets, overloading, pass by value)
like I can in C++? 
Would this be with auto? would I have to make 1 auto class and another non-auto
class and some casting operator between the two?
Basically I want to have all the speed of a local variable with the convenience
of it being a class, and the ability to make pointers to it.

--Daniel
Vega Strike Lead Devel
http://vegastrike.sourceforge.net/
Apr 27 2004
next sibling parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
<hellcatv hotmail.com> wrote in message
news:c6ma69$2i1m$1 digitaldaemon.com...

 Hello, I've been completely enthusiastic by what I've seen about D, and am
 considering porting some of my projects to D.

 However, one thing does come to mind that I wished to ask about: Const


member

 functions.

 As a C++ programmer I have found it extremely useful to have const member
 functions.  For instance I once wrote a destructive member function that


swapped

 certain values between two classes.
 Years later I realized that the function was a bottleneck and that I


needed to

 cache the classes to be swapped from... i.e. I needed to make the function


into

 a nondestructive partial assign, rather than a destructive swap.

 I simply changed the member function to be CONST and the compiler helped


me

 track down every time I did a destructive operation or called a


destructive

 member function (I had to propogate the consts around)

 Once I got it compiling, the program worked with the caching.

 Could I have performed the same were my program written in D?
 Is there some way to have done this with templates that I haven't thought


about,

 or is the const feature missing and I would have not had the compiler's
 assistance here.
 Compile time type safety and const-ness is a very useful feature for


fixing

 legacy/someone else's code. Of course that brings the mutable can of worms


back

 into the picture too.


D can't do const member functions. You can use design-by-contract, though,
which is a better way (because C++'s type constness does not guarrantee
run-time constness).


 Another question (less important): Could I make a special quaternion or


vector3

 class that acted just like a float (multiply, gets, overloading, pass by


value)

 like I can in C++?
 Would this be with auto? would I have to make 1 auto class and another


non-auto

 class and some casting operator between the two?
 Basically I want to have all the speed of a local variable with the


convenience

 of it being a class, and the ability to make pointers to it.


D has structs for this exact purpose.
Apr 27 2004
next sibling parent Daniel Horn <hellcatv hotmail.com> writes:
Achilleas Margaritis wrote:



legacy/someone else's code. Of course that brings the mutable can of worms




  >> backinto the picture too.

 
 
 D can't do const member functions. You can use design-by-contract, though,
 which is a better way (because C++'s type constness does not guarrantee
 run-time constness).
 


while this is true, 90% of debug time is saved if the error is caught by 
the compiler...
i.e. running it and reproducing the bug takes at least 10x longer than 
finding it when building.

so having the equivalent of static_assert for contracts would be ideal.

of course, as with almost any useful compiler feature,
the result of an compile-time assertion is either
true, false or don't know :-)
Apr 27 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 D can't do const member functions. You can use design-by-contract, though,
 which is a better way


That's complete rubbish! const is a compile-time mechanism, and DbC is runtime.
How can it possibly be better?


 (because C++'s type constness does not guarrantee
 run-time constness).


Why oh why oh why do people think that this matters? I have heard this a hundred
times on this NG, and it's utter crap. It does not matter that one can
const_cast, any more than it matters that any other high-level language can be
subverted. The point is that there is a mechanism for encouraging and supporting
robustness when used by professional people. You cannot account for Machiavelli,
and it is foolish to try. For some reason, the general impression on this NG is
that const is designed to do so, and DbC succeeds in doing so. Neither is true!

The *only* reason for not having const in D is that it complicates the compiler
beyond the level at which Walter is prepared to work with it. Everything else is
just hot air.
Apr 27 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message

 Why oh why oh why do people think that this matters? I have heard this a


hundred times on this NG, and it's utter crap.

Spoken like a true Yorkshireman!  There's nothing quite like calling a Spade
"a Spade". However, being a Scot I balk at your restraint over the wide
range of gleefully more colourful phrases <g>
Apr 27 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c6mlen$53j$1 digitaldaemon.com...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message

 Why oh why oh why do people think that this matters? I have heard this a


 hundred times on this NG, and it's utter crap.

 Spoken like a true Yorkshireman!  There's nothing quite like calling a Spade
 "a Spade". However, being a Scot I balk at your restraint over the wide
 range of gleefully more colourful phrases <g>


Nice to know that at least one man on this NG will see the restraint in my post,
since I was trying, Ringo, I was trying _real_ _hard_.
Apr 27 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c6mhpg$30ct$1 digitaldaemon.com...

 The *only* reason for not having const in D is that it complicates the


compiler

 beyond the level at which Walter is prepared to work with it. Everything


else is

 just hot air.


Here's some more hot air for ya: <g>

<hot air>
The reason const as a type modifier is not in D is because the cost is high
(in terms of complexity of the language, and complexity of the
implementation) and the benefits are slight. I've used const for 15 years
and not once has it ever found or prevented a bug. Because it can be legally
subverted, it's  useless as a hint to the optimizer. For the final
indignity, it's ugly to have 'const' appear all over the place (doing a wc
on some headers shows that 'const' is usually among the most frequently
occurring words).
</hot air>
May 09 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Mate, you're just proving my point. I said "beyond the level at which Walter is
prepared to work with it".

1. I accept that it complicates the compiler
2. I have used it for 14 years, and it has helped on countless occasions. I
would
estimate it to be at least in the 10,000s.
3. I don't care what it looks like, and don't find it ugly because I'm used to
using it. The same could be said for any syntax - other than VB, and K&R
bracing - and these things are, IMO, highly irrelevant.

So my statement remains 100% correct. It's out because it's your personal
opinion
that it's not worth the cost. I respect your opinion and your experience highly,
but it's not the totality of all software engineering lore. It is certainly not
in this case.

I believe const is an incredibly powerful tool, and because I believe that, I
use
it as such. Hence, my experience bears out that belief. *You* know just how many
perverse ways I've found to enforce design through use of const, because you've
already read the book. ;)

Conversely, you don't believe it's useful or powerful - and I think it's
perfectly understandable that you're biased against it, because you're a
compiler
writer and will have had all kinds of headaches implementing const - and
consequently it proves to be neither when you use it.


"Walter" <newshound digitalmars.com> wrote in message
news:c7ktc6$18km$1 digitaldaemon.com...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c6mhpg$30ct$1 digitaldaemon.com...

 The *only* reason for not having const in D is that it complicates the


 compiler

 beyond the level at which Walter is prepared to work with it. Everything


 else is

 just hot air.


 Here's some more hot air for ya: <g>

 <hot air>
 The reason const as a type modifier is not in D is because the cost is high
 (in terms of complexity of the language, and complexity of the
 implementation) and the benefits are slight. I've used const for 15 years
 and not once has it ever found or prevented a bug. Because it can be legally
 subverted, it's  useless as a hint to the optimizer. For the final
 indignity, it's ugly to have 'const' appear all over the place (doing a wc
 on some headers shows that 'const' is usually among the most frequently
 occurring words).
 </hot air>
May 09 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c7l3hk$1hm9$1 digitaldaemon.com...

 1. I accept that it complicates the compiler
 2. I have used it for 14 years, and it has helped on countless occasions.


I would

 estimate it to be at least in the 10,000s.


I won't dispute that you find it useful. But useful for what? Making a
program const-correct? Is that a circular requirement <g> ? I have gone
through the exercise of making large programs const-correct. Were there a
lot of const-correct errors? Yes, hundreds. Were any of them a bug? Nope.
Not one. On the other hand, when C added function prototyping, that was a
huge win in eliminating bugs (it was such a huge win that my compiler
implemented a lint-like 'autoprototyping' feature for K&R code, which found
bug after bug). No such win happened when const was added.


 3. I don't care what it looks like, and don't find it ugly because I'm


used to

 using it. The same could be said for any syntax - other than VB, and K&R
 bracing - and these things are, IMO, highly irrelevant.


I strongly disagree that the aesthetics are irrelevant. In my experience,
there's a strong correlation between code that looks good and code that
works well. Aesthetics have been a major factor in the design of D - I want
D code to look good on the page. That's why I agonized for such a long time
trying to find a template syntax that looked good (C++'s does not). I enjoy
reading other peoples' code when they spend the time to make it look good.
If it looks ugly, I don't want to read it.

It's like designing an airplane. If it looks good, it'll probably fly good.
Compare the Wright Flyer with their contemporary contraptions that did not
fly. Continue on with the Sopwith Camel, the DC-3, the Mustang, the 707, the
F16. This observation applies over and over across the spectrum of
engineering.


 So my statement remains 100% correct. It's out because it's your personal


opinion

 that it's not worth the cost. I respect your opinion and your experience


highly,

 but it's not the totality of all software engineering lore. It is


certainly not

 in this case.


I admit it's my opinion <g>.


 I believe const is an incredibly powerful tool, and because I believe


that, I use

 it as such. Hence, my experience bears out that belief. *You* know just


how many

 perverse ways I've found to enforce design through use of const, because


you've

 already read the book. ;)

 Conversely, you don't believe it's useful or powerful - and I think it's
 perfectly understandable that you're biased against it, because you're a


compiler

 writer and will have had all kinds of headaches implementing const - and
 consequently it proves to be neither when you use it.


Actually, I started out as a strong believer in const and used it, even
after implementing it (in the C compiler). There are harder things
implemented in the compiler - like auto destructors - because they have a
strong utility. Ease of implementation is a consideration, but if that was
all there was to it, I'd be writing a toy Pascal compiler.
May 09 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Walter wrote:


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c7l3hk$1hm9$1 digitaldaemon.com...
  


1. I accept that it complicates the compiler
2. I have used it for 14 years, and it has helped on countless occasions.
    


I would
  


estimate it to be at least in the 10,000s.
    


I won't dispute that you find it useful. But useful for what? Making a
program const-correct? Is that a circular requirement <g> ? I have gone
through the exercise of making large programs const-correct. Were there a
lot of const-correct errors? Yes, hundreds. Were any of them a bug? Nope.
Not one. On the other hand, when C added function prototyping, that was a
huge win in eliminating bugs (it was such a huge win that my compiler
implemented a lint-like 'autoprototyping' feature for K&R code, which found
bug after bug). No such win happened when const was added.

  


3. I don't care what it looks like, and don't find it ugly because I'm
    


used to
  


using it. The same could be said for any syntax - other than VB, and K&R
bracing - and these things are, IMO, highly irrelevant.
    


I strongly disagree that the aesthetics are irrelevant. In my experience,
there's a strong correlation between code that looks good and code that
works well. Aesthetics have been a major factor in the design of D - I want
D code to look good on the page. That's why I agonized for such a long time
trying to find a template syntax that looked good (C++'s does not). I enjoy
reading other peoples' code when they spend the time to make it look good.
If it looks ugly, I don't want to read it.
  


What about if "in"'d objects members and array members where made const 
automaticly?  You wouldn't need a keyword at all and it would fill most 
of the gaps in D not having const.

ie
class A
{
int t;

void func() {}

void func2() {t = 10;}

}

void func(A a)
{
    a.func(); //ok
    a.t = 10; //not ok
    a.func2(); //not ok
    a = new A(); //ok but won't be returned
}

void func(int [] a)
{
    a[10] = 5; //not ok
    a.length = 20; //not ok
}

Of course you'd have all the problems with determining if a member is 
actually changing something or not.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 09 2004
parent reply Mike Swieton <mike swieton.net> writes:
On Mon, 10 May 2004 09:01:34 +0800, J Anderson wrote:

 What about if "in"'d objects members and array members where made const 
 automaticly?  You wouldn't need a keyword at all and it would fill most 
 of the gaps in D not having const.


I like this a lot, myself. In fact, I had wondered why 'in' parameters were
not const already. I would suggest a middle ground: methods can be const,
like:

class A {
int foo() const;
}

And then have all 'in' parameters automatically be const. That would require
vastly less magic to detect non-const function calls. Thoughts?

Mike Swieton
__
So he thought it was impossible, and told me not to do it. So I did it anyway.
	- Warren Robinett
May 09 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Mike Swieton wrote:


On Mon, 10 May 2004 09:01:34 +0800, J Anderson wrote:
  


What about if "in"'d objects members and array members where made const 
automaticly?  You wouldn't need a keyword at all and it would fill most 
of the gaps in D not having const.
    


I like this a lot, myself. In fact, I had wondered why 'in' parameters were
not const already. I would suggest a middle ground: methods can be const,
like:

class A {
int foo() const;
}

And then have all 'in' parameters automatically be const. That would require
vastly less magic to detect non-const function calls. Thoughts?

Mike Swieton
__
So he thought it was impossible, and told me not to do it. So I did it anyway.
	- Warren Robinett

  


I would like not to have to type const at all.  You'd think the compiler 
could be smart enough to work out which methods are const.  Of course, 
if someone changes the specifications of a function (forgets it's used 
as const), then there will be trouble.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 09 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
J Anderson wrote:

 I would like not to have to type const at all.  You'd think the compiler
 could be smart enough to work out which methods are const.  Of course,
 if someone changes the specifications of a function (forgets it's used
 as const), then there will be trouble.


1. The compiler will never be able to track which values are const. This
might work if you do full inlining and full data flow analysis, but as soon
as you pass around parameters between functions, the compiler will be lost.

2. Even if the compiler were able to do such a thing, it would miss the
point: The "const" discussion is not about optimization, but far more
important, about safety and documentation. Just think of "const" as a
special kind of a contract, that can even be checked by the compiler.
May 09 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Norbert Nemec wrote:


J Anderson wrote:
  


I would like not to have to type const at all.  You'd think the compiler
could be smart enough to work out which methods are const.  Of course,
if someone changes the specifications of a function (forgets it's used
as const), then there will be trouble.
    


1. The compiler will never be able to track which values are const. This
might work if you do full inlining and full data flow analysis, but as soon
as you pass around parameters between functions, the compiler will be lost.
  


Normally in C++ every const function is checked for constnes .  All I'm 
saying is that every function could be checked for constness and then 
const added to the definition in the object file/lib file.  If what your 
saying is correct, the compiler would never be able to certify that a 
const is indeed correct in the first place.


2. Even if the compiler were able to do such a thing, it would miss the
point: The "const" discussion is not about optimization, but far more
important, about safety and documentation. Just think of "const" as a
special kind of a contract, that can even be checked by the compiler.
  


I already pointed that out.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 10 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
J Anderson wrote:


 Norbert Nemec wrote:

1. The compiler will never be able to track which values are const. This
might work if you do full inlining and full data flow analysis, but as
soon as you pass around parameters between functions, the compiler will be
lost.
  


 Normally in C++ every const function is checked for constnes .  All I'm
 saying is that every function could be checked for constness and then
 const added to the definition in the object file/lib file.  If what your
 saying is correct, the compiler would never be able to certify that a
 const is indeed correct in the first place.


The compiler can check it, if it has access to all the code. If I understand
it correctly, in D, this is always the case. Otherwise, const would clearly
have to be part of the interface of a module. I guess, I'm just not happy
about the idea of mixing interface and implementation in the way D does it.
May 10 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Norbert Nemec wrote:


J Anderson wrote:

  


Norbert Nemec wrote:
    


1. The compiler will never be able to track which values are const. This
might work if you do full inlining and full data flow analysis, but as
soon as you pass around parameters between functions, the compiler will be
lost.
 
      


Normally in C++ every const function is checked for constnes .  All I'm
saying is that every function could be checked for constness and then
const added to the definition in the object file/lib file.  If what your
saying is correct, the compiler would never be able to certify that a
const is indeed correct in the first place.
    


The compiler can check it, if it has access to all the code. If I understand
it correctly, in D, this is always the case. Otherwise, const would clearly
have to be part of the interface of a module. I guess, I'm just not happy
about the idea of mixing interface and implementation in the way D does it.
  


If D had an optional interface like C++, then you would put it in the 
interface manually.  Since D automaticly generates an invisible 
interface it could include it automaticly.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 10 2004
prev sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c7m7uq$33k$1 digitaldaemon.com>, Walter says...

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c7l3hk$1hm9$1 digitaldaemon.com...

 1. I accept that it complicates the compiler
 2. I have used it for 14 years, and it has helped on countless occasions.


I would

 estimate it to be at least in the 10,000s.


I won't dispute that you find it useful. But useful for what? Making a
program const-correct? Is that a circular requirement <g> ? I have gone
through the exercise of making large programs const-correct. Were there a
lot of const-correct errors? Yes, hundreds. Were any of them a bug? Nope.


The one time that I found it useful is for serialization: if you need to use
read-only and read-write locks to serialize access to parts of a struct, then
you need to know who is modifying and who is not.

I was able to solve this for a large C++ module by making methods const and
using "read-write" only on the modules that the compiler choked on.

So it helped a little; Not that this alone justifies it.

But some kind of analysis to prevent "in" parameters from being copied when they
are not modified might be nice.

Kevin
May 09 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c7n5ir$1c2p$1 digitaldaemon.com>, Kevin Bealer says...

In article <c7m7uq$33k$1 digitaldaemon.com>, Walter says...

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c7l3hk$1hm9$1 digitaldaemon.com...

 1. I accept that it complicates the compiler
 2. I have used it for 14 years, and it has helped on countless occasions.


I would

 estimate it to be at least in the 10,000s.


I won't dispute that you find it useful. But useful for what? Making a
program const-correct? Is that a circular requirement <g> ? I have gone
through the exercise of making large programs const-correct. Were there a
lot of const-correct errors? Yes, hundreds. Were any of them a bug? Nope.




(cough) In this case, by "serialization" I meant synchronizing between threads,
not marshalling data.


The one time that I found it useful is for serialization: if you need to use
read-only and read-write locks to serialize access to parts of a struct, then
you need to know who is modifying and who is not.

I was able to solve this for a large C++ module by making methods const and
using "read-write" only on the modules that the compiler choked on.

So it helped a little; Not that this alone justifies it.

But some kind of analysis to prevent "in" parameters from being copied when they
are not modified might be nice.

Kevin
May 09 2004
prev sibling parent "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c7ktc6$18km$1 digitaldaemon.com...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c6mhpg$30ct$1 digitaldaemon.com...

 The *only* reason for not having const in D is that it complicates the


 compiler

 beyond the level at which Walter is prepared to work with it. Everything


 else is

 just hot air.


 Here's some more hot air for ya: <g>

 <hot air>
 The reason const as a type modifier is not in D is because the cost is


high

 (in terms of complexity of the language, and complexity of the
 implementation) and the benefits are slight. I've used const for 15 years
 and not once has it ever found or prevented a bug. Because it can be


legally

 subverted, it's  useless as a hint to the optimizer. For the final
 indignity, it's ugly to have 'const' appear all over the place (doing a wc
 on some headers shows that 'const' is usually among the most frequently
 occurring words).
 </hot air>


It has not prevented bugs for me, either. But it prevented me from calling
non-const methods accidentally.
May 09 2004
prev sibling parent Serg Kovrov <Serg_member pathlink.com> writes:
In article <c6ma69$2i1m$1 digitaldaemon.com>, hellcatv hotmail.com says...

Hello, I've been completely enthusiastic by what I've seen about D, and am
considering porting some of my projects to D.

However, one thing does come to mind that I wished to ask about: Const member
functions.

As a C++ programmer I have found it extremely useful to have const member
functions.  


I feel exactly the same. The D is very promising for me, but lack of const
methods and parameter modifiers are fly in the ointment. The const plays
significant role in design of my applications for many yeas.

Walter, could You please, change your mind eventually. As I see many of your
language's users need this feature badly.

Thanks.

-- serg
Jan 25 2006