www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Passing Structs to function like in C

reply D.Rex <armstronga94 hotmail.com> writes:
Hi,

This has probably been asked many times before, but after search 
for hours and hours I can't find an answer.  I have seen in C an 
extern function taking in a struct as one of its parameters, like 
so:

extern unsigned long free_page_tables(struct task_struct * tsk);

I was wondering how this is achieved in D, or if D has an 
alternative implementation of this.

Cheers.
Aug 12 2016
next sibling parent reply Cauterite <cauterite gmail.com> writes:
On Friday, 12 August 2016 at 15:21:22 UTC, D.Rex wrote:
 extern unsigned long free_page_tables(struct task_struct * tsk);
extern(C) ulong free_page_tables(task_struct* tsk); void main() { task_struct tsk = …… ; free_page_tables(&tsk); }; That should be what you're after?
Aug 12 2016
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 08/12/2016 05:23 PM, Cauterite wrote:
 void main() {
[...]
 };
No semicolon there, please.
Aug 12 2016
parent reply Cauterite <cauterite gmail.com> writes:
On Friday, 12 August 2016 at 16:50:43 UTC, ag0aep6g wrote:
 On 08/12/2016 05:23 PM, Cauterite wrote:
 No semicolon there, please.
Why would I not terminate a declaration with a semi-colon? Why should a declaration not end in a semi-colon just because the last token is a brace? Why should I not tell the lexer precisely where my declaration ends instead of relying on whatever other tokens floating around it not interfering? Why must every thread in this forum contain more posts regarding some irrelevant tangent than posts responding to the original topic?
Aug 12 2016
next sibling parent reply WebFreak001 <janju007 web.de> writes:
On Friday, 12 August 2016 at 17:33:34 UTC, Cauterite wrote:
 On Friday, 12 August 2016 at 16:50:43 UTC, ag0aep6g wrote:
 On 08/12/2016 05:23 PM, Cauterite wrote:
 No semicolon there, please.
Why would I not terminate a declaration with a semi-colon? Why should a declaration not end in a semi-colon just because the last token is a brace? Why should I not tell the lexer precisely where my declaration ends instead of relying on whatever other tokens floating around it not interfering? Why must every thread in this forum contain more posts regarding some irrelevant tangent than posts responding to the original topic?
That would be like putting a semicolon after a while or if block or after defining a delegate inside an argument list. I think it's a bug that dmd doesn't show a warning for unnecessary semicolons outside of function blocks, because inside of them it also shows a warning. Also it's not D-style to put a semicolon there and it's also never specified in the grammar spec. It's just treated as separate empty statement.
Aug 12 2016
parent reply Cauterite <cauterite gmail.com> writes:
Thanks colon-nazis, I'll take that into consideration ¬_¬
Aug 12 2016
parent Engine Machine <EM EM.com> writes:
On Friday, 12 August 2016 at 18:23:55 UTC, Cauterite wrote:
 Thanks colon-nazis, I'll take that into consideration ¬_¬
Be careful! They will cauterize your testicles and rape your children! Those semi-clone, I mean semi-colon-nazis are the worse kind! It's a life and death matter! After all, `proper`(by section 8.043 of the penile nazile book of the dead) use of ';' is more important than your testicles anyways, right?
Aug 13 2016
prev sibling parent reply ag0aep6g <anonymous example.com> writes:
On 08/12/2016 07:33 PM, Cauterite wrote:
 Why would I not terminate a declaration with a semi-colon?
 Why should a declaration not end in a semi-colon just because the last
 token is a brace?
 Why should I not tell the lexer precisely where my declaration ends
 instead of relying on whatever other tokens floating around it not
 interfering?
The semicolon is just noise. You're not helping the lexer at all. It goes by the braces, and doesn't see the semicolon as belonging to the function declaration. The semicolon creates another, empty declaration. This is accepted as well, and means the same: ---- ;;; void main() {} ;;; ----
 Why must every thread in this forum contain more posts regarding some
 irrelevant tangent than posts responding to the original topic?
This is a common mistake - more for structs, though, because of C syntax. So I point it out so that you can learn that there's no point to it in D, and so that others don't get the impression that it's the proper syntax.
Aug 12 2016
parent reply Engine Machine <EM EM.com> writes:
On Friday, 12 August 2016 at 17:53:12 UTC, ag0aep6g wrote:
 On 08/12/2016 07:33 PM, Cauterite wrote:
 Why would I not terminate a declaration with a semi-colon?
 Why should a declaration not end in a semi-colon just because 
 the last
 token is a brace?
 Why should I not tell the lexer precisely where my declaration 
 ends
 instead of relying on whatever other tokens floating around it 
 not
 interfering?
