Named parameters in C

http://blog.noctua-software.com/named-parameters-in-c.html

by guillaumec • 12 years ago

65 35 12 years ago

abcd_f• 12 years ago

Clever, but seems like a solution in a search of a problem.

davekeck• 12 years ago

The problem is that arguments are often ambiguous without the accompanying function declaration. (And the problem's exasperated when there are lots of arguments.)

The solution is named arguments, but I'm not convinced the added complexity of this solution is a net improvement.

JetSpiegel• 12 years ago

If you are writing in C, cryptic and unnecessary truncation is half the fun!

clarry• 12 years ago

Maybe there are some situations in which named arguments could be a genuine improvement, but I think in general it just encourages sloppiness and unneeded verbosity. It encourages writing functions that needlessly take way too many parameters (can't you instead think of a way to simplify the problem?). It encourages calling functions without paying attention to all the parameters, which you usually shouldn't ever ignore. Just like you shouldn't arbitrarily ignore return values. If you don't know your function like the back of your hand, you need documentation. Of course, documentation might be sparse in sloppy code that encourages people to ignore the details...

C is like that really. You really need to pay attention to detail when you're writing C. And if there's too much to worry about, it means you need to redesign and simplify the APIs and/or data you're dealing with.

If I encounter functions with lots of parameters in third party libraries I have to use, I will annotate each argument with a comment (after checking the documentation).

userbinator• 12 years ago

When writing in C, usually you either know the function well enough (including having just written it) to have memorised the arguments, have another window containing the declarations, or else you'll be using an IDE that tells you what the arguments are (along with a lot of other information.)

dllthomas• 12 years ago

I find this problem exacerbated by using a lot of primitive types, and ameliorated (though not eliminated) by wrapping things in context-specific single element structs.

Given:

    int price, quantity;

compare

    place_order(price, quantity);

with

    {
        price_t px = { price };
        quantity_t qx = { quantity };

        place_order(qx, px);
    }

More verbose (especially where, like above, the values weren't already wrapped), but catches a significant error.

It does not permit reordering arguments like the struct approach does, and doesn't help where you have multiple arguments of the same type that it is unreasonable to distinguish.

xuhu• 12 years ago

Doesn't work in MSVC though.

pling• 12 years ago

That's not a proper C compiler though, as Microsoft like to point out regularly as a lame excuse...

fdej• 12 years ago

Yet enough people think it's a C compiler that if you try to use avant garde C99 features in your C project, someone will invariably complain that MSVC doesn't build it.

pjmlp• 12 years ago

MSVC is actually called MSVC++.

Microsoft is committed to C++, as a means to improve systems programming safety with more modern languages.

Besides, the code makes use of GCC extensions.

yxhuvud• 12 years ago

The article specifically states that it requires C99, so of course it doesn't.

eq-2• 12 years ago

C99 compiler won't do, it also requires a GCC extension (statement expressions).

cremno• 12 years ago

Yes, designated initializers were added in ISO C99 and since Visual Studio 2013 they are also supported by MSVC.

But the code is neither ISO C99 nor C11. It uses a GNU C extension called “statement expressions”, which is not supported by MSVC.

Also, its preprocessor has quite a few problems. I think after removing statement exprs and running the code through a different PP, MSVC will compile it.

Of course, one could just simply use MinGW or Clang instead.

nitrogen5• 12 years ago

Named arguments can be done by passing a struct as the only parameter to a function, without the complicated macros. Missing arguments become 0, so you get optional parameters for free.

    func((struct somestruct){.x = 0, .y = 1});

dsego• 12 years ago

What's the point in that? Then you have to write all your functions to accept structs instead of natural arguments.

ygra• 12 years ago

http://c2.com/cgi/wiki?ParameterObject

Sometimes it's a good way to go.

simgidacav• 12 years ago

...agreed, what's the point? Besides, a lot of includes are already a mess of #defines, do we really need another bunch of them?

eliteraspberrie• 12 years ago

This (compound literals) also has the advantage of being strictly valid C, since compound statements are a GNU extension.

micampe4• 12 years ago

I find your statement puzzling. A GNU extension is by definition not “strictly valid C”, compound literals are valid C because they are defined in C99.

peaton• 12 years ago

Wow, that's really interesting. I had no idea this was possible. Do you know of any links to tutorials or blog posts on this? I'd love to see a more detailed example.

micampe4• 12 years ago

A value of 0 is not the same thing as a missing value.

mpyne• 12 years ago

That's true, but the parent comment never claimed that, only that missing arguments are assigned the value 0 in the resultant struct.

CountHackulus• 12 years ago

And that's almost exactly what the macro expands to. It's just some nice syntactic sugar on top.

nitrogen5• 12 years ago

The function declaration with the macro is a bit awkward, IMO. I don't mean to downplay the awesomeness of the macro approach, though; FOR_EACH and putting __VA_ARGS__ at the beginning of the macro argument list isn't something I had considered before.

codehero• 12 years ago

That is really cool.

Combine this with struct definitions in function bodies and I see a great teamup with variadic functions.

Take a theoretical struct_printf, which prints out non promoted data with struct packing (not variadic stack packing, which requires type promotion)

  /* Only uses va_start and va_arg to*/
  void struct_printf(const char* format, ...){
  ...
  }

  void print_foo(){
    struct foo_t{
      float f;
      uint16_t u2;
      uint8_t x;
    } input;

    struct_printf("No type promotion here: %f %hu %hhx\n",
     (struct foo_t){ .f = 0.1, .u2 = 1000, .x = 0xF2});
  }

Now we can actually pass what we mean to pass without the compiler changing it.

NOTE: After I wrote this I'm not actually sure what va_args does with a struct or how to get a pointer to the first member...

nitrogen5• 12 years ago

NOTE: After I wrote this I'm not actually sure what va_args does with a struct or how to get a pointer to the first member...

I think you would still need to know the exact type inside of struct_printf(), unless you knew exactly how the compiler would pack a struct onto the stack or registers, and that it was exactly the same as individual parameters.

Peaker• 12 years ago

Note, %hu and %hhx are not portable ways to print uint16_t and uint8_t.

Instead, you're supposed to #include <inttypes.h> and use:

  "No type promotion here: %f %"PRIu16" %"PRIx8"\n"

eq-2• 12 years ago

It's not (strictly) C, though.

hyperliner• 12 years ago

I think it is an interesting article as a lesson on how macro expansion works.

It is however, a terrible example of how to write good code. Any code that hides the language or manipulates for syntactic sugar only adds complexity, bugs and decreases the maintenability of the code.

As someone already said, a solution in search of a problem.

Named parameters in C

Related Stories