Jump to page: 1 2 3
Thread overview
C style 'static' functions
Jul 19, 2017
John Burton
Jul 19, 2017
Gary Willoughby
Jul 19, 2017
John Burton
Jul 19, 2017
EnterYourNameHere
Jul 19, 2017
Jacob Carlborg
Jul 19, 2017
John Burton
Jul 19, 2017
Kagamin
Jul 19, 2017
John Burton
Jul 19, 2017
Mike Parker
Jul 19, 2017
John Burton
Jul 19, 2017
Mike Parker
Jul 19, 2017
Johannes Pfau
Jul 19, 2017
Johannes Pfau
Jul 19, 2017
Johannes Pfau
Jul 19, 2017
Kagamin
Jul 19, 2017
Johannes Pfau
Jul 19, 2017
Jacob Carlborg
Jul 19, 2017
Mike Parker
July 19, 2017
In C I can declare a function 'static' and it's only visible from within that implementation file. So I can have a static function 'test' in code1.c and another non static function 'test' in utils.c and assuming a suitable prototype I can use 'test' in my program and the one in code1.c will not interfere.

In D it seems that declaring functions as static in a module does not affect visibility outside of a module. So if I declare a static function in one module with a specific name that is just used in internally for the implementation, and then define a function with the same name in another module that is intended to by 'exported' then in my main program they still conflict and I have to take steps to avoid this.

It looked as if I could use 'private' instead of static but although this prevents me from calling the "private" function, it still conflicts with the one I want to call.

In C++ I could use static or an anonymous namespace for implementation functions, but there doesn't seem to be anything similar in D.
Is there any way to achieve what I want in D (Private implementation functions)
July 19, 2017
On Wednesday, 19 July 2017 at 07:22:48 UTC, John Burton wrote:
> In C++ I could use static or an anonymous namespace for implementation functions, but there doesn't seem to be anything similar in D.
> Is there any way to achieve what I want in D (Private implementation functions)

Try the package keyword: https://dlang.org/spec/attribute.html#visibility_attributes
July 19, 2017
On Wednesday, 19 July 2017 at 07:51:11 UTC, Gary Willoughby wrote:
> On Wednesday, 19 July 2017 at 07:22:48 UTC, John Burton wrote:
>> In C++ I could use static or an anonymous namespace for implementation functions, but there doesn't seem to be anything similar in D.
>> Is there any way to achieve what I want in D (Private implementation functions)
>
> Try the package keyword: https://dlang.org/spec/attribute.html#visibility_attributes

This appears to still have the same issue. I can't use the "package" function in the main program but it still conflicts with the one I can use from a different module. Unless I'm doing it wrong...
July 19, 2017
On Wednesday, 19 July 2017 at 07:22:48 UTC, John Burton wrote:
> In C I can declare a function 'static' and it's only visible from within that implementation file. So I can have a static function 'test' in code1.c and another non static function 'test' in utils.c and assuming a suitable prototype I can use 'test' in my program and the one in code1.c will not interfere.
>
> In D it seems that declaring functions as static in a module does not affect visibility outside of a module.

Indeed, static is not a visibility attribute and for a free function static is mostly a no-op. So far i've only seen a meaningful static free func once and it was used as template value parameter.

> So if I declare a static function in one module with a specific name that is just used in internally for the implementation, and then define a function with the same name in another module that is intended to by 'exported' then in my main program they still conflict and I have to take steps to avoid this.
>
> It looked as if I could use 'private' instead of static but although this prevents me from calling the "private" function, it still conflicts with the one I want to call.
>
> In C++ I could use static or an anonymous namespace for implementation functions, but there doesn't seem to be anything similar in D.
> Is there any way to achieve what I want in D (Private implementation functions)

If what you want is an overload that has the same signature, which is not really possible, then you'd rather use a function template:

    enum Internal
    {
       no,
       yes
    }

    void foo(Internal Itr = Internal.no)()
    {
        static if (Itr) {}
        else {}
    }

