Based on what your actual problem is -- it seems like you need to
refactor your code a little. Also, you should trust that the
compiler optimizes correctly.
eg.
if( valueMeta.isValid && pointersSupported) should be optimized out
when pointerSupported == false and the comparison of it shou
On Sun, Nov 24, 2013 at 9:44 PM, Jacob Carlborg wrote:
> On 2013-11-24 21:14, Philippe Sigaud wrote:
>
>> If features are coupled, I see no easy way out.
>
>
> I suspected that. They not so much coupled with each other, rather coupled
> with the default functionality that will always be there.
I
On 2013-11-24 21:14, Philippe Sigaud wrote:
If features are coupled, I see no easy way out.
I suspected that. They not so much coupled with each other, rather
coupled with the default functionality that will always be there.
If references are not supported, you want the else clause all by
>Unfortunately this looks like it works best when providing fairly separate
>features
> that doesn't interact with each other or the main functionality.
If features are coupled, I see no easy way out.
> http://pastebin.com/XYGtTarn
>
> Lines 19-25, 34-37 and 42 are only needed if pointers are s
On 2013-11-24 14:18, Jacob Carlborg wrote:
Does anyone know a good way of composing features at compile time? Say I
have a struct or class that I want to support different features that
are configurable at compile time. One way would be to just pass in a
couple of boolean flags and use static-if
On 2013-11-24 20:53, Philippe Sigaud wrote:
Hmm. Then you still need to define where the policy will act. OK, I
can get that. I thought the OP wanted something more flexible, where
different loggers could inject code at many different places.
But if there is no Logging policy asked for (the use
On 2013-11-24 19:28, Dejan Lekic wrote:
Jakob, whenever I need something like you describe, I do more/less the same what
is described on this Wikipedia page:
http://en.wikipedia.org/wiki/Composition_over_inheritance . C# example is
exactly how I do this (in Java and D).
Unfortunately this look
On Sunday, 24 November 2013 at 19:37:44 UTC, Jacob Carlborg wrote:
So StubLogger would implement "info" but do nothing? How good
would the compiler be at optimizing this?
Last time I checked such stuff LDC is quite capable at
eliminating it completely. It works somewhat better for
state-less
On Sun, Nov 24, 2013 at 6:25 PM, Dicebot wrote:
> On Sunday, 24 November 2013 at 14:23:55 UTC, Philippe Sigaud wrote:
>>
>> But how do you use policies to inject different code in different
>> places of your struct?
>
>
> Don't really get the question. Isn't it what policies do pretty much by
> de
On 2013-11-24 18:31, Dicebot wrote:
To clarify, OP example will look like this:
class Foo (alias Logger)
if (isLoggger!Logger)
{
private Logger logger;
this ()
{
logger = new Logger;
}
void action ()
{
logger.info("performing action
Jacob Carlborg wrote:
> Does anyone know a good way of composing features at compile time? Say I
> have a struct or class that I want to support different features that
> are configurable at compile time. One way would be to just pass in a
> couple of boolean flags and use static-i
On Sunday, 24 November 2013 at 17:25:49 UTC, Dicebot wrote:
Don't really get the question. Isn't it what policies do pretty
much by definition? You decompose part of target functionality
into smaller blocks with optional behavior (including no-op
behavior) and provide specific ones as alias par
On Sunday, 24 November 2013 at 14:23:55 UTC, Philippe Sigaud
wrote:
But how do you use policies to inject different code in
different
places of your struct?
Don't really get the question. Isn't it what policies do pretty
much by definition? You decompose part of target functionality
into sma
But how do you use policies to inject different code in different
places of your struct?
On Sun, Nov 24, 2013 at 3:15 PM, Dicebot wrote:
> Well you can make one step forward and use policy-based design as described
> in Andrei's old C++ book ;) (replace boolean flags with template aliases to
> mi
Well you can make one step forward and use policy-based design as
described in Andrei's old C++ book ;) (replace boolean flags with
template aliases to mixin, providing stub ones for "false") It
does not fix `static-if` sequence but scales better in terms of
configurability.
> Unfortunately logging and events were more of an example, for the real usage
Ah then, you can discard my own proposals. Only #3 is still possible.
Try not to think to much of AST macros :-)
The general problem is to inject code at predetermined points. As Rémy
said, that should remind us of AOP.
I have three other very vague ideas ;-) Not tested in any way.
#1) Create a wrapper, say Interceptor!(Foo, "__ctor", "bar").
Interceptor will act as a Foo, except it will have hooks that are
On 2013-11-24 15:06, "Rémy Mouëza" wrote:
This looks like a case study for aspect oriented programming: several
separated concerns that start to intertwine within your code; if left
unchecked this could result in some messy code.
In Python, I used reflection and "magic" things and have already u
C, Jacob Carlborg wrote:
Does anyone know a good way of composing features at compile
time? Say I have a struct or class that I want to support
different features that are configurable at compile time. One
way would be to just pass in a couple of boolean flags and use
static-if, like this:
class F
Does anyone know a good way of composing features at compile time? Say I
have a struct or class that I want to support different features that
are configurable at compile time. One way would be to just pass in a
couple of boolean flags and use static-if, like this:
class Foo (bool logging
20 matches
Mail list logo
