www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - CTFE with C functions not possible?

reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Using DMD 2.0.69.2, the following code:

extern (C) double sqrt(double x);
enum q = sqrt(4.0);

gives the error:

Error: sqrt cannot be interpreted at compile time, because it has no 
available source code

But if I do:

import std.math;
enum q = sqrt(4.0);

There is no problem. So two questions:

1) Why exactly can't the compiler call a C function at compile time whereas 
it can call a D function?

2) <same as above> ... which itself only in the end calls that very same C 
function IIANM?

I see druntime/import/core/math.d l 91:

double sqrt(double x);  /* intrinsic */

-- 

Dec 31 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 01/01/16 12:52 AM, Shriramana Sharma wrote:
 Using DMD 2.0.69.2, the following code:

 extern (C) double sqrt(double x);
 enum q = sqrt(4.0);

 gives the error:

 Error: sqrt cannot be interpreted at compile time, because it has no
 available source code

 But if I do:

 import std.math;
 enum q = sqrt(4.0);

 There is no problem. So two questions:

 1) Why exactly can't the compiler call a C function at compile time whereas
 it can call a D function?

 2) <same as above> ... which itself only in the end calls that very same C
 function IIANM?

 I see druntime/import/core/math.d l 91:

 double sqrt(double x);  /* intrinsic */
From what I've been able to tell, std.math have some special yucky rules about it and intrinsics. It will make it very hard to split std.math up.
Dec 31 2015
parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Rikki Cattermole wrote:

 It will make it very hard to split std.math up.
I have no desire to split std.math up. :-) What I desire to do is be able to call a C library from a D template like octal to compute a string at compile time. Is this possible or not? --
Dec 31 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 01/01/16 1:05 AM, Shriramana Sharma wrote:
 Rikki Cattermole wrote:

 It will make it very hard to split std.math up.
I have no desire to split std.math up. :-)
I do though.
 What I desire to do is be able to call a C library from a D template like
 octal to compute a string at compile time.

 Is this possible or not?
No, source is not available.
Dec 31 2015
parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Rikki Cattermole wrote:

 Is this possible or not?
No, source is not available.
Why, is it because the D compiler is already linked to the C library (and hence knows where the functions are located and such), but not to my library? I mean, I even gave -L-lmylib and all that, but of course now I realize that that is only telling the *linker* about the lib. How do I tell the compiler to the lib? If Python CTypes can query and find out any library with the SO filename I throw at it, can't a D compiler? --
Dec 31 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 01/01/16 1:14 AM, Shriramana Sharma wrote:
 Rikki Cattermole wrote:

 Is this possible or not?
No, source is not available.
Why, is it because the D compiler is already linked to the C library (and hence knows where the functions are located and such), but not to my library? I mean, I even gave -L-lmylib and all that, but of course now I realize that that is only telling the *linker* about the lib. How do I tell the compiler to the lib? If Python CTypes can query and find out any library with the SO filename I throw at it, can't a D compiler?
You misunderstand, its hardcoded into the CTFE evaluator. That is what an intrinsic is.
Dec 31 2015
parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Rikki Cattermole wrote:

 You misunderstand, its hardcoded into the CTFE evaluator. That is what
 an intrinsic is.
What do you mean hardcoded into the CTFE evaluator? Surely you aren't suggesting that the D compiler contains its own implementation of the functions already implemented in libc? --
Dec 31 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 01/01/16 1:29 AM, Shriramana Sharma wrote:
 Rikki Cattermole wrote:

 You misunderstand, its hardcoded into the CTFE evaluator. That is what
 an intrinsic is.
What do you mean hardcoded into the CTFE evaluator? Surely you aren't suggesting that the D compiler contains its own implementation of the functions already implemented in libc?
Yes and no. It has a small subset of functions which it consider intrinsics. Intrinsics are only a way to tell the compiler hey go call x and give me the result. Remember, if you don't have the source you can't execute it. Unless you provide an escape hatch which is what intrinsics are.
Dec 31 2015
prev sibling parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Shriramana Sharma wrote:

 What I desire to do is be able to call a C library from a D template like
 octal to compute a string at compile time.
