Prev: Template aliases with default arguments and parameter packs
Next: I keep running into long term c++ programmers who refuse to use exceptions
From: Nick Hounsome on 28 Mar 2010 05:20
On Mar 26, 8:43 pm, "Daniel T." <danie...(a)earthlink.net> wrote:
> Nick Hounsome <nick.houns...(a)googlemail.com> wrote:
>
> > I attribute my mistake to the fact that being in the "no const" camp I
> > only ever use const for reference and pointer parameters where it DOES
> > make a difference.
>
> So being in the "no const" camp means to use const everywhere it is
> useful but not where it isn't? How is that no const?
>
> I thought someone was only in the "no const" camp if they only used
> const where the compiler forced them to...

I meant that I don't use const except where it has meaning for the
CALLER of a function.
i.e. where you gaurantee not to alter things for the caller.

I'm currently working on some stuff that is relevant to the original
topic and yes I am having to do some extra typing to cast
away constness to access legacy functions that don't use const but
that is a lot less work than the trawling through the source
to see whether or not they actualy modify things passed as X* instead
of const X*.

When, in the past, I have had to modify stuff with const value
parameters I have often created a non-const local but I now see that I
should have just changed the signature as it would not break any
existing code logic or even the ABI.




--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andrew on 29 Mar 2010 06:16
On 29 Mar, 01:34, Walter Bright <newshou...(a)digitalmars.com> wrote:
> Peter C. Chapin wrote:
>> void f(const int x)
>> {
>> const int y = 2*x + 1;
>> // Here x and y are local constants.
>> }
>
>> But... is my code better for this?
>
> I think so, it's a style I've been slowly adopting.

I must confess, I don't see it in C++ that often and haven't been
using it myself. But I can see the benefit because of my experience of
eclipse with java. The IDE puts the final in for you. Nearly all the
time it makes a small but noticable improvement so I suppose that
means I should start adding const in C++. Now if only I could find a C+
+ IDE that will do it for me....

Regards,

Andrew Marlow


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Nick Hounsome on 31 Mar 2010 23:15
On 25 Mar, 13:27, Tonni Tielens <tonnitiel...(a)gmail.com> wrote:
> Interesting topic. I was thinking about this a while ago. Why does
> Java for instance not have a const mechanism. E.g. in Java you can say
> a reference itself cannot change, but you cannot prevent someone from
> modifying an objects state if he has a reference to it. Why is const
> correctness never introduced in a language like Java and more
> important: why do people not seem to miss it?

They do miss it every time they get an exception because something
they thought they could change turns aout to be a protective wrapper.

I'm not an expert but I think that there is one practical reason why
Java & .NET don't have const like C++ - You can't gaurantee that it is
enforced because the enforcing has to be done by the user of the class
rather than the class implementation - This is because, although
objects can be const in the context of the caller they might not be so
in a different context.
Whilst the standard compilers would obviously always do the right
thing that is only protection against mistakes not against deliberate
hacking at the byte code level where you could effectively cast away
the constnes.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Miles Bader on 1 Apr 2010 16:37
Nick Hounsome <nick.hounsome(a)googlemail.com> writes:
> I'm not an expert but I think that there is one practical reason why
> Java & .NET don't have const like C++ - You can't gaurantee that it is
> enforced because the enforcing has to be done by the user of the class
> rather than the class implementation - This is because, although
> objects can be const in the context of the caller they might not be so
> in a different context.
> Whilst the standard compilers would obviously always do the right
> thing that is only protection against mistakes not against deliberate
> hacking at the byte code level where you could effectively cast away
> the constnes.

Er, but all of that is the same in C++...

const in C++ is _not_ a guarantee of what you (or the compiler) can
assume, it's a statement of what you (probably) shouldn't (note, not
"can't") do.

Thus, C++ compilers cannot really use const for optimization purposes
unless they can track _all_ references to an object, and if/when they
can do that, they don't need const.

"const" is really for humans, not compilers.

-Miles

--
You can hack anything you want, with TECO and DDT.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: Template aliases with default arguments and parameter packs
Next: I keep running into long term c++ programmers who refuse to use exceptions