Why there are no 'physical' object variables (only references)?

[Steve Horne]

On Tue, 12 Sep 2006 17:49:44 +0300, Kristian <kjkilpi at gmail.com>
wrote:

>C++ const is better than nothing. Hopefully there will be a solution that  
>will suit everybody, more or less.

As far as the meaning of 'const' goes, I agree. It represents a
specific, restricted meaning of 'const'. Choosing a reasonable word
for an intended meaning does not mean that all possible meanings of
that word must be valid.

If you're going to fuss about keyword meanings, I'd focus on 'real',
'ireal' and 'creal'. 'Real' cannot handle irrational numbers, and it
can't handle rationals properly either. It does not handle all
possible meanings of 'real' - not even within a given range and
precision, unless you define those terms in a floating-point specific
way. And as for 'imaginary real' and 'complex real', the important
phrase here is 'contradiction in terms'.

The keywords convey an intended meaning. It's a matter of common
sense. Being too literal gets you no-where. Being an Aspie, I have
plenty of experience of this :-(

But I have mixed feelings about C++ const. It has caught errors for
me, but not often, and quite often those errors wouldn't exist without
'const' anyway. For instance...

class c_Test
{
  private:
    int m_Var;

  public:
//  int  Var () const  {  return m_Var;  }
    int& Var ()        {  return m_Var;  }
};

The point of this is the 'missing' method. You can read the value of
m_Var if you have a non-const reference to c_Test. Mark that reference
as const, and suddenly you can no longer do the needed read access -
you have to go back and add the const overloaded access method.

Of course I understand the efficiency benefits, but it's not very
intuitive. And there wouldn't have been any error using simple getter
and setter functions instead of this C++ specific pattern.

What's more, you can end up chasing your tail. You start with a few
const references. Then more and more things need a const tag or a
const variant as a result. Member functions. References. Pointers.
Member pointers.

Pointers even need to be told whether it is the pointer that is const
or the value pointed to, or both for that matter.

So the dependencies mean you have three options...

1.  Make constness into something you think about all the time.
2.  Don't do constness at all.
3.  Do half-hearted constness and have loads of const-casts,
    defeating the point.

And then, your code has to work with someone elses... Someone who has
a very different approach.

Personally, I tend towards case 1 - I can be a perfectionist at times.
Trouble is, this can be a distraction from the real logic. And that
can cause logical errors that wouldn't have happened if my attention
hadn't been split.

D has been a bit of a relief, really.

-- 
Remove 'wants' and 'nospam' from e-mail.