Jonathan Turkanis wrote:
> "Dietmar Kuehl" <dietmar_kuehl@yahoo.com> wrote:
>> Just to avoid any confusion: I *was* very serious about this! I
>> encounter the problem of identical functions differing only by
>> const/volatile qualifications quite often and I would like an
>> approach to deal with it. Personally, I don't consider const_cast
>> the right approach.
>
> Sorry, I wasn't sure. I wan't trying to ridicule your suggestion -- I
> was just having fun maximizing obfuscation.

Nothing to be sorry about: I just wanted to avoid obfuscation and
confusion.

> I also don't like to have to write function definitions which are the
> same except for const. What I don't understand about your proposal is
> this: what, exactly, are the values of the template parameter Const in
> the various specializations?

Well, to be honest, I don't have any reasonably worked out proposal
on this stuff. Just the feeling that the idea in the original did
not really provide the needed facilities. In my mind more or less the
whole template mechanism of C++ will be reworked to bring it into
line with what people are using it for. In this bigger context I'd
like to see eg. the const issue addressed.

> Are they strings, sequences of tokens,
> abstract 'cv-qualifier objects' ... ? In particular, what is the value
> of the parameter in the non-const case? The 'empty cv-qualifier', I
> suppose. How do you write it? I guess you could write f<>() to
> explicitly call the non-const, non-volatile version of f, but usually
> this notation means 'deduce the template arguments'.

I don't know how to write such specializations. One approach could be
the use of 'mutable' to mean the absence of both 'const' and 'volatile'.
.. or 'auto' to give the most underused keyword a place. Personally,
I consider myself a library guy: I'd like a way to parameterize
functions, classes, or whatever can be a template (eg. namespaces,
unions, requirements, ...) on their cv-ness. Let the core people figure
out the details in a bigger context :-)
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Jonathan Turkanis" wrote:
> "Dietmar Kuehl" <dietmar_kuehl@yahoo.com> wrote in message
> news:bv1m0j$mnu20$1@ID-86292.news.uni-berlin.de...
>> Jonathan Turkanis wrote:
>> > Something tells me Dietmar wasn't being quite serious,
>>
>> Just to avoid any confusion: I *was* very serious about this! I
>> encounter the problem of identical functions differing only by
>> const/volatile qualifications quite often and I would like an
>> approach to deal with it. Personally, I don't consider const_cast
>> the right approach.
>>
>
> Sorry, I wasn't sure. I wan't trying to ridicule your suggestion -- I
> was just having fun maximizing obfuscation.
>
> I also don't like to have to write function definitions which are the
> same except for const. What I don't understand about your proposal is
> this: what, exactly, are the values of the template parameter Const in
> the various specializations? Are they strings, sequences of tokens,
> abstract 'cv-qualifier objects' ... ? In particular, what is the value
> of the parameter in the non-const case? The 'empty cv-qualifier', I
> suppose. How do you write it? I guess you could write f<>() to
> explicitly call the non-const, non-volatile version of f, but usually
> this notation means 'deduce the template arguments'.

Might it perhaps be possible to extend the syntax of cv-qualifiers to
allow "<" boolean-constant-expression ">" after a qualifier, where
the boolean-constant-expression controls whether the qualifier really
applies?  This would avoid the need to add a new kind of template
parameter.  However, I don't know whether it would provide sufficient
expressive power.  Some means of expressing and manipulating sets of
qualifiers as entities in their own right might be useful.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Ben Hutchings" <do-not-spam-benh@bwsint.com> wrote in message:
> "Jonathan Turkanis" wrote:

> >
> > I also don't like to have to write function definitions which are
the
> > same except for const. What I don't understand about your proposal
is
> > this: what, exactly, are the values of the template parameter
Const in
> > the various specializations? Are they strings, sequences of
tokens,
> > abstract 'cv-qualifier objects' ... ? In particular, what is the
value
> > of the parameter in the non-const case? The 'empty cv-qualifier',
I
> > suppose. How do you write it? I guess you could write f<>() to
> > explicitly call the non-const, non-volatile version of f, but
usually
> > this notation means 'deduce the template arguments'.
>
> Might it perhaps be possible to extend the syntax of cv-qualifiers
to
> allow "<" boolean-constant-expression ">" after a qualifier, where
> the boolean-constant-expression controls whether the qualifier
really
> applies?  This would avoid the need to add a new kind of template
> parameter.  However, I don't know whether it would provide
sufficient
> expressive power.  Some means of expressing and manipulating sets of
> qualifiers as entities in their own right might be useful.

I think you could get the effect of manipulating sets of qualifiers
using enable_if. Ths removes some of the desired simplicity, but it
might be needed only rarely:

    template<bool Const, bool Volatile>
    typename enable_if<
        !Volatile || Const,
        const<Const> volatile<Volatile>string
    >::type
    get_name() const<Const> volatile<Volatile>;

