The C++ Purist

New Site

2009-11-15T20:30:00.001-08:00

My new site can be found here: http://www.softwarepurist.com

All new blog posts will be at this location.

Software Testing Follow-Up

2009-11-10T11:40:00.000-08:00

As a follow-up to some of the software testing types I posted in an earlier blog, I came across this, which is a great description of various different types of software testing:

http://bugsniffer.blogspot.com/2007/11/software-testing-types.html

Timers During Daylight Savings Time

2009-11-01T17:14:00.000-08:00

With Daylight Savings Time just passing early this morning, it occurred me that timers could have a subtle bug. This occurred to me today because I was running some overnight tests last night. While the tests exhibited no issues with the extra hour, I can foresee scenarios where it could have.

For instance, let's say you have a C++ class that looks something like this (Pseudo-code):


class Timer : public Thread
{
public:
    virtual void run()
    {
           while (running)
           {
                get current time
                while (current time < time value at top of timer queue)
                {
                      pop
                      notify timer listener
                }
                wait for top of timer queue to expire
           }
    }
};

This code is relatively flawless, except, what if the current time drops back an hour? This can occur, depending on how you retrieve your time. Now, in the worst case, all of the timers in your system won't trigger for an extra hour. This basically means your code is mostly nonfunctional for an hour after Daylight Savings Time occurs. In an application, you can just restart the application and the problem vanishes. On server code, this can be a bigger issue at this peculiar time.

Here's one solution I thought of to correct this potential problem:

class Timer : public Thread
{
public:
    virtual void run()
    {
           while (running)
           {
                get current time
                if (current time < last known time)
                {
                       create temporary queue
                       pop each element of queue, subtract difference, push to new queue
                       pop each element off temporary queue, push back to original queue
                }

                while (current time < time value at top of timer queue)
                {
                      pop
                      notify timer listener
                 }
                set last known time equal to current time
                wait for top of timer queue to expire
            }
    }
};

If you do this, you basically have this level of correction code to handle this peculiar scenario. The solution is that every timer is adjusted to handle the problem. Of course, this isn't a perfect solution, but it's one way I can think to mitigate the issue. I may write a test later to see if this solution is good enough or if there are better ones. I suspect many well-known timer libraries handle this already, but in C++, you can sometimes justify rolling your own depending on your needs.

Software Testing

2009-11-01T08:34:00.000-08:00

So, it's been a long while since I've made a blog post. I decided to revive the blog this weekend. I was thinking a good topic would be to talk about a few different types of tests a software developer can do and what each provide.

Unit Tests

The purpose of unit tests is to test the functionality of a generally lower-level software module. External dependencies are stubbed out and mocked, so that you can test components in isolation. Checks are very granular and the test will generally give a pass/fail result, which makes it easily automatable. In my experience, there is often some confusion as to what a unit test can and cannot do well. For example, you might write a unit test that tests a class called String. It might find that you have two issues with this class that you fix. However, this won't necessarily have a noticeable effect on your product. Unit tests are to make the developer's life easier, because they take really difficult-to-fix bugs that wouldn't be found until later stages and make them into generally easy-to-fix bugs at earlier stages. This flows in with a process known as risk mitigation.

However, they don't necessarily make the development cycle take less time. When unit testing is done elaborately, including using a process like Test-Driven Development and automating these tests when making a build, they can be extremely beneficial. But, where time may be saved is often the deployment and QA teams, not necessarily the developers. Companies have to be willing to pay the extra cost for these tests in the name of higher quality, a smoother process, and to ease refactoring. Finally, unit tests are typically terrible at testing any non-deterministic process, especially when threads are involved. It is also generally difficult to test GUI functionality.

Integration Tests

I find these generally less useful, because this is the middle ground, as has enough overlap with unit tests and broader tests that they sometimes can be excluded. Still, in some scenarios they are quite useful. Just like in unit tests, integration tests tend to be automated, but this is not always the case. Where integration tests differ is that you generally don't stub out interfaces, unless it's an interface that is totally superfluous to the test or would prevent the test from running in an automated way. An example of a integration test is it might run the core engine of your application along with another component of the application, such as a logic module. The integration test would start by running a database query to reset the database to a known state, send login requests for 100 users, and verify that the 100 users logged in. It would then check the database and make sure the 100 records were properly set into the database. Then it would clean up the database.

