> I had forgotten about this bug where initializers aren't inlined. Everything works fine if you replace
>      int i = flip(0xFE);
> with
>      int i;
>      i = flip(0xFE);
> or if you hadn't used a variable at all and instead just wrote
> writef("%d\n", flip(0xFE));
> 
> Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.
> 
> -Ben 
> 
> 
Not quite fine - the function gets inlined, and called with the parameter 0xFE.  This correctly gets converted to 0x7F, but it gets converted at runtime, not compiletime.

Brad

Aleksey Bobnev wrote:
>>Though I think the syntax is on the clunky side :)
> 
> 
> The better way:
> 
> template Foo(int n)
> {
>      const int Foo = n - 1;
> }
> 
> const int test = Foo!(10);
> 
> 
Ah, much nicer.  I thought there should be a way to do that, but didn't know the template syntax well enough.

Brad

"brad beveridge" <brad@nowhere.com> wrote in message news:cvij05$1mdo$1@digitaldaemon.com...
>
>> I had forgotten about this bug where initializers aren't inlined.
>> Everything works fine if you replace
>>      int i = flip(0xFE);
>> with
>>      int i;
>>      i = flip(0xFE);
>> or if you hadn't used a variable at all and instead just wrote
>> writef("%d\n", flip(0xFE));
>>
>> Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.
>>
>> -Ben
> Not quite fine - the function gets inlined, and called with the parameter 0xFE.  This correctly gets converted to 0x7F, but it gets converted at runtime, not compiletime.
>
> Brad

Did you pass the -inline and -O flags to the compiler? When I tell the compiler to inline and optimize it does everything at compile time (except with the initiliazer bug). Without those flags it doesn't.

Ben Hinkle wrote:
> "brad beveridge" <brad@nowhere.com> wrote in message news:cvij05$1mdo$1@digitaldaemon.com...
> 
>>>I had forgotten about this bug where initializers aren't inlined. Everything works fine if you replace
>>>     int i = flip(0xFE);
>>>with
>>>     int i;
>>>     i = flip(0xFE);
>>>or if you hadn't used a variable at all and instead just wrote
>>>writef("%d\n", flip(0xFE));
>>>
>>>Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.
>>>
>>>-Ben
>>
>>Not quite fine - the function gets inlined, and called with the parameter 0xFE.  This correctly gets converted to 0x7F, but it gets converted at runtime, not compiletime.
>>
>>Brad
> 
> 
> Did you pass the -inline and -O flags to the compiler? When I tell the compiler to inline and optimize it does everything at compile time (except with the initiliazer bug). Without those flags it doesn't. 
> 
> 
My apologies - you are correct.  I wasn't using the -O flag.  Though the initialiser not inlining/optimising thing is annoying.

Brad

In article <cvi17n$ubp$1@digitaldaemon.com>, Ben Hinkle says...
>I had forgotten about this bug where initializers aren't inlined. Everything works fine if you replace
>     int i = flip(0xFE);
>with
>     int i;
>     i = flip(0xFE);
>or if you hadn't used a variable at all and instead just wrote
>writef("%d\n", flip(0xFE));
>
>Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.


I'll second that ~ such thing can cause much wailing, and gnashing of teeth.

