mark++

Scott Meyers wrote an article in CUJ a few years ago entitled How Non-Member Functions Improve Encapsulation. I highly recommend this article, as well as Herb Sutter’s GotW #84: Monoliths “Unstrung”, in which everyone’s favorite scapegoat, std::string, is refactored using this principle.

I have just stumbled onto a rather satisfying, if obvious, extension of this work. First lets review the properties of a friend function. Recall that a friend:

• …can access the private members of a class
• …is not passed a this pointer
• …does not reside in the class’s namespace

Now consider a function which:

• …cannot access the private members of a class
• …is passed a this pointer
• …does reside in the class’s namespace

With tongue-in-cheek, I call this an enemy function (alternate names are welcome).

We can add as many enemy functions as we like to a class without reducing its degree of encapsulation, because these functions only have access to the class’s public interface. Better still, since we pass a this pointer, we don’t have the inconsistency between w.eat(.564) and nap(w) (from the Meyers article). This means we can fix std::string without breaking existing code. I envision something like this:

   class Foo
   {
      public:
          // ...
      private:
          // ...
      enemy:
          void func();  // may not access private members
    }

   // …time passes…

   Foo f;
   f.func();  //not really a member function

Update (6/4/06):
I threw caution to the wind and posted this idea to comp.lang.c++.moderated. Maxim Yegorushkin made a great suggestion: why not use a public member function in a derived class?

   namespace
   {
   class FooBase
   {
      private:
      int x;
      public:
      FooBase(int x) : x(x) {}
      int size() { return x; }
   };
   }
   class Foo : public FooBase
   {
      public:
      Foo(int x) : FooBase(x) {}
      bool empty() { return size() == 0; }
   };

This does exactly what I wanted. The only downside is that I must write forwarding functions for FooBase’s constructors. I find this much more satisfying than Scott Meyer’s class Foo / namespace FooStuff method.

Update (6/15/06):
Many who object to the subclass solution do so on the grounds that it is “misuse of inheritance”. To appease them, I’ve modified the code above to wrap FooBase in an anonymous namespace. The “world” will have no idea I misused inheritance.

I happened across the following bit of C code at work today. It attempts to allocate storage for an incomplete type:

/* foo.c */
struct foo bar;
struct foo { int x; } bap;

I was surprised to find that this code compiles cleanly with GCC 3.4, Intel 8.1, and Comeau C/C++ 4.3.3 (apparently reserving 4 bytes for both bar and bap). Microsoft Visual C 8.0, however, produces the following error:

foo.c(1) : error C2079: 'bar' uses undefined struct 'foo'

MSVC’s error seems pretty reasonable to me. The primary characteristic of a C definition is that it reserves storage. If you don’t yet know the size of foo, you can’t reserve storage.

I’ve got a copy of the C language spec. Can someone point me to a relevant passage?

Update:
Upon review, it seems that this is indeed legal C. The Microsoft compiler should probably accept it. (Thanks to Jonathan Caves for looking at this.)

I’ve been learning Lisp recently (I’ll eventually post something about how and why) but, oddly enough, all this Lisping has got me thinking about C++.

So, without further ado, a higher-order function in C++:

#include <boost/lambda/lambda.hpp>
#include <boost/function.hpp>
#include <iostream>

using namespace std;
using namespace boost::lambda;

template< typename T >
boost::function foo( T n_ )
{
   // Old code.  Leaks memory.
   //T *n = new T( n_ );
   //return ( *n += _1 );

   boost::shared_ptr pn( new T(n_) );
   return ret< T& >( *constant(pn) ) += _1;
}

int main()
{
   // start with one
   boost::function accum = foo(1);
   cout << accum(2) << endl;
   cout << accum(10) << endl;
}

This blows my mind on so many levels, I don’t know where to start. The gist is that foo is a function which generates new functions (ok technically it generates functors, but if you squint, you can’t tell the difference).

Neat.

(Inspired by Paul Graham’s Revenge of the Nerds.)

Update: I originally declared n as a static local, but then I realized what this actually meant (all generated accumulators share n). The current code leaks, but at least it works for multiple accumulator functions. I’m still trying to figure out how to use a smart pointer to plug the leak.

Update: Thanks to Peter Dimov on boost-users, the code above now uses a boost::shared_ptr and is leak-free. For some reason, it won’t build with gcc 4.0.2.

If you’re a regular reader — and I’m pretty sure you’re not — you may have seen my infamous “craptimizing” articles: one and two. Read them if you like, but the short story is that I thought I had discovered a neat way to optimize using const member functions. Of course, there was a problem.

My approach is still flawed, but tonight I had an “ah-ha” moment. Suddenly, I knew what was missing — what had put the “crap” in “craptimizing”. What I really needed was a const constructor.

In today’s C++, during construction, we have no way of knowing if we are creating a regular ‘ole Foo, or a const Foo. But with a const constructor, I could differentiate:

#include <iostream>
#include <stdexcept>

using namespace std;

template < class T >
class Foo {
    private:
        bool initialized_;
        T data_;
    public:
        Foo() :
            initialized_( false )
        {}

        Foo( T data ) const :
            initialized_( true ),
            data_( data )
        {}

        void set( int data )
        {
            data_ = data;
            initialized_ = true;
        }

        void fubarize()
        {
            if( !initialized_ )
                throw invalid_argument( “Uninitialized Foo” );

            cout << "Called slow fubarize()" << endl;
        }

        void fubarize() const
        {
            // No initialized_ check required.
            // It's important to fubarize quickly.
            cout << "Called fast fubarize()" << endl;
        }
};

int main()
{
    Foo f;

    try
    {
        f.fubarize();   // Will throw invalid_argument
    }
    catch( invalid_argument &e )
    {
        cout << e.what() << endl;
    }

    f.set( 42 );
    f.fubarize();   // OK, calls slow fubarize()

    const Foo cf1( 42 );
    cf.fubarize();  // OK, calls fast fubarize()

    const Foo cf2;  // Error! (This is good)
}

Note that even if we exclusively used const Foos in our program, the compiler could not perform this optimization (omitting the initialized check) without our help. In short, this is because there are precious few circumstances under which the compiler can actually trust the const qualifier. If you want more details, you got ‘em.

Alas, I don’t think there is any reasonable way to get this behavior with standard C++. (To me, separate “Foo” and “ConstFoo” classes is unreasonable.) And, to make matters worse, adding this feature would break lots of existing code, because the status quo is:

const Foo cf;  // Calls Foo::Foo()

This obviously works fine: how else would we create a const Foo?

PS:
Google finds tons of references to “const constructor”. One very interesting document was this ISO/IEC Discussion Draft by Kevlin Henny. His proposal is notable in that it manages not to break backwards compatibility.