I believe C99 changed variable declaration rules so that they are the same as in C++, so it might be valid C99 code.
Oh, well, there you go. I’d probably know more about C99 if MS actually deigned to support it in Visual Studio. :p
I haven’t seen code that hideous in a long time. Presumably it’s better if we can see the block where the pointer is actually used (which I presume is snipped), but still.
Cryptic names, needless error-prone hard-to-debug pointer arithmetic, premature optimization of the sort the compiler will do better anyway, just yuck.
Your ninja reflexes are slow today!
Trying to decode pointer arithmetic will do that to a guy!
That’s true… although I admit I had to look it up in my handy copy of the C99 standard to be sure. :) But remember that variable declarations in C and in C++ are very different under the hood; a C++ variable declaration could effectively be a function call, whereas in C, you’re just making space on the stack or text:
int function(int x, int y)
{
int z = x + y ;
foo(z) ;
Mytype q ;
...
}
int function(int x, int y)
{
Mytype q ;
int z = x + y ;
foo(z) ;
...
}
The above two snippets will generate almost the exact same code in C99, the sole differences being the order in which q and z are put on the stack and, if padding is necessary after Mytype, a size difference of less than one word.
In C++, however, the constructor for Mytype will be called (and the destructor implicitly at the “}”). If Mytype() and foo() have side effects that depend on each other, you’ll not only have different code, but different results.
Of the many bullets that C++ provides for naive programmers to shoot themselves, destructors provide a lot of ammunition.
Rimbo,
You’re basically saying that an object with a constructor will compile differently in C++ than it can in C. Well… yeah… because it won’t compile in C, because C will hit the constructor call and go “wtf is this crap?”.
Anything that compiles in C – namely, Mytype being a typedef’d primitive type or struct – will do the exact same thing in C++.
Wow, I’d totally forgotten about that. I’m sitting here thinking, “that’s nonsense, that’s just a null reference until something is assigned to it.”
C++ is all crazy.
Note that C does not guarantee the order of allocation for objects. That is, make no assumptions about the results of a relative comparison of addresses of two objects. Compilers can, and do, shuffle things around.
As a practical example people get wrong a long, don’t assume that because variable ‘b’ is declared after variable ‘a’ that the address of ‘b’ is greater than the address of ‘a’. That’s true for globals and locals alike.
int a;
int b;
C++ is a multi paradigm language. You can do procedural, object-oriented, and generic programming all at the same time, and then it can all run blazing fast because there’s no virtual machine or interpreter.
Of course, it’s more complicated than C, making it not as good for pure-procedural stuff, it’s not as good at being object oriented as C# or Java, and generic programming just makes everyone’s head hurt in general, with C++'s syntax and lack of high-level tools making hardcore generic programming the realm of super-experts.
It’s so not a perfect language – but it’s a remarkably resilient one, mainly because it’s the highest-level low-level language in common use.
I know that when I write pure C, I start wishing that I could write a few simple classes to make my life easier.
Well, one point here.
Edit: Nevermind the first point. I just re-read OP and we know it’s C code for a fact. :)
Nooooooooooot quite; in C, a struct is just a group of things declared together. In C++, however, a struct is a class with members that are public by default rather than private. So take the following perfectly legitimate C code:
int foo( Mytype x )
{
Mytype q = x;
}
If you’re in C++ with this code, someone could go off and subclass Mytype, and then pass foo() an object of the subclassed type. In the above case, C++ will have to compile the above very differently from C in order to handle that case.
Hm. Isn’t a struct a sort of primitive class in C++? I mean, the i/o functionality of a C program with structs would be exactly the same in both languages, but but maybe there would be some small amount of class-related overhead in C++ code generation for structs – default constructor, say – for something which hardly even exists except as a memory offset in C? But I suppose a C++ compiler is free to be smart if it wants to be, so maybe even the code generation would be the same.
Edit: oops, too late :)
It requires a greater degree of skill for a C++ programmer to write blazingly fast code than a C programmer. It’s obviously quite possible, but naive C++ patterns can lead to awesomely inefficient behaviors.
For example, if you naively inherit the wrong things, you can compile a few lines of code for an amazingly long time (something Google Go was specifically designed to deal with), and the simple little data structure class you think you’ve got is really this monstrously large class with a million methods and some huge amount of private data you weren’t anticipating.
Similarly, if you are doing any recursion with memory allocation, the end of the recursion could totally screw you with this enormous cascade of destructor calls which in the corresponding C program could be taken care of by exit(0) or by an iteration of frees instead of yet more stack frames.
Of course both those examples are kind of dumb, especially the second one, but I’ve seen both in supposedly professional big system code, and there are so many other ways to shoot yourself in C++ that it does require more professional skill and mastery than some other languages.
Of course there are some big systems you wouldn’t ever want to build in C if you could avoid it, and C++ does address some large system issues through OO, but I’m just saying that C++ per se is not automatically blazingly fast unless the programmer knows what he or she is doing.
Ah… annoying. I just wrote up a little post about C++, and then the browser barfed on it.
Summary: C++ is basically a dinosaur at this point. It’s not appreciably faster than Java any more, with Java often actually beating C++ in terms of efficiency. And we’re just talking raw code efficiency there… that is, the ability for the computer to efficiently run the code and do the work. When you factor in the efficiency of the development process, then C++ starts to get crushed, rapidly.
A little comparisonsomeone did in 2008. Note, since then, Java’s actually enjoyed some major updates, which have improved its efficiency in a number of areas (sometimes, by an order of magnitude).
There are times when a language like C, with such little overhead, can be used for key stuff… but at this point, there’s not a whole lot of reason to ever use C++ if you can help it. You’re rarely going to benefit from any performance improvement compared to a language like Java, and you will suffer from using such an antiquated language in terms of development time, bugs, memory leaks, etc.
The arguments in favour of high-speed memory-managed JITted languages have always seemed compelling to me. And yet, the reality is that whenever I’m running a program written in Java, it’s irritatingly slow.
Java is a dinosaur too at this point. I prefer it to C++ for most applications for various reasons, but I hate the vast teetering tower of abstractions and libraries and packages needed to get anything substantial done in it. I’m sure this is a big reason for slowness: most people will lazily accept all the overhead associated with large amounts of unnecessary OO code. No doubt if you write insightful java with as few inheritances and frameworks and factories and all that stuff as possible, and if you don’t recklessly generate too much garbage, it’s quite fast.
All this crap that gets in the way of what you want to do is one big reason why I deliberately quit programming professionally some years ago – and that resignation from the industry is why you should take my opinions here with a grain of salt, fun though they are to express.
Anyhow, it’s obviously somewhat immature for serious work, but I think Go has a lot of potential based on a presentation and demo of it I attended at Google. However, I’ve never written a line of code in it, so who knows, really.
Oh, yeah, getting back to the subject of the thread, from the Go faq:
While I agree in general, it’s dangerous to just generally assert that Java or other high level languages are ‘close enough’. For non-performance intensive apps or high level stuff, sure. But the minute you have to get close to the metal (which still happens, especially in gaming) then a high level language just isn’t an option.
You’re not going to do SPU programming in java any time soon…
Yes, my scenario is basically compiling the struct as C vs C++. And Rimbo assumed a typedef for C anyway.