If you’re using public inheritance in C++, the compiler will implicitly “upcast” from a Derived class pointer to a Base class pointer. So I thought a std::auto_ptr to a Derived class would have a similar implicit upcast. It does…but only for assignment and construction!

The example shows that if you try to pass an auto_ptr<Derived> to a function that takes an auto_ptr<Base>, it fails to convert due to an ambiguity. You must put an explicit static_cast< auto_ptr<Base> > at the calling site.

This “minor” problem led me down an investigation of the state of auto_ptr and its alternative, unique_ptr. I sought the wisdom of friends and people on the Freenode IRC. Wound up even building a newer version of gcc than came with the latest Kubuntu distribution! Though my findings are not the most exciting subject for a blog, I thought writing them up might help someone.

So I have good news, and bad news…

Read the rest of this entry »

A couple years ago, I read an article that gained popularity on social-bookmarking sites which was entitled “8-year-olds should test my code”. It’s a story about a child named Brian (no relation :P), who crashed UCBLogo only seconds after encountering it for the first time:

The author is an engineer at Google, and said this:

“I had played with UCBLogo for two weeks and hadn’t made it crash once. Brian brought the whole thing down in three commands. The most telling part is that when I tried to reproduce the defect a week later I couldn’t. I issued rt with a ton of 9s and just couldn’t get it to break. As it turns, it only crashes when you omit the space, which of course I didn’t think of doing. It took me more time to reproduce the defect than it took Brian to discover it.”

We’re offered the conclusion that we need legions of 8-year old testers, since their lack of preconceptions makes them great sources of unanticipated input. I strongly disagree.

For one thing, automated fuzz testing can be made much more genuinely random. But more importantly: 8-year-olds have better things to do than feed random data into programs that were developed using defective methods! It’s much more gratifying if kids are using solid software tools that enable creativity and learning. Even better is if their curiosity about the tool can be satisfied by reading its implementation!

This is not as unattainable as it sounds. I’ll go deeper into this example to make my case…by showing what caused this bug and how far ahead modern techniques are.

Read the rest of this entry »

Now and again, I look at the searches that bring people to hostilefork.com For some period of time, the largest search phrase bringing people here is “extjs fork”. Sadly, they aren’t looking for the articles I wrote in 2007. Instead…it turns out there was a huge backlash against the Extjs project surrounding a change of the license from LGPL to GPL.

People have been up in arms and threatening to fork the codebase, and independently develop it under the previous contract. (To the best of my knowledge, the only place such a forked codebase has been posted is OpenEXT. But with very few commits and the most recent patch being applied in October of 2008 it is not too promising.)

Since people are finding my blog because of this question, I’ll take a stab at addressing the issue and offer my thoughts. I think they made a mistake in doing this change the way they did. Extjs should revert the current 2.0 repository to LGPL—applying the GPL to only 3.0 and beyond—so anyone using v2 who needs LGPL can use all the bugfixes that body of code has.

I’ll explain in more detail.

Read the rest of this entry »

I’ve uploaded a script (enum.r) to rebol.org, which implements enumerated types. Although I typically prefer catching these things at compile-time instead of run-time, I’m pretty pleased with how it works. Especially cool is that I could add a powerful version of this language feature in only about 60 lines of code!!

(Note: That figure doesn’t include the comments and the regression tests. I included those in the script, but they are not necessary to use the enum itself.)

I called it “powerful” because it does more than just ensure assignments to objects use legal possibilities. Here’s a demo to show it off, and bear in mind that there’s no native support for enumerations in REBOL:

>> fruit: make-enum-type [apple orange banana mango]
 
>> favorite_fruit: make-enum fruit 'apple
 
>> set-enum favorite_fruit 'shoe
** User Error: illegal enum value ( shoe ) when 
     possibilities are [ apple orange banana mango ]
 
>> switch-enum favorite_fruit [
     orange [print "orange"]
     mango [print "mango"]
]
** User Error: missing switch-enum cases for [ apple banana ]
 
>> switch-enum/default favorite_fruit [
     mango [print "mango"]
     apple [print "apple"]
     banana [print "banana"]
] [print "other stuff"]
** User Error: switch-enum specifies a /default which is 
   more clearly expressed as case ( orange )
 
>> switch-enum favorite_fruit [
     appel [print "apple"]
     bananna [print "banana"]
     orange [print "orange"]
     mango [print "mango"]
]
** User Error: illegal case values for switch-enum
     [ appel bananna ] when possibilities are 
     [ apple orange banana mango ]

The syntax isn’t necessarily ideal, but that’s a *lot* of features for 60 lines of code!

It makes me reconsider the tradeoffs when compared with gigantic compilers. Although static analysis tools are necessary for huge codebases, the REBOL approach might be able to reduce the amount of code to a manageable size. Perhaps then, one can verify it is correct by actually reading it.

Read the rest of this entry »

In the preface to his book Modern C++, Andrei Alexandrescu paints a vision of what programming should be like:

“Imagine the following scenario. You come from a design meeting with a couple of printed diagrams, scribbled with your annotations. Okay, the event type passed between these objects is not char anymore; it’s int. You change one line of code. The smart pointers to Widget are too slow; they should go unchecked. You change one line of code. The object factory needs to support the new Gadget class just added by another department. You change one line of code.

You have changed the design. Compile. Link. Done.”

This is a very nice theory. But as C++ programming has remained relevant only among a small (yet important) “fringe” of developers, they have been flexing the standards toward an uncompromising pursuit of this vision. The results are somewhat extreme and not generally easy to work with.

In this article I will talk briefly about the what is happening and what I think of the aesthetics.

Read the rest of this entry »