What would a developer expect from a more agile C++?

I have written a new variant / union style type for C++ and posted it to CodeProject.com.

My answer to YACC and Lex, the YARD parser version 1.0, is now online at SourceForge.net.

I show how static event handlers through template function specializations can be simpler and more efficient than dynamic event handlers through function pointers.

C++ template specializations provide an elegant mechanism for implementing event-driven frameworks. This is the technique that I am using for defining semantic actions in the YARD parser. This is a reprint of an article I just posted to CodeProject.com.

I just finished the first version of the YARD (Yet Another Recursive Descent) Parser for C++, and posted it to CodeProject.com. The YARD parser is a simple regular expression parsing toolset which can operate on generic data.

I am looking at rebuilding the Heron compiler in C++. I am surveying which platform developers would most like to see targeted whether it is native code, java virtual machines, .net, or other.

I finally got an article posted to Slashdot.org on Heron. This is a very nice boost in visibility for the language.

It is a challenge to find definitions for computer science terms, which are understandable, correct and uncontentious. Lately I have needed to come up with a good definition of type.

It is commonly assumed that in order to achieve some measure of run-time polymorphism we have to state in a class declaration that it it either implements an interface or it inherits from a base class with virtual functions. Not anymore ...

I have made a first public release of the C++ Object Oriented Template Library ( OOTL ). An open-source library with the rather ambitious goals of providing object-oriented alternatives to the C++ primitives and the STL collections.

So Microsoft has applied for a new patent on the IS NOT operator in Visual Basic. I hope it is accepted, so I can openly and flagrantly violate the patent in my language, Heron.

Exceptions are not errors. The distinction is more subtle than most programmers realize.

There are many different "[insert-buzzword-here] Driven Design" methodologies, i.e. Policy Driven Design, UI Driven Design, Data Driven Design. I would like to propose a new one: "Implementation Driven Design".

I have been looking mock objects and test driven design lately. The main issue, I see brought up over and over again is that people want to modify existing code by inserting mock objects, but that it is hard to do because of code dependencies. I argue that proper use of abstraction at the implementation level would make it much easier.