"Balog Pal (mh)" wrote:
>
> (followup from a thread on clcm & emalis)
>
> [base problem: why delete works with pointers to const]
> >Balog> I see no problem with forcing a const-cast. Anyone can point a
> >Balog> situation where deleting through const pointers is really good
> >Balog> and needed, and also something comes up requently?
>
> Andrew Koenig writes:
>
> >The most important case, in my opinion, is
> >
> > T* tp = new T;
> > // ...
> > delete tp;
> >
> >in a context where you don't know the type that T represents because it
> >is a template parameter or depends in some way on a template parameter.
> >
> >What's really bad is that this code looks just fine until someone tries
> >to instantiate it with T being `const S' for some S.
>
> That's a problem indeed. But if allowind delete on const pointers were a
> supposed solution to this thing I feel quite disappointed.
>
> The cv-qualifiaction is half-handed as is. You can append 'const' to add
> const, and if you happen to add it an extra time, it's ignored (or flagged
> as error in other situations...). But to remove it you're expected to supply
> an originally non-const type in the cast expression.
> That is bad. A set of extra keywords (like non_const, non_volatile) would
> solve that quite fine, and those would be usable in a big deal of code. Like
> for the above:
...

The very effect can be accomplished with partial specialization (no new
keywords are necessary):

template <class T>
struct const_type
{
    typedef T nonconst_type;
};

template <class T>
struct const_type<const T>
{
    typedef T nonconst_type;
};

template <class T>
void foo ()
{
    typedef typename const_type<T>::nonconst_type nonconst_type;

    nonconst_type x;

    x = nonconst_type ();
}

int main ()
{
    foo <const int>();
}


Regards
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

(followup from a thread on clcm & emalis)

[base problem: why delete works with pointers to const]
>Balog> I see no problem with forcing a const-cast. Anyone can point a
>Balog> situation where deleting through const pointers is really good
>Balog> and needed, and also something comes up requently?

Andrew Koenig writes:

>The most important case, in my opinion, is
>
> T* tp = new T;
> // ...
> delete tp;
>
>in a context where you don't know the type that T represents because it
>is a template parameter or depends in some way on a template parameter.
>
>What's really bad is that this code looks just fine until someone tries
>to instantiate it with T being `const S' for some S.


That's a problem indeed. But if allowind delete on const pointers were a
supposed solution to this thing I feel quite disappointed.

The cv-qualifiaction is half-handed as is. You can append 'const' to add
const, and if you happen to add it an extra time, it's ignored (or flagged
as error in other situations...). But to remove it you're expected to supply
an originally non-const type in the cast expression.
That is bad. A set of extra keywords (like non_const, non_volatile) would
solve that quite fine, and those would be usable in a big deal of code. Like
for the above:

 non_const T* tmp = const_cast< non_const T*>(tp);
 delete tmp;

In regular code adding the non_const in the casts where intention is to
remove constness, or expression of having a non-const
object/pointer/anything is important, it would be nice, documenting, and
leaving more elbowroom for correctness.

As a side-effect it would remove the need of being able to delete non-const
pointers.

Paul
















---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Balog Pal (mh)" wrote:
...
> The cv-qualifiaction is half-handed as is. You can append 'const' to add
> const, and if you happen to add it an extra time, it's ignored (or flagged
> as error in other situations...). But to remove it you're expected to supply
> an originally non-const type in the cast expression.
> That is bad. A set of extra keywords (like non_const, non_volatile) would
> solve that quite fine, and those would be usable in a big deal of code. Like
> for the above:
>
>  non_const T* tmp = const_cast< non_const T*>(tp);
...

Well, you can achieve the desired effect without addition of a new
keyword:

 template <class T> unqualify
 {
  typedef T type;
  typedef T non_const;
  typedef T non_volatile;
 };
 template <class T> unqualify<const T>
 {
  typedef T type;
  typedef T non_const;
  typedef const T non_volatile;
 };
 template <class T> unqualify<volatile T>
 {
  typedef T type;
  typedef volatile T non_const;
  typedef T non_volatile;
 };
 template <class T> unqualify<const volatile T>
 {
  typedef T type;
  typedef volatile T non_const;
  typedef const T non_volatile;
 };

unqualify<T>::type is T, with all cv-qualifications removed.
unqualify<T>::non_const removes only the 'const' qualifier, retaining
the 'volatile' qualifier if present. unqualify<T>::non_volatile removes
the volatile qualifier, retaining 'const' if present. Using these, your
example would become:

 unqualify<T>::non_const *tmp = const_cast<unqualify<T>::non_const
*>(tp);

This is a little clumsier than the syntax you've suggested. However,
when the existing language can already do something without too much
clumsiness, the committee is usually reluctant to provide a new keyword
just to make it a little less clumsy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]