One of the many little things I've wanted to have a crack at over recent years but couldn't really do was tackle writing a Regular Expression library for the GC'd runtime I designed and wrote to use inside Ghost Solution Suite. When Russ Cox went and wrote a series of awesome articles on that after I'd written a big chunk of a Javascript interpreter for that runtime, I wanted to do it even more.
Alas, one of the things that I lost when Symantec cut me loose was access to all that code which I'd created and looked after over more than a decade. It's not of any use to them, but that's the way it goes and so I need to start my personal collection of Useful Stuff from scratch again, only this time I'll take a lot more care to avoid losing ownership of it. And to be fair, starting again means this time I don't have to worry quite so much about compatibility with broken C++ compilers, as I had to back in 1995 when even 1990-level template support and return type covariance were considered supremely exotic.
Anyway, while reading Russ's articles again and contemplating where I'd fit such a thing into my long-term roadmap, a noticed an offhand reference to this gem of an idea. It's not a total game-changer, in that most of the times I've hit this kind of problem no sparse representation was feasible, but now I do find myself contemplating ways of trying this out.
As with so many great ideas, as Russ points out it's not really new at all; there are hints of it being known back at least as far as 1974. Some really neat ideas like this languish in obscurity for a long time; some of my favourite CS papers took a huge amount of time to become well-known like this classic paper by Richard Brent which is a simple and practical method for high-occupancy hash tables very few people ever knew about.
It's really fun trying these things out and demonstrating just how well they work - often, so well that it's truly baffling why they aren't better known. So, extra kudos to Russ not just on the Regexp front but for popularising a classic algorithm like this.
On the more practical front, just a small addendum to yesterday's note on MSBuild and Visual Studio 2010; something that had been puzzling me; for years I've been used to setting up dependent projects as I'd always done so an application which depends on a DLL gets the .LIB for the DLL automatically linked with it. However, in VS2010 it wasn't working, which was perplexing me.
It turns out that this is a consequence of a peculiar change in the build system; the old project dependency system still exists (and it's easy to encounter in the VS UI since it's in the same context menu it's always been in) but the old dependency system only deals with build order. Instead, the old-style dependencies are now handled exclusively through the "Framework and References" part of project settings, which is especially bizarre since this mainly affects C++ projects but the relevant UI is very .NET-oriented. So, there's no way this would be easy to discover, but there you have it - treat your DLL projects like .NET assembly references and you're back at the classic behaviour that's been around since at least Visual C++ 6.0 circa 1998.
No comments:
Post a Comment