July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | On Wednesday, 19 July 2017 at 12:15:05 UTC, Mike Parker wrote: > On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote: >> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote: >>> Try a newer compiler, this was fixed recently. >> >> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated. >> >> Sorry for wasting everyones' time if that's so, and thanks for the help. > > Ah, great! Looks like it's https://wiki.dlang.org/DIP22 that changed this |
July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Burton | On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:
> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:
>> Try a newer compiler, this was fixed recently.
>
> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated.
>
> Sorry for wasting everyones' time if that's so, and thanks for the help.
Just for the record, private is the analog of C's static. All private free and member functions are callable only from the module they are defined in. This is in contrast with C++, Java, C# where private members are visible only the class they are defined in.
|
July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Burton | On Wednesday, 19 July 2017 at 12:16:46 UTC, John Burton wrote: > > Looks like it's https://wiki.dlang.org/DIP22 that changed this Specifically, it was fixed in DMD 2.071.0 released in April of last year: http://dlang.org/changelog/2.071.0.html#dip22 |
July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Burton | On 2017-07-19 14:11, John Burton wrote: > Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated. > > Sorry for wasting everyones' time if that's so, and thanks for the help. I suspected something like this :). Nice to hear that you sorted it out. -- /Jacob Carlborg |
July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Petar Kirov [ZombineDev] | On 7/19/17 8:16 AM, Petar Kirov [ZombineDev] wrote:
> On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:
>> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:
>>> Try a newer compiler, this was fixed recently.
>>
>> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated.
>>
>> Sorry for wasting everyones' time if that's so, and thanks for the help.
>
> Just for the record, private is the analog of C's static. All private free and member functions are callable only from the module they are defined in. This is in contrast with C++, Java, C# where private members are visible only the class they are defined in.
I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables.
You could still call a private function in a D module via the mangled name I believe.
-Steve
Note: not 100% sure of all this, but this is always the way I've looked at it.
|
July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer wrote:
> On 7/19/17 8:16 AM, Petar Kirov [ZombineDev] wrote:
>> On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote:
>>> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote:
>>>> Try a newer compiler, this was fixed recently.
>>>
>>> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated.
>>>
>>> Sorry for wasting everyones' time if that's so, and thanks for the help.
>>
>> Just for the record, private is the analog of C's static. All private free and member functions are callable only from the module they are defined in. This is in contrast with C++, Java, C# where private members are visible only the class they are defined in.
>
> I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables.
>
> You could still call a private function in a D module via the mangled name I believe.
>
> -Steve
>
> Note: not 100% sure of all this, but this is always the way I've looked at it.
That's correct. We unfortunately can't do certain optimizations because of this (executable size related: removing unused or inlined only functions, ...).
The reason we can't make private functions object local are templates. A public template can access private functions, but the template instance may be emitted to another object. And as templates can't be checzked speculatively we don't even know if there's a template accessing a private function.
Dlls on Windows face a similar problem. Once we get the export templates proposed in earlier Dll discussions we can make non-exported, private functions object local.
|
July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer wrote: > On 7/19/17 8:16 AM, Petar Kirov [ZombineDev] wrote: >> On Wednesday, 19 July 2017 at 12:11:38 UTC, John Burton wrote: >>> On Wednesday, 19 July 2017 at 12:05:09 UTC, Kagamin wrote: >>>> Try a newer compiler, this was fixed recently. >>> >>> Hmm it turns out this machine has 2.0.65 on which is fairly ancient. I'd not realized this machine had not been updated. >>> >>> Sorry for wasting everyones' time if that's so, and thanks for the help. >> >> Just for the record, private is the analog of C's static. All private free and member functions are callable only from the module they are defined in. This is in contrast with C++, Java, C# where private members are visible only the class they are defined in. > > I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables. > > You could still call a private function in a D module via the mangled name I believe. > > -Steve > > Note: not 100% sure of all this, but this is always the way I've looked at it. You're probably right about the current implementation, but I was talking about the intended semantics. I believe that with DIP45, only functions and global variables annotated with the export storage class would necessary have externally visible symbols. Also, consider this enhancement request (which I think Walter and Andrei approve of) - https://issues.dlang.org/show_bug.cgi?id=13567 - which would be doable only if private functions don't have externally visible symbols. See also: https://issues.dlang.org/show_bug.cgi?id=9893. |
July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer wrote:
> I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables.
They generate hidden symbols. That's just how it implements private functions in C: you can't do anything else without mangling. You probably can't compile two C units into one object file if they have static functions with the same name - this would require mangling to make two symbols different.
|
July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Petar Kirov [ZombineDev] | Am Wed, 19 Jul 2017 17:25:18 +0000 schrieb Petar Kirov [ZombineDev] <petar.p.kirov@gmail.com>: > > > > Note: not 100% sure of all this, but this is always the way I've looked at it. > > You're probably right about the current implementation, but I was talking about the intended semantics. I believe that with DIP45, only functions and global variables annotated with the export storage class would necessary have externally visible symbols. > Yes, this DIP is the solution to have true C-like static functions. Non-exported private will then be equivalent to C static. > Also, consider this enhancement request (which I think Walter and Andrei approve of) - https://issues.dlang.org/show_bug.cgi?id=13567 - which would be doable only if private functions don't have externally visible symbols. Can you explain why _object-level visibility_ would matter in this case? -- Johannes |
July 19, 2017 Re: C style 'static' functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | Am Wed, 19 Jul 2017 17:37:48 +0000 schrieb Kagamin <spam@here.lot>: > On Wednesday, 19 July 2017 at 15:28:50 UTC, Steven Schveighoffer wrote: > > I'm not so sure of that. Private functions still generate symbols. I think in C, there is no symbol (at least in the object file) for static functions or variables. > > They generate hidden symbols. That's just how it implements private functions in C: you can't do anything else without mangling. This is not entirely correct. The symbols are local symbols in elf terminology, so local to an object file. Hidden symbols are local to an executable or shared library. > You probably can't compile two C units into one object file if they have static functions with the same name - this would require mangling to make two symbols different. 1) C does have mangling for static variables: void foo() {static int x;} ==> .local x.1796 2) Object file? No, but you cant compile two translation units into one object file anyway or declare two functions with the same name in one translation file. For executables and libraries, ELF takes care of this. One major usecase of static functions is not polluting the global namespace. ------------------------------------------------------- static int foo(int a, int b) { return a + b + 42; } int bar(int a, int b) { return foo(a, b); } ------------------------------------------------------- nm => 0000000000000017 T bar 0000000000000000 t foo ------------------------------------------------------- static int foo(int a, int b) { return -42; } int bar(int a, int b); int main() { return bar(1, 2); } ------------------------------------------------------- nm => U bar 0000000000000000 t foo U _GLOBAL_OFFSET_TABLE_ 0000000000000011 T main nm a.out | grep foo => 000000000000063a t foo 0000000000000670 t foo Additionally, when compiling with optimizations both foos are gone: All calls are inlined, the functions are never referenced and therefore removed. This can reduce executable size a lot if you have many local helper functions, so D may benefit from this optimization as well. -- Johannes |
Copyright © 1999-2021 by the D Language Foundation