19 Jan, 2016, Jinx wrote in the 1st comment:
Votes: 0
(Sorry, I posted this in the wrong section earlier although even though I can see it it didn't see to render to any board that is accessible if you look at the thread listings of recent posts and it also wouldn't let me delete it).

This maybe a noob question.

In ROM and MERC (but not Diku) the methods that are declared globally in .h files have "args" wrapped around them like:

int get_skill args((CHAR_DATA *ch, int sn));


Instead of:

int get_skill(CHAR_DATA *ch, int sn);


They seem unnecessary (and I saw in the Ice project that they were taken out all together). Does anyone know why they're there or what purpose they serve/served? It seems to be a Merc construct, at least searching stackoverflow I can't find other examples of this being done which isn't to say they aren't there, I just couldn't find them.
19 Jan, 2016, Tyche wrote in the 2nd comment:
Votes: 0
It was for very ancient non-ansi C compilers. I believe it was done at the time for Irix.
19 Jan, 2016, Jinx wrote in the 3rd comment:
Votes: 0
Very cool. Thank you for the response and the history. :-)
20 Jan, 2016, Kaz wrote in the 4th comment:
Votes: 0
To expand on Tyche's brief description…

Once upon a time (before 1989, when C was standardized), C functions declarations had only an empty arguments block, and the names of the arguments were later added in the function definition itself:

int foo();

/* … */

int foo(int a, char *b)
{
}


Note: this is still possible now: it's the reason for the "int foo(void)" syntax in declarations: that one actually declares a function with no parameters, as opposed to a function with unspecified parameters.

Since Diku was released in (IIRC) 1991, it's possible that some of the compilers they were using had not yet implemented the ability to have typed function arguments in the declarations, and thus they had the args() macro to provide a compile-time switch.

It's completely and utterly obsolete now.
20 Jan, 2016, Jinx wrote in the 5th comment:
Votes: 0
Did I read that to mean in today's world that the (void) is still important as it explicitly says there are no parameters?

int foo(void);


instead of:

int foo();


… where foo really does have no parameters?
20 Jan, 2016, Kaz wrote in the 6th comment:
Votes: 0
Jinx said:
Did I read that to mean in today's world that the (void) is still important as it explicitly says there are no parameters?

int foo(void);


instead of:

int foo();


… where foo really does have no parameters?


*In C*, yes. A function declaration with no parameters declares a function with *an unspecified number* of parameters. You can try this yourself:

#include <stdio.h>
int foo();

int main()
{
printf("%d\n", foo(1, 2, 3));
return 0;
}

int foo(int a, int b, int c)
{
return a + b + c;
}


*In C++*, a function declaration with no declared parameters declares a function that takes no parameters.
21 Jan, 2016, Jinx wrote in the 7th comment:
Votes: 0
Understood. Thank you for the explanation. I code in C# professionally and know it like the back of my hand but I'm basically a C hobbyist. I know how to create code without leaking memory but some of the details I just haven't learned yet (some like this is a result of just duplicating what previously worked and not questioning it).

I'm currently coding on both Ubuntu and in Visual Studio (they get me different things, on Linux I can use Valgrind, with VS I can quickly pause and view the state of anything easily), was looking at tools to auto prototype methods for me but I may write my own (which I'll probably either write in Python or C# depending on environment). Back in the late 90's I had written an IDE that made coding ROM (for me) much quicker, I am thinking about doing something similar now for it via Visual Studio (via extensions) and then sharing it via GitHub. Not rocket science, but automating common tasks (you want to create a command, a dialog will pop up and it will make the entries into interp.c, interp.h and stub a function for you in the file of your choice, etc.).

Anyway, thanks again for all responses. They're much appreciated.
21 Jan, 2016, Tyche wrote in the 8th comment:
Votes: 0
Jinx said:
… was looking at tools to auto prototype methods for me

I use a tool called cproto on old C code to generate correct prototypes and headers.
21 Jan, 2016, Jinx wrote in the 9th comment:
Votes: 0
Tyche said:
Jinx said:
… was looking at tools to auto prototype methods for me

I use a tool called cproto on old C code to generate correct prototypes and headers.


Funny you mention that, I went to apt-get it the other day and the package manager couldn't find the remote server (even with an update). I did find the code for it and was going to compile it but haven't gotten a chance to yet. Thanks for the suggestion!
25 Jan, 2016, quixadhal wrote in the 10th comment:
Votes: 0
It should be noted that there is a difference between a function prototype and a function declaration. :)

When you do something like:

int foo();

int foo(char *bar) {
return 1;
}


The prototype is only there to tell the compiler that the syntax element "foo" is a function, and that it shouldn't complain about foo being undeclared, nor allow one to do foo = 37 without throwing a warning.

It does not really mean the number of arguments is variable, which is a whole different can of worms. "Unspecified" is correct, just don't confuse that with "variable". :)

In practice, I've ALWAYS found it best to write functions with their parameters fully specificed and then put prototypes in a seperate header file of the same name.

/* foo.h */
#ifndef __FOO_H__
#define __FOO_H__
/* function prototypes here */
int foo(char *bar);
#ifndef __FOO_C__
/* extern declarations for variables here */
extern int pfft;
#endif
#endif

and
/* foo.c */
#define __FOO_C__
#include "foo.h";

int global_pfft;

int foo(char *bar) {
return 1;
}


That way, everything that wants to use foo() can include foo.h and be happy, including foo.c itself.
26 Jan, 2016, Jinx wrote in the 11th comment:
Votes: 0
For better or worse I almost always keep them in merc.h and pretty much put everything there. I do group them by file at least so they'd be easy to copy or extract if someone wanted everything from say druid.c.

Thanks again for the responses.
0.0/11