System programming in D (Was: The God Language)

[Jacob Carlborg]

On 2012-01-05 10:54, Artur Skawina wrote:
> 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

The pragma is a standard way to expose non-standard features. You just 
need to wrap it in version statements because the compiler will 
otherwise complain about unrecognized pragmas. If that's a good thing or 
not, I don't know.

-- 
/Jacob Carlborg