Load Testing

I find that these are the tests I write towards the end of the cycle. You generally can get away without these if you're making a standalone application, but it is essential for a server application that expects a high user load. The load testing script, often written in a language simpler than your application, such as Python, will simply simulate a bunch of users repeatedly trying to simulate a variety of scenarios during the test. They often all try to simulate the same scenario, but sometimes they try to stimulate different areas of the system at the same time. Verification at this stage is generally minimal, because in most situations, the users can interfere with each other, creating false failures. What you are trying to verify here is longevity test to prove that the server can withstand a constant barrage for n hours with m users. Failure on this test will often be discovered manually when you come in to check it the next morning, and will be something of the nature of a crash, deadlock, excessive memory growth, performance degredation, etc... Smaller issues, such as 1 out of 1000 users not having their record stored in the database are unlikely to be discovered.

Conclusion

While this isn't all of the types of tests a developer will use, I find these to be the most frequent in my travels. One thing to keep in mind is setting expectations at the appropriate level. Developer-level tests are extremely valuable in making the developer's life easier and making life easier for your coworkers. The thing I want to keep emphasizing is that they don't necessarily save time and money, though. I give this caution, even though I'm a huge fan of software-level testing. You write tests for quality, period. Some hidden benefits are that they also provide additional "documentation", example usage and generally make refactoring easier, because if you have to fit your code into a test, it's more difficult to take shortcuts.

Overall, I have worked at both companies where quality was held highly and others where it wasn't the most important factor in the success of a product. You have to decide for yourself what's most appropriate for what you're doing. One thing that's important is setting expectations correctly. Sometimes management will think that if you write a test, the software will be bug-free. There isn't a single piece of non-trivial software that is bug-free, anywhere in the world.

Ada-like Range Validations

2008-07-11T05:43:00.000-07:00

This post has been migrated to my new blog. Check it out here: Ada-Like Range Validations

What Is Up With Google Search?

2008-02-11T23:36:00.001-08:00

I am getting seriously annoyed with Google search. When I first made this blog, for the first few weeks I varied between #1, #3 and #5 in Google's search if I searched for a term such as "C++ purist". Then, for no obvious reason, I completely dropped off the search. This includes if I googled the exact URL on this site. Nothing. That lasted for weeks upon weeks. Then, my blog miraculously returned and was consistently #3 or #5 in search. Now, when I check this week, it is again gone from search completely, and search terms which can make it arise seem random. For example, "The C++ Purist" only has three hits, none of them mine. However, ["The C++ Purist" Rydinare] (minus the []) will bring my blog up directly.

I can't tell if this is a serious flaw in Google's search algorithm or this is simply Google having some very obscure rules about search. Nonetheless, it's clear to me that a search for "C++ purist" and a search for "The C++ Purist" should have me in the list.

Anyway, for your entertainment, here's a few other interesting links I came across when searching for "C++ purist":

"I think moderation is a necessity also for those trying to protect it.It's basically this that I'm advocating actually. The hatred of C++/CLI comes from religious ferver of the C++ purist. Not to mention inborn hatred of microsoft"

"Any C++ purist who looks at a message map has an immediate question: Why didn't Microsoft use virtual functions instead? Virtual functions are the standard C++ way to handle what mesage maps are doing in MFC, so the use of rather bizarre macros like DECLARE_MESSAGE_MAP and BEGIN_MESSAGE_MAP seems like a hack."

">>OK, in this case it's more a matter of taste.
>>Simply, I'd choose Boost as I'm STL/C++ purist.
>>
>>But I don't agree that Boost would make code inconsistent.
>>If you think so, why don't you replace all STL's containers
>>with QVector and QList?"

"This is a good example of where a C++ purist will always use <<>>, but a pragmatist will just use printf()"

Hmm, interesting how the term "C++ purist" is thrown around. As a C++ purist, I agree with the purist views in the links I checked out. Except for the hatred of Microsoft comment. Nobody really hates Microsoft, they hate the fact that Microsoft always chooses to go its own way, instead of sharing to the benefit of everyone. If they shared, they would allow themselves to become the "standard" across the industry, instead of forcing others to come up with a different implementation. When they make improvements over what's generally out there, they should share, instead of boxing it in Windows. Furthermore, Microsoft has encouraged a lot of bad programming practices over the years, which were against some of the better judgment of the more "purist" community. Those are the reasons why purists are disenchanted with Microsoft.

