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
