« Silence of the Socialites | Main | Obviousity »
Just sitting here watching the compiler lines go by
Posted by aogThursday, 15 November 2007 at 11:26 TrackBack Ping URL

I was checking my RSS feeds while waiting for a system build and I saw a post about OJ Simpson. I almost clicked on it, but then common sense prevailed and I decided I would rather watch messages like

17>Compiling...
17>SQEdit.cpp
17>ShelfModel.cpp
17>querent_app_main.cpp
17>querent.cpp
17>MacroModel.cpp

scroll by in my build output window than read anything more about OJ Simpson.

Comments — Formatting by Textile
Gronker Friday, 16 November 2007 at 13:27

17 screen windows open? Tangent much? :)

Annoying Old Guy Friday, 16 November 2007 at 14:06

No, the “17” means that it’s the 17th project to be compiled in the system build. Although 17 screen windows isn’t that uncommon for me, so go ahead and call me “Tangential Boy”.

Gronker Friday, 16 November 2007 at 18:53

Haven’t changed too much from the “Entropy House” days, hmmm?

Annoying Old Guy Friday, 16 November 2007 at 19:42

Not much.

cjm Saturday, 17 November 2007 at 00:34

since this thread is sort of programming oriented, i guess i will use it to get your views on “design by contract”. i have been using a simplified version of it on a personal project, and have gotten really good results. using assertion statments, i check all method parameters (even public methods) and all critical intermediate results (mostly checking for non-null).

before i was doing if-then-exception type checking which cluttered the code and was awkward to handle from the caller side of things. there is no attempt to “handle” undefined or illegal conditions, and once the assertions are turned off, any errors will have free reign :) anyway, i would value your thoughts on this area, and especially am interested in ay techniques/conventions you use personally.

Annoying Old Guy Saturday, 17 November 2007 at 07:28

I tend to the flavor of design by contract, but tend not to use a lot of assertions. I prefer to use other techniques to enforce the contracts automatically.

  • If my library hands out data to a client to be handed back later, I use a DINO class for that so the client can’t touch the data without explicit hacking to get at it.
  • I use enumerations whenever possible.
  • I use wrapped smart pointers as a variant of the opaque pointer technique. This means that the client can’t
    • create unexpected nil handles
    • improperly initialize new instances
    • leak memory
  • Wrapped handles also lets me redefine error conditions to normal conditions. If a client adds an element to a nil handled wrapped container, the wrapper just auto-instantiates the container and adds the element.
  • I use accessor methods instead of raw member access unless any possible value is acceptable for that member (e.g., the description text for an instance). I actually did this more to make template / STL use easier.
  • I use a lot of templating and code generators, because one of my mottos is “code you don’t write can’t have bugs”.

In the end, I still do a lot of if-then checks for parameters because I have found that assertion failures just don’t give enough information to debug in general. Instead I use a home brew error reporting mechanism that lets me stack error messages for the final output. E.g., if library A calls B and B fails, A can stack its own message on B’s error and return that. This lets me see what the failure locus was and its larger context. “Unexpected nil pointer” is fine, but who passed in the nil pointer and why?

Post a comment