Hooray! AxCrypt2Go can now display icons for AxCrypt-files (although just the small one right now). Anyway, it's a proof of concept, now I'll have to refactor that code into something I can publish. That's one of the advantages of open source - it can't look too bad, so it has to be fixed. But that's not what I want to write about today, not really. I realized that I was not running the compiler at the highest warning-level (4), but only 3 and that's normally a principle I want to follow. Highest warning level, and treat warnings as errors. This actually led to a good thing today, because I just clarified something a little bit in my mind about how to use std::auto_ptr to the best effect. As it turns out, the compiler will complain about the following construct:

auto_ptr<char> s;
// Do something...
s = auto_ptr<char>(new char[100]);

The reason this is not a good idea is rather subtle, but basically it's due to the fact that the temporary object is not a reference to an object, it's an object, and you can't really make a reference to a temporary object like that. At least it's pretty bad form... It's a similar situation where you can't use a temporary object as a parameter for a non-const reference formal parameter to a function.

The way to do this is of course:

auto_ptr<char> s;
// Do something...
s.reset(new char[100]);

This led to some other code being affected, specifically code where methods had the following type of signature:

auto_ptr<char> Func() {
    auto_ptr<char> t(new char[10]);
    // Do something to set t to something
    return t;
}

This looks neat, and is apparently a good idea to ensure that allocated objects are automatically delete'd as part of the auto_ptr destructor. However, this messes things up in other parts of the code since once again for similar reasons as above.

The resulting pattern rule is:

• Always return a pointer, not an auto_ptr, when an object is allocated.
• Never store a pointer, always wrap it in a auto_ptr object when it's kept around for more than passing on in the same statement.

Now we get the best of both worlds, and less things to send up via function return. The above is not guru-level C++, but it helped me to clarify things.

I'm a strong believer in what I call "code policy". Code policy is about formulating rules of coding, a bit like design patterns but more generic small snippets of wisdom accumulated through experience. I use probably 50 - 100 such "code policies" whenever I write code, and it's certainly been extremely useful. It takes the burden out of making many small decisions, and I may start document them for peer review in the future - that could be fun!

Got the mail out anyway now. Back to coding - or actually not so much coding as struggling with other issues. Latest is the issue to get Visual Studio to like WTL - the Windows Template Library that AxCrypt2Go will use for it's GUI. I haven't really succeeded, but I guess I'll just live with it, but it's a bit frustrating to implement a program with a library that does not support Intellisense - and lacks documentation to boot. But it is free... Here's an example of how fun it can be to program the Win32 API - it's an oldie and still goodie, but it serves as a nice example of why it's important to think about things before coding...

The Win32 API call GetModuleFileName is declared as:

DWORD GetModuleFileName(HMODULE hModule, LPTSTR lpFilename, DWORD nSize)

It gets a file name of a running executable, and places it in the buffer pointed to by lpFilename, restricted in number of chars by nSize. So far so good. But how do you figure out how large a buffer you need? Well... The function will return the number of chars copied. If there is not enough room, the result is truncated and nSize is returned. There is no way for the caller to determine if the result was truncated or just exactly fit! To make matters worse - it is definitely not bounded by MAX_PATH as some functions are, it may return an arbitrarily long path, when prefixed with \\?\, if that format was used when the executable was loaded.

All this leads us to ridiculous code like the following (truncated for brevity):

There are many variants on the above, but the point is we must use a trial-and-error loop! A much nicer version is a better API like, for example, GetTempPath. This function will instead return the number of characters required to hold the result, thus easily enabling the caller to determine if the provided buffer was large enough or the result was truncated. Even better, it allows the following pattern:

DWORD dwLen = GetTempPath(0,  NULL);
std::auto_ptr<_TCHAR> szTempPath(new _TCHAR[dwLen]);
dwLen = GetTempPath(dwLen, szTempPath.get());

No loop, just the right amount of data etc. It makes a difference! It should be noted that as far as I can determine, both these APIs are the same age... So - the morale of the story - always think about how the caller can use your API, and never make assumptions about the size of data.

Ok, back to actually writing the program I'm supposed to be coding...

Back from 2 hours of coding - net result: 10 lines of code. Lean and mean, and using the basic API has it's price. All I'm trying to do is to enable my app to display icons from the system icon list plus one single private icon (the ugly one that's used to indicate AxCrypt-encrypted files). This turns out to be a major headache, since the list view control needs a single image list and an index into that to display an icon, and we the contents of the system icon list is dynamic, so we can't just copy that and be done with it. The strategy now is exceedingly complex, may it's time to re-evaluate and check if list views can be coerced into displaying icons some other way. Readers: any ideas?

Started going through lots of old feature requests on SourceForge, incorporating them into the feature list of the next version. It seems I won't have any trouble keeping busy this year either! There are so many nice things to implement - if I get around to 50% of the features and ambition, AxCrypt2Go will be a very nifty and useful little utility!

In the background I'm also thinking about whether the *nix gettext library really is the right way to go. First of all I have not managed to convince the maintainer that programming defensively against memory leaks is a good thing - so it leaks (or rather permanently allocates and does not free on exit), messing up my chances to make a proper program without investing time and material into tools and stuff. I can see why C/C++ programs traditionally have such problems with leaks with that view. It's really frustrating, as I do not want to keep a custom version of code in my code base. Did that once with zlib - been there, done that. Not again. Also, I'll have to delve deeper into gettext to figure out a way to place language packs in smarter location than ..../se/LC_MESSAGES/AxCrypt2Go.so . Haven't really tried either - anybody out there who just knows? Send me a mail.