www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CTFE attribute

reply Manu <turkeyman gmail.com> writes:
--20cf30363f3562c79404b797bc3c
Content-Type: text/plain; charset=UTF-8

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...

--20cf30363f3562c79404b797bc3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This has come up lots of times before.. I just wanted to effectively +1 thi=
s request.<div><br></div><div>I have some templates, and some reasonably co=
mplex functions I use strictly via CTFE to produce enums and evaluate condi=
tions within the templates.</div>
<div>When I build my code, I notice that the CTFE functions, which are neve=
r referenced in any runtime code, are still present in the object file.</di=
v><div>Additionally, one of these functions requires I import std.string, w=
hich is only used in CTFE code, and is otherwise a pointless import.</div>
<div><br></div><div>I&#39;d certainly like to be able to mark these functio=
ns CTFE to be sure no runtime code will ever be generated for them, and als=
o, what can I do about CTFE imports? I don&#39;t want that import in my bin=
ary...</div>

--20cf30363f3562c79404b797bc3c--
Jan 28 2012
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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/
Jan 28 2012
parent reply Robert Clipsham <robert octarineparrot.com> writes:
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/
Jan 28 2012
parent reply Mehrdad <wfunction hotmail.com> writes:
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

Jan 28 2012
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Mehrdad" <wfunction hotmail.com> wrote in message 
news:jg1469$4a6$1 digitalmars.com...


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.
Jan 28 2012
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Mehrdad:

 Why isn't it a constant? o.O

Unspecified implementation difficulties. Bye, bearophile
Jan 28 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--002354470e0cbd547d04b7980c95
Content-Type: text/plain; charset=UTF-8

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? --002354470e0cbd547d04b7980c95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 28 January 2012 17:03, Robert Clipsham <span = dir=3D"ltr">&lt;<a href=3D"mailto:robert octarineparrot.com">robert octarin= eparrot.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 28/01/2012 14:50, Manu wrote:<br=

x #ccc solid;padding-left:1ex"> This has come up lots of times before.. I just wanted to effectively +1<br> this request.<br> <br> I have some templates, and some reasonably complex functions I use<br> strictly via CTFE to produce enums and evaluate conditions within the<br> templates.<br> When I build my code, I notice that the CTFE functions, which are never<br> referenced in any runtime code, are still present in the object file.<br> Additionally, one of these functions requires I import std.string, which<br=

<br> I&#39;d certainly like to be able to mark these functions CTFE to be sure n= o<br> runtime code will ever be generated for them, and also, what can I do<br> about CTFE imports? I don&#39;t want that import in my binary...<br> </blockquote> <br></div></div> There are a couple of things you can do. The first is to make the imports f= unction local, the second is:<br> <br> <a href=3D"http://www.digitalmars.com/d/archives/digitalmars/D/Incremental_= compilation_with_DMD_96138.html#N96337" target=3D"_blank">http://www.digita= lmars.com/d/<u></u>archives/digitalmars/D/<u></u>Incremental_compilation_wi= th_<u></u>DMD_96138.html#N96337</a><br> <br> You&#39;ll notice that thread mentions a pragma(ctfe) patch for DMD, that&#= 39;s another option, though would require a patched compiler. I can&#39;t s= eem to find a link to that patch, a bit of googling should help though.<br> <br> Another idea I&#39;ve just had:<br> <br> T myComplexFuntion()<br> {<br> =C2=A0if (__ctfe)<br> =C2=A0{<br> =C2=A0 =C2=A0 // Implement here<br> =C2=A0}<br> =C2=A0else<br> =C2=A0{<br> =C2=A0 =C2=A0assert(0);<br> =C2=A0}<br> }<br> <br> This should allow the function to be inlined to assert(0); if it&#39;s call= ed at runtime, so while it will still exist in the binary, it won&#39;t int= roduce lots of additional bloat.</blockquote><div><br></div><div>Sweet, I&#= 39;ll do that for now.=C2=A0</div> <div>You mean static if() right?</div></div> --002354470e0cbd547d04b7980c95--
Jan 28 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 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.
Jan 28 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 28 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2012 11:02 AM, Manu wrote:
 I'd also like an error if the function were called outside of CTFE...

if (!ctfe) assert(0);
Jan 28 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2012 12:38 PM, Walter Bright wrote:
 On 1/28/2012 11:02 AM, Manu wrote:
 I'd also like an error if the function were called outside of CTFE...

if (!ctfe) assert(0);

Oops, if (!__ctfe) assert(0);
Jan 28 2012
prev sibling parent Don Clugston <dac nospam.com> writes:
On 28/01/12 19:39, Walter Bright 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.

The problem is how to prevent the moduleinfo from getting linked in. Though this is a general problem, not specific to CTFE. One thing I have been considering is, if a template is only ever instantiated in CTFE (eg in a static if, or while defining an enum value), should it still get written into the obj file? I don't think it is ever necessary, and discarding it would save a lot of space and time.
Jan 30 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--002354470e0c64baba04b79b423d
Content-Type: text/plain; charset=UTF-8

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. --002354470e0c64baba04b79b423d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 28 January 2012 20:39, Walter Bright <span di= r=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digi= talmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 1/28/2012 6:50 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I&#39;d certainly like to be able to mark these functions CTFE to be sure n= o runtime<br> code will ever be generated for them, and also, what can I do about CTFE<br=

</blockquote> <br></div> Being in your object file doesn&#39;t mean they make it into the binary. Op= tlink, for example, will remove unreferenced COMDATs.<br> </blockquote></div><br><div>I still don&#39;t want it polluting my lib, and= I also don&#39;t want the possibility that someone COULD link to it. It&#3= 9;s simply not runtime code.</div><div>Additionally, while the code is stil= l present in my lib, so must be the import that it makes use of...</div> <div><br></div><div>I&#39;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.</div> --002354470e0c64baba04b79b423d--
Jan 28 2012
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 28 January 2012 at 19:02:56 UTC, Manu wrote:
 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.

You could make it private, and expose it via a template. template foo(ARGS...) { enum foo = fooImpl!(ARGS)(); } private auto fooImpl(ARGS...)() { // ... } Phobos uses this idiom often, but mainly because CTFE is more flexible that template metaprogramming. Additionally, simply making the function templated would prevent it from ending up in your library's object file. You can make any regular function templated with an empty template parameter list: void foo()(...) { ... }
Jan 28 2012
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 28.01.2012, 16:42 Uhr, schrieb Trass3r <un known.com>:

 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.

I've recently fucked up my first executable with that. -L--gc-sections had the effect as if 'throw' was a no-op. In other words runtime exceptions are silently ignored. If you use it double-check that exceptions are still thrown!
Jan 29 2012