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/

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

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

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

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

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

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

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

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

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