Thread: My C89 RANT!

I tend to use features from C89 and nothing else when I write new code. I can write classes and templates (including container templates) with structures and macros and a simple naming convention.

Over the years, I have used C++, and looked at C99 now and again, and I have reached one inescapable conclusion: NEW C variants suck. Used correctly, with well chosen libraries, C89 actually is portable, just like C is advertised to be. The newest C++/C99 stuff tends to always be changing, even in minor variations of the same compiler, let alone across platforms.

Many of the features of C++ and additions to C99, such as 'inline' functions are very handy things. I just don't bother to try to use these 'bleeding edge' features anymore. Function call overhead isn't all that big, and macros can be written to safely handle most things I would otherwise use an 'inline' for.

The problem is, all of these language lawyering pedants out there who try to keep up with the latest fickle hairsplitting of C99 or C++ implementation rules and interpretations compete with each other to make the most 'compliant' version of the language compiler/tools according to the interpretation of changing standards.

I have a lot of Visual C++ code from only a few years back that (without a major overhaul) could not possibly be used on a modern version of the same compiler. I dig up fairly straight forward old code, and it doesn't compile anymore. Somebody made a compiler 'better' by breaking my code!

The nice thing about C89 is, everybody quit bickering over the way it should work years ago, and it isn't changing out from under me. It's easy to understand, clear and simple. I write code, and it compiles under any compiler it's likely to be tried on and even most of the half-baked, buggy 'embedded' compilers without having to 'fix' it.

Of course, visual studio is a problem unto its self. It wants to 'upgrade' older projects from earlier versions such that if you share them, nobody can build it without upgrading to the 'latest' version of Microsoft's bug mill, and subtle incompatibilities seep into the code making older versions of the compiler totally unable to build it, even if you compiled with a batch, makefile or jam. Most recently, I had some std::allocator type stl code that built under gcc and Visual studio.net, yet it broke between one version of .NET and another. Of course, GNU isn't free of such defects. The recent GNU C++ 'offsetof' ban (((class*)(NULL))->member) that generated dire warnings that couldn't be turned off really got under my skin. I never use virtualized class members (functions, yes, but not scalars and compounds), but it insisted I mustn't do this "just in case".

Of course, C++ templates would be nice if I could do everything with them that I could do with the preprocessor. I can't. Wouldn't token pasting and string-izing in a C++ template be nice? Then I get some dimwit who insists that I should use the C++ templates for "everything" instead of the preprocessor. Guess what? You can't do 10% of "everything" that can be done with the C preprocessor using C++ templates, and the C preprocessor code is actually easier to write, read and debug (though you might have to invoke the preprocessor and gnu indent on a few things). It is just unlovely to behold.

It's a rant. Since when's a rant supposed to have a point? Just ranting.

why post this c++ rant in the C board?

If the standards committee stopped improving the standards, we would still be programming in K&R style, and without function prototypes. I'm happey that they imporve the language occasionally, makes my life easier.

Why not rant in the C++ forum?

First, because it's also a rant against C99. After all, it's still a moving target, as well.

Second, it would be conspicuous trollish 'flame bait' in the C++ forum.

C89 is an ANSI standard, and already includes 'const' and function prototypes. Maybe when C99 is at least 10 years old, I might begin using those features, too.

Mind you, K&R C had some quite handy tricks in it, like making a structure into discreet arguments that ANSI C seriously doesn't like. A lot of the initial run of 'ANSI' C compilers initially had some serious problems properly handling and interpreting the 'const' keyword, and certain kinds of prototyping. Nobody's perfect. It's just almost all of those awkward problems are far in the past, now.

It's not the standards committee's fault that everybody throws out a compiler that's "90% compatible" with the standard for years after the standard is made 'standard' ... Oh wait, maybe it is. By making hopelessly complex features 'standard' , such that large teams dedicated solely to the task of meeting those specification spend years and years working on it... and never seem to get it quite right, perhaps there is a problem.

So, maybe when C99 is '100%' implemented on several major compilers... around 2009? In the meantime, Microsoft will probably never support C99, since they seem so keen on inventing their own idiosyncratic versions of languages, like C# rather than keeping up with C... which is almost a good thing. At least one piece of their development environment that they haven't screwed up every couple of years. Knock on wood.

As for C++? Really, after all these years, I think it's just a hopeless dream to imagine I'd ever be able to compile the same C++ code on two different compilers without issues, let alone have code remain working after only a few years.

Unfortunately, while C at least has designations like 'K&R', 'ANSI C' and C89/C99/etc., evolving C++ standards largely remain under a 'C++' catch-all designation, and the 'emergent' properties of templates, exceptions and virtualized classes, is usually where the implementations fall apart, meaning the most touted features of C++ are also the the most hazardous to use... if you're going to port that code to more than one platform, or maintain it for more than a year or two.

Whatever the C preprocessor 'was meant to do' from the beginning, it can do much more. It could equally be asserted that since the C standard library was build around 8 bit text and streaming I/O, that C was not meant for GUI applications, and that those 'non-standard' extensions, like support for wide characters should never be integrated into a standard, either.

Whatever the original 'intention' for the C preprocessor, it can be used in many ways to automate elements of code development and make maintenance of C/C++ code far easier. When you tell me what it isn't 'intended' to do, you sound like a previous guy who told me not to use 'break' and 'continue' in loops, or other people who forbid the use of 'goto' without exception.

Yes, an inline function is far easier to write and maintain in most cases than a macro, but for all practical purposes, like every new C99 feature, that keyword is an 'extension' to an older standard for any compiler that is not 100% C99 compliant. Here it is 2005, going on 2006, and even the widely supported open source GNU compiler collection is not 100% C99 compliant.
http://gcc.gnu.org/c99status.html

That makes everything in C99 an 'experimental' feature. Even if GCC magically becomes compliant this very minute, older versions of the compilers will still be in circulation for years.

If I'm going to have to build the code on gcc and Microsoft's compiler at the same time, I'm infinitely better off using C89. If I'm going to use some embedded or game console system's development kit, I can't even expect C89 adherence (i.e. things like a global "int x = 3;" often yield up either a constant or uninitialized or zeroed BSS data), or even for the compiler to be free of obvious bugs.

As pointed out, even when you stick to 'core language features' of C++, you end up with different versions of runtime libraries and stl. STL keeps evolving no matter what, and what did you use C++ for if you didn't intend to use libraries designed to make developing your code easier? All STL commonly does is subtly sabotage your code in a couple of years' time when some 'minor tweak' occurs, and now either the app doesn't build, or it's got some sinister new bug in it. Even when you make the STL distro part of your project's source tree, it doesn't help because language makers (Microsoft prominently so) hide their own compilers' faults in their tweaked stl implementation, so it won't build with a later version of the compiler.

Is there a problem? C89 has not disappeared. What is wrong?

It is better to have a disparity of language extensions and compilerisms that converge on a target than to have a disparity of language extensions and compilerisms that fan out in a spaghetti stack. That is 99.999% of the reason standards are made.

It is better to have standards that everyone can quickly conform and adhere to, rather than standards that cause everyone to be '99%' compliant, because that '1%' tends to grow into a large collection of 'forbidden' features once you consider multiple implementations of that language, and the fact that each of their '1%' is not the same.

Having a standard that says you are ABSOLUTELT NOT ANSI compliant unless you are 100% ANSI compliant would be a good start. After all, every compiler maker likes to advertise '95%' (or whatever) ANSI compliance, sometimes for years, rather than sit down and become 100% compliant (or as near to that as is possible).

So it's the standards fault that people don't aspire to become 100% standards compliant?

I like that concept. We should extend it to include legal matters as well.
"Oh I'm sorry that I was speeding officer, you see, my speedometer is only 95% speed-limit compliant so I guess it must be those 5% that's acting up now."

Originally Posted by kungtotte

So it's the standards fault that people don't aspire to become 100% standards compliant?

I like that concept. We should extend it to include legal matters as well.
"Oh I'm sorry that I was speeding officer, you see, my speedometer is only 95% speed-limit compliant so I guess it must be those 5% that's acting up now."

Actually, it is. You don't get sentenced for '95%' murder. All or nothing. It's a C99 compiler, or it isn't. If it isn't, label it as such, not 'virtually compliant', or some such nonsense.

Originally Posted by evildave

Actually, it is. You don't get sentenced for '95%' murder.

Attempted homicide can get you thrown in jail. And the severity of the damange done can affect your punishment.

Now I've never seen the standard say that a particular compiler is compliant. I have seen compilers saying they are compliant. Buts like a politician saying they are honest.



But seeing as you said this is just a rant .....