Don’t bring C to a string fight

David Shaw, 1:12 am 5th August 2009
Posted under: Blog Babble

A programmer oriented blog post today:

I’m still tinkering around with the guts of my old system, remembering how it all works. Rewriting the code concerns me a bit that I am technically reinventing the wheel, possibly wasting time. But it’s being invaluable in revising my old coding habits and getting back up to speed. I am worried that I am running a few days over where I’d like to be; I was hoping to have a bare bones functional wrapper for the basics done by the start of August.

The biggest change is I’m moving my code from C++ back to C, partly because I want to move to a scripting language for the bulk of the work, partly because I want to see how it looks. Mostly this isn’t much of a change. There used to be a delegate based signal system for passing events through the system that formed the core of the message loop. The code was elegant on the outside but a nightmare on the inside; it heavily used templates and the types the debugger would throw up were horrendous. For now I’ve replaced it with a simpler message passing system somewhat modelled off the interfaces to SDL (which incidentally I’m still using for cross-platform functionality). My simple unit tests seem to suggest it’s working nicely.

But man, does C suck for anything involving strings. I spent all of yesterday just writing the code for reading in a config file (the original used TinyXML, a C++ library). True, that’s partly because I’m a bit rusty and was making boneheaded design errors. But it’s somewhat understandable when you don’t have the usual C++ string library to work with, or a higher language like Python to handle all the ugliness. The stupid thing is I only wanted a fill-in module to handle the early prototypes, as I want to explore using Lua as scripting language; reading config files is (almost literally) what Lua was made to do.

Still, I did get some really good C practice out of it. And it was good practice with Xcode’s debugger, hunting for pointer errors.

It does make me question a bit whether the decision to roll back to C was wise. It does mean I lose a lot of C++ only libraries – admittedly the ones that come precompiled tend to be a pain to use, as you have to have the right compiler, but the ones you can compile yourself are useful. And I lose out on the standard library – which may or may not be an issue, depending on how much I can farm off to Lua. But on the plus side I find C easier to debug, and there’s less of a push to use clever C++ features just because they’re there. I’m also getting a feel it works better for the message passing design paradigm I’m going for; C++ tends to lean towards using objects for everything, even when they’re not really needed. I do miss namespaces; really useful things, namespaces.



7 comments for “Don’t bring C to a string fight”

  1. Andrew Russell says:

    Have I ever mentioned how terrific C# is? (aside: so is XNA)

    There’s no excuse for non-Microsoft platforms – Mono is just as solid. And there’s no excuses about bytecode/JIT either: http://arstechnica.com/open-source/news/2009/01/open-source-mono-framework-brings-c-to-iphone-and-wii.ars

    C++ is a productivity time-sink due to all the extra stuff you have to worry about. But that doesn’t mean C is any better. Where you don’t have to worry about templates and so on, you now find yourself worrying about strings and re-implementing yet more of what a modern standard library should contain.

    And scripting in Lua or Python is just a hack to overcome the limitations of C/C++. With a sensible language in the first place, you won’t need to bother. (AppDomains are useful if you actually care about 3rd party modding.)

    Anyway – if you really, really must use C – it’s worth remembering that C and C++ are interoperable for a reason. And C++ is multi-paridgm – you don’t have to be all academic about orienting objects – leave that for the library developers.

    There is no sense in giving up namespaces and std::string just to have the compiler stop you writing classes!

  2. David Shaw says:

    I haven’t yet properly considred C# – where properly consider involves writing a small program with it. When I decide it’s time to trial a new language I’ve ended up picking other languages like Python. I know a lot of people swear by C#, but when I read overviews and sample programs it just feels a bit too much like Java to me. I never liked Java’s rigid OO framework and its tendency for programming to feel like just a series of system library calls. (Although admittedly I’ve only written a bare half dozen semi-serious apps with Java too.)

    I’m reviving C as my down-to-the-wire language mostly because, after a couple of years of working with higher level langauges, I’ve realised that I actually like C. It’s got a simplicity about it that I find helps when thinking through algorithms. For data types C only really has integers and floats; memory pointers are treated as integer addresses. You can get a feel for what the code is doing at any point of time. Of course, there’s a bit of nostalgia here too; C is the first app quality language I learnt (after BASIC variants), I’ve used it a fair bit in apps and games, and it’s probably the langauge I’d say I’m best at.

    The big (big) downsides is that C doesn’t do any housekeeping for you by default, so you’ve got to put in error checks and be very careful about memory. And strings are a royal pain. ;)

    While I’m keeping C# in mind as an alternative, I’m not going to switch languages until I’ve done a proper test of this approach. If everything clicks into place, I’m hoping a C-with-higher-language approachis good for me to work on experimental algorithm ideas. If however everything falls into a heap and the combination proves unworkable, I’ll switch to something managed and scale back the algorithm ambition somewhat.

  3. Andrew Russell says:

    I wouldn’t worry about it being like Java. When people call C# “Java done right”, they’re not kidding.

    Speaking of “C-with-higher-language” – C# can interop with C very capably, if that’s what floats your boat :P

  4. David Shaw says:

    True, but “Java done right” still sounds very Java-like. ;)

    I also admit I’m a bit uncertain as to the cross-platform friendliness of C#. I develop on Macs, and these days I aim for cross-platform between Mac and Windows from the get go. I admit it isn’t straight-forward in C or C++ – libraries help, but there’s a bit of hacking – and I’m sure Mono might make that easier. But there’s still a strong impression I get that C# is a Microsoft OS language; it’s good for .NET in Windows and Xbox, but not so great a choice for Macs or Linux. I don’t know if that impression is unwarranted these days, but I do know there’s a very strong assumption you’re primarily aiming for Windows, using .NET and working in Microsoft Visual C#. That can be a thorn when you’re just starting out.

    Eventually I’ll need some GUI tools. I’ll be using another language for those, as I’d be crazy to write my tools in C. I was thinking of writing the tools in Python, but I might use that as a method for learning C#; or at least, a way of trialling it against Python. I recently trialled some cross-platform wiki software which included Tomboy Notes, a Mono app, so I know it can work. More Mac native than WikidPad (written in Python), too (although I prefer WikidPad for functionality reasons).

  5. Andrew Russell says:

    Well – I must admit that I’ve never actually tried to use it cross-platform. So I’m not really sure if the tools are up to the standard of Visual Studio (but then – not much else is either). But the language itself – and the libraries with little exception – are obviously OS neutral.

    Mono actually has a bit of a step-up on regular .NET for Windows. The installation for .NET 3.5 is slow to the point of unusable for games – however 2.0 comes with Vista, so I just use that. Whereas Mono you can package the runtime itself (or a subset) to meet your needs.

    (Aside: If you do need a cross-platform UI, and you need to go native, then my recommendation is wxWidgets.)

  6. David Shaw says:

    I did a bit of research, and the general advice for using C# on a Mac is “Get Parallels and run Windows and Visual Studio”. That’s kind of defeating the reason why I develop on a Mac. :)

    And C# has wxWidgets too? That library seems like it’s been ported to every language.


Leave a Reply