Unvanquished Is Rewriting, Modernizing The Quake 3 Engine

[Irritant]

Quake 3 engine is outdated. Xonotic has better engine.

This is the annoying shit that I am so sick of seeing. This is a thread about Unvanquished and the progress they have made. If you want to extoll the virtues of Xonotic, post on a Xonotic thread, or start a new one. This shit is getting older than your grandma's panties.

[c117152]

To the best of my knowledge it is implementation-dependant in all the C standards. Most compilers will expect a return type of int for main though some may allow something like void.

Yap. It's a working, cross-platform, production, open-source compiler. Though like I said, it's not all standard.
Besides, Even in ANSI C (http://www.iso-9899.info/wiki/The_Standard) and ISO C (http://www.iso.org/iso/catalogue_det...csnumber=17782) the main() return types are optional. It's just not very clear if you're not used to reading and implementing standards.
To be specific, in C99 (http://atrey.karlin.mff.cuni.cz/proj...rr/doc/c99.pdf), "5.1.2.2. Program startup", the phrasing is:
...

The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent; or in some other implementation-defined manner
...

So, what happened is that most implementers figured the "or" only applied to the parameters. Where, in fact, it applied to the entire subject of the sentence. That is, the "other implementation-defined manner" overrides both whole "defined with a return type of int and with no parameters" and not just "and with no parameters".
In the following section, "5.1.2.2.3 Program termination" it's made rather explicit:
...

If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument; reaching the } that terminates the main
function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.
Forward references: definition of terms (7.1.1), the exit function (7.20.4.3).

...

The key here is "If the return type of the main function is a type compatible with int,". That is, it's not guaranteed that you have to return int. And if you don't, you're going to need to use the exit(). Which I did.

By the way, I've never seen a fully standard compatible compiler. Even GNU C has some violations. And of course, the most popular, Microsoft Compiler is filled with poor, miss, and downright obtuse violations.

Now, the next hint is that I didn't make any mistakes. That code compiles and runs without any errors.

[IanS]

While I've lost interest in the thread, I'll have some fun with this one and give you another clue: You only return from main() in ANSI C...

To the best of my knowledge it is implementation-dependant in all the C standards. Most compilers will expect a return type of int for main though some may allow something like void.

[c117152]

Did you seriously just use void main()........

While I've lost interest in the thread, I'll have some fun with this one and give you another clue: You only return from main() in ANSI C...

[curaga]

For that matter, I built your struct example using 4.7.1 -O1.

The stripped sizes were 2.2kb and 2.4kb, the runtimes 2ms and 4ms, repeatedly. Perhaps some parts are different on Windows, like using mscvrt.dll.

[curaga]

I said "in almost all cases". Hello world clearly doesn't apply, do something with actual functions and actual work. Build some existing open source program with more than few lines.

[mrugiero]

Are you sure that if you write the same construct will give to you a different size?

I never stated so, it was the one I quoted. I told him (I didn't check what he said, though) that if that was true, it was still unfair, because you should disable features enabled by default that you don't use. Until now, I haven't programmed in C++ yet, I just read the differences to C, which I did code.

Also, I don't expect C++ to be harder to parse and compile if the constructs are simple. It could be, because it allows you to make more complex constructs syntactically, but if you don't, the compiler should behave, AFAIK, pretty much as the C one.

[ciplogic]

To be fair, if you don't use such features on your program, you should disable them. Not disabling what you don't use is just laziness, and harms the user for nothing.

The things are even better when are measured.

So, I will go on the lazy side and I will write a minimalist printf coding in a C respectively in a C++ file.
The result on Windows, is the following:

http://snag.gy/fztNT.jpg

In short: 32.5 KB for both.

Let's add some class (in C a struct):

http://snag.gy/gV6y4.jpg

Still: 32.5 KB

Are you sure that if you write the same construct will give to you a different size?

My original quote was:

So, let's clarify, C++ will give to you basically the same performance as C with a similar coding style.

To reproduce the result use a release build for both configurations, I used GCC/G++ 4.7.1 with -O1 (you can pick O2 if you find it more convenient).

[mrugiero]

No it won't, by default. Compile almost any C code as C++, and it will run slower, unless you manually disable both exceptions and RTTI. It will also compile slower and produce a bigger binary, though the binary size is also somewhat alleviated by manually disabling the mentioned features.

To be fair, if you don't use such features on your program, you should disable them. Not disabling what you don't use is just laziness, and harms the user for nothing.

[curaga]

Wheeeee language thread!

So, let's clarify, C++ will give to you basically the same performance as C with a similar coding style.

No it won't, by default. Compile almost any C code as C++, and it will run slower, unless you manually disable both exceptions and RTTI. It will also compile slower and produce a bigger binary, though the binary size is also somewhat alleviated by manually disabling the mentioned features.