- Kris

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:cvi17n$ubp$1@digitaldaemon.com...
>
> "brad beveridge" <brad@nowhere.com> wrote in message news:cvhc9r$1vm$1@digitaldaemon.com...
> > brad beveridge wrote:
> >>
> >>> That's ok - trusting the compiler can be risky. Though if dmd's
inlining
> >>> and constant folding can't produce the same result in your case as a C
> >>> compiler would then Walter needs to spend some time and fix that.
> >>> See also http://www.digitalmars.com/d/htomodule.html the section about
> >>> macros and http://www.digitalmars.com/d/pretod.html the section about
> >>> macros.
> >>> Inlining is your friend!
> >>
> >>
> >> That's good to hear, and it is what I expected.  I had thought that
what
> >> might happen is
> >> 1) Constant folding occurs (ie, 0xF0 - this is as reduced as it can
get)
> >> 2) Inlining occurs, the ~ operation still has to happen on 0xF0.
> >> But if constant folding occurs after inlining, then everything is OK.
If
> >> I am feeling particularly bored I might need to look at the assembler output.
> >>
> >> I think the template method is closer to what I am wanting.
> >>
> >> Brad
> > As much as replying to my own post is poor form, here I am doing it. The
> > following code illustrates both methods
> > 1) Inlining a function call of a constant
> > 2) Generating a constant with a template
> > The bad news is that you were wrong Ben :)
> > (1) doesn't give optimal results
> > (2) does
> > D doesn't inline & then fold constants.  Which makes sense - I don't
know
> > much about compilers/optimisers, but I expect that an optimiser would
need
> > to be very smart to decide "hey, this function has constant inputs,
maybe
> > I should evaluate it at compile time and see if I can give it a constant output"
> >
> > Anyhow, here is some sample code.  A little grovelling through the assembler output shows what is going on.
> >
> > Brad
> >
> > import std.stdio;
> >
> > int flip(int x)
> > {
> >     return ( ((x & 0x80) >> 7) |
> >                           ((x & 0x40) >> 5) |
> >                           ((x & 0x20) >> 3) |
> >                           ((x & 0x10) >> 1) |
> >                           ((x & 0x08) << 1) |
> >                           ((x & 0x04) << 3) |
> >                           ((x & 0x02) << 5) |
> >                           ((x & 0x01) << 7) );
> > }
> >
> > template tflip(int x)
> > {
> >     const int val = ( ((x & 0x80) >> 7) |
> >                           ((x & 0x40) >> 5) |
> >                           ((x & 0x20) >> 3) |
> >                           ((x & 0x10) >> 1) |
> >                           ((x & 0x08) << 1) |
> >                           ((x & 0x04) << 3) |
> >                           ((x & 0x02) << 5) |
> >                           ((x & 0x01) << 7) );
> >
> > }
> >
> > void main()
> > {
> >     // comment these lines in/out to show that constant folding happens
> >     // before inlining.
> >
> >     // sub-optimal behaviour, the flip function is called and 0xFE
> >     // is bit flipped at runtime
> >     // note, you cannot have this int "const"
> >     //int i = flip(0xFE);
> >
> >     // optimal method - the template is evaluated at compile time
> >     // and i evaluates to 0x7F, as is correct
> >     //const int i = tflip!(0xFE).val;
> >     writef("%d\n", i);
> > }
>
> I had forgotten about this bug where initializers aren't inlined.
Everything
> works fine if you replace
>      int i = flip(0xFE);
> with
>      int i;
>      i = flip(0xFE);
> or if you hadn't used a variable at all and instead just wrote
> writef("%d\n", flip(0xFE));
>
> Walter, is that bug fixable? It's very natural to want to put inlinable expressions in initializers.

Yes.

brad@domain.invalid wrote:
> I'm just looking at a couple of projects, and wondering how I can convert them to D.  The point of these macros to to translate a human readable value to something that is hardware specific.  The details aren't too specific, but the macros convert from one constant form to another [...]

> I really feel like this would be a powerful addition to D (if it doesn't already support it).  If it does support it - how can I do it?

Sure does.  Try this:

    version = INVERT_COMMANDS;

    version (INVERT_COMMANDS) {
        template INVERT(int I) {
            const int INVERT = ~I;
        }

    } else {
        template INVERT(int I) {
            const int INVERT = I;
        }
    }

    version = FLIP_COMMANDS;

    version (FLIP_COMMANDS) {
        template FLIP(int X) {
            const int FLIP =
                ((x & 0x80) >> 7) |
                ((x & 0x40) >> 5) |
                ((x & 0x20) >> 3) |
                ((x & 0x10) >> 1) |
                ((x & 0x08) << 1) |
                ((x & 0x04) << 3) |
                ((x & 0x02) << 5) |
                ((x & 0x01) << 7) )
            ;
        }

    } else {
        template FLIP(int X) {
            const int FLIP = X;
        }
    }

    const int SOME_COMMAND = INVERT!(FLIP!(0xE0) & 0xFF);

 -- andy

Derek Parnell <derek@psych.ward> wrote:

[...]
> I've occasionally thought that a write-once type of variable would be a useful addition to a language.

sather has `once' parameters

<cite href="http://www.icsi.berkeley.edu/
~sather/Documentation/LanguageDescription/webmaker/DescriptionX2Eiter
ators-chapte-1.html#HEADING1-36">
Arguments which are marked with the mode 'once' are only evaluated
the first time they are encountered during a loop execution.
</cite>

And "once" variables are easily done in D with properties:

<example>
private:
  int m= void;
  bit assigned= false;
public:
  int i(){
    if( assigned)
      return m;
    else
      throw new Exception;
  }
  int i( int value){
    if( assigned)
      throw new Exception;
    else {
      m= value;
      assigned= true;
    }
  }
</example>