C++/CX: Not a simple love or hate

Standards are important. Standards makes it clear what to expect or what is expected of you. If you are still wondering what I am talking about, well then a bit of an explanation follows: I am talking about official standards as published by a Standard Organisation (such as ISO etc…). I want to quickly give my brief opinion C++/CX, a small deviation from the C++ standard, where, in my opinion, it is not quite clear cut whether the decision to deviate from the Standard was a good thing or a bad thing.

C++/CX, according to the Microsoft site (here), is a set of extensions to C++ that are targeted at Windows Store and Windows Runtime development. I came across C++/CX when I was reading some Windows 8 development tutorials and have not yet used it very much. My first thought was “why? oh why do you do this to us?”. Why not just make use of standard C++? First of all the applicability of a Standard in the context of Windows Runtime development isn’t as important since we are confined to that specific context. The applications developed are not aimed at being cross-platform, and developers are not likely to try and use a different compiler (although sometimes that might still be nice).

But there are other reasons that maybe we should stick to the Standard? How about the fact that a C++ developer has to now contend with and learn new language constructs that wouldn’t normally be seen in a C++ program? The other side of this argument is that experienced developers normally have no issue coming to terms with new programming languages (and since C++/CX introduces new syntactical elements is has to be defined as a altogether different language).

Maybe something can be found if the reasons for such a deviation can be inferred. This is trivial – the deviations have introduced new language features obviously intended so that developers do not have to cobble a lot of code together for elements that occur frequently in Windows Runtime programs. I have found some of these features to be interesting and potentially useful (interfaces, accessor methods etc.)

So where does this leave the issue? I think it leaves it in a fairly grey area. Deviations or extensions in this manner add a bit of diversity – as such, some of the features might be considered for the actual standard (just as many of the constructs in Boost have been added into the Standard C++ library). I don’t think we should fault developers for augmenting the tools available so as to have the tools they need. Yes, it can be frustrating sometimes if it is (basically) forced upon us by a big corporate giant. However in this case you have a choice (C#, Javascript, C++). The inclusion of Javascript deserves sidetracking from the main topic, and so I shall finish with it. Javascript’s inclusion tells me that Microsoft seems to be taking note of global trends these days instead of trying to beat the trends into submission and set their own. There are more and more examples of this including but not limited to the inclusion of Node.js into the Azure platform and more recently the integration of git into Visual Studio and Team Foundation. I kind of like the initiative, whether it is an elaborate marketing ploy to lure in new developers or not – time will tell.

Use cases – Menace or Miracle

I am sure I can say that any programmer who has been involved in any sort of formal software engineering will agree with me when I say that the process of formalising a system in documentation is tedious and boring. In many cases it has been found that too many resources has been spent on documentation for the benefits it has brought about which is why agile development methodologies have become more and more popular.

However, it doesn’t matter what type of methodology you are using when developing a complex system, there is still some documentation that always seems to exist. The first is of course some sort of requirements specification. History has shown that incomplete requirements is one of the main reasons software projects fail. The next piece of documentation that seems to always exist in one form or another is some sort of behavioural overview of the system that depicts how users interact with the system. This is normally shows the goals that the system needs to accomplish. In agile these are normally user stories. Similar to user stories are use cases which are depicted using use case diagrams and explained using use case narratives. During this past year (with the final year project) I had become tired of use case diagrams, at one stage I was basically eating and breathing them.

I am currently developing a complex system. I am the only developer and I know what the system needs to do. I couldn’t believe my own surprise when I ended up drawing use case diagrams for the system on my whiteboard. They just seemed to capture the essence of what the system needs to do and how it interacts with the users. Normally I would start hacking away at a new software project of mine, but here with one that I hope to expand to sell one day I just felt more comfortable in formalising in what the system will do – it provides a measure of confidence. This sort of documentation has always accompanied a fear of “what if I forget something”, but now I see that this is forcing me to actually take some time to think and brainstorm of absolutely everything.

So, is all this planning and formalising a system a complete waste of time – probably not. There is an entire industry that will probably back me on that answer. I know how frustrating it can be sometimes, especially for those doing these sorts of projects at university for the first time – trust me when I say that it is all done for a reason.