http://www.artima.com/cppsource/cpp0x.html
Look like they are tackling some of the things that make me swear a lot. That can only be a good thing [:)]
quote:Originally posted by pb
http://members.safe-t.net/jwalker/programming/interview.html
pb
Rather cheeky putting that old joke up pb [:)] Don't take it seriously anyone, it's a well known (and very well done) fake.
quote:Originally posted by pb
I've grown to hate C++ over the last 6 months. It seems to mess with people's minds. For a particular task, if they were coding C, they wouldn't use a table of function pointers, but give them C++ and they start using virtual functions (which does the same thing)... Why!?
Hmm... a couple of possibilities I can think of:
1) the C design was made better, more readable/maintainable, more powerful/flexible or more future proof by abstraction, inheretence and virtual functions.
2) they don't really understand virtual functions and just realise that "bad things" can happen if they don't make a function virtual.
:-P
Maybe try Objective C pb, the language of NextStep/MacOSX. It's slower than C++ but doesn't have most of the gotchas. C made object oriented in a smalltalkish kind of way.
COM is the worst culprit for virtual functions of course.
I don't like plain old C much (I've written some sizeable apps in it), and I really detest system level programming languages running inside a virtual machine (like Java and C#), hence I'll be sticking to C++ in combination with a scripting language for a while yet.
Bjarn has had some good ideas in the past: http://public.research.att.com/~bs/whitespace98.pdf ;)
Here is a nice presentaion by Herb Sutter on sexy future features (from the IDE perspective) as well, especially wrt multithreading: http://microsoft.sitestream.com/PDC05/TLN/TLN309_files/Default.htm
Just remember in C++ you only pay for features you use, and some people should just not be allowed near C++ compilers.
(btw lorien C# is JIT compiled)
quote:Originally posted by Dragoon
Hmm... a couple of possibilities I can think of:
1) the C design was made better, more readable/maintainable, more powerful/flexible or more future proof by abstraction, inheretence and virtual functions.
2) they don't really understand virtual functions and just realise that "bad things" can happen if they don't make a function virtual.
:-P
The "C design"? You can do abstraction with function pointers in C. This idea that if you were implementing an OOD project in C you'd have that silly SQUARE,TRIANGLE,CIRCLE switch statement that you constantly see in C++ literature is just crap.
I reckon that when people are forced to explicitly put that function pointer table in they seem to make more sensible decisions about abstraction and inheritence.
Mindlessly making functions virtual can also cause bad thing to happen. But I guess you're right on this point, if you're playing the odds you'd make it virtual (although it will cost you in speed and memory).
pb
Redwyre - You're asking for trouble posting an IE-only link in response to one of lorien's posts [:P]. Also, believe me, java is also largely JIT compiled (mutter-debugging-sun's-thread-firkin-unsafe-JIT-compiler-on-sparc-mutter) :)
will watch young herb's presentation with interest...
edited to make it clear I was responding to redwyre's post, not pb's
quote:Originally posted by pb
...give them C++ and they start using virtual functions... Why!?
Because of the [url="http://www.joelonsoftware.com/articles/LeakyAbstractions.html"]Law of leaky Abstractions[/url], programmers either don't know or don't care that these are, in effect, the same thing.
So, it comes down to whether you'd prefer to employ (or work with) a programmer that doesn't know, or one that doesn't care. Personally, I choose the 'don't care' every time. After all, you know what they say about premature optimisation.
quote:Originally posted by pb
The "C design"? You can do abstraction with function pointers in C. This idea that if you were implementing an OOD project in C you'd have that silly SQUARE,TRIANGLE,CIRCLE switch statement that you constantly see in C++ literature is just crap.
I reckon that when people are forced to explicitly put that function pointer table in they seem to make more sensible decisions about abstraction and inheritence.
Mindlessly making functions virtual can also cause bad thing to happen. But I guess you're right on this point, if you're playing the odds you'd make it virtual (although it will cost you in speed and memory).
pb
Yes you can do object oriented programming in C, the cleanest example I've seen of it is the GTK windowing toolkit for Linux. You wouldn't have the switch statement for it under GTK in C, but something like:
[code]
if( GTK_FRAME_CAST( obj ) )
{
// stuff
}
else if( GTK_CANVAS_CAST( obj ) )
{
// other stuff
}
or
GtkWindow* window = GTK_WINDOW_CAST( obj );
if( window )
{
// stuff with window
// eg:
gtk_window_show( window, 1 );
}
[/code]
which is not too different from C++, but requires a lot more effort to implement in C.
(the specific macro names probably aren't accurate - but they basically cast obj to the type pointer or return NULL if it isn't possible through the ?: operator)
I guess what I am trying to say is that C++ does "virtual functions" much cleaner and less error prone because they are part of the language and automatic with the keyword. If you take using function tables in C as a replacement odds are that because of compiler optimisations in C++ it would be slower than a virtual function in C++.
Still back to the original question, sure you could move code from C to C++ without using virtuals, but as in case 1, using them could improve the code quality considerably through a better design without the pain of trying to implement object oriented inheritance in C. This largely depends upon what you're moving to C++ though, certainly not all code would warrant virtual functions or be improved by them.
I guess I ask myself, if I was programming in C I would program it the C way which is unlikely to include object oriented inheritance in C as its a real pain and "works against the grain" of the language. If I was to program it in C++ my thinking and design would default to the C++ way, including thoughts on future proofing against others using it for inheritence re picking functions to be virtual.
quote:Originally posted by Dragoon
I guess what I am trying to say is that C++ does "virtual functions" much cleaner and less error prone because they are part of the language and automatic with the keyword. If you take using function tables in C as a replacement odds are that because of compiler optimisations in C++ it would be slower than a virtual function in C++.
Really? You have some example code that shows superior compiler output using a virtual over a function pointer table? Or is this just more C++ dogma? I've even heard C++ evangalists claim that const makes your code go faster (!?)..
On the premature optimization point - this often gets cited as an excuse to not do any optimization at all, or to leave it all to the end, but really its talking about it in context - obviously you optimize your design quite early, otherwise you go down a dead end and will never be able to optimize without a massive re-write.
As for doing this or that being a pain in C - thats because C is a very literal language - it doesn't do much for you. If its a pain to code its probably slow to execute.
pb
quote:Originally posted by pb
On the premature optimization point - this often gets cited as an excuse to not do any optimization at all, or to leave it all to the end, but really its talking about it in context - obviously you optimize your design quite early, otherwise you go down a dead end and will never be able to optimize without a massive re-write.
Agreed 100%, making sure the obvious parts are designed with speed/memory tradeoffs in mind are key. However, when I see [url="http://www.gamasutra.com/features/20051220/thomason_01.shtml"]articles about next-gen optimisation[/url] which recommend:
quote:
We can eliminate branches entirely by changing code of this kind:
if( x == 0 ) y = z;
to
y = x == 0 ? z : y;
and
if( ptr != 0 ) ptr->next = prev;
to
*( ptr != 0 ? &ptr->next : &dummy ) = prev;
it just blows my mind. Most people will miss or ignore his comment about this being applicable to "critical methods" and will start thinking that the perf tuned code is "better" than the maintanable code above.
I'd shoot any programmer that tried this on with me unless appropriate code comments made it maintainable, and proof of them using a frickin' profiler was forthcoming. There's a lot of layers in most pieces of software, and tuning one in isolation "just on principle" normally doesn't help much.
Mcdreski is right- if you want me to read a link it's got to work in Konqueror or Firefox.
IMHO "Just In Time Compiler" should be changed to "Just Too Late Compiler" [:)] And IMHO Sun's hotspot optimisers guarantee sluggish progs because the bulk of the prog remains fairly unoptimised.
I agree with mcdrewski about optimising for next gen- that's one of the reasons I've been looking into templates. But you DON'T want that code all over the place... The way I look at it is if there is low level code that gets used everywhere or is known to be time critical it's probably worth optimising- but watch out for bottlenecks with a profiling.
quote:Originally posted by pb
Really? You have some example code that shows superior compiler output using a virtual over a function pointer table? Or is this just more C++ dogma? I've even heard C++ evangalists claim that const makes your code go faster (!?)..
No I've never looked at the compiler output, but C++ will optimise every call to a virtual for which it can deduce the type at compile time by not requiring a look up in the function table. You have to remember to do this manually in C, and people in such respects get lazy or forget. I'm not an evangalist for any language. I take each on its merits, and not only the language merits, but library support, maturity, community, etc. Is it that you are a C evangalist or hate C++ or both? (maybe your not, but you seem to not like C++) I can't think of why else anyone would prefer C to C++ for object oriented programming.
Const does not increases your "code speed" significantly that I am aware, but does improve your "coding speed" ;-) It traps a lot of improper function usage and errors before they happen saving you debugging time.
quote:
As for doing this or that being a pain in C - thats because C is a very literal language - it doesn't do much for you. If its a pain to code its probably slow to execute.
Wrong on the speed point... I can see what you are getting at but you've overly generalised. Optimisation for example (of code not design) almost always complicates the code (and is a real pain to do for some algorithms), results in many more lines of code, but produces faster code.
Object oriented coding and inheretance in C is a pain, which I don't like because it takes significantly longer to code (many more lines) is far more prone to error than having it done for you with the use of a keyword, is much harder to maintain, and is much harder for another programmer to learn your code. These are all bad things when coding.
quote:Originally posted by lorien
Mcdreski is right- if you want me to read a link it's got to work in Konqueror or Firefox.
Not even Lynx ;-(
quote:
IMHO "Just In Time Compiler" should be changed to "Just Too Late Compiler" [:)] And IMHO Sun's hotspot optimisers guarantee sluggish progs because the bulk of the prog remains fairly unoptimised.
Additionally a seperate virtual machine with it own memory confines can be good for some applications, but for the general case is just a little strange. The JIT compilers can get algorithmic speed (in a mathematical sense) close to C, but in Java you have to work hard to write fast code, else the garbage collector creates and destroys far too many objects, and who wants to use Object pooling just to get code to run quickly. Yucky!
quote:
I agree with mcdrewski about optimising for next gen- that's one of the reasons I've been looking into templates. But you DON'T want that code all over the place... The way I look at it is if there is low level code that gets used everywhere or is known to be time critical it's probably worth optimising- but watch out for bottlenecks with a profiling.
Yep in general the first versions are much better. There aren't too many places in a game engine where the second optimisation would make a noticable difference.
quote:Originally posted by mcdrewski
Agreed 100%, making sure the obvious parts are designed with speed/memory tradeoffs in mind are key. However, when I see [url="http://www.gamasutra.com/features/20051220/thomason_01.shtml"]articles about next-gen optimisation[/url] which recommend:
it just blows my mind. Most people will miss or ignore his comment about this being applicable to "critical methods" and will start thinking that the perf tuned code is "better" than the maintanable code above.
I'd shoot any programmer that tried this on with me unless appropriate code comments made it maintainable, and proof of them using a frickin' profiler was forthcoming. There's a lot of layers in most pieces of software, and tuning one in isolation "just on principle" normally doesn't help much.
Plus those sorts of optimizations are stupid no matter where and when you use them. If you're trying to control individual instructions its time to break out the assembler. Reverse engineering the compiler to understand how it generates its instructions is a good idea for determining when/where the compiler might fail you, but that knowledge shouldn't be used to finesse the compiler into producing particular instructions.
There's a notorious example from years ago where the sign of a float is determined by casting the address of the float to the address of an int, deferencing and checking the top bit - on modern achitectures this actually runs slower because the value needs to be moved to an int register.
pb
Anybody can create crap in any language, it's all really a matter of knowing your tools, knowing your task, and then being intelligent about the design. It all comes down to design, or engineering as it is sometimes called. To prove that anyone can create crap in any language just take a look at the Daily-WTF (http://www.thedailywtf.com/). Anyways, being a programmer or an engineer is about designing solutions to problem, and if you can't to that well then you shouldn't be one.
quote:Originally posted by Dragoon
No I've never looked at the compiler output, but C++ will optimise every call to a virtual for which it can deduce the type at compile time by not requiring a look up in the function table. You have to remember to do this manually in C, and people in such respects get lazy or forget. I'm not an evangalist for any language. I take each on its merits, and not only the language merits, but library support, maturity, community, etc. Is it that you are a C evangalist or hate C++ or both? (maybe your not, but you seem to not like C++) I can't think of why else anyone would prefer C to C++ for object oriented programming.
As I mentioned before, I've grown to dislike C++ over the past few months. Up until that point I saw it as a superset of C (although C is going in its own direction now, it has restricted pointers for example) and even though I'm of the view that some of the new features are silly or poorly implemented I went with Mcdrewski's view that you only pay for the features you use.
What changed my mind was observation of the human factor. Mark Twain put it like this: "To a man with a hammer, everything looks like a nail."
One of the first things people learn about operator overloading is that there's a time and a place to do it and you shouldn't go nuts putting it into everything. The reason this is such an important lesson is because without it (and even with it) people tend to overuse it. Templates are the same, massively overused for no apparent purpose (unless thrashing the instruction case is the objective).
You mention people getting lazy and forgetting. But this fact produces far more unnessary virtual calls in C++ than suboptimal virtual calls in C. Not that the langauge should even be dicating a design decision.
Then there's the C++ community. In one well known critique of C++ (I don't have it here, I'll cite it later) the author points out that in a C++ book or paper the number of references to other C++ literature vastly outnumbers those that refer to work outside of the C++ community, indicating that its very closed off.
I tend to agree with this conclusion because I see the same old unsubstantiated claims going around the community. The numerous claims about how sticking virtual everywhere future proofs your code for example. The claim that the design of your software should be influenced by the language itself (just in this thread we've had terms that indicatate this form of thinking: "C design", the "C++ way", "works against the grain of the language").
quote:Const does not increases your "code speed" significantly that I am aware, but does improve your "coding speed" ;-) It traps a lot of improper function usage and errors before they happen saving you debugging time.
Type safety, const included, is an investment. You put in the extra effort to write type safe code and you'll be rewarded by the compiler finding bugs for you. So its a balance. You need to ask yourself - have I done more work for const, or has const done more work for me?
Personally I think the idea of read-only/const for type safety is sound. The C++ implementation is just bad. Is it bitwise const, or is it conceptual const. Now thanks to mutable it can either, both or even neither. The propogation of constness into references, args etc is quite clumsy too.
quote:Wrong on the speed point... I can see what you are getting at but you've overly generalised. Optimisation for example (of code not design) almost always complicates the code (and is a real pain to do for some algorithms), results in many more lines of code, but produces faster code.
No, I deliberatly avoided over generalising by qualifying my statement with the word "probably".
quote:Object oriented coding and inheretance in C is a pain, which I don't like because it takes significantly longer to code (many more lines) is far more prone to error than having it done for you with the use of a keyword, is much harder to maintain, and is much harder for another programmer to learn your code. These are all bad things when coding.
More claims without any evidence. "not future proof", "more prone to error", "much harder for another programmer to learn", "much harder to maintain". Pick up any C++ book and you'll see it all there, repeated over and over, complete with claims about how good the compiler output is, (always written by people who don't study the output).
Object oriented programming and inheritence is a pain in C++ too. Just because they make it a feature of the language doesn't mean its works well. I've had to deal with lots of bugs that were caused by a tangled mess of inherited classes and it takes ages for another programmer to peel back all the layers, follow a function call from the most derived class up the inheritence chain etc. Now I know - you can write crap code in any language - thats true. But my view is that C++ gives you some awesome tools to make a convoluted web of inheritence, people tend to use the tools they're given just because they can, it gets combined with a community that seems to operate on faith and in the end you get a bloated, slow, unmaintainable, unoptimisable mess.
And what about some of the really poor aspects of the C++ standard. The fact that a constructor is permitted to produce side effects, that temporaries must be constructed with said constructor, but that the compiler implementation determines when to create temporaries, basically means that the compiler implementation is allowed to output code that generates side effects without any specific guidance from the standard. If the standard can't even pin down when and how side effects are generated I'd say you're dealing with a very ill-defined langauge. Hardly surprising, the standard is only about 200 pages longer than C99.
pb
quote:Originally posted by pb
...I see the same old unsubstantiated claims going around the community. The numerous claims about how sticking virtual everywhere future proofs your code for example. The claim that the design of your software should be influenced by the language itself.
I find this a very interesting point. In my commercial experience I had a lot of freedom to select languages and technologies which fitted in the right spot in the solution. Thus the design influenced the language first. However once that decision is made, I see no reason why the lower-level design should not be influenced in turn by the language. After all, in an ideal world that language was chosen for a reason.
quote:
Type safety, const included, is an investment. You put in the extra effort to write type safe code and you'll be rewarded by the compiler finding bugs for you. So its a balance. You need to ask yourself - have I done more work for const, or has const done more work for me?
I think I understand your position here pb, I sense the soul of an old-school hacker who wants to make the system under his power dance and sing using the best way possible. In your case const probably does just make you waste valuable coding time, in the same way that passing lots of void*'s around to save messy and confusing casting can save coding time.
The problem there comes when working with other programmers. If the const declaration saves someone ELSE time when maintaining, debugging or on the day after you're hit by a bus then the investment pays off. If nobody ever looks at your code again, it'll never pay off.
Fundamentally I agree with you, since after all the aim of a SW company is [url="http://www.joelonsoftware.com/articles/fog0000000074.html"]"to convert money to code through programmers"[/url], there's no need to waste that money. However, people [url="http://www.sei.cmu.edu/cmmi/"]teach these practices for a reason[/url]. Mostly because people change companies, and one day someone else not as good as you is going to have to work on that code. Help 'em out. :P
quote:Originally posted by mcdrewski
[url="http://www.joelonsoftware.com/articles/fog0000000074.html"]"to convert money to code through programmers"[/url], there's no need to waste that money.
And here I was thinking that programmers converted caffeine into code... [;)]
Pb perhaps you should join the boost mailing list- I haven't been on it for years, but there are plenty of people who have a lot of say about the standard subscibed to it. With a new standard due in 2009 it now could be a good time to make a stink.
quote:Originally posted by mcdrewski
I think I understand your position here pb, I sense the soul of an old-school hacker who wants to make the system under his power dance and sing using the best way possible. In your case const probably does just make you waste valuable coding time, in the same way that passing lots of void*'s around to save messy and confusing casting can save coding time.
The problem there comes when working with other programmers. If the const declaration saves someone ELSE time when maintaining, debugging or on the day after you're hit by a bus then the investment pays off. If nobody ever looks at your code again, it'll never pay off.
You've summed it up perfectly. The old-skool hacker way is fine and dandy if you're the only person working on it, you'll never touch it again and you're only targetting one platform. For the rest of us who work in TEAMS, we trade raw performance for readability and maintainability and cross-platformability. (Yes, they're all perfectly cromulent words!) A little bit of extra effort on your part is pretty much guaranteed to more than pay for itself down the line when you quit, die or someone else has to look at the code.
Of course, if your C++ programmers are doing brain dead things with inheritance, overloading, templates, etc. then you need to either not hire people like that, help teach them how to do things properly or fire them.
Profiling will point you in the direction of the places that need your hardcore low-level optimisations, but more often than not you won't need to drop to assembly, just change something around - it could be something as simple as making sure data is aligned. I used to think that every cycle was valuable and that code should be as tight as possible, but all that matters is that you don't drop any frames. =]
quote:Originally posted by Shplorb
You've summed it up perfectly. The old-skool hacker way is fine and dandy if you're the only person working on it, you'll never touch it again and you're only targetting one platform. For the rest of us who work in TEAMS, we trade raw performance for readability and maintainability and cross-platformability. (Yes, they're all perfectly cromulent words!) A little bit of extra effort on your part is pretty much guaranteed to more than pay for itself down the line when you quit, die or someone else has to look at the code.
Of course, if your C++ programmers are doing brain dead things with inheritance, overloading, templates, etc. then you need to either not hire people like that, help teach them how to do things properly or fire them.
Profiling will point you in the direction of the places that need your hardcore low-level optimisations, but more often than not you won't need to drop to assembly, just change something around - it could be something as simple as making sure data is aligned. I used to think that every cycle was valuable and that code should be as tight as possible, but all that matters is that you don't drop any frames. =]
Gawd, don't you people ever come up with an arguement you didn't read out of a religious/C++ book?
But hey, don't believe me - you can see for yourself that every part of your arguement is nonsense by taking a look at FMOD, which is not only worked on by a team but used by lots of other developers, massively multi-platform, squeezed down to every cycle and written in C and assembler. Oh its also highly readable and easy to understand, far more so than your typical C++ project.
By all means blame the programmer, but don't you find it odd that in just about every game studio that uses C++ its always basically the same? When Sony surveyed and profiled PS2 games to see how their hardware was being used and developed for they found most titles were coded in C++ and spent the bulk of their cycles thrashing the instruction cache.. Gee, I wonder why.
Yes, you can write good code in C++, but I think its ironic that the language of "abstraction" and "data hiding" is the one that requires you to understand every detail of how the compiler works if you want it to generate half reasonable code, and its usually only the low level guys who are interested in looking at compiler disassembly and they don't use C++ in the first place.
Of course since this is a matter of faith I'm sure that pointing to FMOD as evidence of the falacy of this C++ malarcy won't actually change anyone's mind. I can hear it now... If they had done it in C++, it would be even better, more readable, more maintable, it would magically acquire the property of being better in a team environment...
As for not dropping frames, thats easy, just don't render very much or have much gameplay. Then you can make your code as sloppy as you like... and still achieve the most important thing..
pb
quote:Originally posted by pb
Gawd, don't you people ever come up with an arguement you didn't read out of a religious/C++ book?
Heh, the only "religious" C++ book I've read was "Teach Yourself C++" or something back in 1994 when I was 13. C++ has changed a lot since then and compilers all mostly work like they should.
quote:But hey, don't believe me - you can see for yourself that every part of your arguement is nonsense by taking a look at FMOD, which is not only worked on by a team but used by lots of other developers, massively multi-platform, squeezed down to every cycle and written in C and assembler. Oh its also highly readable and easy to understand, far more so than your typical C++ project.
...
Of course since this is a matter of faith I'm sure that pointing to FMOD as evidence of the falacy of this C++ malarcy won't actually change anyone's mind. I can hear it now... If they had done it in C++, it would be even better, more readable, more maintable, it would magically acquire the property of being better in a team environment...
Having spent last year working intimately with FMOD (to the point of modifying it... your CTO was alarmed when I told him about it) I have to say that you sir, are smoking crack if you think it is clean and easy to follow code! (No offense to Firelight!) FMOD3 is also like 10 years old and I believe that the current version was completely re-written in C++ as well. Only the core mixing routines are done in asm... the parts that take the most time!
The use of C++ doesn't imply that something will be more readable, etc. just for using it, Just like using C doesn't imply that something will be fast just for using it. Generally though, I say that C++ code on average tends to be more readable in that you can come to grips with a new codebase faster, and that its features allows for complex things to be expressed in a more concise manner. In a team environment I think that is more important than raw speed.
quote:As for not dropping frames, thats easy, just don't render very much or have much gameplay. Then you can make your code as sloppy as you like... and still achieve the most important thing..
They're both valid options, but I think I'd rather profile to identify hotspots and try to fix them instead of bitching about us damn kids and our newfangled C++. =]
quote:Having spent last year working intimately with FMOD (to the point of modifying it... your CTO was alarmed when I told him about it) I have to say that you sir, are smoking crack if you think it is clean and easy to follow code! (No offense to Firelight!) FMOD3 is also like 10 years old and I believe that the current version was completely re-written in C++ as well. Only the core mixing routines are done in asm... the parts that take the most time!
Smoking crack? I'm not the one claiming C++ is readable. If you think FMOD3 is so bad maybe you'd like to point me towards some more readable middlware in C++... Unreal perhaps.. or what about Havok??
quote:The use of C++ doesn't imply that something will be more readable, etc. just for using it, Just like using C doesn't imply that something will be fast just for using it. Generally though, I say that C++ code on average tends to be more readable in that you can come to grips with a new codebase faster, and that its features allows for complex things to be expressed in a more concise manner. In a team environment I think that is more important than raw speed.
Its interesting that we both seem agree on what's important - readability and good in a team environment.
In my view C++ is fine when you're coding by yourself, but as soon as you put it in a team environment, where you have to read and work with other people's code, its a ruinous disaster area. What the hell does the expression "a+b" mean? What will the compiler do? It could call constructors (with side effects), it could be calling "operator+", it could be doing implicit type conversions, it might be copying memory around, you have *no* idea without spending all day looking through code.
In C, I don't need to, all I need to know is whether + is int or float and if a or b get promoted. No matter how messy and poorly designed the C code is, thats always true. In C++ I can't assume anything. I suspect if you took away the Visual Assist and other similar features most C++ coders would be utterly lost.
quote:They're both valid options, but I think I'd rather profile to identify hotspots and try to fix them instead of bitching about us damn kids and our newfangled C++. =]
I spend a lot of time doing exactly that. In fact its been precisely this process that has turned be right off C++.
quote:The fmod3 C source code is a mess really. not very nice at all.
FMOD Ex on the other hand i am quite proud of. It is extremely neat and well thought out, written in C++ but doesnt do anything fancy. Just inheritance - no stl or templates or any of that stuff.
Well, if thats as bad and messy as plain C gets then I think it proves my point, its much easier to find your way around than even a slightly messy C++ library.
pb
I guess it could be worse. You could be working on enterprise software written in ( dare I say it ) Java. At work I have to deal with several different code streams that we maintain and it is a major headache porting a fix across all affected versions. Syntax is a nightmare and all the Java IO streams are all over the place, there's no joy or satisfaction in working with that technology.
http://members.safe-t.net/jwalker/programming/interview.html
pb