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