dwalker07@snet.net (Daryle Walker) wrote in message news:<dwalker07-369688.03083214062003@newssvr10-ext.news.prodigy.com>...
> In article <j0uEa.39352$Io.3425282@newsread2.prod.itd.earthlink.net>,
>  eldiener@earthlink.net ("Edward Diener") wrote:
>
> > Dhruv wrote:
> > > Well, this is regarding the const keyword in the c++ programming
> > > language, when used as a keyword to specify that a member function is
> > > const, that is it does not modify it's class' member data. I was
> > > wondering if there was a way to sepecify that the same function can be
> > > specified to do stuff if the object is const or non-const, because it
> > > is very tedious to write the same stuff again just for const objects
> > > of that type. an example;
> > >
> > > struct foo [ //the shift key does not work on this keyboard.
> > > void bar [void];
> > > void bar [void] const;
> > > ];
> >
> > Aside from '[' and ']' not being correct above, there is a reason to write a
> > const and non-const version of a member function. If your member function
> > does not modify your class's data, simply write a const version and both
> > const and non-const objects will use that single version. If your member
> > function does modify your class's data, then if you want a const version of
> > your normally non-const member function, your const version has to be
> > different from your non-const version in order to have your const version
> > not modifying your class's data, and therefore you can not have the same
> > member function doing both things. Therefore your wish to have the same
> > member function being both const and non-const has no reason to exist.
>
> I think Dhruv's point was something like:
>
> struct test1
> {
>    int *a;
>
>    test1() : a(new int[5]) {}
>    ~test1() { delete [] a; }
>
>    int &  at(int i) { return a[i]; }
>
>    int const &  at(int i) const { return a[i]; }
> };
>
> The two "at" methods are token-for-token identical except for the
> qualifier differences.  Doesn't this seem familiar?  We took care of
> this problem for similarly used types and similarly used constants with
> templates!  Why not do the same for qualifiers:
>
> struct test2
> {
>    int *a;
>
>    test2() : a(new int[5]) {}
>    ~test2() { delete [] a; }
>
>    template < qualifier Q >
>    int Q &  at(int i) Q { return a[i]; }
> };
>
> We have to add a new keyword "qualifier".
>

I had not thought of this originally, but later this occured to me,
but could not understand what I was thinking??? (typical situation of
a newbie). Yes, this kind of behaviour was found by me in the stl in
containers that implement begin/end, and front/back, and there are
separate functions that do the exact same thing......

-Dhruv.

---
[ 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 <j0uEa.39352$Io.3425282@newsread2.prod.itd.earthlink.net>,
 eldiener@earthlink.net ("Edward Diener") wrote:

> Dhruv wrote:
> > Well, this is regarding the const keyword in the c++ programming
> > language, when used as a keyword to specify that a member function is
> > const, that is it does not modify it's class' member data. I was
> > wondering if there was a way to sepecify that the same function can be
> > specified to do stuff if the object is const or non-const, because it
> > is very tedious to write the same stuff again just for const objects
> > of that type. an example;
> >
> > struct foo [ //the shift key does not work on this keyboard.
> > void bar [void];
> > void bar [void] const;
> > ];
>
> Aside from '[' and ']' not being correct above, there is a reason to write a
> const and non-const version of a member function. If your member function
> does not modify your class's data, simply write a const version and both
> const and non-const objects will use that single version. If your member
> function does modify your class's data, then if you want a const version of
> your normally non-const member function, your const version has to be
> different from your non-const version in order to have your const version
> not modifying your class's data, and therefore you can not have the same
> member function doing both things. Therefore your wish to have the same
> member function being both const and non-const has no reason to exist.

I think Dhruv's point was something like:

struct test1
{
   int *a;

   test1() : a(new int[5]) {}
   ~test1() { delete [] a; }

   int &  at(int i) { return a[i]; }

   int const &  at(int i) const { return a[i]; }
};

The two "at" methods are token-for-token identical except for the
qualifier differences.  Doesn't this seem familiar?  We took care of
this problem for similarly used types and similarly used constants with
templates!  Why not do the same for qualifiers:

struct test2
{
   int *a;

   test2() : a(new int[5]) {}
   ~test2() { delete [] a; }

   template < qualifier Q >
   int Q &  at(int i) Q { return a[i]; }
};

We have to add a new keyword "qualifier".

Daryle

---
[ 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                       ]

"Daryle Walker" <dwalker07@snet.net> wrote in message
news:dwalker07-369688.03083214062003@newssvr10-ext.news.prodigy.com...
[snip]
> I think Dhruv's point was something like:
>
> struct test1
> {
>    int *a;
>
>    test1() : a(new int[5]) {}
>    ~test1() { delete [] a; }
>
>    int &  at(int i) { return a[i]; }
>
>    int const &  at(int i) const { return a[i]; }
> };
>
> The two "at" methods are token-for-token identical except for the
> qualifier differences.  Doesn't this seem familiar?  We took care of
> this problem for similarly used types and similarly used constants with
> templates!  Why not do the same for qualifiers:

I'm not sure that there are enough places where this is necessary to justify
a completely new keyword.
It is useful where two methods, one const and one non-const, return const
and non-const references respectively.
The example above, and operator[] itself, is the most obvious case.

I've seen accessors done as pairs too (although I'm still not persuaded by
this idiom):

class X
{
public:
std::string & name();
std::string const & name() const;
};

So you can now go anX.name() = "new name".

You can currently prevent double typing with casting:-

    int const & at( int i ) const;
    int & at( int i ) { return const_cast<int&>( const_cast< X const
*>(this)->at( i ) ); }

but I agree this is horrid...

I'm not sure I like adding complexity to templates - how about (ab)using
'mutable?

class X
{
public:
    int mutable & at(int i) mutable;
};

Which would mean 'const where object is const'.

Roger Orr
--
MVP in C++ at www.brainbench.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                       ]