To be more explicit, I wrote a library in C since it's much leaner size-wise than the D code (although admittedly much *much* more tedious to write especially with all those string manipulations) and since it's callable from other languages like Python too. None of those other languages have CTFE AFAICS. I would like to provide at least the D wrapper to the C library with a template which will enable CTFE computation via the library (it's just a string to string conversion). But the D compiler is complaining that it cannot call the C function at compile time even though the library is installed under /usr/local/lib and Python is able to access it via CTypes. Please help! --
Dec 31 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 01/01/16 1:11 AM, Shriramana Sharma wrote:
 Shriramana Sharma wrote:

 What I desire to do is be able to call a C library from a D template like
 octal to compute a string at compile time.
To be more explicit, I wrote a library in C since it's much leaner size-wise than the D code (although admittedly much *much* more tedious to write especially with all those string manipulations) and since it's callable from other languages like Python too. None of those other languages have CTFE AFAICS. I would like to provide at least the D wrapper to the C library with a template which will enable CTFE computation via the library (it's just a string to string conversion). But the D compiler is complaining that it cannot call the C function at compile time even though the library is installed under /usr/local/lib and Python is able to access it via CTypes. Please help!
As I said its just not possible. Either port it to D and extern(C) it so it is accesible from other languages or not have CTFE support.
Dec 31 2015
parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Rikki Cattermole wrote:

 Either port it to D and extern(C) it so it is accesible from other
 languages or not have CTFE support.
I already wrote it in D, then I ported to C with much effort. The option to extern(C)-ing it didn't occur to me. :-( Also, the D version is really much too bulky. I suppose I could always maintain both the C and D versions separately. --
Jan 01 2016
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 01/01/16 11:15 PM, Shriramana Sharma wrote:
 Rikki Cattermole wrote:

 Either port it to D and extern(C) it so it is accesible from other
 languages or not have CTFE support.
I already wrote it in D, then I ported to C with much effort. The option to extern(C)-ing it didn't occur to me. :-( Also, the D version is really much too bulky. I suppose I could always maintain both the C and D versions separately.
How exactly is a D version more bulky then C? After all everything C can do, D can do with a very similar syntax.
Jan 01 2016
parent Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Rikki Cattermole wrote:

 How exactly is a D version more bulky then C?
 After all everything C can do, D can do with a very similar syntax.
Source-code wise D is much leaner than C, obviously, but object-code wise it is *huge* even with dynamically linking Phobos: The binary size of compiling my C version is 20271 and that of the D version with exact same functionality is 1031061. I thought maybe it's because I'm using a few ctRegex-es and that's getting included into the source code, but using ordinary regex actually increases the size to 1112343. I suppose 1 MB is not a big deal these days, and if I cared about quick programming and not worry about buffer overflows, I have to sacrifice *something*, but still comparing to C, I can't help but feel that most of that 1 MB is functionality that the program never uses but I'm not expert enough to find out. If DMD had something like -fdata-sections -ffunction- sections, passing --gc-sections might be able to slim that down, I dunno... --
Jan 01 2016
prev sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
On Thursday, 31 December 2015 at 11:52:01 UTC, Shriramana Sharma 
wrote:
 Using DMD 2.0.69.2, the following code:

 extern (C) double sqrt(double x);
 enum q = sqrt(4.0);

 gives the error:

 Error: sqrt cannot be interpreted at compile time, because it 
 has no available source code

 But if I do:

 import std.math;
 enum q = sqrt(4.0);

 There is no problem. So two questions:

 1) Why exactly can't the compiler call a C function at compile 
 time whereas it can call a D function?

 2) <same as above> ... which itself only in the end calls that 
 very same C function IIANM?

 I see druntime/import/core/math.d l 91:

 double sqrt(double x);  /* intrinsic */
No you can't call your own C function with CTFE. I do not say it is not possible to implement this in dmd compiler, but IMHO it is not something too much usefull
Dec 31 2015