c++ - Why is volatile required with template argument in one case but not other? -

in c++03, have following code built gcc v3.4.6 don't understand why calling _setvaluesafefails() compiler error calling similar _incrvaluesafe() not.

test.h:

class test { public:   void test();    template<typename t> void _incrvaluesafe(t &value) {     ++value;   }    template<typename t> void _setvaluesafefails(t &value, const t setval) {     value = setval;   }    template<typename t> void _setvaluesafeworks(volatile t &value, const t setval) {     value = setval;   }    volatile bool _testvalue;  }; 

test.cpp:

#include "test.h"  void test::test() {   _incrvaluesafe(_testvalue);   _setvaluesafefails(_testvalue, true);   _setvaluesafeworks(_testvalue, true); }  test.cpp: in member function `void test::test()': test.cpp:5: error: no matching function call `test::_setvaluesafefails(volatile bool&, bool)' 

shouldn't _incrvaluesafe() same error since there no volatile in signature either? how these 2 treated differently, or compiler bug?

as others have explained, binding first parameter _testvalue implies t volatile bool, whereas binding second parameter true implies t merely bool (without volatile modifier). clang compiler gives nice diagnostic:

clang++ -o main  -std=c++1y -pedantic -wall -stdlib=libc++ main.cpp -stdlib=libc++ main.cpp:26:5: error: no matching member function call '_setvaluesafefails'     _setvaluesafefails(_testvalue, true);     ^~~~~~~~~~~~~~~~~~ main.cpp:12:35: note: candidate template ignored: deduced conflicting types parameter 't' ('volatile bool' vs. 'bool')         template<typename t> void _setvaluesafefails(t &value, const t setval) {                                   ^ main.cpp:9:13: warning: incrementing expression of type bool deprecated [-wdeprecated-increment-bool]             ++value;             ^ ~~~~~ main.cpp:25:5: note: in instantiation of function template specialization 'test::_incrvaluesafe<volatile bool>' requested here     _incrvaluesafe(_testvalue);     ^ 1 warning , 1 error generated. make: *** [main] error 1 

regarding leading underscores: avoid them, partly avoid debates or isn't strictly legal. prefer popular convention: prefix private variables m_, , don't decorate private function names in special way. (leading underscores de rigeur private members in python, of course, c++ different language.) record, holy standard says following:

17.6.4.3.2 global names [global.names]

---

1. certain sets of names , function signatures reserved implementation:

   — each name contains double underscore __ or begins underscore followed uppercase letter (2.12) reserved implementation use.

   — each name begins underscore reserved implementation use name in global namespace.