I forgot to mention, if those functions are made inline, then it compiles down to the same type of bit manipulations that would have been in the original program as well.

First of all, the assumption is that there is a lot more client code than there are declarations, so the template bit field and the macro declarations are irrelevant as far as the size is concerned. If you start with a 20-line program in the first place, then you can replace all bit manipulation operations with member function calls. How would you like to do the same in 2 million line program?

> I, like others who have been around long enough to
> remember the early language wars, find this seriously
> amusing. Not because it's wrong, per se, but because of
> the change in perceptions the years have wrought.

Read, sort and write floating point numbers C/C++ ratio (optimized)
500,000 el. 2.04
5,000,000 el. 4.62

For more details, see:
http://www.research.att.com/~bs/new_learning.pdf

Not to start a 'language war', but why don't you back up your 'per se' claim with some hard data?

> "C++ is a language for writing efficient high-performance
> programs"
>
> That's funny!
>
> I, like others who have been around long enough to
> remember the early language wars, find this seriously
> amusing. Not because it's wrong, per se, but because of
> the change in perceptions the years have wrought.

Indeed. C++ wasn't considered as such in its early days. There were Fortran and C with better predictability of performance and memory. C++ was just an application programming language, not scaring away those who didn't want to program OO but procedural C code instead. This changed in the 90s. Most notably with WinNT being written in C++.

> In ten years:
>
> "Python/Ruby/Perl/PHP is a language for writing efficient
> high-performance programs"

Maybe not. But one of them will be the prefered choice in writing "large scale business applications" and evil minded persons will say "Ruby is the new COBOL" since one language always has to be COBOL no matter which.

>
> In twenty years:
>
> "Javascript is a language for writing efficient
> high-performance programs"

JavaScript will be the language for writing "net-centric operating systems". So definitely yes: JavaScript will become the most widely used systems programming language.

> The important (off-topic) things first :)
>
> 1) C++ compilers have improved a lot in the last 10 years,
> and there is no reason for a C++ program to be less
> efficient than an equivalent C one. Of course, Fortran is
> still the "daddy" when it comes to performance (at least
> numeric calculations).

When was a C++ program slower than the equivalent C program? I don't think there was ever such a case. C++ was deemed slower than C in the same tasks that C did, but in an object-oriented way. But the programs were not equivalent.

Fortran is the king of numeric computation performance because it does not have aliases which prevent a compiler to do the appropriate optimizations.

>
> 2) NT kernel is pure C, but pretty much everything else in
> Windows is C++ these days.
>

I think the definition of the O/S is not the applications distributed with it but its kernel and drivers. And I think all of NT is written in C, even in these days.

I read a book that noted just that(can remember which), but I picked the example described there and added a few features:
// from the book
template<unsigned long N>
struct binary
{
static const unsigned int digit = N % 10;
BOOST_STATIC_ASSERT(digit == 0 || digit == 1);

static unsigned long const value = binary<N/10>::value * 2 + digit;
};

template<>
struct binary<0>
{
static unsigned int const value = 0;
};

// from me...
template<unsigned long N, unsigned long S>
struct binary_shift_left : binary<N>
{
static unsigned long const value = (binary<N>::value << S);
};

template<unsigned long N, unsigned long S>
struct binary_shift_right : binary<N>
{
static unsigned long const value = (binary<N>::value >> S);
};

template<unsigned long N, unsigned long P = 0>
struct flag : binary_shift_left<N, P> { };

template<unsigned long P>
struct bit_flag : flag<1, P>{ };

// usage
int main(int argc, char *argv[])
{
unsigned long flags = 0x00;

flags = binary<1010101010>::value;

flags |= bit_flag< 1 >::value;
flags |= bit_flag< 2 >::value;
flags |= bit_flag< 3 >::value;
flags |= bit_flag< 4 >::value;
flags |= bit_flag< 5 >::value;
flags |= bit_flag< 6 >::value;
flags |= bit_flag< 7 >::value;
flags |= bit_flag< 8 >::value;

flags |= flag<11, 9>::value | flag<101, 5>::value;

cout << binary<1111>::value << endl;

return EXIT_SUCCESS;
}


It's to be noticed that recent compilers will resolve the templates and the code remains as optimized as in C.