On 01/04/12 10:39, Manu wrote:
> Walter made an argument "The same goes for all those language extensions you
> mentioned. Those are not part of Standard C. They are vendor extensions. Does
> that mean that C is not actually a systems language? No."
> This is absurd... are you saying that you expect Iain to add these things to
> GDC to that people can use them, and then create incompatible D code with the
> 'standard' compiler?
Some of these things are *already* in GDC... Probably not documented and tested
enough [1], but they are there. So you /can/ have function declarations such as:
pragma(GNU_attribute, always_inline, flatten, hot) int fxx(int i) { ... }
Now, this wouldn't be that bad, if we had a preprocessor or some kind of macro
facility. But as it is, writing portable code is too expensive. (I may need to
add a cpp stage for D because of issues like this, haven't decided yet...)
> Why would you intentionally fragment the compiler support of language
> features rather than just making trivial (but important) features that people
> do use part of the language?
There are more issues, that *will* be fixed in time, once (maybe even "if") D
matures. A wiki page etc listing all the needed changes ("D next generation")
would definitively be helpful. Not only to record what needs fixing, but also
what to avoid. Could reduce the inevitable balkanization significantly.
Functions attributes seems like it could be an easy, backward compatible
addition:
@attr(attributes...)
then define some obvious generic attributes like "inline" (which is
(always|force)_inline, as it's the only one that makes sense), "noinline",
"hot", "cold" etc. This lets you write "@attr(inline) int f(i){}" etc, but
doesn't help the vendor specific attr case at all, unfortunately. [2]
artur
[1] Like the "target" "tune" (sub)attribute, which is not per function, but
global (ie behaves as C #pragma). That might be a gcc bug though. Also, using
gcc asm in a function makes the compiler generate worse code (triggered by the
/first/ asm use, next ones within a function are free).
[2] The problem is what do you do when you have a lot of function/methods that
need to be inlined/flattened, have a different calling convention or otherwise
need to be specially marked _and_ it needs to be done differently for different
compilers?...
