Re: Idiom: identical const and non-const methods

* Kenneth Porter:


The accepted idiom is, as I understand it (based on slightly outdated
experience, but then all my experience says that nothing's really
changed since 1946, all this focus on buzzwords and being "current" is
just hogwash!), is to write small functions and duplicate the code.


const_cast is relatively clean.

Forwarding to a common operation

   Item& find_impl( Key const& key ) const;

is even more clean but also more code, and lest you want a const_cast in
there (centralizing the const_cast), needs the item as mutable or
accessed via indirection.

Cleanest but also more intricate, for non-virtual accessors you can
templatize the thing and wrap the templatizing in macros. Now the
templatizing is not my own idea, although I've posted such code earlier
(in comp.std.c++ I think). As I recall I first saw such templatizing in
an article by a Russian (I think) in [comp.lang.c++].

My own postings of such code have been in connection with suggestions
for language extensions to handle this, and as I recall I informally
proposed one very similar in spirit to the macros, then learned that
numerous proposals have been made and nothing has ever come out of it.

(Firing up old Visual Studio...)

(Writing code...)

OK,

template< typename AType >
struct Accessor{ typedef AType const T; };

template< typename AType >
struct Modifier{ typedef AType T; };

#define TWINFUNCIMPL \
     template< template <class> class Constness > static
#define TFI_TYPE( t ) typename Constness<t>::T

//----------------------------- Example A:

class ContainerA
{
public:
     typedef double Item;
     typedef int Key;
     typedef ContainerA ThisClass;

private:
     Item myItem;

     TWINFUNCIMPL
     TFI_TYPE(Item)& doFind(
         TFI_TYPE( ContainerA )& tfi_self,
         Key const& key
         )
     { return tfi_self.myItem; }

public:
     ContainerA(): myItem( 1.234 ) {}

     Item& find( Key const& key )
     { return doFind<Modifier>( *this, key ); }

     Item const& find( Key const& key ) const
     { return doFind<Accessor>( *this, key ); }
};

//----------------------------- Example B:

#define TWINFUNC_1ARG( rType, funcName, argType, argName ) \
     TWINFUNCIMPL \
     TFI_TYPE(rType)& funcName( \
         TFI_TYPE( ThisClass )& tfi_self, \
         argType argName \
         )

class ContainerB
{
public:
     typedef double Item;
     typedef int Key;
     typedef ContainerB ThisClass;

private:
     Item myItem;

     TWINFUNC_1ARG( Item, doFind, Key const&, key )
     { return tfi_self.myItem; }

public:
     ContainerB(): myItem( 1.234 ) {}

     Item& find( Key const& key )
     { return doFind<Modifier>( *this, key ); }

     Item const& find( Key const& key ) const
     { return doFind<Accessor>( *this, key ); }
};

int main()
{
     ContainerA c1;
     ContainerA::Item& item1 = c1.find( 6 );

     ContainerA const c2;
     ContainerA::Item const& item2 = c2.find( 9 );

     ContainerA c3;
     ContainerA::Item& item3 = c3.find( 6 );

     ContainerA const c4;
     ContainerA::Item const& item4 = c4.find( 9 );
}


There is no such problem. Calls on a const object go to the const
function, calls on a non-const object go to the non-const function.

Hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]