Sunday, October 30, 2005

C++ Coding

This is not a comprehensive list - just the things that come to mind right now.

Thing I like:
  • Classes. Having difficulty going back to C to do embedded work. My solution: try to convince everyone at day job to compile C code with a C++ compiler :-)
  • Very like C (which has it's own positives and negatives...) but I know it well and I can use old code I have.
  • Can drop into procedural style if necessary for certain problems (like some other languages, e.g. Python). Some people think this is a bad thing ... I think they are slightly mad ... more limitations is not good.
  • Can write everything from faceless computationally heavy stuff to gui stuff (although no standard makes it interesting)
  • Has a fairly good set of standard libraries as part of the language.
  • Love the container classes. Maybe not quite as easy to use as Python's lists. But fast and saves you having to write your own containers (as you did with C) which are never good enough and tend to end up as a compromise.
  • Easier to avoid buffer overrun problems.
  • Speed - never a problem. Obviously you have to have a good "algorithm" (or rather, not a bad one) but this has not been a problem for me. This is a definite advantage over Java, Python, etc. ...
Things I don't like:
  • I'm sure doing classes in C++ takes more lines of code (compared with classes in other languages), which I think might be slower to write? (Not entirely convinced by the suggestion that a line of code in any language takes the same time to write, however).
  • Sometimes the large amount of control over C++ classes is a burden (because things aren't controlled by the compiler and therefore, although they are more flexible, there are a lot of extras you need(?) to learn.
  • The book "The C++ Programming Language" is a blessing and curse. Comprehensive and impenetrable. However, I haven't been able to replace it with a work that is as comprehensive. Definitely need the latest edition (3rd or special). Arrggghh..... Got lots of post-it notes in my copy at home - to find things quickly. Everything is in there, usually buried.

Friday, October 28, 2005

Big Gap

Yep, a large article free gap.

Well, for the day job, I spent some time in Germany, doing "the next big thing". Whilst we know (generally) what the next big thing should do, how to go about building it is a whole different matter. We know it involves OO, some minimal UML and probably C++. Our expertise with these is in varying degrees. Should be 'interesting' - but at least it's something different.

Outside the day job the last two weeks have been a bit barren. In the Germany week and then afterwards last weekend in my exhaustion I started to write another GA life creation terminal-based thing (called slimey for want of a better name. Yes I know how 'slimy' is spelt now) using a slightly different class based design than 'Evolving Minds'. I guess at some point I should merge the two projects - but I think slimey, partly because of it's simplicity, is further along in the interpreted program / GA breeding stakes - which is what they are both intended to investigate. I think I should carry on with slimey as it is until I have it working - then perhaps merge with EM rather than add objects to be manipulated directly in slimey. (Naming note: I guess that should be Slimey rather than slimey since it's a name. It's just my filenames tend to be lower case.)

By last Tuesday I was feeling I should really start to work back on the space game. Although I've looked at the project and tinkered over the course of this week, I haven't got into 'the zone' at all. Earlier in the week the problem was because I was simultaneously listening to the audio-book for Harry Potter and the Philosophers Stone. (Partly my wife's fault for reading all the books in just over 3 weeks). I have learnt that it's almost impossible for me to listen to a book and program at the same time - my concentration appears to be indivisible in that respect.

Tonight (Friday) I've done hardly anything. I surfed slashdot truth be told - as I have a few times this week. I gave up reading that infernal thing ... now I'm back on it. MUST GIVE IT UP AGAIN! Hopefully I'll get some quality coding time this weekend (especially since I've got Monday off for a 4yr-old's b-day party (Sad but true. Hopefully there will be birthday cake. Apparently the invited kids got a formal invite. But not us. Verbal only. Pah!).

Oh well. Must try to code at least a few lines before I go to bed (set the tone for the weekend and all that).

Sunday, October 16, 2005

Here's a place for C programmers to spend hours of (wasted) time.

If you want to know what they do (somewhat spoils the fun of discovery, but still fun...)

The great thing about these programs is not just the abuse of the C compiler (and the rules!) but also the fact that these real programs are so small!!!!

Have fun!

Saturday, October 01, 2005

Variably Global?

A good friend of mine and me were discussing global variables. One of our older projects has quite a lot of them and, with various compilers different scoping rules, there has been some strange effects between accidental duplicates. Nothing serious and the original problems were a mixture of a lack of conformity and lack of warnings - both from an old compiler.

This got us talking about global variables in general. I was saying that I thought globals are generally a bad idea and he was saying that they don't pose any more risk than some other language features.

I know that I don't think this about global functions and I wonder why? Perhaps it's because that part of easily traceable flow of execution? Theoretically namespace conflicts can be a problem with global anything if you are not careful - not that I've had the problem (and C++ namespaces can provide the solution if necessary).

I always take care to make my module level variables and functions local to that file (static since this project is mostly C). Certainly I suspect some 'OO-purists' might say that they think global functions are a bad idea and so are module level anything - and everything should a method/member functions of a class and variables should be class instance variables only.

So I am still left wondering why they are so bad according to the warnings in literature and on the web.

Some of the warnings talk about unexpected alteration which I guess might be a problem in a very big program or in a program where the usage of the variable is not well understood coupled with a bad name or something. But might this failure mode not happen in another way equally as often? Not understanding the modes of a program is certainly not localised to global variables. Someone must have statistics for different sizes of program I guess - but they would need to compare then to the same failures using other methods?

I guess the unexpected mutual dependancy problems really depend on how you use global variables. It is not like the goto problem where there is a entirely better way that's as simple to use* since, for instance, you can get a mental parameter argument overload when too many parameters are passed. Global things are really useful sometimes - to the extent that OO-purists have duplicated a complicated version called a "singleton". Tell me that's not effectively a global class instance!

*I think gotos have nearly entirely died out from programs not because of the spaghetti code that some people would generate but because goto got replaced because more readible, more usable flow control methods could be used easily to express the same thing.

Oh well, back to my canned variable font code.
Newer›  ‹Older