Am Wed, 19 Jul 2017 19:18:03 +
schrieb Petar Kirov [ZombineDev] :
> On Wednesday, 19 July 2017 at 18:49:32 UTC, Johannes Pfau wrote:
> >
> > Can you explain why _object-level visibility_ would matter in
> > this case?
>
> (I'm sure you have more experience with shared libraries than me,
>
On Wednesday, 19 July 2017 at 18:49:32 UTC, Johannes Pfau wrote:
Can you explain why _object-level visibility_ would matter in
this case?
(I'm sure you have more experience with shared libraries than me,
so correct me if I'm wrong)
We can't do attribute inference for exported functions bec
Am Wed, 19 Jul 2017 17:37:48 +
schrieb Kagamin :
> 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
Am Wed, 19 Jul 2017 17:25:18 +
schrieb Petar Kirov [ZombineDev] :
> >
> > 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 D
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 implemen
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.
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.
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'
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
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
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.
S
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
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.
S
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
inte
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
t
Try a newer compiler, this was fixed recently.
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'
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
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
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 wha
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
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
22 matches
Mail list logo