Linked by Thom Holwerda on Thu 7th Oct 2010 19:10 UTC, submitted by tyrione
General Development LLVM 2.8 has been released. The release notes describe this new, ehm, release in greater detail, so head on over and give it a read.
Thread beginning with comment 444504
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by kaiwai
by Neolander on Fri 8th Oct 2010 12:41 UTC in reply to "RE[2]: Comment by kaiwai"
Neolander
Member since:
2010-03-08

I know it is a pain in the rear that the standard lacks some niceties but I'd sooner that people wrote code according to the standard, even if it means they have to write an extra 1000 lines of code simply for the sake of being able to pick up any compiler and it all works nicely because the programmer chose to stick to the straight and narrow.

How was it done before these features appeared? they wrote it out the long way - time to go back to the good old days instead of looking for quick and dirty short cuts that create giant clusterfucks when it comes to code portability.

It's not a matter of number of LOC, you just can't define a packed structure in vanilla C++. Nor know the size of the integers you're using (which is quite idiotic for anything except but int which is supposed to handle the machine's faster integer type, if you ask me).

When people did not have compiler extensions, they used either known compiler-specific behavior (like my typedef long int64_t), gigantic macros that are horrible to debug, or assembly code which has the worst possible portability. Generally a combination of all three. I don't see what's wrong with using compiler extensions, compared to this mess...

Reply Parent Score: 2

RE[4]: Comment by kaiwai
by Neolander on Fri 8th Oct 2010 14:10 in reply to "RE[3]: Comment by kaiwai"
Neolander Member since:
2010-03-08

Nor know the size of the integers you're using (...)

When I read this again, I fear that this is going to be misinterpreted, so I prefer to say it right away : I know that I can use sizeof() to know the size of integer types. But it doesn't make the results less platform- and compiler-specific.

If I use, say, "short" or "long", there's no way I can know what the size in bits of those are on a random platform and compiler, which is highly inconvenient in some cases (like if you want to be sure you can store number X in an integer data type, or for low-level development tasks) while not being exactly advantageous in any way. See http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models as an example of this horrible mess.

We wouldn't have this if C, back in the day, had been defined with stdint-like fixed-size integer types in the first place and only "char" and "int" as vaguely-sized types (char because it's used to store characters anyway and int because it's a convenient shortcut to the machine's fastest integer type), or if its horrible integer types were not copied by C++ for compatibility reasons.

But well, I can't go back in time and change this... And thanks to the introduction of stdint.h in the C99 revision of C, the thing has been fixed there. So I can only hope that this fix is ported to C++ someday. Fixed-sized integers are just the way it should have been done in the first place.

Edited 2010-10-08 14:18 UTC

Reply Parent Score: 2

RE[4]: Comment by kaiwai
by Neolander on Fri 8th Oct 2010 16:49 in reply to "RE[3]: Comment by kaiwai"
Neolander Member since:
2010-03-08

Oh, and another almost-mandatory compiler extension to C and derivatives that's not properly described by the relevant standards : inline assembly. As awful as GCC's syntax for it can be, it's often much better than keeping separate .s files and writing headers for them, because...
-Doing so is overkill for those assembly snippets of less than 10 lines that form most of CPU-specific code.
-When you're writing ASM, you don't write portable code anyway.
-It's better for code clarity.
-Except for that class of tiny CPU-specific code chunks, ASM is often used for high-performance code, that kind of code where even a CALL's penalty can be too much...

Edited 2010-10-08 17:00 UTC

Reply Parent Score: 2

RE[5]: Comment by kaiwai
by moondevil on Sun 10th Oct 2010 13:16 in reply to "RE[4]: Comment by kaiwai"
moondevil Member since:
2005-07-08

Assembly place is on .s files.

I for one vote for not having inline assembly.

I don't see any problem with having to write a few external functions.

Reply Parent Score: 2