The semicolon is just noise. You're not helping the lexer at all. It goes by the braces, and doesn't see the semicolon as belonging to the function declaration. The semicolon creates another, empty declaration.
Then it should error if it doesn't accept ';'. If it accepts it then it is legal. Your post is noise since it also is relatively meaningless and just takes up space. Why is it no ok for him to add a noisy ';' but it is ok for you to add noise to noise by adding a noisy post?
 This is accepted as well, and means the same:

 ----
 ;;;
 void main() {}
 ;;;
 ----

 Why must every thread in this forum contain more posts 
 regarding some
 irrelevant tangent than posts responding to the original topic?
This is a common mistake - more for structs, though, because of C syntax. So I point it out so that you can learn that there's no point to it in D, and so that others don't get the impression that it's the proper syntax.
It is not a mistake... only in your mind. If it was a mistake D wouldn't allow it. Somewhere you picked up the mistake that adding a semicolon to the end of a struct is a mistake. Maybe you should unlearn that mistake? There is no point in a lot of things, but pretending that life depends on such trivial things is a much worse mistake, IMO.
Aug 13 2016
parent ag0aep6g <anonymous example.com> writes:
On 08/13/2016 09:23 PM, Engine Machine wrote:
 Then it should error if it doesn't accept ';'. If it accepts it then it
 is legal.
It is legal, yes. It's also pointless and misleading. It should be pointed out for the benefit of the author, as they may have a misconception about D syntax. It should also be pointed out so that others don't form such misconceptions. [...]
 It is not a mistake... only in your mind.
In my experience, an empty declaration or statement is usually a mistake. And it's usually done by people coming from C. If it's not a mistake, it's a pretty weird style choice. A similar thing is `return(foo);`. I'd point that out, too, because like the extra semicolon, it looks like it might be necessary syntax, but it's really just extra punctuation without purpose. Of course, everyone is free to write their code however they want. But if you post here, it can't be surprising when you get feedback on it. Especially when it's an answer to someone else, which means it's more important to write good code, because you're influencing someone who's learning.
 If it was a mistake D wouldn't allow it.
D deliberately allows many mistakes, and they can be much more serious than the little style mishap at hand. [...]
 There is no point in a lot of things, but pretending that life depends
 on such trivial things is a much worse mistake, IMO.
I originally wrote one little line on this. I don't think anyone here is "pretending that life depends on" it.
Aug 13 2016
prev sibling parent reply D.Rex <armstronga94 hotmail.com> writes:
On Friday, 12 August 2016 at 15:23:17 UTC, Cauterite wrote:
 On Friday, 12 August 2016 at 15:21:22 UTC, D.Rex wrote:
 extern unsigned long free_page_tables(struct task_struct * 
 tsk);
extern(C) ulong free_page_tables(task_struct* tsk); void main() { task_struct tsk = …… ; free_page_tables(&tsk); }; That should be what you're after?
Thanks for the answer! I really appreciate it :). I'm not sure if the context of what I wrote is entirely correct, I came across this particular thing (passing structs as parameters) to methods when I was taking a look at some of the linux source code and stumbled upon an instance of this, and realised I had never seen its usage before. The method was in a the mm.h header file 'include/linux/mm.h, line 111 (in Linux Kernel v0.99, and probably in later versions as well) and links to memory.c (mm/memory.c) where it has the same thing (struct task_struct * tsk) - task_struct being already defined in include/linux/sched.h. I suppose declaring the method in mm.h would be pointless in D equivalent anyway since (as far as I am aware) D doesn't have seperate Header and Source files, and the method could simply be declared in memory.d in a D context, and instead of using an import for mm.h for using free_page_tables(), one could simply import memory.d and it would work much the same, please correct me if I am wrong. So going out on a limb here ( and again please correct me if I am mistaken ), given what you have shown above if all code were translated to D, it would look something like: /* memory.d file */ module memory; import include.linux.sched; /* contains task_struct definition */ void free_page_tables(task_struct* tsk) { /* do something with &tsk */ } And to use the method from somewhere else /* use method.d */ module usemethod; import include.linux.sched; import mm.memory; void some method() { free_page_tables(*pointer to task_struct*); } I hope my explanation is not rambling nonsense. Cheers.
Aug 13 2016
parent reply Cauterite <cauterite gmail.com> writes:
On Saturday, 13 August 2016 at 15:47:51 UTC, D.Rex wrote:
 /* memory.d file */
 module memory;
 import include.linux.sched;    /* contains task_struct 
 definition */

 void free_page_tables(task_struct* tsk) {
         /* do something with &tsk */
 }

 And to use the method from somewhere else
 /* use method.d */

 module usemethod;
 import include.linux.sched;
 import mm.memory;

 void some method() {
         free_page_tables(*pointer to task_struct*);
 }

 I hope my explanation is not rambling nonsense.

 Cheers.
