Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variadic functions can be used safely #53

Closed
jzwinck opened this issue Sep 28, 2016 · 2 comments
Closed

Variadic functions can be used safely #53

jzwinck opened this issue Sep 28, 2016 · 2 comments

Comments

@jzwinck
Copy link

jzwinck commented Sep 28, 2016

Regarding this: https://github.com/lefticus/cppbestpractices/blob/master/04-Considering_Safety.md#do-not-define-a-variadic-function

Rather than avoiding C-style variadic functions entirely, you should advise to enable type checking for them. This is included in -Wall; you should also suggest -Wformat=2 in the list of useful warnings, as this warns about non-literal format strings etc.

And in the section which currently says not to define variadic functions, you should say, "unless they can be type-checked by your compiler." And if the function is similar to printf(), scanf(), strftime(), etc., it can be. See the "format" attribute described here: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes .

There are times when C-style variadic functions are most convenient, such as making a strftime() method on a user-defined time class. And they can be safe enough.

@lefticus
Copy link
Member

I would have a very hard time suggesting all of these caveats. C++ style variadic templates can do the same things while ensuring safety on all compilers with or without special compiler support.

I may, however, link back to this discussion from inside of the document so that it's known that there are methods by which type safety with C style can be addressed.

@lefticus
Copy link
Member

I have closed this issue and linked back to the doc. Discussion can continue here, even in the closed issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants