On Monday, March 11, 2024 10:51:48 AM MDT Andy Valencia via Digitalmars-d-
learn wrote:
> On Monday, 11 March 2024 at 16:25:13 UTC, Jonathan M Davis wrote:
> > ...
> > But what exactly static means varies based on the context.
>
> Thank you for the list! But none of those appear to apply to a
> fu
On Monday, 11 March 2024 at 16:51:48 UTC, Andy Valencia wrote:
On Monday, 11 March 2024 at 16:25:13 UTC, Jonathan M Davis
wrote:
...
But what exactly static means varies based on the context.
Thank you for the list! But none of those appear to apply to a
function defined in the outermost sco
On Monday, 11 March 2024 at 16:25:13 UTC, Jonathan M Davis wrote:
...
But what exactly static means varies based on the context.
Thank you for the list! But none of those appear to apply to a
function defined in the outermost scope of the module. Is static
accepted here--but has no actual e
On Monday, March 11, 2024 9:56:24 AM MDT Andy Valencia via Digitalmars-d-learn
wrote:
> Leveraging my knowledge of C, I assumed a "static" function would
> be hidden outside of its own source file. I can't find any
> statement about the semantics of a static function in the
> documentation, and i
Leveraging my knowledge of C, I assumed a "static" function would
be hidden outside of its own source file. I can't find any
statement about the semantics of a static function in the
documentation, and in practice (ldc2 on Linux) it doesn't hide
the function?
file tst.d:
import std.stdio :
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
tended 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
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 j
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 implement
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 d
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 c
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
On 03/21/2013 01:34 PM, Dan wrote:
> Json serializeToJson(T)(T value) {
> ...
> static if( __traits(compiles, value = T.fromJson(value.toJson())) ){
It looks like fromJson must be a static member function because the
condition is written in a way that fromJson is called on the type
itself. (I
I have an enum, say:
enum AssetCategory {
Investment,
PrimaryResidence,
FamilyProperty,
FinancialInstrument
}
and I have functions that convert to/from strings to be used in
Json (via vibe json). The vibe wants to call out to user supplied
toJson/fromJson if both functions are provided
On 5/21/2012 6:32 AM, jerro wrote:
On Sunday, 20 May 2012 at 21:19:14 UTC, p0xel wrote:
This seems to work when the class is in the same file as main(), but
if I move it to it's own file and use "import foo" it errors. What am
I missing?
When you write "import foo;" and then foo.bar, the compi
On Sunday, 20 May 2012 at 21:19:14 UTC, p0xel wrote:
This seems to work when the class is in the same file as
main(), but if I move it to it's own file and use "import foo"
it errors. What am I missing?
When you write "import foo;" and then foo.bar, the compiler
thinks that
you a referring to
This seems to work when the class is in the same file as main(),
but if I move it to it's own file and use "import foo" it errors.
What am I missing?
I pretty sure I'm an idiot.
[code]
class foo {
public static int bar() {
return 0;
}
}
[/code]
How do I call bar() without creating an instance of foo?
foo.bar() results in "Error: undefined identifier 'bar'"
I'm having a really hard time finding anything relat
tion as a normal function.
>>> This is why the OP said they "don't make sense" Although his
>>> statement really should be "immutable static functions don't make
>>> sense", not "static functions in immutable types don't make se
em I see is in definition of what const
or immutable member function means:
from D specs: "Immutable member functions are guaranteed that the
object and anything referred to by the this reference is immutable."
Which applies both to instance and s static functions. I think the
abo
r function means:
from D specs: "Immutable member functions are guaranteed that the
object and anything referred to by the this reference is immutable."
Which applies both to instance and s static functions. I think the
above definition should apply only to instance functions. Static
const
ce is immutable."
Which applies both to instance and s static functions. I think the above
definition should apply only to instance functions. Static const or
immutable functions should be defined as:
Immutable static member functions are guaranteed that the static
variables of object and
nce is immutable."
Which applies both to instance and s static functions. I think the
above definition should apply only to instance functions. Static
const or immutable functions should be defined as:
Immutable static member functions are guaranteed that the static
variables of object and
mutable."
Which applies both to instance and s static functions. I think the above
definition should apply only to instance functions. Static const or
immutable functions should be defined as:
Immutable static member functions are guaranteed that the static
variables of object and
every
its member so. The problem I see is in definition of what const or immutable
member function means:
from D specs: "Immutable member functions are guaranteed that the object
and anything referred to by the this reference is immutable."
Which applies both to instance and s stati
... don't make sense. So is there a reason why they aren't excluded from
the "everything in an immutable is immutable" rule?
Tomek
41 matches
Mail list logo
