Archive for category C++/C#/SQL/Web Programming

Huge Spam Wave

spam[1]After the weekend’s festivities, we returned home on Sunday.  On Monday, after having settled in a bit and gotten the kids off to school, I sat down to post the pictures in yesterday’s entry.

We’ve gotten a lot of spam in the past, but it was ridiculous yesterday.  85 new messages had come in since I posted Friday.  Most were the usual “Anubis Gates” pharmaceutical shill, but there was another type of gibberish spew that had apparently walked through my blog, targeting a pretty decent subset of all the posts I have.

With Akismet, of course, it’s the work of a moment to delete them all, but this was by far the biggest wave I’ve been hit by.  Akismet has registered something less than 600 spams total, making the weekend’s attack 15% of all the spam I’ve ever gotten on this blog.

Tags: ,

The Saga of the New Keyboard

keyboards-709573[1]I program.  A lot.  I type in a lot of code at work and at home as well, and I’ve had numerous flirtations with carpal tunnel syndrome in the past.  What finally cured the problem for me — and it was a dramatic cure — was moving to the Microsoft Natural Keyboard around 13 years ago.

Programmers get attached to their keyboards, and it’s no wonder; we type tens, possibly hundreds of millions of keystrokes on the things.  Switching keyboards is a big, big deal — nothing to approach lightly.  As an example of how particular we can get, note that the keyboards pictured to the right are recognizable instantly as examples of the Microsoft Natural Keyboard Elite model, which are inferior to the original models in key feel, function key size, and the layout of the insert/delete and cursor arrow key blocks.

Don’t mess with our keyboards.

The original Microsoft Natural Keyboard is, in my opinion, the pinnacle of keyboard design.  Nothing before or since matches its ergonomics, key feel, or spare layout and design.  I bought one for work and one for home way back in the day, and have used them for well over a decade now — they’ve outlasted at least 3 computers with never a problem.  I’m typing this post on one right now.  I have an Elite as a spare, but I try not to have to use it.

There’s only one problem; the original Microsoft Natural Keyboard is a PS/2-only device.  That’s not been a fatal problem even in the age of USB, as there are PS/2-to-USB converters.  However, either the converter or the new Dell I got recently (or both) are not fully compatible with the keyboard, as I get dropped keys when typing at speed, and it can’t handle interleaving multiple simultaneous keypresses very well, which affects ALT- or CTRL-key combinations and games.

So it was time to look for a new keyboard.

Of course, the first place I went was to Microsoft’s offerings.  After over a decade of complete satisfaction, I knew they understood what a programmer needs in a keyboard.  I also knew they had a suite of new keyboards, all of which natively supported USB.  After reading some reviews I went with the Microsoft Natural Keyboard 4000, which seemed to be the intended successor to the original Microsoft Natural Keyboards.  I ordered it from Newegg, got it, and plugged it in.

With one exception, it’s really quite a good keyboard overall.  The key feel is OK, the layout is good (read:  familiar) — everything about it was acceptable, except for the spacebar.

The spacebar.  How could they screw up the spacebar?  When you type on an ergonomic keyboard, especially  a split one like the Natural series, the spacebar has to be wide to bridge the gap between the two sides of the keyboard.  For comfortable hand positioning, you have to have your thumbs on the very ends of the spacebar — it’s required by the very concept of a split keyboard.  So why would Microsoft make a keyboard with a single contact for the spacebar, and a cheap swaybar to try to balance the forces?  It presses OK in the exact center, but when you press on the ends, it sticks.  Badly.  On either side.

It’s a dealbreaker.  It may be news to Microsoft, but the spacebar is a commonly used key.  I’ve used it several hundred times in this blog post already, which is more than I can say for the ‘x’ or ‘q’.  So back the Natural 4000 went to Newegg, and I looked for another answer.