OpenMP, Threading-Building Blocks, Others?

2008-01-12T09:46:00.001-08:00

This post has been migrated to my new blog. Please check it out here: http://www.softwarepurist.com/blog/index.php/openmp-threading-building-blocks-others/

Best Practices

2007-12-15T19:02:00.000-08:00

I do mostly C++ and stick to the portable side. So while you can go to non-portable things like Microsoft APIs or .Net, I avoid those. I'll give a runthrough of my opinion as to things that should be in modern C++ applications of reasonable size.

When programming C++, there's books by Scott Meyers, Herb Sutter and Andrei Alexandruscu which teach you many of the best practices in the language. As far as I'm concerned, it's no longer acceptable to simply have a working program. You have to make it flexible, code for reusability and use best practices. It does show in aspects of the end product. Use of the Boost library is also very helpful for a C++ program nowadays, as it fills in many of the holes that the standard has not gotten to. Knowledge of good object-oriented techniques as well as good template metaprogramming skills make code much more maintainable when done correctly.

Gang of Four Design Patterns is still not known by 9 out of 10 developers. That's insane to me. The book has been out over 10 years. Generally the very good programmers make use of design patterns. Head First Design Patterns is great to learn it. I see the Gang of Four book as more of a reference. I consider the grasp patterns just as important. These are described in one of Craig Larman's books.

Use of UML for modeling and describing behavior. Most developers on my team don't know UML. Another insane thing. UML is a great tool for describing a system and designing it out. Especially sequence diagrams. If there's one thing that should be used more, it's sequence diagrams.

Test-Driven Development is great for making more flexible code and actually having tests for individual pieces of a system. What I like is in order to write the test you have to decouple things. There's a few books on this which are great.

Refactoring techniques are another area not understood by many software developers. Moreso you have to understand what you eventually want the code to look like, and I think most developers see mush, see that it works and then are happy. Refactoring techniques and TDD play in very nicely together, because if you have the initial test, you can make "safer" refactorings, and keep running quick tests each time you make changes.

Separation of GUI and logic has always been a great idea. You never know if someday you might run the GUI separately or want to swap out the GUI entirely and not change other code. That's the basis of all good object-oriented design, minimizing impact to the entire system, localizing impact to specific areas. Finally, as far as separation of logic, separating it further into a scripting engine with external scripts, gives a nice mix of flexibility and speed. You can then write scripts which control specific parts of a system without rewriting the engine and waiting for recompilation all day long. Furthermore, non-developers can write scripts too. Huge advantage to a development team.

Some of these have been known as good practices for many years. They're even more publicized today as good practices. Why there is so much resistance to known good practices is beyond me. Those are my feelings anyway. There's certainly other good practices that I haven't mentioned here.

Why COM Is So Dreadful and Outdated

2007-12-14T19:22:00.000-08:00

I have two coworkers that absolutely love COM. Let's face facts; COM was designed to solve a specific type of problem and it not capable of solving others. COM is also very outdated at this point.

Let's go through the details:

COM was designed to work around a few things: First that C++ does not have a standard ABI (C does). The advantage here is that DLLs will be compatible between debug builds, release builds, and builds from different compilers, even different programming languages. Microsoft developed a whole library of components based on this (we'll can get into how truly bad MS's APis are some other time).

Now, the negatives:

1) Registration. Evil, evil, evil, evil. You mean to tell me that you can dynamically change the behavior of my app from right under my nose? This is worse than your regular DLL hell because registration ensures that there is only one "registered" copy per system. Finally with the advent of registration from COM, MS has realized how bad this "hell" is. Nonetheless, it absolutely causes havok. Consider a developer working on multiple builds on the same system. You can't run both builds at once because of this restriction! You can't even build one and have one run at the same time because you can have them conflict. This is an insane requirement. It is the #1 reason why COM is so terrible. Remember, global is bad. Every time you make some global, remember this rule. Anything that is global is bad. When you make something global, you're saying it's universally applicable. Everything is universally applicable until the day we discover that it isn't. That is the same day that we are screwed.

