On 01/05/12 08:19, Jacob Carlborg wrote:
> On 2012-01-04 16:31, Artur Skawina wrote:
>> 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) { ... }
>
> If you want your code to be portable (between compilers) you would need to
> wrap that in a version statement.
>
Exactly. Which isn't a problem if you have one or two such functions. But
becomes one when you have hundreds. And different compilers use different
conventions, some do not support every feature and/or need specific tweaks.
Copy-and-pasting multiline "declaration attribute blocks" for every function
that needs them does not really scale well.
In C/C++ this is CPP territory where you solve it with a #define, and all of
the magic is both hidden and easily accessible in one place. Adding support for
another compiler requires only editing of that one header, not modifying
practically the whole project. Let's not even think about compiler version
specific tweaks (due to compiler bugs or features appearing in newer
versions)...
D, being in its infancy, may have been able to ignore these issues so far
(having only one D frontend helps too), but w/o a std, every vendor will have
to invent a way to expose non-std features. For common things such as forcing
functions to be inlined, keeping them out of line, marking them as hot/cold,
putting them in specific text sections etc relying on vendor extensions is not
really necessary.
It's bad enough that every compiler will use a different incompatible runtime,
in some cases calling conventions - and consequently different shared
libraries; reducing source code portability (even if just by making things
harder than they should be) will lead to more balkanization...
artur