This would define versions of get_name() for all combinations of
cv-qualifiers except volatile alone.

I'm starting to like Dietmar's idea of using mutable to indicate lack
of
constness and volatility, so that you could write f<mutable>(),
f<const volatile>(), etc. I still don't like the notation

      template<const Const> etc.

because it gives 'const' a distinguished role; why not

      template<volatile Volatile> etc. ?

A neutral proposal would use:

     template<qualifier Q>
     Q string get_name() Q;

But of course, this introduces a new keyword.

-------

Best Regards,
Jonathan


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

technews@kangaroologic.com ("Jonathan Turkanis") wrote:
> A neutral proposal would use:
>
>      template<qualifier Q>
>      Q string get_name() Q;
>
> But of course, this introduces a new keyword.

In the presentation of the ideas for the C++/CLI binding at the last C++
committee meeting at Kona, Herb showed how Microsoft worked around the
introduction of new keywords: they used words which had a predefined
meaning only in a particular context. This approach could be used to
restrict the use of 'qualifier' only in template argument lists. Roughly
the only conflicts this would introduce are things like

  #define qualifier something

and

  enum qualifier { foo, bar };
  template <qualifier Q> ...

To avoid conflicts while not favouring any of the expected keywords, we
could use one of the overused keywords, ie. 'static', or one of the underused
keywords, ie. 'auto', instead. In the end, I don't care that much about the
details as long as the general feature becomes available.

This actually brings up a much more important point than the general syntax
details: is anybody volunteering to write a proposal? ... or is there already
something in this direction on the table?
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:TpNlcFCdqFDAFwyJ@robinton.demon.co.uk...
> In article <400b8651$0$22625$61ce578d@news.syd.swiftdsl.com.au>, cadull
> <cadullh.no@spam.icqmail.com> writes
> >I use const extensively but find it tiresome creating const and non const
> >functions with identical content, e.g. accessor methods. My suggestion is
> >the addition of an aconst keyword. This would compile as both a const and
> >non const function. E.g.
>
> If they have identical content why would you want a non-const version?

It could call a function where there was a difference between const and
non-const, even though that particular function was identical for const and
non-const.

Ken


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <busq64$f26$1@eeyore.INS.cwru.edu>, Ken Alverson
<USENET.Ken@Alverson.net> writes
>"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
>news:TpNlcFCdqFDAFwyJ@robinton.demon.co.uk...
>> In article <400b8651$0$22625$61ce578d@news.syd.swiftdsl.com.au>, cadull
>> <cadullh.no@spam.icqmail.com> writes
>> >I use const extensively but find it tiresome creating const and non const
>> >functions with identical content, e.g. accessor methods. My suggestion is
>> >the addition of an aconst keyword. This would compile as both a const and
>> >non const function. E.g.
>>
>> If they have identical content why would you want a non-const version?
>
>It could call a function where there was a difference between const and
>non-const, even though that particular function was identical for const and
>non-const.

It seems to me that this would be rare and not worth the cost of
changing the language. While I am generally against 'cut and paste' it
would seem appropriate in this case, or if you really must:

void mytype::foo(){
#include impl_code
}

void mytype::foo()const{
#include impl_code
}

But if you truly often want to have functions that are identical in
source code but have that source compile differently you have a very
unusual coding style.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 24 Jan 2004 18:56:03 +0000 (UTC), francis@robinton.demon.co.uk
(Francis Glassborow) wrote:

> It seems to me that this would be rare and not worth the cost of
> changing the language. While I am generally against 'cut and paste' it
> would seem appropriate in this case, or if you really must:

> void mytype::foo(){
> #include impl_code
> }

> void mytype::foo()const{
> #include impl_code
> }

> But if you truly often want to have functions that are identical in
> source code but have that source compile differently you have a very
> unusual coding style.

You seem to be missing the obvious as suggested in the original post.

T& Map<K,T>::at (size_type pos);
T const& Map<K,T>::at (size_type pos) const;

Where Map is implemented as a balanced binary search tree with
positional access.  The functions are identical with the exception
of the return type.  We know about the technique

T& Map<K,T>::at (size_type pos) {
   return const_cast<T&>(static_cast<Map<K,T> const&>(*this).at(pos));
   }

but even simple things like

Map<K,T>::iterator Map<K,T>::begin () { return p; }
Map<K,T>::const_iterator Map<K,T>::begin () const { return p; }

would be nice to just generate from once.  Specifying how it should
know about const_iterator should be amusing here or in Dietmar's
templates.  ;-)

John

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"John Potter" <jpotter@falcon.lhup.edu> wrote in message:

> but even simple things like
>
> Map<K,T>::iterator Map<K,T>::begin () { return p; }
> Map<K,T>::const_iterator Map<K,T>::begin () const { return p; }
>
> would be nice to just generate from once.  Specifying how it should
> know about const_iterator should be amusing here or in Dietmar's
> templates.  ;-)
>

Something tells me Dietmar wasn't being quite serious, but I suppose
it could be written:

    template<const Const>
    struct begin_end_traits {
    typedef typename
            compile_time_if<
                 is_same<Const int, const int>::value,
                 const_iterator,
                 iterator
             >::type type;
    };

      template<const Const>
      typename begin_end_traits<Const>::type begin() Const { return
p; }

This certainly makes things simpler! :-)

Jonathan


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Jonathan Turkanis wrote:
> Something tells me Dietmar wasn't being quite serious,

Just to avoid any confusion: I *was* very serious about this! I
encounter the problem of identical functions differing only by
const/volatile qualifications quite often and I would like an
approach to deal with it. Personally, I don't consider const_cast
the right approach.

> but I suppose
> it could be written:
>
>     template<const Const>
>     struct begin_end_traits {
>     typedef typename
>             compile_time_if<
>                  is_same<Const int, const int>::value,
>                  const_iterator,
>                  iterator
>              >::type type;
>     };
>
>       template<const Const>
>       typename begin_end_traits<Const>::type begin() Const { return
> p; }
>
> This certainly makes things simpler! :-)

The meta program has only to be written once and function types,
being part of the class' don't change as often as function
implementations anyway. Having to correct two identical functions
is more error prone than getting the above return type correct
- assuming the meta program is readily availabe. Also, with constness
being a template parameter, it is likely that 'iterator' and
'const_iterator' are just typedefs for a template class differing
only in the constness. Thus, the function is more likely to look
like this:

       template <const Const>
       inter_iterator<Const> begin() Const { return p; }
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Dietmar Kuehl" <dietmar_kuehl@yahoo.com> wrote in message
news:bv1m0j$mnu20$1@ID-86292.news.uni-berlin.de...
> Jonathan Turkanis wrote:
> > Something tells me Dietmar wasn't being quite serious,
>
> Just to avoid any confusion: I *was* very serious about this! I
> encounter the problem of identical functions differing only by
> const/volatile qualifications quite often and I would like an
> approach to deal with it. Personally, I don't consider const_cast
> the right approach.
>

Sorry, I wasn't sure. I wan't trying to ridicule your suggestion -- I
was just having fun maximizing obfuscation.

I also don't like to have to write function definitions which are the
same except for const. What I don't understand about your proposal is
this: what, exactly, are the values of the template parameter Const in
the various specializations? Are they strings, sequences of tokens,
abstract 'cv-qualifier objects' ... ? In particular, what is the value
of the parameter in the non-const case? The 'empty cv-qualifier', I
suppose. How do you write it? I guess you could write f<>() to
explicitly call the non-const, non-volatile version of f, but usually
this notation means 'deduce the template arguments'.

I guess I'd like some more detail.

Best Regards,

Jonathan



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

I use const extensively but find it tiresome creating const and non const
functions with identical content, e.g. accessor methods. My suggestion is
the addition of an aconst keyword. This would compile as both a const and
non const function. E.g.

class ClassType
{
public:
    aconst ObjectType& AccessObject(const int index) aconst;
};

would be equivalent to writing

class ClassType
{
public:
    ObjectType& AccessObject(const int index);
    const ObjectType& AccessObject(const int index) const;
};

I doubt I'm the first to suggest this, so are there plans to add such a
feature? Is there a way to do this sort of thing already, i.e. avoiding the
duplication of accessors? Are there complications with implementing this?

thanks,
cadull


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <400b8651$0$22625$61ce578d@news.syd.swiftdsl.com.au>, cadull
<cadullh.no@spam.icqmail.com> writes
>I use const extensively but find it tiresome creating const and non const
>functions with identical content, e.g. accessor methods. My suggestion is
>the addition of an aconst keyword. This would compile as both a const and
>non const function. E.g.


If they have identical content why would you want a non-const version?

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

cadullh.no@spam.icqmail.com ("cadull") wrote:
> I use const extensively but find it tiresome creating const and non const
> functions with identical content, e.g. accessor methods. My suggestion is
> the addition of an aconst keyword. This would compile as both a const and
> non const function. E.g.
>
> class ClassType
> {
> public:
>     aconst ObjectType& AccessObject(const int index) aconst;
> };

My personal perference would be extending the template system to take
constness into account:

  class ClassType
  {
  public:
    template <const Const>
    ObjectType Const& AccessObject(int index) Const;
  };

(my preference is to consistently place the "const" and "volatile" keywords
to the right of the entity being made const).

Being at it: there are other things, too, which should be possible template
parameters, eg. namespaces.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]