December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On Sat, 31 Dec 2011 03:40:43 +0200, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> Take a pick of any examples posted on this ML. They are far better
> fit to use as a test bed. Ideally one that does number crunching and
> can't be easily folded away.
I don't understand your point btw, why it shouldn't be easily folded away?
@inline is exactly for that reason, why would i pay for something i don't want?
|
December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | On 12/30/2011 5:59 PM, so wrote:
> Well not them but another dummy function, i didn't think it would differ this much.
It differs that much because once it is inlined, the optimizer deletes it because it does nothing.
I don't think it is a valid test.
|
December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sat, 31 Dec 2011 04:30:01 +0200, Walter Bright <newshound2@digitalmars.com> wrote:
> On 12/30/2011 5:59 PM, so wrote:
>> Well not them but another dummy function, i didn't think it would differ this much.
>
> It differs that much because once it is inlined, the optimizer deletes it because it does nothing.
>
> I don't think it is a valid test.
Yes i can see from asm output but are we talking about same thing?
@inline IS all about that. We can try it with any example, one outperforming the other is not the point.
for(....)
fun()
With or without @inline i know fun should/will get folded away, then why should i pay for the function call?
|
December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 12/31/2011 03:16 AM, Andrei Alexandrescu wrote:
> On 12/30/11 6:25 PM, Timon Gehr wrote:
>> I'd be happy to extend the system, but currently I don't see it fall
>> short any of the three requirements. Can you help me out?
>
> I think it would be great to reproduce the expansion semantics of ddoc.
>
> Andrei
So basically, just breaking infinite recursion on recursive identical instantiations?
In what way does such a feature improve the expressiveness of the macro system?
|
December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | On 12/30/2011 6:35 PM, so wrote:
> With or without @inline i know fun should/will get folded away, then why should
> i pay for the function call?
Because if the function did anything useful, the overhead of the function call is insignificant.
I don't think that dealing with large, complex functions that do nothing merits a language extension.
|
December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 12/30/2011 6:59 PM, Timon Gehr wrote: > On 12/31/2011 03:16 AM, Andrei Alexandrescu wrote: >> On 12/30/11 6:25 PM, Timon Gehr wrote: >>> I'd be happy to extend the system, but currently I don't see it fall >>> short any of the three requirements. Can you help me out? >> >> I think it would be great to reproduce the expansion semantics of ddoc. >> >> Andrei > > So basically, just breaking infinite recursion on recursive identical > instantiations? > > In what way does such a feature improve the expressiveness of the macro system? Because inevitably someone will write: #define FOO a + FOO and expect it to work (the correct expansion would be "a + FOO", not a stack overflow). The C preprocessor works this way, as do makefile macros, as Ddoc does. |
December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 12/31/2011 04:50 AM, Walter Bright wrote:
> On 12/30/2011 6:59 PM, Timon Gehr wrote:
>> On 12/31/2011 03:16 AM, Andrei Alexandrescu wrote:
>>> On 12/30/11 6:25 PM, Timon Gehr wrote:
>>>> I'd be happy to extend the system, but currently I don't see it fall
>>>> short any of the three requirements. Can you help me out?
>>>
>>> I think it would be great to reproduce the expansion semantics of ddoc.
>>>
>>> Andrei
>>
>> So basically, just breaking infinite recursion on recursive identical
>> instantiations?
>>
>> In what way does such a feature improve the expressiveness of the
>> macro system?
>
> Because inevitably someone will write:
>
> #define FOO a + FOO
>
> and expect it to work (the correct expansion would be "a + FOO", not a
> stack overflow). The C preprocessor works this way, as do makefile
> macros, as Ddoc does.
Makes sense, but why is it an issue if expansion is explicit?
enum FOO = q{a + FOO};
mixin(FOO);
|
December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 12/30/2011 8:02 PM, Timon Gehr wrote:
> On 12/31/2011 04:50 AM, Walter Bright wrote:
>> Because inevitably someone will write:
>>
>> #define FOO a + FOO
>>
>> and expect it to work (the correct expansion would be "a + FOO", not a
>> stack overflow). The C preprocessor works this way, as do makefile
>> macros, as Ddoc does.
>
> Makes sense, but why is it an issue if expansion is explicit?
>
> enum FOO = q{a + FOO};
>
> mixin(FOO);
Because the expanded text is then rescanned for further macro replacement.
|
December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 12/31/2011 05:19 AM, Walter Bright wrote:
> On 12/30/2011 8:02 PM, Timon Gehr wrote:
>> On 12/31/2011 04:50 AM, Walter Bright wrote:
>>> Because inevitably someone will write:
>>>
>>> #define FOO a + FOO
>>>
>>> and expect it to work (the correct expansion would be "a + FOO", not a
>>> stack overflow). The C preprocessor works this way, as do makefile
>>> macros, as Ddoc does.
>>
>> Makes sense, but why is it an issue if expansion is explicit?
>>
>> enum FOO = q{a + FOO};
>>
>> mixin(FOO);
>
> Because the expanded text is then rescanned for further macro replacement.
>
Yes, but in q{a + FOO} there is none.
|
December 31, 2011 Re: System programming in D (Was: The God Language) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 12/30/2011 8:34 PM, Timon Gehr wrote: > On 12/31/2011 05:19 AM, Walter Bright wrote: >> On 12/30/2011 8:02 PM, Timon Gehr wrote: >>> On 12/31/2011 04:50 AM, Walter Bright wrote: >>>> Because inevitably someone will write: >>>> >>>> #define FOO a + FOO >>>> >>>> and expect it to work (the correct expansion would be "a + FOO", not a >>>> stack overflow). The C preprocessor works this way, as do makefile >>>> macros, as Ddoc does. >>> >>> Makes sense, but why is it an issue if expansion is explicit? >>> >>> enum FOO = q{a + FOO}; >>> >>> mixin(FOO); >> >> Because the expanded text is then rescanned for further macro replacement. >> > > Yes, but in q{a + FOO} there is none. #define FOO a+Foo FOO; What is the text after macro expansion? |
Copyright © 1999-2021 by the D Language Foundation