What I came up with in the end was a used Microsoft Natural Keyboard Pro.  This model supports USB natively, has the same key layout as the original Natural, a good spacebar, and a bunch of extraneous buttons at the top that I just ignore.  Key action is OK; not as good as the Natural, but acceptable.  The function keys are the small Elite size, but I can live with that; I don’t use the function keys nearly as much as the spacebar.  And since older Natural keyboards are almost indestructible, it still works great.

I wish I’d found this one originally, as it was cheaper than the 4000 and I wouldn’t have lost the $18 on return postage and restocking fee when returning the 4000 to Newegg.  But even so I consider it a cheap lesson to learn.  The important thing is that I have an acceptable keyboard to use now; one that works well enough that it seems to blend into the background, and becomes something I can just ignore while I work.

Tags: , , ,

Best SQL Server 2005/2008 Index Maintenance Script Ever

ccrp_0908_04_z+electric_q_jet_carburetor+rebuild[1]It covers reorganization when it makes sense, rebuilding when it has to, has a debug mode, intelligently determines whether online rebuilds are possible or not, is well documented, and generally seems like a very professional SQL script, other than a single typo bug due to the conversion from HTML.

Use it.

Tags: ,

C# vs. C++ — Swimming With the Current

1696193472_34d83c57f3[1]I know I just posted on the glories of smart pointers in C++.  I love C++ like a brother, and I have many C++ friends, but this article does a great job of illustrating, with wit and great examples, one of the most important truths about programming that I think I can pass on, and it’s not flattering to C++:

If you can manage it, try to swim with the current.

The link above is really a series of articles comparing the development of a simple application to read a Chinese dictionary in both unmanaged C++ and C#.  You should read it — it’s very interesting and educational — but the upshot is that although the C++ author eventually got his fully optimized performance to exceed that of the fully-optimized C# program, it took a large amount of very touchy, bug-prone work to do so, while the naïve version of the C# program already had great performance out of the box, and was easily optimizable to speed up further.

Why is this?  You can blame Microsoft’s substandard support for C++, and that’s probably partially right.  You can blame the glacial pace of improvement in C++ Standard Library design and performance, and that’s probably partially right as well.

But why are both of these situations the case?

The fundamental reason is that, for most non-systems programming tasks, the state-of-the art — the current — for development on Microsoft platforms is strongly flowing toward C# and .NET.  .NET is getting the benefits of new technologies and new advances in the craft of software development, and C++ really isn’t.  You can still paddle around in the C++ backwater, but very little in the way of support and improvements is going to be coming your way.  TR1 is very nice (and very overdue) but at this point it’s almost too little, too late.  Those of us who have to stay in the backwater are just going to have to get used to the faintly stagnant smell.

For most development, the current heading toward C# and .NET is almost certainly a good thing.  Personal computers are not the same as they were when C++ was first rising to dominance in the early 90s.  Multicore machines are the norm now, with multiple orders of magnitude more memory and disk storage than ever before.  Modern CPU pipeline optimizations are so complicated that trying to hand-optimize assembly code for a modern processor is almost laughable; a compiler will always do a better job than you can now, and that certainly wasn’t the case 15, even 10 years ago.

When you have memory to spare, a terabyte of hard disk space, most of the work you are doing is manipulating top-level UI constructs, your minimum-spec machine has an 8-core processor, and preventing obscure malicious exploits is a priority, does it make sense to use a language designed around minimalist efficiency, where threading is a foreign operation bolted on with great difficulty, memory is managed manually out of the box, security is an afterthought and you end up with a static executable optimized for the lowest common denominator of machine?  Or might it be better to use a language with built-in garbage collection, easily-used multithreaded constructs and just-in-time optimization based on the environment the app is running in?

C++ is a great language for many purposes, but the current has passed it by for user-level application programming.  Swim with the stream if you can!

Tags: , ,

In Praise of Smart Pointers

