View mode: basic / threaded / horizontal-split · Log in · Help
January 28, 2012
CTFE attribute
This has come up lots of times before.. I just wanted to effectively +1
this request.

I have some templates, and some reasonably complex functions I use strictly
via CTFE to produce enums and evaluate conditions within the templates.
When I build my code, I notice that the CTFE functions, which are never
referenced in any runtime code, are still present in the object file.
Additionally, one of these functions requires I import std.string, which is
only used in CTFE code, and is otherwise a pointless import.

I'd certainly like to be able to mark these functions CTFE to be sure no
runtime code will ever be generated for them, and also, what can I do about
CTFE imports? I don't want that import in my binary...
January 28, 2012
Re: CTFE attribute
On 28/01/2012 14:50, Manu wrote:
> This has come up lots of times before.. I just wanted to effectively +1
> this request.
>
> I have some templates, and some reasonably complex functions I use
> strictly via CTFE to produce enums and evaluate conditions within the
> templates.
> When I build my code, I notice that the CTFE functions, which are never
> referenced in any runtime code, are still present in the object file.
> Additionally, one of these functions requires I import std.string, which
> is only used in CTFE code, and is otherwise a pointless import.
>
> I'd certainly like to be able to mark these functions CTFE to be sure no
> runtime code will ever be generated for them, and also, what can I do
> about CTFE imports? I don't want that import in my binary...

There are a couple of things you can do. The first is to make the 
imports function local, the second is:

http://www.digitalmars.com/d/archives/digitalmars/D/Incremental_compilation_with_DMD_96138.html#N96337

You'll notice that thread mentions a pragma(ctfe) patch for DMD, that's 
another option, though would require a patched compiler. I can't seem to 
find a link to that patch, a bit of googling should help though.

Another idea I've just had:

T myComplexFuntion()
{
  if (__ctfe)
  {
     // Implement here
  }
  else
  {
    assert(0);
  }
}

This should allow the function to be inlined to assert(0); if it's 
called at runtime, so while it will still exist in the binary, it won't 
introduce lots of additional bloat.

-- 
Robert
http://octarineparrot.com/
January 28, 2012
Re: CTFE attribute
On 28 January 2012 17:03, Robert Clipsham <robert@octarineparrot.com> wrote:

> On 28/01/2012 14:50, Manu wrote:
>
>> This has come up lots of times before.. I just wanted to effectively +1
>> this request.
>>
>> I have some templates, and some reasonably complex functions I use
>> strictly via CTFE to produce enums and evaluate conditions within the
>> templates.
>> When I build my code, I notice that the CTFE functions, which are never
>> referenced in any runtime code, are still present in the object file.
>> Additionally, one of these functions requires I import std.string, which
>> is only used in CTFE code, and is otherwise a pointless import.
>>
>> I'd certainly like to be able to mark these functions CTFE to be sure no
>> runtime code will ever be generated for them, and also, what can I do
>> about CTFE imports? I don't want that import in my binary...
>>
>
> There are a couple of things you can do. The first is to make the imports
> function local, the second is:
>
> http://www.digitalmars.com/d/**archives/digitalmars/D/**
> Incremental_compilation_with_**DMD_96138.html#N96337<http://www.digitalmars.com/d/archives/digitalmars/D/Incremental_compilation_with_DMD_96138.html#N96337>
>
> You'll notice that thread mentions a pragma(ctfe) patch for DMD, that's
> another option, though would require a patched compiler. I can't seem to
> find a link to that patch, a bit of googling should help though.
>
> Another idea I've just had:
>
> T myComplexFuntion()
> {
>  if (__ctfe)
>  {
>     // Implement here
>  }
>  else
>  {
>    assert(0);
>  }
> }
>
> This should allow the function to be inlined to assert(0); if it's called
> at runtime, so while it will still exist in the binary, it won't introduce
> lots of additional bloat.


Sweet, I'll do that for now.
You mean static if() right?
January 28, 2012
Re: CTFE attribute
On 28/01/2012 15:13, Manu wrote:
> Sweet, I'll do that for now.
> You mean static if() right?

No, I mean if().

__ctfe is a magic variable, and during CTFE it is true, at run time it 
is false. As it is a variable and not a constant, it cannot be read at 
compile time, so static if() won't work.

See also:
http://dlang.org/function ctrl+f for __ctfe

-- 
Robert
http://octarineparrot.com/
January 28, 2012
Re: CTFE attribute
On 1/28/2012 7:24 AM, Robert Clipsham wrote:
> On 28/01/2012 15:13, Manu wrote:
>> Sweet, I'll do that for now.
>> You mean static if() right?
>
> No, I mean if().
>
> __ctfe is a magic variable, and during CTFE it is true, at run time it 
> is false. As it is a variable and not a constant, it cannot be read at 
> compile time, so static if() won't work.
>
> See also:
> http://dlang.org/function ctrl+f for __ctfe
>
Why isn't it a constant? o.O
January 28, 2012
Re: CTFE attribute
"Mehrdad" <wfunction@hotmail.com> wrote in message 
news:jg1469$4a6$1@digitalmars.com...
>>
> Why isn't it a constant? o.O

It isn't a compile-time constant, it is constant.

You need to use if, not static if, because code versioned out with static if 
does not get processed in the compiler beyond parsing.  It needs to be done 
with a normal code branch that is always taken when in the interpreter but 
never taken at runtime.
January 28, 2012
Re: CTFE attribute
Mehrdad:

> Why isn't it a constant? o.O

Unspecified implementation difficulties.

Bye,
bearophile
January 28, 2012
Re: CTFE attribute
> When I build my code, I notice that the CTFE functions, which are never
> referenced in any runtime code, are still present in the object file.

For now you can get rid of it with -L--gc-sections (or LTO).
gdc also needs -ffunction-sections -fdata-sections.
January 28, 2012
Re: CTFE attribute
On 1/28/2012 6:50 AM, Manu wrote:
> I'd certainly like to be able to mark these functions CTFE to be sure no runtime
> code will ever be generated for them, and also, what can I do about CTFE
> imports? I don't want that import in my binary...

Being in your object file doesn't mean they make it into the binary. Optlink, 
for example, will remove unreferenced COMDATs.
January 28, 2012
Re: CTFE attribute
On 28 January 2012 20:39, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/28/2012 6:50 AM, Manu wrote:
>
>> I'd certainly like to be able to mark these functions CTFE to be sure no
>> runtime
>> code will ever be generated for them, and also, what can I do about CTFE
>> imports? I don't want that import in my binary...
>>
>
> Being in your object file doesn't mean they make it into the binary.
> Optlink, for example, will remove unreferenced COMDATs.
>

I still don't want it polluting my lib, and I also don't want the
possibility that someone COULD link to it. It's simply not runtime code.
Additionally, while the code is still present in my lib, so must be the
import that it makes use of...

I'd also like an error if the function were called outside of CTFE... so
the CTFE attribute others have discussed seems like a good idea to me.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home