September 26, 2012 Re: Function prototype + definition in the same file | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix Attachments:
| On 26 September 2012 13:09, deadalnix <deadalnix@gmail.com> wrote:
> Le 26/09/2012 10:14, Manu a écrit :
>
>> On 26 September 2012 02:35, Timon Gehr <timon.gehr@gmx.ch <mailto:timon.gehr@gmx.ch>> wrote:
>>
>> On 09/26/2012 01:29 AM, Timon Gehr wrote:
>>
>> On 09/25/2012 01:53 PM, Manu wrote:
>>
>> So I have this recurring pattern, it's really starting to
>> annoy me.
>> It stems from the fact that a function prototype and the
>> definition can
>> not appear in the same file in D (as it can in C/C++)
>> Eg,
>>
>> void func(int x); // <-- declaration of function, informs
>> type and
>> associated names, args, ...
>>
>> //later
>> void func(int x) // <-- may be generated with magic (and may
>> use the
>> prototype declaration for type information as declared by
>> the prototype
>> above)
>> {
>> ... do stuff
>> }
>>
>> I really need this. Why is it illegal? Is there chance of
>> having this
>> supported? What are the problems?
>> ...
>>
>>
>> It is illegal because nobody has written code to support it. It
>> should be possible to support it. I don't think there are any
>> problems
>> with the concept.
>>
>>
>> (The implementation faces some challenges, the following is easy to
>> get wrong:
>>
>> module module_;
>>
>> void foo();
>>
>> alias foo alias1;
>> static if(is(typeof(alias1))){
>> void foo(){}
>> alias foo alias2;
>> }
>>
>> static assert(__traits(isSame, alias1, alias2));
>> static assert(__traits(allMembers, module_).length == 3); // 2
>> alias, 1 function definition
>> )
>>
>>
>> I'm not sure I understand the point being illustrated here. I don't see how the aliases are relevant?
>>
>
> From a compiler perspective, the example above is hell. That was his point.
>
> In other terms, supporting such a feature add complexity to the compiler, and it should come with a sufficient benefice to make sense to implement.
>
I can't imagine why the example above is hell, but I know nothing about the compiler.
I have no idea how the existing bug was implemented, but it needs to be
fixed one way or another.
It sounds fairly trivial to me to promote a prototype to a definition if a
definition is found later in the same module.
|
September 26, 2012 Re: Function prototype + definition in the same file | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On Wednesday, 26 September 2012 at 10:09:14 UTC, deadalnix wrote:
> In other terms, supporting such a feature add complexity to the compiler, and it should come with a sufficient benefice to make sense to implement.
It seems to be just opposite: creating ambiguity between function body and its declaration is a language complexity.
|
September 26, 2012 Re: Function prototype + definition in the same file | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On 2012-09-26 12:19, Manu wrote: > I can't imagine why the example above is hell, but I know nothing about > the compiler. > > I have no idea how the existing bug was implemented, but it needs to be > fixed one way or another. > It sounds fairly trivial to me to promote a prototype to a definition if > a definition is found later in the same module. If the definition is found first, just ignore the prototype? -- /Jacob Carlborg |
September 26, 2012 Re: Function prototype + definition in the same file | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| On 26 September 2012 14:21, Jacob Carlborg <doob@me.com> wrote:
> On 2012-09-26 12:19, Manu wrote:
>
> I can't imagine why the example above is hell, but I know nothing about
>> the compiler.
>>
>> I have no idea how the existing bug was implemented, but it needs to be
>> fixed one way or another.
>> It sounds fairly trivial to me to promote a prototype to a definition if
>> a definition is found later in the same module.
>>
>
> If the definition is found first, just ignore the prototype?
Indeed.
|
September 26, 2012 Re: Function prototype + definition in the same file | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On 25.09.2012 13:53, Manu wrote:> So I have this recurring pattern, it's really starting to annoy me. > It stems from the fact that a function prototype and the definition can > not appear in the same file in D (as it can in C/C++) > Eg, > [...] > I also have numerous more advanced cases of the same problem, and > becomes even more unsightly when used in structs to emulate dynamic > linkage to static methods of C++ classes. > > The solution is seemingly trivial; allow function prototypes and > definitions to exist in the same file, like in C/C++. > I think this should be allowed, aswell as implementing forward declared enums and structs (IIRC the compiler even has some error messages that suggest that it is intended). As a workaround, you could put your prototypes into a struct and generate the declarations for the static linking and the stubs for dynamic linking from their declarations and run your magic on the members of "prototypes": struct prototypes { void fun1(int a, int b); void fun2(int a, int b); } mixin(magic([__traits(allMembers, prototypes)]) That way you don't put the symbols into the same scope as the prototypes, and you will not add new symbols to the same scope that you are iterating over. |
September 27, 2012 Re: Function prototype + definition in the same file | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rainer Schuetze Attachments:
| On 26 September 2012 20:28, Rainer Schuetze <r.sagitario@gmx.de> wrote:
>
> I think this should be allowed, aswell as implementing forward declared enums and structs (IIRC the compiler even has some error messages that suggest that it is intended).
>
> As a workaround, you could put your prototypes into a struct and generate the declarations for the static linking and the stubs for dynamic linking from their declarations and run your magic on the members of "prototypes":
>
> struct prototypes
> {
> void fun1(int a, int b);
> void fun2(int a, int b);
> }
>
> mixin(magic([__traits(**allMembers, prototypes)])
>
>
> That way you don't put the symbols into the same scope as the prototypes, and you will not add new symbols to the same scope that you are iterating over.
>
Good idea! I'll give that a shot.
So it seems like there is fairly general consensus on this then, is there a next step? Should I log a bug? (I think I did log one months ago)
|
Copyright © 1999-2021 by the D Language Foundation