hacker_bomb[1]At work I program in C++, which is a great and powerful language but also an inherently unforgiving one that imposes dire penalties for failing to adhere to its ritualized memory-management rules.  Simple programs are easy to make work correctly, but anything complex runs the risk of a memory leak, which can eventually bring a system to its knees, or a double-deletion or dereferencing of a bad pointer, which can cause an instantaneous program crash.

The issue of memory management in C++, in fact, is such a big problem that there are all sorts of methodologies, class libraries, third party tools, and even alternative languages that have been developed, wholly or partially, to avoid this problem.

In my opinion, however, there is nothing easier or more effective in the vast majority of cases than using the Boost library’s (and now the TR1 library’s as well) shared_ptr<> class.  shared_ptr<>, as the name implies, provides shared access to memory, which is compatible with the behavior of raw system pointers — multiple smart pointers can reference, or “own”, the target memory at one time.  This means that you can easily substitute shared_ptr<> objects anywhere you would normally use a raw pointer.

However, unlike raw pointers, shared_ptr<>; objects support internal reference counting, which (except for some obscure circular reference cases) simply makes the memory management issue go away.

An example of how this might (not) work, with old-style pointers:

int main(int argc, char *argv[])
{
    int *i1 = new int;
    {
        int *i2 = i1; // two raw pointers now point to the same int value.
        delete i1;
        printf("%ld\n", *i2); // if above line is uncommented, we crash due to a deleted object being
        // accessed!  If the above line is commented out, we'll leak the pointer at the
        // conclusion of the program.
    }
    return 0;
}

With shared_ptr<>, there’s no need to use the manual “delete” operator any more — shared_ptr<> internally tracks how many total shared_ptr<> objects reference the contained object, and deletes it automatically when there are no references remaining.  The code thus simplifies to:

using boost;
int main(int argc, char *argv[])
{
    shared_ptr i1(new int);
    {
        shared_ptr i2 = i1; // two shared_ptr objects now point to the same int value.
        printf("%ld\n", *i2); // works fine
    } // at the end of this scope, the i2 object gets destroyed, but the reference
      // count in its destructor sees that there is still an outstanding reference, so
      // it's not deleted yet.
    return 0;
} // now i1 is destroyed, the shared_ptr destructor sees that there are no
  // remaining references, and automatically deletes the int.  No crash, no leak,
  // no manual memory management!

Developers like this behavior because they can drop common memory management tasks completely out of their minds and focus on more important implementation issues.  Architects like it because it’s easy to retrofit into large existing codebases.  Managers like it because it’s a magic bullet for stability.

So what’s the catch?  Well, there are a few:

  • First off, it’s a bit slower than using raw pointers.  shared_ptr<> uses an internal reference count, which makes the object larger than a corresponding raw pointer.  This can cause speed issues in certain applications.  However, most higher-level code is not strongly performance-sensitive, so this is usually not an issue.
  • Second, you can’t use the standard casting operators on them.  Boost provides alternative functions to do what you need to do, but their syntax is slightly different, which increases the amount of code you need to change to retrofit them into an existing system, and is one more thing to remember when you’re working with them.
  • And finally, they are verbose.  typedef will definitely become your friend when setting up shared_ptr<> support in a system.  You will likely want to set up a macro for typedef-ing new types of shared_ptr<> objects to cut down on the excessive keystrokes even so.

There’s a lot more to smart pointers in general, and shared_ptr<> in particular than I’ve covered here, but 99% of the time this is all you need to get rolling with them. Obviously, use C# or Java if your application calls for it, but if you are in the C++ world by force or by choice, get with the program.  Folks, it’s almost 2010.  If you’re still using manual memory management in cases where you aren’t certain you need to (and if you’re not certain, you probably don’t need to) you are not being smart. Let smart pointers make your code smart, and give you the time to solve real problems rather than fiddle around with memory.

Tags: , , ,

Type-Safe Message-Passing in Win32/MFC — Update

no[1]In a previous post, I talked about the problem of Windows messaging not working well with smart pointers and type-safe programming practices.  I’ve come up with a fairly good solution for this in MFC, and was interested in writing an article about it, so I sent submission proposals to MSDN Magazine and Dr. Dobb’s Journal.

MSDN sent a rejection letter, as I expected.  MFC, the Win32 message-passing API, and, frankly, C++ in general are very passe technologies compared with their usual topics, so although I had tried my best to spin it as retro-cool, and an example of a practical programming technique for reengineering legacy systems with modern C++ concepts, I still didn’t get any nibble of interest.  I haven’t heard back from Dr. Dobb’s, but I’m expecting the same response (or no response) from them.

In the meantime, I’ve found a few minor holes in my approach, and while none of them are fatal or even really relevant to my original need, and I could probably fix them with enough additional spit-and-polish effort, I have enough other things to do that I’m not really interested in doing so at this point.  With that decision, however, I realize that the sum total of what I’ve done isn’t really up to full print publication-quality, so I’m not going to pursue the magazines any more, and just write it up here and at the Code Project. So expect to see a couple additional articles on my technique in the coming weeks, along with a discussion about what the holes are and what might be able to be done to deal with them.

Stay tuned!

Tags: , , ,

Hit Me With Your Best Shot

blog-tour-overload[1]I recently read a post on Coding Horror where Jeff Atwood was crowing about how well the blogging platform Moveable Type has worked for him over the last years.  I’ve been a WordPress user ever since I started blogging, and hadn’t realized that in a default installation, the dynamic page creation WordPress uses can really limit the number of pages that you can serve at a time.  And although I have yet to write that breakthrough post that gets on Digg, Reddit, and Slashdot all at the same time, I figured it might still be prudent to take steps to minimize the load on my relatively puny server.

After clicking through and reading some of the links describing different caching schemes for WordPress, I decided to grab one of the highly-rated plugins to handle caching this blog.  I chose WP-SuperCache.  Although it has a bewildering variety of options, it boils down to taking the dynamically-generated pages you publish, boiling them down to the raw HTML that ends up served to the client, and caching that on the server.

When this is done, the webserver only has to sling raw HTML to the browser, rather than make multiple round-trips through PHP to the MySQL database to construct the page.  This should be both faster and lower load on the server.

So feel free to load up this site as much as you want, and send links to all your friends.  Sure, even include another few hundred “Anubis Gates” spammers.  I can take it!

Tags: , , , ,

Type-Safe Message Passing in Win32/MFC — Part 1: The Problem

Statshot-Top-Safety[1]This is the first in what should be a series of  posts about a problem I’m addressing at work.

I work on an application that is fairly old; it’s grown through accretion over the past decade.  There have been a few architectural revolutions during the process of development, but the code is still very much the Visual Studio 6-based C++ MFC application it started as.

One of the areas where we’ve made progress in the past year or so is in the introduction of smart pointers, specifically boost::shared_ptr<>.  When we upgraded to Visual Studio 2005, which has a fully standards-compliant compiler engine, we suddenly gained access to a number of modern C++ libraries, including Boost.  One of the best modules available in Boost is the smart pointer one, and the “best” (most generally useful) smart pointer in that module is boost::shared_ptr<>.

I won’t bore you with the details, but shared_ptr — a “reference-counted smart pointer” — allows you to almost completely rid yourself of the headaches of manual memory management in C++.  It wraps raw pointers in such a way that you can pass them around freely, like any other first-class object in the system, and internal logic in the shared_ptr object will track the number of references for you.  When there are no references left (all copies of the owned pointer have gone out of scope or been otherwise decomissioned) it will automatically delete the wrapped pointer.

The upshot is that this is great behavior, and very useful to us.  We’ve put them in everywhere we could do so easily, and reaped the benefits of stability by doing so.  We’d like to use them in other places, but unfortunately our architecture heavily leverages the standard Windows messaging system.

