With this sample program I observe a different behavior in g++ and clang
Foo.h:
#include <iostream>
namespace Bar
{
class Foo
{
public:
Foo(int x) : _x(x)
{}
int x() const
{
return _x;
}
private:
int _x;
};
}
std::ostream& operator <<(std::ostream& os, const Bar::Foo* foo);
Foo.cpp
#include <Foo.h>
using namespace std;
ostream& operator <<(ostream& os, const Bar::Foo* foo)
{
return os << foo->x();
}
main.cpp
#include <iostream>
using namespace std;
template<typename T>
void print(const T& t)
{
cout << t << endl;
}
#include <Foo.h>
int main(int argc, char** argv)
{
Bar::Foo* foo = new Bar::Foo(5);
print(foo);
}
Compiling with clang++ and g++ produce different results:
air:~ jose$ clang++ Foo.cpp main.cpp -I.
air:~ jose$ ./a.out
0x7ff9e84000e0
air:~ jose$ g++ Foo.cpp main.cpp -I.
air:~ jose$ ./a.out
5
Which one is correct and why?.
In this particular case, clang++ is correct.
The problem is how lookup is performed inside the template print. In the expression inside print the call to operator<< is dependent. Name resolution for dependent names is handled in 14.6.4:
In resolving dependent names, names from the following sources are considered:
— Declarations that are visible at the point of definition of the template.
— Declarations from namespaces associated with the types of the function arguments both from the instantiation context (14.6.4.1) and from the definition context.
In your case, the declaration of your operator is not visible at the point of definition of the template, since the header is included afterwards, and it does not live in any of the associated namespaces of the function arguments (namely ::std for ::std::ostream and ::Bar for ::Bar::Foo*), so it won't be found.
Now, there is an overload in ::std that takes a void*, and that will be found by Argument Dependent Lookup. The ::Bar::Foo* will be converted to a void* and the address will be printed.
That is, in a standard compliant compiler.
I forgot to add this here, and left it only in the comment, but it is important enough:
Always define the operators that apply to your types in the same namespace that holds the types on which they apply. Let Argument Dependent Lookup do it's magic for you. It was specifically designed to serve this particular purpose, use it.
Related
I have a C-struct (in a C header file) that looks like so:
struct Foo {
int a;
int b;
int c;
};
typedef struct Foo Foo;
I want to test equality of two vectors of these structs, and so I would like to define a custom equality operator for this struct for just my translation unit.
I am able to do so with
static inline bool operator==(const Foo&, const Foo&) {...}
but not with
namespace {
bool operator==(const Foo&, const Foo&) {...}
}
Why can the equality template for std::vector not find this operator, and is there a better way than tossing a static inline in the global namespace?
I think you'll find that std::vector actually does find the operator in the anonymous namespace, if that operator's declaration occurs before #include <vector>.
The reason it doesn't find it in your code is related to the two-phase lookup for names in template functions. The first phase finds candidates in all namespaces in scope. The second phase only finds dependent names. "Argument-dependent lookup" which searches the namespace containing the type is dependent just as the phrase says. Lookup in the anonymous namespace is not dependent, so it won't be done during the second phase.
See also:
Declare function after template defined
Template specialization doesn't see a function in its point of instantiation
Why does the compiler find my function if is not yet declared?
The first thing to be noted is that an anonymous namespace is not the same as no namespace.
namespace
{
bool operator==(const Foo&, const Foo&) {...}
}
is really something like
namespace ANameUniqueToTheFile
{
bool operator==(const Foo&, const Foo&) {...}
}
using ANameUniqueToTheFile;
with the downside that the language does not give you the ability to get the name of the namespace.
For that reason, the operator== function defined in the anonymous namespace is not found using ADL.
I can see why you would want to put the operator== function in a namespace. One possbile way to do that would be to #include the .h file that defines the struct inside a named namespace.
FooWrapper.h:
namespace MyApp
{
#include "foo.h"
// Declare the function.
bool operator==(Foo const& lhs, Foo const& rhs);
}
FooWrapper.cpp
#include "FooWrapper.h"
namespace MyApp
{
// Implement the function.
bool operator==(Foo const& lhs, Foo const& rhs) { ... }
}
However...
I realize that I'm simplifying a bit about what's in "foo.h". Adding all of them in namesapce MyApp might not be appropriate, specially if "foo.h" includes other .h files and/or standard header files. I am hoping it gives you some ideas on how to tackle the problem.
If putting all of "foo.h" in namespace MyApp does not work smoothly, it will probably be expedient to define the operato== function in global scope.
I am writing a simple logger class similar to QDebug, which has a template method that save data into QStringList. The code is here:
#include <QtCore/QString>
#include <QtCore/QStringList>
#include <QtCore/QTextStream>
class Logger
{
public:
Logger();
~Logger();
template <typename V>
Logger &operator<<(V const &value);
private:
QStringList msg;
};
inline Logger::Logger():
msg(QString("INFO:"))
{}
inline Logger::~Logger()
{
QTextStream out(stderr);
out << msg.join("");
}
template <typename V>
inline Logger &Logger::operator<<(V const &value)
{
msg << log(value);
return *this;
}
inline QString log(QString const &value)
{
return value;
}
inline QString log(int const (&value)[20])
{
return QString("Array");
}
int main(int argc, char *argv[])
{
Logger c;
int a[20] = {};
c << QString("test") << a;
return 0;
}
However, this doesn't compile with GCC 4.8.3.
$ g++ -I/usr/include/qt4 -L/usr/lib64/qt4 -lQtCore -o test2 test2.cpp
test2.cpp: In instantiation of ‘Logger& Logger::operator<<(const V&) [with V = int [20]]’:
test2.cpp:50:29: required from here
test2.cpp:32:21: error: ‘log’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
msg << log(value);
^
test2.cpp:41:16: note: ‘QString log(const int (&)[20])’ declared here, later in the translation unit
inline QString log(int const (&value)[20])
Indeed, if I move inline QString log(int const (&value)[20]) to the beginning or put a forward declaration, it compiles and works. But what confuses me is that inline QString log(QString const &value) works without any problem:
$ ./test2
INFO:testArray
I notice that QHash relies on qHash function, which is similar in this case. QHash works pretty fine with user-defined key classes (except arrays, which can't be a function return type).
Why do they behave differently? What did I miss here?
Thank you for your help.
BTW: Would you please tell me what would be good keywords for this question. I've tried combinations of "specialiation" "template" "forward declaration" "QHash" and "user-defined types", but they don't work.
The name log is looked up twice. At the point of template definition, ordinary lookup is performed. It doesn't find anything, since log is not declared at this point.
Then, at the point of instantiation, only argument-dependent lookup is performed. When the parameter is of type QString, the global namespace is searched since QString is declared there, and so log(QString) is found. But the type int[] doesn't have any associated namespaces, so argument-dependent lookup has nothing to search and finds nothing. Hence the error.
I have noticed a strange behavior when trying to compile the code included below. I have 4 files as follows
createshared.h:
#ifndef CREATESHARED_H_
#define CREATESHARED_H_
#include <memory>
#include <utility>
#ifdef USE_REFREF
template<typename T, typename... Args>
std::shared_ptr<T> create_shared(Args&&... args)
{
class HelperClass : public T
{
public:
HelperClass (Args&& ... nargs) : T(std::forward<Args...>(nargs)...) {}
virtual ~HelperClass() = default;
};
return std::make_shared<HelperClass>(std::forward<Args...>(args)...);
}
#else
template<typename T, typename... Args>
std::shared_ptr<T> create_shared(Args... args)
{
class HelperClass : public T
{
public:
HelperClass (Args ... nargs) : T(nargs...) {}
virtual ~HelperClass() = default;
};
return std::make_shared<HelperClass>(args...);
}
#endif
#endif
staticinitclass.h
#ifndef STATICINITCLASS_H_
#define STATICINITCLASS_H_
class StaticInitClass
{
public:
#ifdef INITIALIZE_IN_HEADER
static const int default_i = 1;
#else
static const int default_i;
#endif
virtual ~StaticInitClass() = default;
StaticInitClass() = delete;
protected:
StaticInitClass(int i);
};
#endif
staticinitclass.cpp:
#include "staticinitclass.h"
#include <iostream>
#ifndef INITIALIZE_IN_HEADER
const int StaticInitClass::default_i = 2;
#endif
StaticInitClass::StaticInitClass(int i)
{
std::cout << "Created with " << i << std::endl;
}
main.cpp:
#include "staticinitclass.h"
#include "createshared.h"
#include <memory>
int main(int argc, const char* argv[])
{
auto shared = create_shared<StaticInitClass>(StaticInitClass::default_i);
}
With no flags, the program compiles and runs fine.
$ g++ -std=c++11 main.cpp staticinitclass.cpp
$ ./a.out
Created with 2
Fine, because default_i is an integral type, we can initialize it in the header. Let's do that
$ g++ -std=c++11 main.cpp staticinitclass.cpp -DINITIALIZE_IN_HEADER
$ ./a.out
Created with 1
Good, still compiles and works fine. Now, let's add our && and std::forward
$ g++ -std=c++11 main.cpp staticinitclass.cpp -DINITIALIZE_IN_HEADER -DUSE_REFREF
/tmp/cc3G4tjc.o: In function `main':
main.cpp:(.text+0xaf): undefined reference to `StaticInitClass::default_i'
collect2: error: ld returned 1 exit status
Linker error. Well, let's now try initializing our default_i member in the .cpp
$ g++ -std=c++11 main.cpp staticinitclass.cpp -DUSE_REFREF
$ ./a.out
Created with 2
And it works again. Using clang yields the same result, which would lead me to believe that this isn't just an isolated compiler error, but perhaps something in the language itself that prevents the static initialization. I just can't seem to connect why adding && would cause the break.
Currently I am using g++ 4.8.2 and clang++ 3.5 on Ubuntu 14.04
Any ideas what is broken here when using -DINITIALIZE_IN_HEADER and -DUSE_REFREF?
Following §9.4.2 [class.static.data]:
3 If a non-volatile const static data member is of integral or enumeration type, its declaration in the class definition can specify a brace-or-equal-initializer in which every initializer-clause that is an assignment expression is a constant expression (5.19). [...] The member shall still be defined in a namespace scope if it is odr-used (3.2) in the program and the namespace scope definition shall not contain an initializer.
In other words, giving a const static data member a value directly in a header does not mean you don't need to define that data member. You should have this in staticinitclass.cpp file:
#ifndef INITIALIZE_IN_HEADER
const int StaticInitClass::default_i = 2;
#else
const int StaticInitClass::default_i; // this is what you don't have
#endif
Binding to a reference (to a forwarding reference && in your case deduced as const lvalue reference) counts as odr-use of this data member.
In case you don't use a forwarding reference and you take the argument by-value, then it is not an odr-use of that static data member, therefore no linker error is raised.
Here is the code:
struct foo {
template<typename T = void>
friend foo f() { return {}; }
};
int main() {
auto x = f(); // clang++ can't find it, g++ can.
}
clang++ 3.4 gives:
fni2.cpp:8:12: error: use of undeclared identifier 'f'
auto x = f(); // clang++ can't find it, g++ can.
^
1 error generated.
g++ 4.9.0 compiles it, but I don't think it should have. This is a related question, but there was no definitive answer. Section 15.4.2/2,4 discuss this, but neither of them say anything to suggest that friend function templates defined in-class should have different visibility from non-template friend functions defined in-class.
This is of academic interest to me only, though it did arise from a question by someone else who may have had an actual use case.
It looks like a g++ bug to me.
Yes, this is an error. I'm surprised it's finding the function. Apparently GCC fails entirely to hide function templates.
This C++03 example also compiles, so it could be a regression:
struct foo {
template<typename T >
friend void f( T ) { }
};
int main() {
f( 3 ); // clang++ can't find it, g++ can.
}
I have the following code (stripped down version from actual project to reproduce
the issue) that results in a compiler error on RHEL5 (g++ version 4.1.2):
----------- driver (test.cpp)--------------
#include <iostream>
#include <classa.hpp>
#include <func.hpp>
namespace globals {
static int kth(const A& a) {
return kth(a.ival());
}
}
using namespace globals;
int main() {
A a;
std::cout << func(a) << std::endl;
return 0;
}
----------class A (classa.hpp)------------
class A {
public:
A():val(0){}
const int ival() const {return val;}
private:
int val;
};
------- namespace globals (func.hpp) ------
namespace globals {
int kth(const int& c) {
return c;
}
template <class T>
int func(const T& key) {
return kth(key);
}
}
--------------------------------------------
Compiling it using g++ 4.1.2 gives me the following error:
func.hpp: In function ‘int globals::func(const T&) [with T = A]’:
test.cpp:15: instantiated from here
func.hpp:8: error: invalid initialization of reference of type ‘const int&’ from
expression of type ‘const A’
func.hpp:2: error: in passing argument 1 of ‘int globals::kth(const int&)’
Same code compiles and runs perfectly fine on RHEL4 (g++ version 3.4.6)! Any explanations/ideas/suggestions on how to resolve this error(?) on RHEL5 will
be much appreciated!
Edit:
Thanks Sergey. That is the obvious solution that I am aware of already. But I forgot to add that the restriction is that func.hpp cannot be edited (for e.g., its 3rd party write-protected). Any workarounds?
Here's what happens. When the function func() is defined, the compiler doesn't know about the function kth(const A&) yet because it is defined later in the code. So when it encounters a reference to kth() inside func(), it assumes that it is a reference to kth(const int&). Now when func() is actually instantiated, it fails to compile it because T is A, not int. I am not sure why it works in another version of the compiler, but I think it is because it actually starts resolving references when a template function is instantiated, not when it is declared. But this looks like a bug in the older version because with such behavior a function definition changes depending on where it is instantiated from, which is very confusing.
The only way to fix your code that it works with any compiler would be to put the definition of kth(const A&) between kth(const int&) and func() or a forward declaration of kth(const A&) somewhere above func().
Update
With the restriction of not editing func.hpp the best workaround I can think of is to create a custom header file with something like this:
#include <classa.hpp>
namespace globals {
static int kth(const A& a); // defined later, but used by func.hpp
}
#include <func.hpp>
I also don't see why kth(const A&) is defined as static, but used by a global header. I'd rather put it into the classa.cpp and its declaration into the classa.hpp. But this may be some design feature or artifact I am not aware of.