www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - extern(C) function declarations and extra keywords.

reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
I was thinking of adding some keywords like final, pure, and 
nothrow in to my library to improve various things where 
improvements could be made. As I was thinking about this, I 
wondered about my extern(C) function declarations and how 
keywords could improve those as well.

Since the C functions can't access anything from D code save for 
what is passed through as parameters, can it be called pure? And 
if so, does the compiler know how to distinguish C and D in this 
instance and make it inherently pure? Does purity do anything in 
terms of speed/safety here?

I noticed that in Deimos and Derelict that most(if not all) C 
function declarations are marked as nothrow. What are the 
speed/safety benefits of including this? And likewise as with the 
pure aspect, does the compiler know how to distinguish C and D 
and make it inherently nothrow?

C's name mangling doesn't allow function overloading, but as far 
as I know you can overload extern(C) functions in D. Does adding 
final help with speed improvements in the D side of things if 
added to an extern(C) function declaration?

Thanks much!
Dec 28 2013
next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
 Since the C functions can't access anything from D code save 
 for what is passed through as parameters, can it be called pure?
Probably not since it might not be pure and eg. mutate global variables.
 Does purity do anything in terms of speed/safety here?
A pure function is expected to give the same result given the same parameters. Similar calls to a pure function (same parameters) can be optimized out by the compiler.
 I noticed that in Deimos and Derelict that most(if not all) C 
 function declarations are marked as nothrow. What are the 
 speed/safety benefits of including this?
No speed or safety benefit, but it allows to call these C functions in functions marked nothrow themselves. As a rule of thumb you can put nothrow systematically when binding C code.
 And likewise as with the pure aspect, does the compiler know 
 how to distinguish C and D and make it inherently nothrow?
No.
 C's name mangling doesn't allow function overloading, but as 
 far as I know you can overload extern(C) functions in D. Does 
 adding final help with speed improvements in the D side of 
 things if added to an extern(C) function declaration?
No.
Dec 28 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 28, 2013 at 09:57:06PM +0000, ponce wrote:
[...]
I noticed that in Deimos and Derelict that most(if not all) C
function declarations are marked as nothrow. What are the
speed/safety benefits of including this?
No speed or safety benefit, but it allows to call these C functions in functions marked nothrow themselves. As a rule of thumb you can put nothrow systematically when binding C code.
[...] Yes, since C code will not throw D exceptions (C doesn't know anything about D exceptions). Unless you pass in a function pointer to a D function that does throw an exception... but that case doesn't work for other reasons, so it generally shouldn't be done. So, barring that, all C code is automatically nothrow. T -- What do you call optometrist jokes? Vitreous humor.
Dec 28 2013
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 29 December 2013 at 14:50:52 UTC, H. S. Teoh wrote:
 Yes, since C code will not throw D exceptions (C doesn't know 
 anything
 about D exceptions). Unless you pass in a function pointer to a 
 D
 function that does throw an exception... but that case doesn't 
 work for
 other reasons, so it generally shouldn't be done. So, barring 
 that, all
 C code is automatically nothrow.
Some C libraries are designed to support long-jumping or throwing[1] out of some of their callbacks (when they are, it will be explicitly stated in the documentation). These callbacks need not necessarily be marked nothrow. Of course, the C function that calls the callback should have the same throwness as the callback - if one is marked as nothrow, both should be, and vice versa. Interestingly, D programs that catch non-Exception's and try to return to a normal path of code execution will be extra prone to spectacular failure if they use C libraries with callbacks that don't support long-jumping out of them, which is most... [1] Whether stack-unwinding will work is dependent on the exception mechanism and sometimes compilation flags etc.
Dec 29 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-28 22:47, Jeremy DeHaan wrote:

 Since the C functions can't access anything from D code save for what is
 passed through as parameters, can it be called pure? And if so, does the
 compiler know how to distinguish C and D in this instance and make it
 inherently pure? Does purity do anything in terms of speed/safety here?
It can access global variables. -- /Jacob Carlborg
Dec 29 2013