2) Hack of the C++ type system; incompatibility with the rest of C++. This is an unforgiveable requirement of COM. How can you make something in C++ that is incompatible with the rest of the language? They hacked their own version of virtual tables, force internal casting all over the place, simulates exception handling, thus preventing actual C++ exception handling, and is incompatible with many features of C++. Yes, you can use these features internally if they don't leak out of implementation. Wonderful. The fact that I can't pass an STL string through a COM interface makes it unsalvageable for C++. I could live with these restrictions, but only purely on the boundary between language, not within the same language.

3) Casting hell and cosmic hierarchies. Barf. I know at some point, Java, COM, etc... all though that having all classes derive from a single point was a great idea (let's not even get into IDispatch), but it encourages bad programming. In COM it's directly encouraged. To cast to/from IDispatch/IUnknown to get around bad design is poor. It's common practice in COM. Yet, ideally in object-oriented programming, you make use of design patterns to avoid such cases where casting in necessary. In COM based programming, people think that they are following good design since there's always a base interface. Wrong.

4) Factory abuse. COM factories are an abomination. The factory pattern was never meant to be used this way; COM's version isn't the factory pattern. It's not the abstract factory pattern either. These patterns were used to make object creation generic, not to hop around the type system and use IDs to check the registry, pick which DLL to load, load it, call a method, get returned an object, do internal casts to make it the type it should be, and then return it. Abuse. This is the kind of thing that should get you arrested by the C++ police.

5) The anti-refactoring. COM code is excessively difficult to refactor. This is exacerbated by the never-change-an-interface mantra. When you release third party SDks, you have to take care in changing interfaces. Nonetheless, it does happen. Some changes are breaking; they have to be. Breaking changes are sometimes required to progress an API. Otherwise you may be stuck with an underpowered, incomplete API. That is a poor solution to the risk of breaking code.

6) The idea that you can bring an app to a new system, run it with a newer COM object and it still works. A) Wrong. B) Wrong. C) Wrong. This doesn't always happen in practice. This is a benefit of keeping clean interfaces; COM wasn't required to do this. However, you NEVER want to toss new code into an existing code without retesting the entire thing. Thinking you can do this is niave at best, and moreoften, harmful. What's worse, because the actual changes are more insulted, instead of crashing (which is admittely nasty), you instead get a subtle bug and things appear to work... until they don't.

6) Difficult to write; difficult to read. COM objects are excessively difficult to write. I easily find that the overhead of setting up a COM object in addition to the registration woes is rough. Furthermore, having to convert my types into COM-friendly types back and forth is extra unnecessary effort. Writing them is annoying enough. As a developer, I hate writing COM. This is second only to how much I hate reading COM code. Ugly. What happened to clean modular code? All of this extra work, marshalling types back and forth, just to pass the COM layer. All of this extra work to catch every exception possible, to translate it into an error code, only to later translate it back into a _com_error.

There are so many reasons why COM is bad. It's just a bad technology. XPCOM has its own issues, as you can read here: COM in Mozilla

Development Thoughts

2007-12-14T19:15:00.000-08:00

Hey guys.

One thing I was thinking about today is that quality of the code is very undervalued in software. The code has to be maintained by developers on a daily basis. It can make things more difficult if some developers write code that make it tougher for others to work with.

My mentality to try to follow a set of established rules, and attempting to create code that is both readable (self-documenting) and modular. A clear separation of GUI and logic adds more flexibility between those layers. Writing tests and trying to following a process such as TDD can help turn difficult-to-find issues later into easy-to-fix issues now. Choosing the best tools for the job and avoiding the "golden hammer", while using known "best practices" I find extremely beneficial. I try to help things get organized so things that have been hinderances don't continue to be so. I also try to help increase communication as much as possible, share information.

There's some irony in this, because I've run into some very poorly written code before. One example off the top of my head is that I ran into this monster function that had 1000 lines of code. After tracking down the exception that was occurring based on an error log, I was astonished to find out that there were about 998 lines between that try and catch.

Development has a lot of dynamics; well-written code is a pleasure to work with. Poorly written code takes twice as long, and management doesn't always understand why since it "worked" before.