Invented for Windows 3.1 (or possibly earlier; I’m not familiar with pre-3.1 Windows) way back in the Dark Ages, the Windows messaging system is a way to modularize applications by providing a generic messaging interface.

You make calls by calling PostMessage() or SendMessage() and providing the window handle of your target, the message code you want to send, and a couple of generic parameters that carry information about what you are trying to do.  The calls look like:

LRESULT ret = ::SendMessage(hWnd, WM_MESSAGE, p1, p2);

There is then code on the receiving side that retrieves these messages and dispatches them to the appropriate handler function with the provided parameters. Voila, instant decoupled function call!

This is all great, as far as it goes.  Where the problem comes in is with the parameters.  These (in Win32) are 32-bit integers, and if what you want to send is too large to fit in two 32-bit integers you need to pass the address of the object you want to access as one of the parameters.  Once you’ve done that, you are faced with a number of problems:

  1. How do you ensure the receiver treats the pointer you’ve sent as an object of the correct type?
  2. How do you know whether or not the receiver should delete the object’s pointer after it’s done using it?
  3. How do you even know (in the case of PostMessage) that the object will even be valid by the time the receiver gets around to using it?

All of these are major issues, and unfortunately all of them are easy to get wrong and there’s no way to tell until your code hits a problem and explodes.  There are better message-passing schemes that have been invented more recently (such as signal/slot, etc.) but completely replumbing our application to support these is not an option.  We’re stuck with Windows messaging.

It would be really nice to use smart pointers for these types of calls though, wouldn’t it?  If we could properly use shared_ptr, that would eliminate issues 2 and 3.  And it would be nice to add some compile-time type safety as well to eliminate issue 1.  If you could do this, you’d have a way to pass typed arguments via the Windows messaging system without worrying about memory allocation or ownership issues, and if you made an object typing mistake, the compiler would inform you about it right away, rather than letting your users inform the customer service desk.

This is the problem I’m trying to solve.  More to come!

Update:  I may need to defer writing any more on this until I find out whether my magazine article submissions are accepted or not.  They won’t accept material that’s been previously published, even online.  I’ll keep you informed.

Tags: , ,

Cool Plugin — WP-Syntax

nerd-cake[1]I hope to eventually have some more programming-related updates here; I’m working on a solution at work to add compile-time type-safety to Windows message passing that will make a good article (or two) when I’m done.

In the meantime, I have my IFComp updates, although vacation and the sheer number of other projects I have at home is cutting down on the amount of time I have to code in Inform 7.

What both these types of posts need, however, is a good way to format code.  By default, WordPress does not do a good job at all with code samples.  Luckily, however, there are a wide variety of plugins available to do a better job.  The one I chose is WP-Syntax, which leverages the GeSHi highlighter engine to do formatting syntax highlighting for a wide variety of languages.

None of these languages include Inform 7, but syntax highlighting wouldn’t really do much for Inform 7 anyway. For that language I’m just happy to have a nice box and a good font, which I get by default.

Here’s a (nonsensical) example for C++, to show off the highlighter features:

template <typename T, typename U>
class Complicated <T *, U> : public ComplicatedBase
{
public:
    Complicated(const CString &szData) 
    { 
        if (szData.IsEmpty())
        {
            m_szData = "Error";
        }
        else
            m_szData = szData;
    }
    virtual ~Complicated() { /*do nothing*/ }
    void SomeFunction() const;
private:
    CString m_szData;
};

…and another for SQL:

SELECT t1.a AS Name, t2.b AS Something_or_other
FROM Table_1 t1
    INNER JOIN Table_2 t2 ON t1.t1_ID = t2.t1_id
WHERE t1.c BETWEEN 4 AND 8
-- had a GROUP BY here...

Pretty cool, eh? The drawback is that the very nice visual editor in WordPress is not compatible with the formatter, but I can live with writing in raw HTML to get results this nice.

Tags: , , ,

The Quern is Digg proof thanks to caching by WP Super Cache