Yes, you're right. Passing structure pointers to functions is an extremely common practice in C, because there aren't really any other compelling options. In D we have things like methods, classes, 'const ref' params, return-type inference, etc., so there's usually a better way to achieve the same result.
Aug 13 2016
next sibling parent D.Rex <armstronga94 hotmail.com> writes:
On Saturday, 13 August 2016 at 18:37:54 UTC, Cauterite wrote:
 On Saturday, 13 August 2016 at 15:47:51 UTC, D.Rex wrote:
 /* memory.d file */
 module memory;
 import include.linux.sched;    /* contains task_struct 
 definition */

 void free_page_tables(task_struct* tsk) {
         /* do something with &tsk */
 }

 And to use the method from somewhere else
 /* use method.d */

 module usemethod;
 import include.linux.sched;
 import mm.memory;

 void some method() {
         free_page_tables(*pointer to task_struct*);
 }

 I hope my explanation is not rambling nonsense.

 Cheers.
Yes, you're right. Passing structure pointers to functions is an extremely common practice in C, because there aren't really any other compelling options. In D we have things like methods, classes, 'const ref' params, return-type inference, etc., so there's usually a better way to achieve the same result.
Cheers!! Speaking of classes, and this may have been answered elsewhere, but I am yet to find said answer, or am just missing something right in front of my face...but how does one go about accessing a method from a class if said class is passed to a function as a pointer? By that I mean something like class Foo { void fooMethod() { } void bar(Foo *f) { }
Aug 14 2016
prev sibling parent reply D.Rex <armstronga94 hotmail.com> writes:
On Saturday, 13 August 2016 at 18:37:54 UTC, Cauterite wrote:
 On Saturday, 13 August 2016 at 15:47:51 UTC, D.Rex wrote:
 /* memory.d file */
 module memory;
 import include.linux.sched;    /* contains task_struct 
 definition */

 void free_page_tables(task_struct* tsk) {
         /* do something with &tsk */
 }

 And to use the method from somewhere else
 /* use method.d */

 module usemethod;
 import include.linux.sched;
 import mm.memory;

 void some method() {
         free_page_tables(*pointer to task_struct*);
 }

 I hope my explanation is not rambling nonsense.

 Cheers.
Yes, you're right. Passing structure pointers to functions is an extremely common practice in C, because there aren't really any other compelling options. In D we have things like methods, classes, 'const ref' params, return-type inference, etc., so there's usually a better way to achieve the same result.
Cheers!! Speaking of classes, and this may have been answered elsewhere, but I am yet to find said answer, or am just missing something right in front of my face...but how does one go about accessing a method from a class if said class is passed to a function as a pointer? By that I mean something like class Foo { void fooMethod() { } } void bar(Foo *f) { /* access fooMethod from &f */ } Thanks for all your help, I really appreciate it!!
Aug 14 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 14 August 2016 at 14:54:27 UTC, D.Rex wrote:
 Speaking of classes, and this may have been answered elsewhere, 
 but I am yet to find said answer, or am just missing something 
 right in front of my face...but how does one go about accessing 
 a method from a class if said class is passed to a function as 
 a pointer?
It just works with the regular dot. But don't pass classes as pointers in D except in very rare circumstances. They are already pointers under the hood automatically.
Aug 14 2016
parent reply D.Rex <armstronga94 hotmail.com> writes:
On Sunday, 14 August 2016 at 14:59:17 UTC, Adam D. Ruppe wrote:
 On Sunday, 14 August 2016 at 14:54:27 UTC, D.Rex wrote:
 Speaking of classes, and this may have been answered 
 elsewhere, but I am yet to find said answer, or am just 
 missing something right in front of my face...but how does one 
 go about accessing a method from a class if said class is 
 passed to a function as a pointer?
It just works with the regular dot. But don't pass classes as pointers in D except in very rare circumstances. They are already pointers under the hood automatically.
So you can access a method from a class pointer the same way you would access a method from a class normally? so '&foo.bar();' works the same as 'foo.bar();'? ah that makes sense, classes being pointers behind the scenes, Most of my programming experience is in Java, so the usage of pointers is a rather new concept for me. Thank you kindly for your answer, much appreciated!! :-)
Aug 14 2016
parent Cauterite <cauterite gmail.com> writes:
On Sunday, 14 August 2016 at 16:21:58 UTC, D.Rex wrote:
 so '&foo.bar();' works the same as 'foo.bar();'?
