Grr...

Dec. 17th, 2006 11:50 pm
wolfwings: (Default)
[personal profile] wolfwings
...I hate C++. Without automated tools, there's no way to guarantee, without a doubt, that the code does what it looks like it does. Even standard assumptions can be over-ridden, and far too often are in example C++ code to make the code make 'more sense' to the original coder. But in the process making it vastly harder to parse and understand to a layman trying to port the code elsewhere.

Currently picking through Matt Timmermans Bijective Arithmetic/Range Coding Compressor and (very slowly) shambling through converting it to straight C instead of a heap of C++ files for some very simple code bits of code.

And yes, this ties in vaguely to my old WikiCode idea. And no, my usual complaints about C++ don't all apply to the linked-to code, but are a complaint with the basic design of the language.

(no subject)

Date: 2006-12-19 07:09 pm (UTC)
From: [identity profile] mira-fastfire.livejournal.com
Wait...why is C++ bad?

Unfortunately, I don't have the option of taking just a C course, but I'm certainly learning to prefer C strings to C++ strings. :) They can do more things!!

It's not that it's bad.

Date: 2006-12-19 09:16 pm (UTC)
From: [identity profile] wolfwings.livejournal.com
It's that it's completely redefinable. I've run across compression-routine examples for C++ that do such stupidity as make the compression context a variable type that you multiply characters by to encode, for example.

C++ is, when used correctly, a wonderful thing. But way, WAY too often (especially in larger projects) code will end up with some of the strangest, most ass-backwards mappings, and at some point or another someone will redefine a basic operation for some exotic data-type.

Basically, in C, you can read a small fragment of the code from a larger project, and know for a fact that you understand exactly what it does. With C++, you need to know for a fact that nothing anywhere else in the project changes the basic operations in the small segment you're working with. Which means you have to rely on automated tools to track down any possible modifications to the operations done in that tiny segment, or have to wrap your head around the majority of the project itself.

This makes starting to work on a larger C++ project, once you realize this danger, rather problematic. C++ is a very good language, but they made it too capable of redefining everything under the sun, I fear.

Re: It's not that it's bad.

Date: 2006-12-31 07:41 am (UTC)
From: [identity profile] jjwolverine.livejournal.com
Yeah, it's the operator overloading that dooms you, mostly. That along with the preprocessor are the tools of the devil :)

Fortunately Java has neither--- so when I have to read other people's shitty code, I pray that it's in Java. :) I presume Java's not an option for you, since it sounds like you're writing performance-sensitive short-running processes?

Re: It's not that it's bad.

Date: 2006-12-31 09:59 am (UTC)
From: [identity profile] wolfwings.livejournal.com
Not actually writing anything-sensitive code. It's for a project I'm working on I've nicknamed Easy2Port, which focusses on breaking fancy computer tidbits down to basic math operations. First thing I tackled was back-converting a very cutting-edge range coder to math steps and small, modular functions easy enough for a beginning programmer to understand.

The resulting code ends up passably fast because it's so simple most modern compilers can heavilly optimize it, but it's made to be plain and straight-forward to read first and foremost.

I'd love your comments on what I've posted so far, also. =^.^= I do need to upload Yet Another Update to the range coder, but that'll wait until I get my laptop back from HP and put my HD back into it, since that's the only Athlon 64 in the building so I can't just boot the drive in another machine. =^.6=

Style Credit