The Nightstar Zoo

Recently hacked a simple Julia fractal generator together over the space of about three days. The resulting source code is probably a litany of How Not To Do It examples, written in C++. For example, here are some of the screwier bits:


Laziness is a virtue, right? RIGHT?


Note the sucky indentation style and the extra insightful error message.


You may note that, aside from the blatant use of the wrong damn tool for the job, I also abuse C++ style comments horribly.


This is probably the cleanest bit of the entire codebase. Except, of course, if one notes the style of comment used...


Good news is, I'm actually using the right type of comment for the job this time around. Bad news is, I'm using a screwy hack because I can't figure out why GCC keeps putting my structs together in a completely different order to that specified in the header file.


I'm also horribly cheeky.

Discuss. (Also, does anyone know why GCC might be putting a struct together in some completely different order to that specified in my header files? This is bordering on a hair-rippy-out magnitude annoyance.)

It looks like there's two fields of size 2, and it's putting them into the same word to save space. Does the definition specify "packed", or does the build tool pass "-fpack-struct" to GCC?

Wouldn't it be easier to make a serialization function (or even make it a class) so that you can write by field name and never have to worry about it?

Doing things by offset is tricky business no matter how you do it. Even though you want the binary representation to be the same in the file, endianess, size, and padding can change on different architechures.

I needed this laugh. Thank you.

I have done this. I've also used variable names in that same vein. I checked in a bit of code once at Acclaim with a variable name that was about 300 characters long. It was a temporary variable needed because another programmer wrote a get method that took a pointer to int and returned void. The variable name explained all if this and then, at great length, detailed my position on this kind of programming in general before concluding with some rather graphic conjectures about the other programmer's heritage and anatomy.

The problem is that he's writing what appears to be a BMP file. (Why BMP? Even MSPaint handles GIFs and PNGs these days...) The structure in question implements the BMP header and its fields have to appear in a specific order.

The problem here might be that this is a C++ program, and in C++, a struct is just another name for a class with all fields public. I'd wager that the differences between a C struct and a C++ class make their binary representations incompatible, and wrapping the struct definition in an extern "C" block may fix the problem.

I imagine it's because BMP takes about 5 minutes to implement...



I don't really know C++ but just doing it by field name in a serialization function works no matter what's breaking it.

Or three days, if you happen to be an utter n00blet with a headache, like me...


Pray tell precisely what you mean by a, "serialization function," in this particular context. Please pay attention to the fact that I am indeed an utter n00blet at making things work in general.
Also, I'm not *explicitly* passing -fpack-struct to GCC... unless of course some other part of the toolchain might be doing so without telling me? Just to be on the safe side, could I please ask what is the parameter I'd have to give in order to make absolutely certain that it's NOT packing the struct(s)?

Thanks in advance.

You know, your problem description has really had me scratching my head. According to my calculations, your bug is not actually happening.

Could you post the code somewhere? The complete test file, along with any make files, the expected output and buggy output? If you lack a place to post it, email it to me (forum username at nightstar.net) and I'll post it on the zoo somewhere.

Basically a serialization function turns something into a stream of bytes suitable for writing to file or sending across a network. If you use field names instead of offsets you'll get whatever order you want regardless of what the order is, you can leave out things like pointers that don't belong in files, and then it can be in a black box that you don't have to worry about anymore.



I think it might do it if you set the optimizations high enough. As a rule, don't go above -O2. I don't know specifically because always have problems above -O2 and therefore never do it.

So, instead of: (transposed)


You're suggesting I instead do something like:

That about right? Sounds more sensible than what I'm doing right now, anyway. Apologies for the fact that the above code is a pile of horse crap, I'm far too lazy to put in real variable names for it all.


I'm not optimising at all right now... though I'll have to change that fact later in order to cut down the amount of time that rendering a huge animated one takes.


No worries man, it doesn't actually happen according to my calculations either
I'll try bugfixin' a la serialisation (there are one or two other little bugs hiding about the place that might also be a result of these struct related woes) and then if that doesn't work I'll .tar.gz it all and ftp it somewhere. If it does work, then I'll do the same thing, only I'll add smiley faces and a readme.txt to it

Also there's a sizeof operator so you don't have to hardcode the size. It's also helpful to use a type that's the same on every architechture in a case like yours. Instead of "short int", you can use "int16_t". Also, you should make sure the data is in the correct endian format, eg if it has to run on a Mac or something.

These should be regarded as necessary even if you're pretty sure it won't leave that OS or architechture. Without caution to make sure everything is well defined, code produces weird bugs, as you've seen. Projects that no one is ever going to see aren't an opportunity to slack of with good style. They're a chance to practice good style.

http://www.fit.hcmuns.edu.vn/~dxquang/Teaching/Ctdl1/References/c.pdf

It's helpful to read this cover to cover, and have a good grasp of C before you take C++ too seriously. I've seen many a programmer get sucked into C++, and then have a hard time with the underlying principals because there's too much magic in the language and you just have to give up and accept it. In C, there's very little magic and what little there is is exposed through libraries that must be explicitly called rather than language features that "just work". Exclusively C++ programmers also tend to have trouble with other languages because they want to turn everything else into C++, it's the only style they know. If you start with C, then you have a solid foundation but the language isn't powerful enough to do everything by itself so you learn other things as optional extensions rather than a mandatory minimum.

Oh. My. Crapwacket.

What did you just do? You better tell me what you just did, because I KNOW you did not just point someone to K&R and say they should learn and practice that style.



MineFelinePossesseth: my severe allergic reaction notwithstanding, the K&R book is THE reference to have on learning to program and think in C. It's worth reading. Just don't forget to ALSO practice good style.

On the subject of programmers trying to turn everything into C++: No. It's true for most new programmers that they try to use the paradigms they learned in their first language. This is most definitely not unique to new C++ programmers, and is part of the learning process.

However, once you get to a certain point, you learn to think in whatever language you're using, and choose that language based on the problem at hand. Or at least that's my opinion on it.

That's all, mister sweeping generalizations.

My point is that C++ seems more likely to make it hard for programmers to break out of that way of thinking. That doesn't mean C++ programmers are always like that, just that it's a greater risk for them when they're getting started.

Upon further consideration, I think it might also be because it attracts programmers that want to learn one language that they can use for everything. That's a very short list, and the others (Java, C#) have significant disadvantages that keep them from being universal.

I managed to avoid this by the simple expedient of learning two "languages" at once (C64 BASIC and LOGO), followed several years later by a bondage and discipline structured language (Pascal). This made it literally impossible to use the same idioms/paradigms/style. Fortunately I survived both and now I'm fairly comfortable with several real languages.

I'm very much a proponent of the "choose the correct language for the job" philosophy. I have had to do *way* too much debugging of code written in inappropriate languages.