21 Nov, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
So this is random, but does anyone out there write their code in C89?
Lua is implemented in C89 for portability, and I was wondering if there were
any enthusiasts out there that followed this discipline. Am I correct in understanding
that, in order to write truly portable code, you could write it in C89, but not write
things that wouldn't compile in say gcc 4.+? In other words, if Lua can be compiled on
most C compilers, wouldn't it be wise to make sure that your mud is also written this way?
22 Nov, 2009, quixadhal wrote in the 2nd comment:
Votes: 0
I reject antique standards unless there's a really good reason to use them.

In the case of Lua, I suspect they want it to be useable for embedded devices and things which may not have modern compilers available, but for a game project, I'd rather spend time coding the fun game logic, rather than nitpicking casting rules and how paramaterized macros get expanded.

For that matter, I'd say it's just about pointless to limit yourself to the C language, when almost every environment you'll have C in will also give you C++. Unless you happen to enjoy pain, char *'s are just plain evil, and string handling errors are probably the number one cause of data corruption and crashes out there.

Heck, even Debian has dropped support for gcc 3.2 from their distributions, and that's from 2002. If an OS designed to run on anything from a 386sx/16 to a quad-core i7 doesn't need to follow C89, I see no reason for a game driver to do so.

But that's just my 2 cents. :)
22 Nov, 2009, David Haley wrote in the 3rd comment:
Votes: 0
I think that you should write strict standards-complaint code, but you don't need to pick ANSI C as your standard. For example, people should not write code that doesn't respect constness or doesn't cast correctly.

And yes, Lua is written in strict ANSI C because it is meant to be available on platforms that don't have recent compilers, such as embedded devices. Chances are you won't be compiling your game on those platforms. :wink:
22 Nov, 2009, Tonitrus wrote in the 4th comment:
Votes: 0
I think the reason that certain projects use C89 is that C99 still isn't portably implemented, compilers have added various features from it, but haven't wholly implemented it.

I personally can't think of any reason you should write your mud to any sort of "standard" unless you're planning on releasing a codebase to the general public. Even then, you should only bother with C89 if you plan for it to run on toasters, microwaves, traffic lights, and other such nonsense.

With a mud you have a totally different audience than something like Lua, namely, you. You probably won't want to host a mud on anything that will only run a C89 compiler anyway, so who cares?

In other news, I can't wait to see how long it takes C1x to be implemented.
22 Nov, 2009, David Haley wrote in the 5th comment:
Votes: 0
Tonitrus said:
I personally can't think of any reason you should write your mud to any sort of "standard" unless you're planning on releasing a codebase to the general public

Or you want to be able to easily run your own code in a few years, or silly things like that. :rolleyes:

It's like using shorthand in your own notes: it's all well and good when you know what you mean, but a few years later your own notes can be incomprehensible to you until you re-establish your shorthand conventions.

BTW, C99 is in fact rather portably implemented for almost all practical intents and purposes. One should not overstate the impact of it not being absolutely, completely portably implemented.
22 Nov, 2009, Tonitrus wrote in the 6th comment:
Votes: 0
David Haley said:
It's like using shorthand in your own notes: it's all well and good when you know what you mean, but a few years later your own notes can be incomprehensible to you until you re-establish your shorthand conventions.

I can't read notes I wrote yesterday, and I don't even use shorthand. :(
David Haley said:
BTW, C99 is in fact rather portably implemented for almost all practical intents and purposes. One should not overstate the impact of it not being absolutely, completely portably implemented.

I think it bears mentioning that "portability", especially with regards to C, is a situation of sharply diminishing returns.

I couldn't personally care less about any compiler that isn't gcc, which, incidentally, doesn't completely support C99.

I believe most compilers have the basics of it implemented, and it looks like a few of them have it entirely, but as far as I'm aware, there isn't much that won't compile C89 code.

So mainly, for the issue of portability, it's technically true that C89 is more portable than C99.

If I'm not mistaken, it's also technically true that C89 is more portable than C++.

The appropriate response to all these observations/questions, though, unless you're making something where portability is a top priority (which it practically never is) is "Who cares?"

Use whatever language/standard you feel comfortable with and will write good code in. If you don't like what you're writing, you won't enjoy programming in it, and you'll either give up or persist and be miserable.
22 Nov, 2009, David Haley wrote in the 7th comment:
Votes: 0
Tonitrus said:
I can't read notes I wrote yesterday, and I don't even use shorthand.

Yes, well, some of us actually like to be able to use stuff we produce later on. :rolleyes: So for people like that, writing code that one can use later is important.

The reason we try to adhere to standards is not to slavishly appease the God of Standards – there are good reasons why standards exist. That you don't personally care doesn't really mean you can make very general statements about what other people should do. Just IMHO, I suppose.
22 Nov, 2009, Tyche wrote in the 8th comment:
Votes: 0
I also usually write code that will compile on multiple compilers, compiler versions and operating systems in their "default" mode.
That isn't quite the same as C89 compliance. I think my way is probably a more pragmatic approach, but the latter would probably
tend to work on compilers/systems one might not necessarily have access to. Of course many functions required for a mud are not
found in the ANSI C standard library.
0.0/8