Re: Constness for user-defined by-reference types

On Jan 3, 10:15 pm, SG <s.gesem...@gmail.com> wrote:


The OP is not confused about the semantics and has not misunderstood
the problem. You can see that by the way that his example in the
original post and subsequent post is correct. Every time this topic
comes up, people keep on claiming that this kind of complaint is based
on a misunderstanding of how C++ works. Apparently no amount of
completely correct exposition seems to convince people that this is
not a misunderstanding.

The OP is instead _complaining_ about how the semantics work. Not
misunderstanding them. He wants C++ to provide a mechanism to make the
semantics of his classes a bit different.

The complaint restated is this:

Imagine you have a type with copy semantics eg, std::vector. You can
write a function:

void foo(const vector<int>& i);

i behaves like it is conceptually const. There is no way of modifying i
[0]. Now imagine you have a class with reference semantics, eg a
reference counted version of std::vector. It may for instance
internally be implemented with a shared_ptr<vector<int> > and forward
on all the functions of vector, eg:

template<class C> class refvector
{
    private:
     shared_ptr<vector<C> > vec;

    public:
       refvector()
       :vec(new vector<C>)
       {}

       C& operator[](size_t i)
       {
           return (*vec)[i];
       }

       const C& operator[](size_t i) const
       {
           return (*vec)[i];
       }
   // etc

};

If you write a function like this:

void bar(const refvector<int>& j)
{
    refvector<int> nonconst_j(j);
    nonconst_j[0] = 0xdeadbeef; //conceptually modify j.

}

Then j is not conceptually const, as illustrated, despite the
similarity between the interface of vector and refvector and the
similarity between the function definitions. The complaint is that C++
has no mechanism for making the two examples have the same semantics.
I.e. it has no mechanism for making the top-level const stronger.

Of course is possible to write instead:

void bar2(const refvector<const int>& j);

and make sure that that refvector<int> knows how to turn itself in to
a refvector<const int>. Of course, the code looks different, meaning
that the uniformity of interface is spoiled. Imagine writing a rather
generic function which works on vector like objects, provided that
they provide operator[] and a .size() method:

One may wish to write the function like this:

template<class T> int sum_vector_like_object(const T& v)
{
    //make a temp copy of v
    T tmp_v(v);
    //sort_inplace is a domain specific sorting function which also
uses operator[] and .size()
    sort_inplace(v); //This improves the precision for summing an array
of positive reals
    double sum=0;
    for(int i=0; i < tmp_v.size(); i++)
       sum += tmp_v[i];
    return sum;

}

If one initially write the function with std::vector and std::valarray
in mind and then passes a refvector, the code is broken in that the
argument is modified. The problem is that C++ does not allow
sufficient control over the semantics for one to design refvector that
produces an error in the above function.

Essentially what is missing is the ability to optionally make top-
level const stronger so that it propagates further, allowing one to
use const to further protect oneself from one's own mistakes.

This is not based on a misunderstanding of C++ semantics. It is a
complaint based on the inability to make reference classes
conceptually const like value classes. This is a complaint I happen to
agree with.

-Ed
--
(You can't go wrong with psycho-rats.)(http://mi.eng.cam.ac.uk/~er258)

/d{def}def/f{/Times s selectfont}d/s{11}d/r{roll}d f 2/m{moveto}d -1
r 230 350 m 0 1 179{ 1 index show 88 rotate 4 mul 0 rmoveto}for/s 12
     d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage

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