This approach makes sense in certain circumstances. But it should not be used as a systematic approach for every function.
In long with more details
It makes very much sense to group into a
struct some groups of parameters that are used repetitively in several functions of your API. This approach is very natural: the repetitive use of the same parameters strongly suggests that these parameters are somehow related. And the
struct only materializes this relation.
The pros is that it makes function calls shorter, makes the API easier to memorize, and in addition enlighten the user about the relation between the struct components.
There are a couple of examples in the standard library, such as
mktime() . But there are many more examples in well known API out there, where the struct is used together with other parameters (e.g. WinAPI where you often have the choice between using either x,y coordiantes or a POINT structure) and not as a lonesome struct parameter.
In everyday programming we sometimes forget the huge progress languages have made. Back in the early days of K&R it was very easy to make mistakes in parameter passing: when calling a function the parameters where just pushed onto the stack (or into registers) assuming that the function would use the same parameters in the same orders. When the caller made a mistake, for example used the parameters in the wrong order, or forgot one, the compiler didn't complain. I remember very well how nasty and difficult such errors were to find.
When Standard C later introduced the function prototypes and parameter checking, it was a blessing! A lot of dumb mistakes were immediately caught by the compiler. For me it was hundreds of hours of late night debugging avoided thanks to the compiler error message. And brought to a team, it's in the tousands of hours if not beyond.
The main problem with the
struct, is exactly that: it makes call-argument-checking less effective: you pass the struct, the compiler is happy. You forgot to initialize one of the struct member? You will suffer; or worse, your code might create a security issue.
This is why this technique should use only when it brings a significant benefit that outweight the risk. Never use this as a systematic approach.