mark++

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.

The other day, I had this great (read: stupid) idea: I wanted to write a Perl script to process a .c file, find all the #include directives, and replace them with the included file’s contents. I wanted to do this recursively, such that the resulting .i file would have zero #include lines.

Notice that this is not the same as just running the C preprocessor on the file. That would have processed lines like #ifdef _AMD64_ and resulted in a non-portable .i file. All I wanted to do, was to “flatten” a complicated program down to one (still-portable, possibly enormous) file.

Please take my word for the fact that I have a totally reasonable justification for wanting to do this. Honestly. I could convince you, but it would take another page of text.

I wrote the Perl program in about 20 minutes, and turned it loose on my .c file.

A few minutes and 26 megabytes of .i file later, I decided the program would never terminate. That’s about the time it hit me: include guards.

In CS-nerd speak, all the files in a C program form a directed graph where the edges represent inclusion. This graph contains cycles. That means that A.h can include B.h which can include A.h, and so forth, until your brain explodes. You typically fix this problem with so-called include guards:


#ifndef __FOO_H
#define __FOO_H
//... text of foo.h goes here ...
#end


Beginner C/C++ programmers often learn about include guards the hard way. For me, they are reflexive — which is why I totally forgot about them.

So here’s the irony: I want only to process #include directives, and not #define directives, but I can’t sucessfully do the former without doing the latter too.