get module name of function
How do I get the module name that a function is defined in?
I have a generic template that
auto Do(T)()
{
pragma(msg, moduleName!T);
}
in a module
and in another module I define a function
void foo() { }
and a class
class C { }
and call Do!(typeof(foo)) and Do!(C)
but it fails for the function. I use type of because it fails
when I do not.
Is there not some uniform way to treat types like classes and
functions as the same for meta programming?
If I do
pragma(msg, moduleName!foo);
in the same module as foo it works.
So I guess I have to use Do(alias T)() but then that breaks the
class(cause I use `isClass`(= is(T == class) wrapper) and it
complains ;/
I don't understand what the difference between alias and T is.
Alias can be most things and T must be a type, sometimes they
overlap and sometimes they don't ;/ Is there any way to convert
one thing to another when they do overlap and to know which
direction to go?
Do(alias T) or Do(T)?
The second can only take types, the first can take symbolic
expressions and other stuff but not types?
Re: D interface bug?
On Saturday, 30 March 2019 at 00:44:31 UTC, Alex wrote:
On Saturday, 30 March 2019 at 00:06:23 UTC, H. S. Teoh wrote:
On Fri, Mar 29, 2019 at 11:44:35PM +, Alex via
Digitalmars-d-learn wrote:
interface iBase
{
iBase fooBase(iBase);
}
class cBase : iBase
{
cBase fooBase(cBase c) { return c; }
}
cBase.fooBase should be a valid override of iBase.fooBase
because they are the same type! cBase is a super type so it
contains everything iBase contains and maybe more.
No, that's wrong. Consider this:
class cBase : iBase
{
int x;
cBase fooBase(cBase c) { return (x==1) ? c : null; }
}
class dBase : iBase
{
string y;
dBase fooBase(dBase c) { return (y=="a") ? c : null; }
}
iBase intf = new cBase;
dBase dobj = new dBase;
dobj.fooBase(intf); // oops: intf.y doesn't exist!
I.e., it's invalid for dBase.fooBase to override the interface
method.
The parameter type of fooBase must be the interface type or a
super-interface thereof. For a class C to inherit from an
interface X means that C contains a subset of all possible
objects that X might refer to. Therefore, if a method takes a
parameter of type C, it *cannot* be passed an argument of type
X, since the actual object might be outside the subset that C
includes. IOW, such a method cannot be covariant with a method
that takes X as a parameter.
There should be no reason why the compiler can't figure this
out. It's a very simple rule.
Any time the user calls iBase.fooBase it can be replaced with
cBase.fooBase so it should not compromise any code to go
ahead and accept it as a proper override.
[...]
Nope. The user can call iBase.fooBase, passing it an instance
of a different class that also implements iBase but does not
inherit from cBase. Then cBase.fooBase would receive an
argument of incompatible type.
T
Ok. In my use case, which is what I was thinking of, there will
never be a dBase. There will never be any other class that
inherits from the interface. I have to use an interface ONLY
because D does not allow for multiple inheritance.
class X;
class C;
class Q : X, C;
Which can't be done, so I want to do
interface iC;
class C : iC;
class Q : X, iC;
which now works. The problem now is that I have to then still
follow these rules which are very restrictive. It's true that
someone could come along and create an new class D : iC and
cause problems, but that should never happen in my case.
Ideally, if they did, they would use the same pattern as above:
interface iD;
class D : C, iD;
and this then also alleviates the problem.
In your case it is
iC
/ \
/\
C D
but in my case it should never happen, or if it would, it is
better to do
iC
/
/
C iD
\ /
\ /
D
I'm only using interfaces because I have to, not because I want
to. But then that forces me to do strange things in D and it
causes many problems. Since one can't have fields in an
interface it requires using properties and all that code bloat
that comes with them, along with the casting issues, and
overloading, etc.
Maybe, CRTP is something you can use?
https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern
The fact, that your interfaces are bounded to the classes in a
1:1 manner would be a hint for this...
Re: D interface bug?
On Saturday, 30 March 2019 at 00:06:23 UTC, H. S. Teoh wrote:
On Fri, Mar 29, 2019 at 11:44:35PM +, Alex via
Digitalmars-d-learn wrote:
interface iBase
{
iBase fooBase(iBase);
}
class cBase : iBase
{
cBase fooBase(cBase c) { return c; }
}
cBase.fooBase should be a valid override of iBase.fooBase
because they are the same type! cBase is a super type so it
contains everything iBase contains and maybe more.
No, that's wrong. Consider this:
class cBase : iBase
{
int x;
cBase fooBase(cBase c) { return (x==1) ? c : null; }
}
class dBase : iBase
{
string y;
dBase fooBase(dBase c) { return (y=="a") ? c : null; }
}
iBase intf = new cBase;
dBase dobj = new dBase;
dobj.fooBase(intf); // oops: intf.y doesn't exist!
I.e., it's invalid for dBase.fooBase to override the interface
method.
The parameter type of fooBase must be the interface type or a
super-interface thereof. For a class C to inherit from an
interface X means that C contains a subset of all possible
objects that X might refer to. Therefore, if a method takes a
parameter of type C, it *cannot* be passed an argument of type
X, since the actual object might be outside the subset that C
includes. IOW, such a method cannot be covariant with a method
that takes X as a parameter.
There should be no reason why the compiler can't figure this
out. It's a very simple rule.
Any time the user calls iBase.fooBase it can be replaced with
cBase.fooBase so it should not compromise any code to go ahead
and accept it as a proper override.
[...]
Nope. The user can call iBase.fooBase, passing it an instance
of a different class that also implements iBase but does not
inherit from cBase. Then cBase.fooBase would receive an
argument of incompatible type.
T
Ok. In my use case, which is what I was thinking of, there will
never be a dBase. There will never be any other class that
inherits from the interface. I have to use an interface ONLY
because D does not allow for multiple inheritance.
class X;
class C;
class Q : X, C;
Which can't be done, so I want to do
interface iC;
class C : iC;
class Q : X, iC;
which now works. The problem now is that I have to then still
follow these rules which are very restrictive. It's true that
someone could come along and create an new class D : iC and cause
problems, but that should never happen in my case. Ideally, if
they did, they would use the same pattern as above:
interface iD;
class D : C, iD;
and this then also alleviates the problem.
In your case it is
iC
/ \
/\
C D
but in my case it should never happen, or if it would, it is
better to do
iC
/
/
C iD
\ /
\ /
D
I'm only using interfaces because I have to, not because I want
to. But then that forces me to do strange things in D and it
causes many problems. Since one can't have fields in an interface
it requires using properties and all that code bloat that comes
with them, along with the casting issues, and overloading, etc.
Re: D interface bug?
On Fri, Mar 29, 2019 at 11:44:35PM +, Alex via Digitalmars-d-learn wrote:
> interface iBase
> {
> iBase fooBase(iBase);
> }
>
>
> class cBase : iBase
> {
> cBase fooBase(cBase c) { return c; }
>
> }
>
> cBase.fooBase should be a valid override of iBase.fooBase because they
> are the same type! cBase is a super type so it contains everything
> iBase contains and maybe more.
No, that's wrong. Consider this:
class cBase : iBase
{
int x;
cBase fooBase(cBase c) { return (x==1) ? c : null; }
}
class dBase : iBase
{
string y;
dBase fooBase(dBase c) { return (y=="a") ? c : null; }
}
iBase intf = new cBase;
dBase dobj = new dBase;
dobj.fooBase(intf); // oops: intf.y doesn't exist!
I.e., it's invalid for dBase.fooBase to override the interface method.
The parameter type of fooBase must be the interface type or a
super-interface thereof. For a class C to inherit from an interface X
means that C contains a subset of all possible objects that X might
refer to. Therefore, if a method takes a parameter of type C, it
*cannot* be passed an argument of type X, since the actual object might
be outside the subset that C includes. IOW, such a method cannot be
covariant with a method that takes X as a parameter.
> There should be no reason why the compiler can't figure this out. It's
> a very simple rule.
>
> Any time the user calls iBase.fooBase it can be replaced with
> cBase.fooBase so it should not compromise any code to go ahead and
> accept it as a proper override.
[...]
Nope. The user can call iBase.fooBase, passing it an instance of a
different class that also implements iBase but does not inherit from
cBase. Then cBase.fooBase would receive an argument of incompatible
type.
T
--
"A man's wife has more power over him than the state has." -- Ralph Emerson
Re: Easiest way to use Linux system C files / tiny C libraries
On Fri, Mar 29, 2019 at 10:48:47PM +, Chris Katko via Digitalmars-d-learn
wrote:
> What's the easiest way to use POSIX and Linux-specific C include
> files?
That depends on what you're expecting and what you're willing to do
yourself.
If you want a nicely-packaged, black-box way of using C libraries from
D, perhaps what you want is:
https://github.com/jacob-carlborg/dstep
> I know you can write a wrapper but it seems like half the time these
> files include 20 files which include 20 files which use strange enums,
> arrays, etc that don't clearly have answers on how to wrap them.
What exactly do you mean by "strange enums, arrays, etc"? Giving a
specific example would help us identify what it is you're having trouble
with, and how to help you.
Keep in mind that should you encounter #include's of standard C library
headers, or standard OS headers (like the various standard Posix
#include files), these have already been translated to D as core.*,
for example, core.stdc.* for the standard C library, and
core.sys.posix.* for POSIX headers, and core.sys.linux.* for
Linux-specific headers. All it takes is to import the relevant
module(s), which have exactly the same name as their C counterparts, and
you're ready to go.
Also, a small number of C libraries may already have D bindings
available; check code.dlang.org to see if someone has already done the
hard work for you.
[...]
> I "could" write my own in D but then once again, I've not solved my
> re-occurring problem of "what if I DO need a C library."
>
> Do I need to implement every piece of a C header / library, or can I
> get away with a tiny subset that I'm actually using?
If dstep doesn't do the job for you, or if for whatever reason you need
manual control over exactly how the C header(s) are translated, you can
follow my approach of "absolute minimum declarations to get the thing to
compile".
Basically, a C library doesn't really care what declarations you use on
your end, as long as (1) the runtime C symbol is invoked with (2) the
right argument types and values. Remember that C doesn't have mangling
issues unlike C++, so you don't even need to use the same type names
that the C header uses, as long as your declarations are
binary-compatible with the C declarations (though generally I'd stick
with the same / similar names in order to avoid confusion). So for (1),
all you need is an extern(C) declaration with the C function name and
arguments of the right (or equivalent) type(s).
For (2), usually an extern(C) struct declaration will get you there.
Note that not all struct declarations actually need to be translated;
many C libraries take arguments via pointers, so if you don't need to
care about the struct contents or layout, you can get away with just an
empty forward declaration:
extern(C) {
struct SomeLibraryStruct;
int SomeLibraryFunction(SomeLibraryStruct *arg);
}
For translating macros, it depends on the intent of the macro.
Generally, they tend to fall into these categories:
- Poor man's implementation of compile-time constants: use enum, e.g.:
/* C code */
#define MAX_OBJ_SIZE255
// D equivalent
enum MAX_OBJ_SIZE = 255;
- Poor man's function name aliasing, e.g.:
/* C code */
#define my_func(x,y)_my_func_impl((x), (y));
// D equivalent
alias my_func = _my_func_impl;
- Function call wrappers, e.g.:
/* C code */
#define my_func(x,y)_my_func_impl((y), (x));
// D equivalent (you'll have to look up the actual types of x
// and y and substitute them for 'int' below)
auto my_func(int x, int y) { return _my_func_impl(y, x); }
- Inline functions:
/* C code */
#define error_log(msg) \
do { fprintf(stderr, "%s\n", (msg)); } while(0);
// D equivalent: just use a regular function
void error_log(string msg) { stderr.writefln("%s\n", msg); }
- Syntax hacks: use mixin templates, or better yet, don't bother, just
write out what you mean in real syntax.
For translating C enums, generally my advice is: don't use an actual D
named enum, but only use `enum` in the sense of a manifest constant,
because that's what the C semantics are, and sometimes the library API
will expect you to use it that way. For example, I often see something
like this:
/* C */
enum {
BLAH = 1,
BLEH = 2,
... /* ad nauseaum */
} my_enum_t;
/* Obviously, myfunc really wants my_enum_t, but the authors
* were lazy and C doesn't care */
void myfunc(int my_enum);
// D equivalent: don't even bother with the whole my_enum_t
// nonsense.
enum BLAH = 1;
enum BLEH = 2;
void myfunc(int my_enum);
If you want some measure of type safety, you can of course use D enums
(where the compiler will actually tell you if
Re: D interface bug?
On Friday, 29 March 2019 at 23:44:35 UTC, Alex wrote:
> interface iBase
> {
> iBase fooBase(iBase);
> }
>
>
> class cBase : iBase
> {
> cBase fooBase(cBase c) { return c; }
>
> }
>
> cBase.fooBase should be a valid override of iBase.fooBase
> because
> they are the same type!
The return value there is allowed, but the parameter is not. Consider this case:
class AnotherChild : iBase { /* snip */ }
iBase i = new cBase(); // allowed, cBase implements iBase
i.fooBase(new AnotherChild);
That second line should be allowed: the interface says it accepts any
implementation of the iBase interface.
But the cBase implementation doen't allow *any* implementation of iBase - it
only accepts cBase and down. That function wouldn't be able to handle my
AnotherChild instance.
Thus, cBase.fooBase does NOT implement the iBase's interface, and it fails to
compile.
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Friday, 29 March 2019 at 20:34:32 UTC, Michelle Long wrote: I really wish you would start taking screenshots! It is not hard! You still think this is about me not knowing how to take a screenshot? :) I guess you didn't read my reply to your last request.
Re: Derived classes? Reflection
On Saturday, 13 April 2013 at 17:50:00 UTC, Tofu Ninja wrote: On Saturday, 13 April 2013 at 17:45:12 UTC, Tofu Ninja wrote: Maybe this is helpfully: http://forum.dlang.org/thread/scgjnudclnwlbdqqd...@forum.dlang.org Oddly enough, I found that at about the same time you posted it. Sadly this does not provide a compile time solution, only runtime. I wonder if one could use this to first spawn a process at compile type and then spit out the information and then process that info at compile time(say from a text file).
D interface bug?
interface iBase
{
iBase fooBase(iBase);
}
class cBase : iBase
{
cBase fooBase(cBase c) { return c; }
}
cBase.fooBase should be a valid override of iBase.fooBase because
they are the same type! cBase is a super type so it contains
everything iBase contains and maybe more.
There should be no reason why the compiler can't figure this out.
It's a very simple rule.
Any time the user calls iBase.fooBase it can be replaced with
cBase.fooBase so it should not compromise any code to go ahead
and accept it as a proper override.
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Friday, 29 March 2019 at 16:21:59 UTC, aberba wrote: Have shared gtkdcoding.com with some folks and they like it, keep it coming!! Cool. Thanks, aberba.
Re: Easiest way to use Linux system C files / tiny C libraries
On Friday, 29 March 2019 at 22:48:47 UTC, Chris Katko wrote: What's the easiest way to use POSIX and Linux-specific C include files? For standard ones, they are pre-done for you under the `core.sys.posix` D package namespace (or `core.sys.linux` for Linux-specific ones). For ones not in the standard... it depends. I don't know the libprocps one, but I can say in general: Do I need to implement every piece of a C header / library, or can I get away with a tiny subset that I'm actually using? I say do the bare minimum that works for you. Just the functions, structs, and values you use. And if you are using structs exclusively via pointers, you don't even need their definitions; you can cheat and use void* instead.
Easiest way to use Linux system C files / tiny C libraries
What's the easiest way to use POSIX and Linux-specific C include files? I know you can write a wrapper but it seems like half the time these files include 20 files which include 20 files which use strange enums, arrays, etc that don't clearly have answers on how to wrap them. Is there something I'm missing? For example, right now, the most recent problem I've had related to this is wanting to use the libprocps-dev library. All it does is expose the /proc/ process data in an easy-to-use format. I "could" write my own in D but then once again, I've not solved my re-occurring problem of "what if I DO need a C library." Do I need to implement every piece of a C header / library, or can I get away with a tiny subset that I'm actually using? I don't know. I know this is all vague. But I've run into this problem multiple times and every time, after hours of googling, never gotten anywhere. Thanks.
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Friday, 29 March 2019 at 14:25:16 UTC, Ron Tarrant wrote: I'm having trouble replying to the thread I usually use, so... There's a new tutorial for using a GTK Grid. You can find it here: http://gtkdcoding.com/2019/03/29/0022-grids.html I really wish you would start taking screenshots! It is not hard!
Re: gtkDcoding Blog Post for 2019-03-29 - Grid
On Friday, 29 March 2019 at 14:25:16 UTC, Ron Tarrant wrote: I'm having trouble replying to the thread I usually use, so... There's a new tutorial for using a GTK Grid. You can find it here: http://gtkdcoding.com/2019/03/29/0022-grids.html Have shared gtkdcoding.com with some folks and they like it, keep it coming!!
gtkDcoding Blog Post for 2019-03-29 - Grid
I'm having trouble replying to the thread I usually use, so... There's a new tutorial for using a GTK Grid. You can find it here: http://gtkdcoding.com/2019/03/29/0022-grids.html
Re: How to decode UTF-8 text?
On Wednesday, 27 March 2019 at 19:16:21 UTC, kdevel wrote: On Wednesday, 27 March 2019 at 13:39:07 UTC, Andrey wrote: Thank you!
