I started in Applesoft basic, briefly, then used ASM on a 65c02, and then in Pascal, then very thankfully to C and some x86 ASM, and then on.
I started with a c64, so not much difference then.
Take five years away from C and see if you remember the little things - not about null terminators, but which routines add them and which don't, etc. Does strcpy copy the null-terminator? Does strncpy if the string is longer than n characters? This isn't "programming", this is API trivia.
In actual fact, I haven't used the standard C string functions (unsafe, C programmers almost never use
the unsafe functions, like gets) in many years, but I can almost certainly guarantee(sp?) that strncpy
will add in the terminator *unless* the length of the source string is greater than or equal to the
length of the destination array.
Anyways, your comment is a further example... I posted a pesudo-codish for-loop illustrating the initialization, check, and self increment. There are easier ways for strings, as you list:
but they don't generalize to arrays that aren't null-terminated or where you wish to walk
backwards, etc.
I replied with something that generalises to arrays and can be used in reverse (from end of array). I
have to concede that I have nothing that will generalise to pointers to malloc'ed arrays.
And then with all the different ways to allocate space, assign strings, set nulls, you still don't think it's full of gotchas? Maybe gotchas that you learn when working in it, but if you just picked up K&R and started coding you'd turn out bad code. Of course not; this is C we are talking about - it was created to write a portable OS. Even now, it is very
rarely used to implement business logic, hence it comes with disadvantages for high-level constructs, but it
does come with a rather intuitive mapping to the computer (hence, nice for teaching computer architecture).
My point was that you are criticising something when it is blindly obvious that it has been some time since you
have used it intimately.
Worse, semi-stable bad code that works but only until you change compiler,
platforms, etc.
If you read the standard, this never happens; the only times I have seen this is in the hands
of developers who think that an int, in C, is 32 bits (because it is on their platform) or who
think that the code "void main ()" is legal C.
IOW, the only people who suffer are those that look at what their compiler generates and then
infers what is and isn't in C. Drop by comp.lang.c sometime and you'll see these people getting
constantly corrected when they say "it depends on your platform".
I think I proved my point inadvertently as well. C is too complex to use safely as a psuedo-code language.:)
Nope - all you proved is that you need to learn C before you can 'dis it:-). Seriously, no one would
take me seriously if I wrote glaring errors in $LANGUAGE_I_DID_NOT_LEARN code and then insisted that
it is the fault of the language and not the fault of the programmer who never learned the language.
char x[5] = "foo"
char x[5] = "longer string"
The first is bad form because the second would still compile. It'd probably be zero-terminated, but stomping on your other variables.
Actually, this is in the damn C standard! You are picking on things that are part of the language
specification that *every* programmer in that language should know!!! How can you call yourself a
C programmer if you've never read the standard?
Nope, just tested that. It's limited to the declared length, but it's not zero-terminated.
Or, you know, you could have read the C standard instead; then this would be one of
many so-called "gotcha's" that you would never even notice.
Anyways, that's C - tons of little gotchas, most of which are somewhat platform dependent. You remain stubborn in your opinion that, even if you never read the language standard (or spec),
then it is the fault of the language that you do not know things that are common knowledge to
all C programmers. I think perhaps you should re-examine your arguments about C, but first
at least read the standard.
Yeah, I forgot to calloc the string, or specifically null the last byte.
I get the idea that you still do not know what you are talking about.
But that's my point. C has too many gotchas like that where the standard library is nearly unusable - scanf is bad, gets is bad, printf with user-controllable strings isn't safe, etc.
Of course; you have to learn it first. Your code snippet that I quoted provided a very good reason
for teaching programming via something that maps so well onto the hardware (such as C); if you had
been taught C before getting to develop on $LANGUAGE-OF-CHOICE, you would appreciate $LANGUAGE-OF-CHOICE
much more.
Same with C++. Use strings to avoid these problems, but which string library. Which smart pointers? Which resizable array, or associate array library?
As a professional programmer, you would have read the standards documents on the language you
are using. If you haven't, do not go blaming the language for "gotcha's" when they are
so clearly spelled out in the standards documents.
However I get the impression (correct me if I am wrong) that you do not actually read the
standards (or specifications) documents for the language you want to use, hence you will
get tripped up all the time by stuff that should not be an issue.
(btw: I program in C all the time (daily), and I malloc/free all the time as well, and
the last time I had a bug that was a memory leak in production was in the 90's. I do not
worry about it at all - proper factoring of the code, proper testing (valgrind is part
of the test harness, including diff scripts) catches all the memory bugs.
Thankfully it's been too many years for me to be more specific.
If you're still awake at this point, let me attempt to point out the problems
with the code you posted; I'm ignoring the missing ';' as that is almost certainly
a typo - what I am not ignoring is your severe misconceptions.
Here is your code snippet:
1. You were incorrect upthread when you assumed that no NULL byte
was added; it most certainly is.
2. If you are traversing an array, you use the sizeof operator
to calculate the array length at compile time like this:
for (i=0; i < sizeof array / sizeof array[0]; i++)
3. You are calling strlen before every loop - this usually results in
unacceptably long execution times for the loop. For a pointer to a string
use a while loop like this:
while (*ptr++) {... }
For a char array, use the sizeof operator.
4. You are running through the loop body with a mutable string but
relying on the end of the string to break the loop. This is a source
of very difficult to track bugs once the maintainer starts work. Instead,
use sizeof *or* use a constant/variable; this prevents the loop going
haywire when the array/string is modified within the body of the loop.
5. If you need a string constant, then use one like this:
char *sro = "test string";
If you need a writeable string, then do this:
char srw[] = "test string";
There are very few reasons for this:
char srw[20] = "test string";
If you really needed the extra space, then it is
clearer to the maintainer what you meant if you do not
initialise when declaring. Rather copy in the values
with a safe string function after declaration, otherwise
this is almost certain to happen.
Are you trying to be funny, or just down right rude?
I was aiming for "gentle correction, but in a funny way:-)"
It's early in the morning here, I haven't finished waking up yet, and I have a long day at work ahead of me.
Congratulations - however, with much of my previous posting on usenet groups
that equate sloppy spelling with sloppy thinking, I generally fire off
one or two corrections every 20/30 posts.
I haven't read TFA (this being Slashdot and all), but if those professors actually mention Ada as a better language for teaching than Java, I wouldn't trust anything else they say, because they obviously stopped caring about the evolution of Computer Science at some point in the 80s.
I find this ironic; the reality is that anyone who feels java is superior in some unmeasurable way has
obviously stopped caring about the evolution of Computer Science...
Students have to start somewhere. It's easier to start with simple stuff than to try to cram their heads full of everything all at once.
Trouble is, Java is not "the simple stuff", Pascal is "the simple stuff". Java has inconsistent syntax,
has only one model for all programs (OO), etc. It all depends on what you are trying to teach, and if
you are trying to teach:
1. Computer architecture, OS designs, Hardware, etc
then use C (or a subset of C++).
2. Computer Science, theory of automata, TM's, state-machines, etc
then use Scheme.
3. Programming, data-structures, algorithms, etc
then use Pascal.
4. Java, C++, $LANGUAGE_OF_CHOICE
then use Java, C++, $LANGUAGE_OF_CHOICE
There is no place for Java in tuition unless it is taught as
a vocational skill. Universities never were about teaching
vocational skills.
I started programming in Pascal, and then moved to C/C++. Structured programming, language syntax, variable typing, functions, parameters, recursion, etc I could ALL learn in Pascal.
Once again, depends on what you are trying to teach/learn. Pascal (which I like, btw) teaches different
things than one would learn in C. In pascal you are learning a programming language; very often in C
you are using it for a specific platform/architecture, and hence get to use and understand things
like signals, volatile variables, memory-mapped IO, etc...
When I came through Java was still pretty new, but I did take a java course, and found it reminded me a more of Pascal than C/C++; I'd say its a good starter language.
For what, exactly? Java (and C#, etc) bring nothing new to the party; everything they offer
has already been offered (sometimes decades ago) by different programming languages. The only
reason to use them is peer-pressure, in which case the only place to teach them is in vocational
colleges, not universities.
Also you can easily write command line apps in java, so i don't know why they blamed gui dependancy on java.
And as for 'systems programming' well DUH. Your first language is where you learn the basics of programming, before you start taking systems programming you should also have a lower level course ideally in something like assembly language (even if its just on emulated hardware) or C. Like I said above, it all depends on what you are trying to teach; for example, it is possible to teach
OO using plain old C, but it is rather painful! In much the same way, the only time you would want to
use Java is when your problem maps nicely to an OO architecture (and most problems do not!).
For example, without a doubt the best way to get rid of the squirrels in your attic is to squirt just a small amount of fox urine fox urine up there.
Oh yeah? Well what happens when my attic is bristling with foxes . Now that they smell a fox-friendly, air conditioned home? What then, smarty pants? Bobcat urine? No thanks! I'll stick with squirrels, thankyouverymuch. At least they fill my attic with acorns.
I wouldn't worry about it; sounds like your attic is filled, alright.
Is this really a question of ethics, or just fueling our beliefs that our beloved pets must have emotions/souls?
Whoa there tiger... you aren't making the assumption that a belief in humans having souls is
correct, are you? I mean, do *you* have a soul? Can you prove it? Can you construct a test to
disprove it?
And where's your backup on your presented "fact" that pets having emotions[1] is merely a belief?
By imposing our own human mannerisms on top of their default primal, instict-driven, action-reaction behavioral patterns, we delude ourselves into thinking our pets would really bother to think twice about eating you alive if the "easier" food sources suddenly became scarce. Sure, you might be able to stop one of them, before the main course starts, but not without enduring a decent amount of damage to your flesh.
So, big man... do your ethics of convenience come back after you committed yourself to snapping the necks of puppies and kittens to sustain your own wellbeing?
That makes so much sense!!! I kill defenceless animals ("puppies and kittens") only because of a lapse in ethics. And
because I am a human I have a soul and experience emotions, and am not subject to "primal, instict(sic)-driven action-reaction behavioral patterns"... not that those are not all one and the same...
Congratulations; you've set a new benchmark for stupidity! Your parents must be so proud.
[1] Only if it is defined in such a way that begs the question.
My wife didn't choose to weaponize sex until after we were married. She has found out that if she holds out for months at a time she can't get what she really wants when she wants it ("We can do it if I get to...(insert expensive item here)" - wife to husband. My solution: Cold War. I'm not giving it up either.
If sex is not something you both look forward to, then you're both doing it wrong. I've only married once (still
married, anyway), but not my wife nor any of my past g/friends ever chose to weaponise sex; I'm not too sure how
I would deal with it.
If I were in your shoes, I'd just follow through with a divorce - there are names for woman
who trade material items for sex and I don't want to be married to one of them.
there's 50/50 about who will survive (the non-patent deal Linux companies, or the patent deal Linux companies)
History is scattered with the remains of those companies who made a deal with Microsoft. I doubt that
the odds are 50/50... realistically, they are more like 1/99 that Novell will survive. Novell isn't
"gambling" anymore than Russian Roulette with a single empty chamber is "gambling"
1 is a non-issue, really. I've written tons of code (graphics and simulation, OpenGL/C++/STL, plus some open source packages) using a good portion of the STL and haven't run into problems on either Windows or Linux. No #pragma's, no #ifdef WIN32. And you aren't limited by #2 to C funcionality but you have to provide appropriate interfaces to the programming language in question - so yes, if you are talking C, you have to be careful how you construct classes and provide wrappers for templates.
You can easily interface with Java, Python, Lua, any.NET language (if that's your cup of tea), and many others. Yes, C can access C++ code and classes if you are a good programmer and (1) careful in the initial coding and (2) provide wrappers for templates. (I've done this before, applying modern c++ libraries to c code almost as old as I am:) ) I'm not even sure where to begin... Can you provide a small example in C accessing
the following C++ code:
template <class T> add (T first, T second) { return first + second; }
How about accessing class members? Classes with multiple-inheritance,
getting the construction/destruction correct? Classes that overide
operators? Hell, you cannot even access plain functions (as C++
implementations do rather complex name-mangling) without implementations
providing some help, nevermind accessing overloaded functions.
The sad fact is, if you are writing a toolkit, then it must be accessible
to as many different language implementations as possible. Currently,
C is the lowest common denominator - every language has bindings to C
purely because every (non-niche) OS is written in C. Any language that
needs to run on the OS needs to call OS routines, hence they need to
have an interface to C-written code.
Like you, I have also written much cross-platform code, a lot of which
was written in C++; however I have also written quite a lot embedded
code and I have to say the C++ support is not as uniform as you seem
to think it is.
(ps. I was not aware that ecl provided bindings to C++; the ecl documentation
does not mention anything other than C and I've never been able to get
ecl to access C++ code. Could you perhaps elaborate?)
What exactly makes C sane compared to C++ when in comes to game programming?
Not specifically for games programming, but for long-lived toolkits.
For example, lets say that we implement a toolkit for NPC behaviour. If we implement
it in C we get certain benefits that will not be available with C++:
1. It will be portable to more platforms
2. It can be distributed in binary system libs (.so,.dll)
3. It can be used from almost any programming language
For #1 above, sure C++ is almost as portable as C, but C still cannot
be beat. For #2, it is certainly possible to ship C++ written.so or.dll files, but then they are limited to only the functionality provided
by C anyway. For #3, bear in mind that this is a *toolkit*; you want
every language to be able to interface to this - last I checked, very
few languages could interface to C++ classes or templates.
If I wanted to write my game in gcl, I would not be able to call C++
code, although I could call C code. The same goes for many other Lisp
dialects/implementations, scripted languages and other compiled languages.
(Hell, even *C* cannot call C++ libraries!)
In order to expose your toolkit to the largest number of users it needs to
be in exposed via C.
Arrr! I be thinking it be more fun to have an actual lightsabre, be it plastic I don't be carin', with the Wii controller attached some way, so ye be hackin' and slashin' (and no small bit o' swashbucklin'!) to the dulcet tones of sommon bellowin' 'Hey, you could poke an eye out with that thing!'
We recently re-wrote a C application in python, the original application took 5 programmers 3 years to create, we recreated it in python with 2 programmers in 6 months, it is feature complete vs the C implementation, it is slower, but not outside of what would be considered reasonable
That isn't surprising; the first application will certainly take longer, no matter what the
language is. What I suspect is that the original spec took 5 years and 3 programmers
to prototype in C. Once you have a reference implementation in any language, then you
have a bullet-proof, engraved-in-stone, never-to-be-changed-while-coding specification
that makes actual development a walk in the park.
Attributing the development speedup to a language just makes you look silly! There
are plenty of research papers comparing various languages that do not include the
development of the spec to artificially cripple any language's benchmark - cite one
of those instead.
I want evidence, or better yet, a "proof". A proof of miracles, or God, would be fine.
Do you believe in your postman?
Religion requires belief, belief requires faith. Having a proof
or evidence of gods existence negates any requirement for
belief and faith, hence making religion unneeded (because we do
not have a faith-based worship in things that do exist).
IOW, if there was proof that god exists, religion wouldn't.
Slashdot Mirror
I started with a c64, so not much difference then.
Take five years away from C and see if you remember the little things - not about null terminators, but which routines add them and which don't, etc. Does strcpy copy the null-terminator? Does strncpy if the string is longer than n characters? This isn't "programming", this is API trivia.
In actual fact, I haven't used the standard C string functions (unsafe, C programmers almost never use the unsafe functions, like gets) in many years, but I can almost certainly guarantee(sp?) that strncpy will add in the terminator *unless* the length of the source string is greater than or equal to the length of the destination array.
Anyways, your comment is a further example... I posted a pesudo-codish for-loop illustrating the initialization, check, and self increment. There are easier ways for strings, as you list: but they don't generalize to arrays that aren't null-terminated or where you wish to walk backwards, etc.
I replied with something that generalises to arrays and can be used in reverse (from end of array). I have to concede that I have nothing that will generalise to pointers to malloc'ed arrays.
And then with all the different ways to allocate space, assign strings, set nulls, you still don't think it's full of gotchas? Maybe gotchas that you learn when working in it, but if you just picked up K&R and started coding you'd turn out bad code. Of course not; this is C we are talking about - it was created to write a portable OS. Even now, it is very rarely used to implement business logic, hence it comes with disadvantages for high-level constructs, but it does come with a rather intuitive mapping to the computer (hence, nice for teaching computer architecture).
My point was that you are criticising something when it is blindly obvious that it has been some time since you have used it intimately.
Worse, semi-stable bad code that works but only until you change compiler, platforms, etc.
If you read the standard, this never happens; the only times I have seen this is in the hands of developers who think that an int, in C, is 32 bits (because it is on their platform) or who think that the code "void main ()" is legal C.
IOW, the only people who suffer are those that look at what their compiler generates and then infers what is and isn't in C. Drop by comp.lang.c sometime and you'll see these people getting constantly corrected when they say "it depends on your platform".
Nope - all you proved is that you need to learn C before you can 'dis it
char x[5] = "foo" char x[5] = "longer string" The first is bad form because the second would still compile. It'd probably be zero-terminated, but stomping on your other variables.
Actually, this is in the damn C standard! You are picking on things that are part of the language specification that *every* programmer in that language should know!!! How can you call yourself a C programmer if you've never read the standard?
Nope, just tested that. It's limited to the declared length, but it's not zero-terminated.
Or, you know, you could have read the C standard instead; then this would be one of many so-called "gotcha's" that you would never even notice. Anyways, that's C - tons of little gotchas, most of which are somewhat platform dependent. You remain stubborn in your opinion that, even if you never read the language standard (or spec), then it is the fault of the language that you do not know things that are common knowledge to all C programmers. I think perhaps you should re-examine your arguments about C, but first at least read the standard.
Yeah, I forgot to calloc the string, or specifically null the last byte.
I get the idea that you still do not know what you are talking about.
But that's my point. C has too many gotchas like that where the standard library is nearly unusable - scanf is bad, gets is bad, printf with user-controllable strings isn't safe, etc.
Of course; you have to learn it first. Your code snippet that I quoted provided a very good reason for teaching programming via something that maps so well onto the hardware (such as C); if you had been taught C before getting to develop on $LANGUAGE-OF-CHOICE, you would appreciate $LANGUAGE-OF-CHOICE much more.
Same with C++. Use strings to avoid these problems, but which string library. Which smart pointers? Which resizable array, or associate array library?
As a professional programmer, you would have read the standards documents on the language you are using. If you haven't, do not go blaming the language for "gotcha's" when they are so clearly spelled out in the standards documents.
However I get the impression (correct me if I am wrong) that you do not actually read the standards (or specifications) documents for the language you want to use, hence you will get tripped up all the time by stuff that should not be an issue.
(btw: I program in C all the time (daily), and I malloc/free all the time as well, and the last time I had a bug that was a memory leak in production was in the 90's. I do not worry about it at all - proper factoring of the code, proper testing (valgrind is part of the test harness, including diff scripts) catches all the memory bugs.
Thankfully it's been too many years for me to be more specific.
If you're still awake at this point, let me attempt to point out the problems with the code you posted; I'm ignoring the missing ';' as that is almost certainly a typo - what I am not ignoring is your severe misconceptions. Here is your code snippet:
1. You were incorrect upthread when you assumed that no NULL byte was added; it most certainly is.
2. If you are traversing an array, you use the sizeof operator to calculate the array length at compile time like this:
3. You are calling strlen before every loop - this usually results in unacceptably long execution times for the loop. For a pointer to a string use a while loop like this:
For a char array, use the sizeof operator.
4. You are running through the loop body with a mutable string but relying on the end of the string to break the loop. This is a source of very difficult to track bugs once the maintainer starts work. Instead, use sizeof *or* use a constant/variable; this prevents the loop going haywire when the array/string is modified within the body of the loop.
5. If you need a string constant, then use one like this:
If you need a writeable string, then do this:
There are very few reasons for this:
If you really needed the extra space, then it is clearer to the maintainer what you meant if you do not initialise when declaring. Rather copy in the values with a safe string function after declaration, otherwise this is almost certain to happen.
...
This
Or, come to think of it, without supervision.
I was aiming for "gentle correction, but in a funny way
It's early in the morning here, I haven't finished waking up yet, and I have a long day at work ahead of me.
Congratulations - however, with much of my previous posting on usenet groups that equate sloppy spelling with sloppy thinking, I generally fire off one or two corrections every 20/30 posts.
Yes, they say "spell it correctly!"
right back at ya: "if the only tool you have is a chainsaw, every problem looks like hours of fun
I find this ironic; the reality is that anyone who feels java is superior in some unmeasurable way has obviously stopped caring about the evolution of Computer Science
Trouble is, Java is not "the simple stuff", Pascal is "the simple stuff". Java has inconsistent syntax, has only one model for all programs (OO), etc. It all depends on what you are trying to teach, and if you are trying to teach:
1. Computer architecture, OS designs, Hardware, etc
then use C (or a subset of C++).
2. Computer Science, theory of automata, TM's, state-machines, etc
then use Scheme.
3. Programming, data-structures, algorithms, etc
then use Pascal.
4. Java, C++, $LANGUAGE_OF_CHOICE
then use Java, C++, $LANGUAGE_OF_CHOICE
There is no place for Java in tuition unless it is taught as a vocational skill. Universities never were about teaching vocational skills.
That depends on what you are trying to teach.
I started programming in Pascal, and then moved to C/C++. Structured programming, language syntax, variable typing, functions, parameters, recursion, etc I could ALL learn in Pascal.
Once again, depends on what you are trying to teach/learn. Pascal (which I like, btw) teaches different things than one would learn in C. In pascal you are learning a programming language; very often in C you are using it for a specific platform/architecture, and hence get to use and understand things like signals, volatile variables, memory-mapped IO, etc
When I came through Java was still pretty new, but I did take a java course, and found it reminded me a more of Pascal than C/C++; I'd say its a good starter language.
For what, exactly? Java (and C#, etc) bring nothing new to the party; everything they offer has already been offered (sometimes decades ago) by different programming languages. The only reason to use them is peer-pressure, in which case the only place to teach them is in vocational colleges, not universities.
Also you can easily write command line apps in java, so i don't know why they blamed gui dependancy on java. And as for 'systems programming' well DUH. Your first language is where you learn the basics of programming, before you start taking systems programming you should also have a lower level course ideally in something like assembly language (even if its just on emulated hardware) or C. Like I said above, it all depends on what you are trying to teach; for example, it is possible to teach OO using plain old C, but it is rather painful! In much the same way, the only time you would want to use Java is when your problem maps nicely to an OO architecture (and most problems do not!).
Criminals aren't usually known for being the sharpest knives in the drawer.
Neither are cops
Yes.
Oh yeah? Well what happens when my attic is bristling with foxes . Now that they smell a fox-friendly, air conditioned home? What then, smarty pants? Bobcat urine? No thanks! I'll stick with squirrels, thankyouverymuch. At least they fill my attic with acorns.
I wouldn't worry about it; sounds like your attic is filled, alright.
Goose meet the gander.
Charmed.
Whoa there tiger
And where's your backup on your presented "fact" that pets having emotions[1] is merely a belief?
By imposing our own human mannerisms on top of their default primal, instict-driven, action-reaction behavioral patterns, we delude ourselves into thinking our pets would really bother to think twice about eating you alive if the "easier" food sources suddenly became scarce. Sure, you might be able to stop one of them, before the main course starts, but not without enduring a decent amount of damage to your flesh.
So, big man... do your ethics of convenience come back after you committed yourself to snapping the necks of puppies and kittens to sustain your own wellbeing?
That makes so much sense!!! I kill defenceless animals ("puppies and kittens") only because of a lapse in ethics. And because I am a human I have a soul and experience emotions, and am not subject to "primal, instict(sic)-driven action-reaction behavioral patterns"
Congratulations; you've set a new benchmark for stupidity! Your parents must be so proud.
[1] Only if it is defined in such a way that begs the question.
If sex is not something you both look forward to, then you're both doing it wrong. I've only married once (still married, anyway), but not my wife nor any of my past g/friends ever chose to weaponise sex; I'm not too sure how I would deal with it.
If I were in your shoes, I'd just follow through with a divorce - there are names for woman who trade material items for sex and I don't want to be married to one of them.
Good luck
Found the link
http://www.sciencedaily.com/releases/2007/04/070409164849.htm
I've heard rumours that smoking drives down the possibility
of brain-related diseases (alzheimers(sp?), parkinsons).
Anyone care to comment?
History is scattered with the remains of those companies who made a deal with Microsoft. I doubt that the odds are 50/50
Responding on
How about accessing class members? Classes with multiple-inheritance, getting the construction/destruction correct? Classes that overide operators? Hell, you cannot even access plain functions (as C++ implementations do rather complex name-mangling) without implementations providing some help, nevermind accessing overloaded functions.
The sad fact is, if you are writing a toolkit, then it must be accessible to as many different language implementations as possible. Currently, C is the lowest common denominator - every language has bindings to C purely because every (non-niche) OS is written in C. Any language that needs to run on the OS needs to call OS routines, hence they need to have an interface to C-written code.
Like you, I have also written much cross-platform code, a lot of which was written in C++; however I have also written quite a lot embedded code and I have to say the C++ support is not as uniform as you seem to think it is.
(ps. I was not aware that ecl provided bindings to C++; the ecl documentation does not mention anything other than C and I've never been able to get ecl to access C++ code. Could you perhaps elaborate?)
Not specifically for games programming, but for long-lived toolkits.
For example, lets say that we implement a toolkit for NPC behaviour. If we implement it in C we get certain benefits that will not be available with C++:
1. It will be portable to more platforms
2. It can be distributed in binary system libs (.so,
3. It can be used from almost any programming language
For #1 above, sure C++ is almost as portable as C, but C still cannot be beat. For #2, it is certainly possible to ship C++ written
If I wanted to write my game in gcl, I would not be able to call C++ code, although I could call C code. The same goes for many other Lisp dialects/implementations, scripted languages and other compiled languages. (Hell, even *C* cannot call C++ libraries!)
In order to expose your toolkit to the largest number of users it needs to be in exposed via C.
With care, yes.
That isn't surprising; the first application will certainly take longer, no matter what the language is. What I suspect is that the original spec took 5 years and 3 programmers to prototype in C. Once you have a reference implementation in any language, then you have a bullet-proof, engraved-in-stone, never-to-be-changed-while-coding specification that makes actual development a walk in the park.
Attributing the development speedup to a language just makes you look silly! There are plenty of research papers comparing various languages that do not include the development of the spec to artificially cripple any language's benchmark - cite one of those instead.
Do you believe in your postman?
Religion requires belief, belief requires faith. Having a proof or evidence of gods existence negates any requirement for belief and faith, hence making religion unneeded (because we do not have a faith-based worship in things that do exist).
IOW, if there was proof that god exists, religion wouldn't.