Jump to page: 1 2
Thread overview
CTFE attribute
Jan 28, 2012
Manu
Jan 28, 2012
Robert Clipsham
Jan 28, 2012
Manu
Jan 28, 2012
Robert Clipsham
Jan 28, 2012
Mehrdad
Jan 28, 2012
Daniel Murphy
Jan 28, 2012
bearophile
Jan 28, 2012
Trass3r
Jan 29, 2012
Marco Leise
Jan 28, 2012
Walter Bright
Jan 28, 2012
Manu
Jan 28, 2012
Vladimir Panteleev
Jan 28, 2012
Walter Bright
Jan 28, 2012
Walter Bright
Jan 30, 2012
Don Clugston
January 28, 2012
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
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
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
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
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
"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
Mehrdad:

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

Unspecified implementation difficulties.

Bye,
bearophile
January 28, 2012
> 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
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
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