Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
compile-time fun: C++ template meta programming

By mvw in MLP
Thu May 03, 2001 at 04:39:56 AM EST
Tags: Technology (all tags)
Technology

Another indication that we have not explored all possibilites of the C++ language yet is this link to template meta programming, a technique that allows for compile-time programming.


It looks like a hacker's gadget, but has been actually used in the construction of numerical libraries that are claimed to be very close or even faster than their Fortran equivalents ( more here)

Interesting as well is the connection to Generative Programming, a subject worth its own article here. Those GP folks realized a tiny Lisp Interpreter using template meta programming.

A related article recently posted by codemonkey_uk on Kuro5hin can be found here.

Who said that C++ templates are less fun than C's cpp macros? :-) Have fun.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Your favourite programming?
o assembly programming 16%
o structured programming 16%
o object oriented programming 30%
o extreme programming 4%
o generative programming 1%
o intentional programming 4%
o using an UML tool 1%
o hacking 25%

Votes: 72
Results | Other Polls

Related Links
o Kuro5hin
o template meta programming
o numerical libraries
o more here
o Generative Programming
o codemonkey _uk
o here
o Also by mvw


Display: Sort:
compile-time fun: C++ template meta programming | 39 comments (37 topical, 2 editorial, 0 hidden)
Poll option (4.50 / 2) (#3)
by wiredog on Wed May 02, 2001 at 01:52:18 PM EST

You forgot "Machine code". You know what I mean. Programming the bare metal in pure, raw, hexadecimal. Makes assembly look fast and easy.

The idea of a global village is wrong, it's more like a gazillion pub bars.
Phage

pure raw hex? (4.50 / 2) (#4)
by Speare on Wed May 02, 2001 at 02:01:11 PM EST

Just being flippant, mind you, but I don't think the "bare metal" knows anything about hexadecimal. Binary, baby, and not even those silly notions of "one" or "zero." Sink or source. Vcc or GND.
[ e d @ e x p l o r a t i . c o m ]
[ Parent ]

Well, (2.50 / 2) (#7)
by wiredog on Wed May 02, 2001 at 02:30:48 PM EST

It was a board that was plugged into the bus. So the actual programming was something like:
outp 0x310 0xff
outp 0x311 0xb9
etc...

The idea of a global village is wrong, it's more like a gazillion pub bars.
Phage
[ Parent ]

HC11 opcodes (3.00 / 1) (#10)
by mikael_j on Wed May 02, 2001 at 03:49:33 PM EST

86 ;LDAA direct adressing
FF ;255
7B ;STAA
10 ;on
04 ;PORTB

Sure looks like hex to me...

/Mikael Jacobson
We give a bad name to the internet in general. - Rusty
[ Parent ]
Real Men and Oscilloscopes (4.00 / 1) (#12)
by SpaceHamster on Wed May 02, 2001 at 04:02:51 PM EST

In a particular newgroup I was once frequented a fellow had the following sig:
"Real men program in assembly and debug with an oscilloscope."
I found it endlessly amusing at the time, and it seems appriopriate now.

[ Parent ]
Guess I'm a Real Man, then (3.00 / 1) (#17)
by wiredog on Wed May 02, 2001 at 05:26:36 PM EST

Well, it's been a couple of years since I used a scope for debugging, but still... Btw, the Fluke 105B is really cool.

The idea of a global village is wrong, it's more like a gazillion pub bars.
Phage
[ Parent ]

You know... (4.28 / 14) (#5)
by trhurler on Wed May 02, 2001 at 02:03:26 PM EST

It never ceases to amaze me that if I write a clever for loop in C, someone accuses me of "hackery" and says I'm a bad programmer, but C++ programmers continually find newer and more obscure ways to accomplish what others did in far more reasonable ways 30 years ago, and then brag about it.

People, if it takes this much trickery to get the performance we had with Fortran, then YOUR LANGUAGE SUCKS. Get over it. Similarly, if it takes a monstrosity like the STL to make C++ even close to as flexible as Smalltalk, YOUR LANGUAGE SUCKS. I could go on at length about stupid C++ tricks, but why bother...

(C99 can in fact support numerical libraries as fast as Fortran. The only thing missing before was a way to specify that a pointer wasn't aliased, and we got that with "restrict." The resulting code is comprehensible, too. Imagine that. This is why adding tons of features before people have had time to really go out and figure out what's missing just because those features are trendy is a STUPID way to design languages.)

--
'God dammit, your posts make me hard.' --LilDebbie

well... (3.33 / 3) (#6)
by SEAL on Wed May 02, 2001 at 02:19:55 PM EST

I think this type of bragging is more along the lines of these clever Perl sigs or things of that nature. Most people wouldn't use them in practice but they are an interesting challenge.

However, I wanted to know what your issue with the STL is. I've never had any difficulty using it. One of the key benefits of the STL is that if you know how to use one container type, you can apply that to almost any of them. The other good point is that most of the algorithms are well optimized and have a lot of thought put into them.

Yes, the internals of the STL can be nasty and difficult to understand. But I don't have to deal with them. They've done a good job of providing an interface while hiding the details from the user.

- SEAL

It's only after we've lost everything that we're free to do anything.
[ Parent ]
STL (3.50 / 2) (#8)
by trhurler on Wed May 02, 2001 at 02:37:08 PM EST

Well, I was talking about its internals. That crap should NEVER be necessary.

Also, yes, people ARE using this crap. Follow the link to Blitz++ for an example. They think they're the shit. I'll agree with the "they're" and "shit" parts.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
STL Intenals (4.50 / 2) (#20)
by Morn on Wed May 02, 2001 at 05:45:53 PM EST

You can't ague that a Language is bad because it's associated libraies are implemented in a complex manne.

The agument that Java was a 'bad' language because its hash tables were implemented in a hard to undestand fashion intenally, whateve you views on the language in general, would not be a valid one.

The agument should be based on how the language is to use in normal applications (and Blitz++ is not nomal), and many people (myself, I admit, included) find the STL, and templates in general, to be a poweful, elegant, and, above all, useful tool.

--

Fogive my lack of 'r's. My keyboad is in the pocess of beaking.

[ Parent ]

more notes (4.00 / 1) (#21)
by SEAL on Wed May 02, 2001 at 06:20:02 PM EST

I'd like to point out that Dinkumware's implementation of the STL is particularily confusing compared to others, such as STLPort.

Also, some of the fault lies with the compiler vendors. Many C++ compilers are incomplete, or do not adhere to specs (e.g. VC++). Since the STL uses advanced features, it tends to run into problems with these compilers. To maintain portability, some ugly tricks have been required. If the only target was g++, for example, the STL would be a lot cleaner.

- SEAL

It's only after we've lost everything that we're free to do anything.
[ Parent ]

Well, (none / 0) (#27)
by trhurler on Thu May 03, 2001 at 11:12:25 AM EST

Go use Smalltalk for some project of at least moderate size. After that, you will NEVER describe ANYTHING about C++ as elegant again. I promise. The STL is a brittle clusterfuck that works IFF you don't break any of its often unstated assumptions or expect it to really work like a set of containers instead of like a parameterized-type hack. Its internals, even when they're "clean," still don't look like anything anyone ever ought to have to write. I'm not arguing that you have to worry about those internals as a user; what I'm saying is, that complexity and nastiness is a sign of a very poorly designed type system in C++. The mantra to chant is "single rooted object hierarchy." It makes all things taste better.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
single-rooted object heirarchy... (none / 0) (#28)
by beergut on Thu May 03, 2001 at 11:31:29 AM EST

Kind of like Objective-C?

The problem with a single-rooted object heirarchy, in my experience, is that in order to do anything really intricate with it you need runtime type information. This is one of the nastinesses C++ is incorporating, and is the root of the dynamic_cast<> ugliness, etc. To say that there is a runtime effect is to seriously understate the issue.

Objective-C is cool, technologically, but is too Smalltalkish in its syntax to make it flow naturally for a C programmer. A redesign of Objective-C's syntax, from a more-C/less-Smalltalk perspective, rooted on the same foundation could be tasty. Given, however, that you also made strings a first-class type, and that you made it possible to change character sizes.

What you'd have, with a single-rooted object heirarchy, is essentially void*.

Boilerplate programming with a construct like templates is nice, but they'd have to be better constructed than C++'s idea. I'd like to see a "template" idea take a "namespace" as a parameter, making possible some truly splendidly efficient code, but obviating the need for a wacked-out specialized "class". I do like their step in generalizing the default argument handling to include templates. That makes sense, and makes it easier to construct generic code. The gyrations they have to go through to make it reasonably portable across compilers, because compilers are generally a "maze of twisty little standards - all different", is truly nightmarish.

That can hardly be blamed on the language (except in that it is a clusterfuck from the ground up).

i don't see any nanorobots or jet engines or laser holography or orbiting death satellites.
i just see some orangutan throwing code-feces at a computer screen.

-- indubitable
[ Parent ]

Well well :-) (none / 0) (#32)
by krlynch on Thu May 03, 2001 at 02:10:37 PM EST

Go use Smalltalk for some project of at least moderate size. After that, you will NEVER describe ANYTHING about C++ as elegant again.

I've never used Smalltalk, and I don't necessarily disagree that C++ is not "elegant". But, go use Smalltalk for any moderately computationally intensive project, and you will NEVER describe ANYTHING about Smalltalk as fast enough again. (tongue in cheek....please don't take offense :-)

I don't really understand your statement that the STL is "brittle" or that it has "unstated assumptions". I've never encountered these problems. In fact, I've found the STL implementations that I've used to be rather robust, and I don't know which "unstated assumptions" you are talking about. The standard is very clear on what the assumptions are in most cases.

I've mentioned this before, somewhere else in this thread, but I think it deserves mention again: C++ (like every language) is a set of compromises, and has advantages and disadvantages. C++ traded some elegance to maintain some level of compatibility with C; Smalltalk traded performance for a very clean type system. You can't have it all. And while I don't agree with them all, Stroustrop does a very good job of explaining why the design decisions that were made were made, what the goals were, and in many cases, why certain things were not done (in The Design and Evolution of C++). In particular, he discusses why C++ does not have a singly rooted object hierarchy, but he never says that it isn't a valid choice to make in other contexts. If you haven't already, you might want to read it, if just to understand the choices made, even if you don't agree with them.

[ Parent ]

Ha! (none / 0) (#35)
by trhurler on Thu May 03, 2001 at 02:49:39 PM EST

I think maybe you've been listening to too many smalltalk legends from the 80s. Fast, space efficient smalltalk has been around for a long time now.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Smalltalk (none / 0) (#36)
by ucblockhead on Thu May 03, 2001 at 04:54:32 PM EST

Go use Smalltalk for some project of at least moderate size.
But certainly not one you want to execute in a reasonable time.

And again, the STL is ugly inside because of C++'s C heritage. Had C near-compatibility not been a goal, it would have been simple to make those things nice and clean looking.

But then, if C near-compatibility not been a goal, there'd be no reason for C++ in the first place.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

No (none / 0) (#37)
by trhurler on Fri May 04, 2001 at 10:58:40 AM EST

First off, using classes instead of an object type doesn't really improve C compatibility one bit. It isn't as though 'class' is valid C, and it isn't as though you'd have trouble linking C code into a language that had objects, if they were properly done(ie, if the language still had primitive types as well.) It just made Bjarne's job in the Cfront days easier from a technological perspective. Please stop blaming C for Bjarne's laziness and/or mistakes.

Secondly, Smalltalk is a lot faster these days than it used to be. There are some implementations that are quite competitive with modern OO languages, although I don't have exact figures for any benchmarks. You might not want to assume that what you or someone you talked to experienced back in the 70s or 80s is true today. I write C, but if I had to use some OO language, I think I'd rather write Smalltalk than C++ or Java.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
You see... (none / 0) (#38)
by ucblockhead on Fri May 04, 2001 at 03:06:59 PM EST

I don't want to use an OO language.

I also don't want to use a procedural language.

I want to use a language that allows me to do whichever is appropriate.

In terms of what I'm talking about compatibility, well, you seem to have missed the point. Badly.

But then, you've apparently missed the whole point of the C++ language, which is not to be an OO language. It is to be a language that allows OO. This is a huge difference, and it is what makes my job easy every day.

I've got almost ten years straight C coding experience and seven years C++ coding experience, and I can tell you flat out that I'll only use straight C if I have no choice.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

C and crap (3.50 / 2) (#24)
by ucblockhead on Wed May 02, 2001 at 11:29:49 PM EST

The reason "that crap" is necessary is because of C, and because C lacks either a string type or data structures. If C++ hadn't been based on C, then it would have had a string tyoe and container classes from the beginning, and the STL would have been unnecessary.

For a Java or a Perl programmer to bitch about C++'s STL makes sense. Both have superior structures. But for a C programmer to bitch about that is just ludicrous.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Speaking of CRAP (none / 0) (#26)
by trhurler on Thu May 03, 2001 at 11:04:09 AM EST

No. The problem is not C. The problem is that Bjarne had almost zero experience designing a programming language, and set out to make arguably the most comprehensive and complete one ever. He screwed the pooch. Here's a subset of how he did that:

First, he extended structs into classes instead of creating a real object type. The latter would have meant a single rooted object heirarchy based on objects of type "object," and container types would have been trivial to produce by simply placing them at an appropriate level in the resulting type tree. C is not at fault for the STL. He doubtless did this because it was the easy and natural way to get objects back in the Cfront days, but it is still wrong.

Second, he chose not only to keep the C style string, but to not even try to augment it until so late into the process of creating a language that there was already a huge body of legacy code using C strings. The end result is that you cannot write "nice" string handling code in C++ unless you never ever use ANY third party libraries except those specifically written with the STL, which is to say, except for an almost nonexistent subset of what's out there.

There's more, but this is enough to make my point and answer your claim that C is to blame for C++. One could make a much better OO C derivative.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
I have to agree here (none / 0) (#29)
by spiralx on Thu May 03, 2001 at 12:36:23 PM EST

First, he extended structs into classes instead of creating a real object type. The latter would have meant a single rooted object heirarchy based on objects of type "object," and container types would have been trivial to produce by simply placing them at an appropriate level in the resulting type tree.

Being a huge Delphi fan I totally agree with this. The Delphi VCL library is all descended from type TObject, and it contains a complete set of objects for containers, streams, components and controls without ever becoming messy. And if you're using C++ Builder you can use the VCL with C++ as well, allowing you to totally ignore the STL.

And seriously, what's up with not having a string type? Who on Earth would design a language without one... it's just a recipe for disaster, and means that every time you want to do something you need to implement loads of pointless code. Bah.

You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
[ Parent ]

Sorry, I don't buy your argument (none / 0) (#31)
by krlynch on Thu May 03, 2001 at 01:48:50 PM EST

I agree with you that C is not to "blame" for the C++ STL (but it is for most of the C++ SL, since it IS the C SL). Bjarne discusses at length in "The C++ Programming Language" about the design decisions made in the language and libraries. Despite your claim, he DOES have substantial language and systems design experience, and he DOES understand the tradeoffs and shortcomings of the language he designed. And he doesn't agree with all of the decisions that he made or that the ISO committee made. But most everything in the language is there for a reason, whether you (or he!) agree or not. No language is perfect, and no language should ever claim to be. Bjarne Stroustrop never claims that C++ is perfect or the best. If you don't like it, don't use it....but don't tell the rest of us that "C++ sucks" as if it were fact.

And one final point: there are no "strings" in C, technically speaking. There are "null terminated arrays of char" that are traditionally used to stand in for strings, but they are just convention enshrined in the standard, not a type in and of themselves.....

[ Parent ]

Oops, wrong title (none / 0) (#33)
by krlynch on Thu May 03, 2001 at 02:12:13 PM EST

I hate to respond to my own post, but I didn't mean "The C++ Programming Language", I meant "The Design and Evolution of C++". Different books.

[ Parent ]

Um... yeah. (none / 0) (#34)
by trhurler on Thu May 03, 2001 at 02:47:30 PM EST

No strings in C... well, if you define "string" to mean "a type, in the same manner as an integer or a real," then that's true. Otherwise, it is blatant foolishness. Seeing as the authors of C were using the term "strings" to refer to null terminated character arrays before most of the people reading this were born, and seeing as that gives their use of the term a history dating back about half the time we've had von Neumann machines to program on, I'm going to say this is nothing but the delusional myopia of someone who's spent too many hours parked in front of OO textbooks. C has "strings" in any sense of that term which is useful to people who aren't just OO propagandists.

As for the object type issue, yes, there is a reason for the way it was done: it was easy to do in Cfront that way. There's no particular other reason it needed to be that way. I'm sure Bjarne can come up with some bogus claim about why it was done, just as he spent 2 hours verbally flatulating at a conference I was at about how exceptions unify error handling when in fact they make error handling even harder in real environments(ie environments with legacy library code,) by adding yet another way rather than unifying previous approaches, and their real reason for being there is that they're trendy and he didn't buck the trend. He talks a good talk, but it doesn't always make sense. That's life.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Uh.... (2.50 / 4) (#9)
by ucblockhead on Wed May 02, 2001 at 03:42:54 PM EST

You do realize that if C99 supports numerical libraries as fast as Fortran, then C++ does as well, don't you?


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Well, no... (4.00 / 1) (#11)
by trhurler on Wed May 02, 2001 at 04:01:09 PM EST

Not unless you want to claim that C supports MMX just because you can inline assembler into it. What you have there is a program that is partly C++. The fact remains that trying to achieve Fortran-like performance in C++ requires the use of stunts that make obfuscated C contest entries look tame and unsophisticated. The STL is a similar clusterfuck, this time meant to solve C++'s lack of type system depth.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Oh, bullshit. (3.00 / 1) (#13)
by ucblockhead on Wed May 02, 2001 at 04:31:22 PM EST

You seem to be confusing C++'s OO language features with the entirety of the language.

Listen, C++ is NOT just an OO language. It is a language that can be either procedural, like C, or OO. And don't tell me that this is not true, because it is the whole fucking point of the language.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Ha... ha... hahahaha... (3.50 / 2) (#15)
by trhurler on Wed May 02, 2001 at 04:52:39 PM EST

Yes, I know. In the last five years or so, after realizing that C++ was NEVER going to be a really top flight OO language, Bjarne has been calling it a "generic programming language." Before that, he insisted that it was or was going to be an OO utopia. He's said all sorts of things over the years; if it put C++ in a good light, he said it. So what? If you DON'T use the OO features, then there's even less justification for choosing this albatross of a language!

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Bullshit, Bullshit, Bullshit. (4.00 / 1) (#18)
by ucblockhead on Wed May 02, 2001 at 05:37:56 PM EST

Again, that's pure crap.

The whole point of the language, from the beginning (speaking as someone who learned the language using "cfront" in 1985) was an extension of C that would allow you to use OO features in C. It was never to be a completely OO utopia. That already existed at the time. (Smalltalk).

The point is that you can use OO features, yet access procedural features (like, say, math libraries) in exactly the same way as from C.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

not really (3.50 / 2) (#16)
by Delirium on Wed May 02, 2001 at 05:00:08 PM EST

AFAIK, there are no plans to include the C99 additions to C as part of the C++ standard.

[ Parent ]
Numerical libraries (4.00 / 2) (#19)
by ucblockhead on Wed May 02, 2001 at 05:41:11 PM EST

The feature in question, basically linking to libraries, is the same in C and C++.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

oops (3.66 / 3) (#23)
by Delirium on Wed May 02, 2001 at 08:03:38 PM EST

Ah ok, I thought you were making a blanket claim that "if C99 supports [x], then C++ supports [x]," which is not necessarily true since standard C++ is no longer guaranteed to be a superset of standard C. Since you were just discussing libraries then I presume you are correct (I don't personally know enough about C or C++ internals myself to say).

[ Parent ]
Metaprogramming (3.66 / 3) (#22)
by sigwinch on Wed May 02, 2001 at 07:54:33 PM EST

People, if it takes this much trickery to get the performance we had with Fortran, then YOUR LANGUAGE SUCKS. Get over it.
The concept isn't entirely without merit, though. Think small, oddball CPUs like in PDAs and cell phones. No Fortran compiler exists, and even if it did, gluing the Fortran code into the rest of the system would be a PITA. Blitz++ may suck, and C++ template metaprogramming in general may suck, but they can still be cheaper than writing hand-optimized assembly. (Especially if you're targeting something like "the cheapest Windows CE PDA of the week", where you'd end up having to maintain assembly for half a dozen different CPUs.)

--
I don't want the world, I just want your half.
[ Parent ]

Ditto (2.00 / 1) (#25)
by tkatchev on Thu May 03, 2001 at 07:53:57 AM EST

Yes. C++ SUCKS. Period. This is so
obvious it doesn't even bear discussion.
Stop wasting thought cycles on this
and just put up with the fact that
THIS LANGUAGE SUCKS. Period.


   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Ah, K5 (none / 0) (#39)
by codemonkey_uk on Wed May 16, 2001 at 08:59:38 AM EST

Where you find a c++ article, you'll find trhurler trolling. Wonderful.

Sorry, mate, but today I just can't be bothered to argue with you... :)
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

IOC++CC??? (3.00 / 2) (#14)
by slambo on Wed May 02, 2001 at 04:43:46 PM EST

Now that's what I call obfuscated C++ code!
--
Sean Lamb
"A day without laughter is a day wasted." -- Groucho Marx
Modern C++ Design (none / 0) (#30)
by kallisti on Thu May 03, 2001 at 01:11:58 PM EST

This in the name of a book by Andrei Alexandrescu, which shows how to use all kinds of C++ template whackiness. It will have no effect on people's perception of C++ usefulness, if you hate it already, you'll really hate it after this book! It combines type traits, metaprogramming and other tricks to actually make something useful.

For example, ha shows how one can create a "typelist" which is expanded out such as the following Abstract Factory:

typedef AbstractFactory <TYPELIST_3(Soldier, Monster, SuperMonster)> AbstractEnemyFactory;

This expands out to 3 virtual create methods, thereby giving you an AbFactory for some Doom-type game. One advantage is that you can create sub-factories, such as only sending AbstractFactory<Soldier> to a file and thereby reduce coupling.

Similar generic Command, Singleton, Factory, and Visitor templates are created, as well as novel uses of sizeof to determine conversion ability, the use of classes that don't exist and compile-time asserts.

Of course, there are no real C++ compilers (last I checked), and I am in no way an expert so I can't tell if any of this would really work, but it is quite nifty.

compile-time fun: C++ template meta programming | 39 comments (37 topical, 2 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!