That should do the trick, although i don't know the context.
July 19, 2017
On 2017-07-19 09:22, John Burton wrote:
> In C I can declare a function 'static' and it's only visible from within that implementation file. So I can have a static function 'test' in code1.c and another non static function 'test' in utils.c and assuming a suitable prototype I can use 'test' in my program and the one in code1.c will not interfere.
> 
> In D it seems that declaring functions as static in a module does not affect visibility outside of a module. So if I declare a static function in one module with a specific name that is just used in internally for the implementation, and then define a function with the same name in another module that is intended to by 'exported' then in my main program they still conflict and I have to take steps to avoid this.
> 
> It looked as if I could use 'private' instead of static but although this prevents me from calling the "private" function, it still conflicts with the one I want to call.
> 
> In C++ I could use static or an anonymous namespace for implementation functions, but there doesn't seem to be anything similar in D.
> Is there any way to achieve what I want in D (Private implementation functions)

I think it would be easier if you provide a small code example of what you want to achieve.

-- 
/Jacob Carlborg
July 19, 2017
On Wednesday, 19 July 2017 at 11:31:32 UTC, Jacob Carlborg wrote:
> On 2017-07-19 09:22, John Burton wrote:
>> In C I can declare a function 'static' and it's only visible from within that implementation file. So I can have a static function 'test' in code1.c and another non static function 'test' in utils.c and assuming a suitable prototype I can use 'test' in my program and the one in code1.c will not interfere.
>> 
>> In D it seems that declaring functions as static in a module does not affect visibility outside of a module. So if I declare a static function in one module with a specific name that is just used in internally for the implementation, and then define a function with the same name in another module that is intended to by 'exported' then in my main program they still conflict and I have to take steps to avoid this.
>> 
>> It looked as if I could use 'private' instead of static but although this prevents me from calling the "private" function, it still conflicts with the one I want to call.
>> 
>> In C++ I could use static or an anonymous namespace for implementation functions, but there doesn't seem to be anything similar in D.
>> Is there any way to achieve what I want in D (Private implementation functions)
>
> I think it would be easier if you provide a small code example of what you want to achieve.


Here is an artificial example of what I mean. The point is that I can break main.d from compiling by adding what is meant to be a purely internal implementation detail inside  of lib1. - In C I can make internal functions static to avoid this... Im D, none of static, package, private etc seem to do this. They prevent it from being called but don't hide the existence of the function from the module importing it.

If there is no way to achieve this it's not a big problem, I'm just curious now :)


---- lib1.d ----

private void init()
{
    // init function used only as an implementation detail
}

void mything()
{
    init();
}


---- lib2.d -----

void init()
{
    // init function meant to be used as part of the module interface
}

---- main.d ----

import lib1;
import lib2;

void main()
{
    init();  // This is meant to call lib2.init because it's the only
             // function of that name. lib1.init() is supposed to be
             // an entirely internal implementation detail of lib1
             // Even though I can't call lib1.init() because it's private
             // this call still shows up as ambigous.
 	     //
             // In C I'd write "static void init()" in lib1.d to indicate
             // that the function was entirely local to that file. However static
             // does not appear to have that same effect in D
}


July 19, 2017
Try a newer compiler, this was fixed recently.
July 19, 2017
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.
July 19, 2017
On Wednesday, 19 July 2017 at 11:52:09 UTC, John Burton wrote:
>
> ---- lib1.d ----
>
> private void init()
> {
>     // init function used only as an implementation detail
> }
>
> void mything()
> {
>     init();
> }
>
>
> ---- lib2.d -----
>
> void init()
> {
>     // init function meant to be used as part of the module interface
> }
>
> ---- main.d ----
>
> import lib1;
> import lib2;
>
> void main()
> {
>     init();  // This is meant to call lib2.init because it's the only
>              // function of that name. lib1.init() is supposed to be
>              // an entirely internal implementation detail of lib1
>              // Even though I can't call lib1.init() because it's private
>              // this call still shows up as ambigous.
>  	     //
>              // In C I'd write "static void init()" in lib1.d to indicate
>              // that the function was entirely local to that file. However static
>              // does not appear to have that same effect in D
> }

This should work as you expect, as that's what private in module scope is supposed to do. And it does work for me 2.074.1. There was a bug with the visibility of module-private symbols in the D frontend that was fixed a couple of releases back (can't recall off hand which version). So if you're using an older version of DMD, or a version of LDC or GDC that uses an older version of the frontend, then you'll still encounter the bug.

The workaround (until you get a compiler with a more recent frontend) is to use the fully qualified name (FQN) of the function you want to call, in this case: lib2.init();

July 19, 2017
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!
« First   ‹ Prev
1 2 3