with pointers, D automatically rewrites expressions like this: f.fooMethod() to this: (*f).fooMethod() which is why you're able to index an object-pointer-pointer (Foo*) the same way as an object-pointer (Foo). Most built-in D types have value semantics, so it's understandable that you wouldn't expect classes to be reference types. Associative arrays are also reference types, FYI. Structs on the other hand are value types; if you're new to the language make sure you familiarise yourself with the differences between structs and classes.
Aug 14 2016
prev sibling parent cy <dlang verge.info.tm> writes:
On Friday, 12 August 2016 at 15:21:22 UTC, D.Rex wrote:
 I was wondering how this is achieved in D, or if D has an 
 alternative implementation of this.
It isn't, because C interfaces that require you to pass in structures are inherently bad design, and usually both unstable and extremely C specific. Nobody wants to bother with that, and get stuck maintaining it to boot. You have to re-define the struct in D's language in order to comprehend it, but then you look in libuv and you see things like: struct uv_shutdown_s { UV_REQ_FIELDS uv_stream_t* handle; uv_shutdown_cb cb; UV_SHUTDOWN_PRIVATE_FIELDS }; and you let out a slow, agonized groan of disgust, because now you have to go searching through the CPP parser output manually to determine the nature of the struct. Once you've done that, your code is unstable and likely to stop working with even minor version changes, because the C programmers used those #define statements on the assumption that what substitutes in there won't always remain the same. And since C doesn't check the size of a structure, you usually get no error when they add another byte in the middle, only silent failures and breakage. But... assuming you're forced to do this, you'd run the header file through cpp with all the relevant flags. There is no parser for C that works in the general case (and C programmers just LOVE using all the horrible edge cases), but you can just manually go through and look at the structures you want to use. For instance: struct uv_shutdown_s { void* data; uv_req_type type; void* active_queue[2]; void* reserved[4]; uv_stream_t* handle; uv_shutdown_cb cb; }; cpp doesn't fill in typedefs, so you have to manually go and look at what those are (and hope that they don't change depending on compilation parameters). Oh, and I should mention cpp erases all newlines, so any substitution is all going to be crammed on a single line. But once you see that, then you make a uv.d file containing: ... alias ShutdownCallback = void function(shutdown*, int); struct Shutdown { void* data; Req type; void*[2] active_queue; void*[4] reserved; Stream* handle; ShutdownCallback cb; } as well as the same thing done for "req" (uv_req_t) and "stream" (uv_stream_t). Then you can just... extern (C) int uv_shutdown(Shutdown*, Stream*, ShutdownCallback); extern (C) void* malloc(size_t); void foo(Stream* something, int delegate() handle) { Shutdown* req = cast(Shutdown*)malloc(Shutdown.sizeof); req.data = handle; // ? uv_shutdown(req, something, unpack_delegate); } ...and it'll work, until they change something, or you try to switch to a 64 bit machine, or something. ...and if instead, libuv used an opaque structure for Shutdown and Stream, and functions to access its data, you could do this: struct Shutdown; struct Stream; extern (C) int uv_shutdown(Shutdown*, Stream*, ShutdownCallback); extern (C) Shutdown* uv_new_shutdown(); void foo(Stream* something, int delegate() handle) { Shutdown* req = uv_new_shutdown(); req.data = handle; uv_shutdown(req,stream,unpack_delegate); } Much simpler, no? Plus it's stable even when they change the structure of their implementation. When I have to write a C library, I almost always write a C interface that doesn't suck, in order to do the things I want with that library. Then at least when they change their internal structure, my C can recompile, and present a stable and simple ABI to the D side of things. This is actually a problem for every language that's not C, not just D. Passing structs as arguments to your interface just always makes things harder for language supporters.
Aug 12 2016