9

Consider this piece of code:

#include <iostream>

int main () { 
  std::string str = "not default";
  std::cout << str << std::endl;
  return 0;
}

Running clang-tidy -checks=* string.cpp gives the following:

7800 warnings generated.
/tmp/clang_tidy_bug/string.cpp:4:21: warning: calling a function that uses a default argument is disallowed [fuchsia-default-arguments]
  std::string str = "not default";
                    ^
/../lib64/gcc/x86_64-pc-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/basic_string.h:509:39: note: default parameter was declared here
      basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
                                      ^
Suppressed 7799 warnings (7799 in non-user code).

Is there some other argument that can be passed to make this warning go away? I am not really using any argument defaults here. But the implementation of std::string does.

Edit: Changed the code to simplify the test case.

urmish
  • 127
  • 1
  • 6
  • 1
    Does `clang-tidy -checks=*,-fuchsia-default-arguments string.cpp` work? – Justin Jul 06 '18 at 21:15
  • 4
    A lot of clang-tidy's checks are specific to certain organizations, so I do not recommend turning on all checks. It would be best to only turn on the checks that you want – Justin Jul 06 '18 at 21:17
  • I could ignore these, but I was wondering if there was a coding solution for this common occurrence. The piece of code I posted is pretty basic. I am just curious if someone knows an alternate approach to this. – urmish Jul 06 '18 at 21:59
  • Why would you enable the "fuchsia*" warnings for your C++ program? – Jesper Juhl Jun 13 '23 at 01:13

1 Answers1

8

I am not really using any argument defaults here. But the implementation of std::string does.

The string class defined the default argument. But you used the default argument by calling the constructor without passing the second argument explicitly.

Is there some other argument that can be passed to make this warning go away?

Yes. If you pass all arguments explicitly (including defaulted ones), then nothing is going to warn about using the default arguments†. The argument that you need to pass in this case is the second argument of the string constructor, as helpfully pointed out by the warning message. It is the allocator for the string. It has the type std::allocator<char>.

Note that in order to pass more than one argument in copy-initialization expression, you need to use a braced-init-list:

std::string str = {
    "actually not default",
    std::allocator<char>(),
};

† That said, it isn't generally considered a bad practice to use default arguments, and you might arguably be better off by keeping the use and disabling the warning instead. But whether that's the case, is mostly based on opinion. Strangely enough, both the warning name, and documentation imply that the warning is intended for the fuchsia codebase, yet fuchsia docs explicitly allow the use of default arguments (but suggests using "judgement").

eerorika
  • 232,697
  • 12
  • 197
  • 326
  • Thank you. I agree with the users saying that using defaults isn't a bad practice. This is mostly an academic exercise for me. I am trying to clear up warnings for a piece of code I have written. I hadn't heard about `std::allocator`, which I can now look into. – urmish Jul 07 '18 at 01:17
  • 2
    Just to add a bit to the discussion: At first I thought this check is overly pedantic, but there seem to be some issues that can occur with default arguments. On the other hand the suggested code above is not desirable either. I just checked that if I use std::string_view instead, the check seems not to be triggered (no allocator here). So if a different type is applicable, this migh be another option. – tom_imk Sep 30 '19 at 11:14