My C89 RANT!

This is a discussion on My C89 RANT! within the C Programming forums, part of the General Programming Boards category; I tend to use features from C89 and nothing else when I write new code. I can write classes and ...

  1. #1
    Registered User
    Join Date
    Dec 2005
    Posts
    15

    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.

  2. #2
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    Uh huh. And the point of this meaningless rant is?
    My best code is written with the delete key.

  3. #3
    Registered User
    Join Date
    Dec 2005
    Posts
    15
    It's a rant. Since when's a rant supposed to have a point? Just ranting.

  4. #4
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    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.

  5. #5
    Registered User
    Join Date
    Dec 2005
    Posts
    15
    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.

  6. #6
    Sr. Software Engineer filker0's Avatar
    Join Date
    Sep 2005
    Location
    West Virginia
    Posts
    235

    Some observations

    Speaking as one who participated in the C89 standard process, I would like to take a stab at addressing a few issues raised:
    • The comittee was dedicated to not breaking existing 'well formed' code. The changes to the language itself (not the library) were intended to be additions, not replacements, to existing semantics. There were some items where different compilers did things in incompatible ways (ie, the structure in union semantics -- bsd and K&R had different rules), and a single interpretation had to be chosen for the standard, so code that relied on a particular version of that language feature might have required changes to compile without warnings. Also, some pre-ANSI features were depricated -- they were not removed, just marked as being "not the right way to do it in ANSI C, so you'd better change it soon".
    • The standard library was part of the standard. There were a lot more changes in the library that required changes to existing code than there were in the language definition itself. I always thought that the library should have been a separate, associated standard. It was my opinion that the library subcomittee was less dedicated to compatibility than the language people, but that's a subjective observation.

    Also:
    • The C preprocessor is very primitive. It was intended to do very simple things, so there are no conditional or looping structures within C macros, and is unable to access the actual structure of the code. I've often wished that C had a more comprehensive macro facility. Templates are similar in some ways to a macro facility, but they have insight into the C++ class/type environment in which they are defined.
    • C macros are best used for simple replacement (manifest constants and simple expression replacement) and conditional compilation, but using a complicated C macro to define a non-trivial function, though possible, is not a very good idea in most cases. (It is also quite difficult to debug, but so are C++ Templates, so I suppose that's a wash.) I can't imagine using C++ templates to define manifest constants or to do conditional compilation.
    • It is my experience that much of the trouble porting between different versions of the same compiler are library and header file issues, not language construct issues. Templates in C++ changed between when I first learned to use them and when I actually had to use them in a production environment. Since then, I believe that the template semantics have remained pretty consistant. On the other hand, if you use a non-standard language extension provided by a compiler, don't be too surprised when it stops working in later versions of that compiler, especially if a later version the language standard adds that feature.
    • Inline functions in C are useful even if the call overhead is minimal. They allow the optimizer to analyze more of the program logic within a scope and can lead to much more efficient generated code. This may not be an issue for recreational or school projects, but it is critical in real-time and high performance computing environments. Though it is true that you can use C macros as inline functions, it becomes much harder to follow the source, debugging is a nightmare, and multi-line macros are fragile.

    I'd write more, but I'm late for work as it is. I hope this is a useful addition to the discussion.
    Insert obnoxious but pithy remark here

  7. #7
    Registered User
    Join Date
    Dec 2005
    Posts
    15
    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.

  8. #8
    aoeuhtns
    Join Date
    Jul 2005
    Posts
    581
    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.

  9. #9
    Registered User
    Join Date
    Dec 2005
    Posts
    15
    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).

  10. #10
    Registered User
    Join Date
    Jun 2005
    Location
    Stockholm, Sweden
    Posts
    64
    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."

  11. #11
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >Having a standard that says you are ABSOLUTELT NOT ANSI
    >compliant unless you are 100% ANSI compliant would be a good start.
    You must be one of those odd people who bring up non-existent issues to get attention. This is precisely what the standard says, and it's called strictly conforming. It's also damn near useless for programs of any real complexity. Now, you might have a job that only requires you to write trivial programs that can be strictly conforming, but I don't, and I don't know anyone else that does.

    Allow me to quote your first post and I'll explain why you're confused:
    I tend to use features from C89 and nothing else when I write new code.
    Most people do. Nobody cares enough about C99 to encourage compiler vendors to comply to it. Therefore, the majority of experienced programmers will use an intersection of C89 and C99 to enforce good style as well as conformance to both standards for when C99 is widely implemented.
    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.
    Your complaint is about C99, not C++, so C++ shouldn't even enter the conversation. Concerning C99, very few compilers even attempt to conform to it, and both of them require a switch to enter C99 mode. I don't see what your problem is when you have to go out of your way to use the "latest fickle hairsplitting" of the standard.
    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!
    Visual C++ implements C89, it has for a long time. If your code is from a few years back and it's broken on a newer version of the compiler, then your complaint is with pre-standard C++ being compiled as standard C++. In that case your argument is pointless, and if you can't see why then I pity you. This alone tells me that you're confused about the differences between C and C++.
    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.
    Once again, you're talking about C++, not C. When you use a compiler to compile as C, it's always C89 unless you're using one of the two compilers that implement C99 features and use the switch to explicitly ask for C99. Every compiler in common use (with the exception of Miracle C) has no problem comforming to C89. Of course, if you'd be willing to name compilers and features that don't conform to C89 instead of vague references to "everybody", we'll take you seriously.
    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.
    Yes, that's the way it is. So, uh, what was your problem again? Are we talking about some hypothetical world where C99 is widely but poorly implemented? Or are you just annoyed that Visual C++ 6.0 sucks and Visual C++ .NET 2003 tries harder to conform to the C++ standard?
    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.
    I've discovered the solution to your problem! If you just write C, or just write C++, instead of some confused and bastardized mixture of both of them, your problems will go away!
    My best code is written with the delete key.

  12. #12
    Registered User
    Join Date
    Dec 2005
    Posts
    15
    Quote 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.

  13. #13
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Quote 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 .....

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. C89 or C99
    By talin in forum C Programming
    Replies: 6
    Last Post: 05-26-2008, 12:45 PM
  2. c89 allows bool data type?
    By manav in forum C Programming
    Replies: 10
    Last Post: 05-21-2008, 12:08 AM
  3. C99 C89
    By salvadoravi in forum C Programming
    Replies: 4
    Last Post: 01-21-2008, 06:43 AM
  4. The space time continueimnms mm... (rant)
    By Jeremy G in forum A Brief History of Cprogramming.com
    Replies: 32
    Last Post: 06-27-2004, 01:21 PM
  5. Rant Rant Rant!!
    By face_master in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 12-19-2002, 02:46 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21