So I have these two classes: Foo and Bar.
//forward declaration for Bar
class Bar;
typedef enum Type { TYPE1, TYPE2, TYPE3 };
// My class Foo
class Foo
{
public:
explicit Foo(Type fooType)
:mType(fooType)
{}
Type getFooType() const
{
return mType;
}
inline bool operator==(const Bar& bar) { return (bar.getBarType() == mType); } //ERROR: error C2027: use of undefined type 'Bar'
private:
Type mType;
};
// My class Bar
class Bar
{
public:
explicit Bar(Type barType)
:mType(barType)
{}
Type getBarType() const
{
return mType;
}
private:
Type mType;
};
Now somewhere in my code, I want to compare two instances (one from the Foo and other from Bar class).
Like this:
if(myBar->getBarType() == myFoo->getFooType())
{
//...
}
QUESTION:
I know that I need to implement operator== to allow this comparation.
So I've done as seen above...
And I get that error, despite the fact that I've made the forward declaration.
What am I missing here that allows me to compare using the operator== on both classes?
You need to define your operator== after the Bar class definition, rather than in the Foo class. Declare it in the class, but define it outside.
inline Foo::operator==(const Bar &bar) const { ... }
This won't quite help with your test above, since you have the Bar element on the left and the Foo on the right, so the operator== in Foo won't be considered. Defining symetric global operator== functions would be useful.
inline bool operator==(const Bar &bar, const Foo &foo) { return foo == bar; }
You say you want this comparison to work...
if(myBar->getBarType() == myFoo->getFooType())
That's comparing the enum Type values returned by the getXType functions, not the Foo and Bar objects themselves, and enums are comparable by default so you don't need to provide your own operator==.
Never-the-less, you have tried to do so, and in...
inline bool operator==(const Bar& bar) { return (bar.getBarType() == mType); } //ERROR: error C2027: use of undefined type 'Bar'
...the problem is that Bar is not defined at the place this function definition appears in the translation unit. You could just declare the function...
inline bool operator==(const Bar& bar);
...then define it later in the translation unit, after the definition of class Bar.
This would still only allow you to omit the explicit getFooType() call when comparing with a Foo as the left-hand-side argument and a Bar at right. To support the other ordering you asked for, you'd need a similar operator inside Bar that worked with a const Foo&.
One more detail... you say...
And I get that error, despite the fact that I've made the forward declaration.
A forward declaration just lets the compile know that Bar is a class, it doesn't tell the compiler that Bar contains a Type getBarType() member function, and that knowledge is needed to compile your operator==.
Related
header.h
class Foo{
public:
void fooFunction(std::map <std::string, Bar> &);
}
class Bar{
public:
void barFunction(std::map <std::string, Foo> &, Foo &);
}
When I try to compile this, I get an error saying Bar is not declared in the scope of fooFunction, and when I switch the order of the declarations, I get an error saying Foo is not in the scope of barFunction.
How can I make them be in the scope of each other? If I need multiple header files, how should I set that up in my makefile and #include s?
You can simply forward-declare the other class in the header that requires it:
class Bar;
class Foo
{
public:
void fooFunction(std::map <std::string, Bar>&);
};
class Bar
{
public:
void barFunction(std::map<std::string, Foo>&, Foo &);
};
This works provided that Foo does not use Bar by value anywhere until after Bar has been defined. That means storing it as a member, passing as parameter, returning value of that type. In this case you're fine, since the Foo parameters are passed by reference.
Note that even though your std::map stores type Bar by value, this is still okay because it's a template and is not resolved until you use it, at which time Bar will be defined.
I'm getting this strange problem which I don't know why happens. The first and second of the following code snippets compile, while the third does not:
Compiles:
class Foo {
public:
Foo() { Bar(); }
private:
class Bar {};
};
Compiles:
class Foo {
class Bar {}; // Or only forward declare here and define later
public:
Foo(Bar) {}
}
Does not compile:
class Foo {
public:
Foo(Bar) {}
private:
class Bar {};
};
What makes the third fail to compile while the first can?
Normally, in C++, you can only reference declarations that were previously made in the translation unit. However, within a class definition, the definition of member functions are allowed to reference declarations which are made later in the class. Basically, the compiler restructures your in-class definitions so that they work as though they were written just after the class.
But this is only true of the function definitions. The declaration of the function (including parameter types) isn't allowed to do this. They can only reference declarations that have already been made in file order.
So you can do this:
class Test
{
public:
void Func(int x) {Inner foo;}
private:
class Inner {};
};
But not this:
class Test
{
public:
void Func(Inner x) {}
private:
class Inner {};
};
First example does not expose anything about private Bar to the outside, while third does.
Third example is pretty much saying, that there exist some class Foo, which has constructor with single argument of type Bar. But Bar is unknown to the outside. Imagine calling such constructor.
Foo f{Foo::Bar{}};
Will result probably in something like Foo::Bar is inaccessible.
The more I program, the more I like the snake_case and the less the CamelCase. There is one particular inconvenience irritating me a bit: I do not like getters start from the get_ prefix, but that is not always possible without some extra work when using the snake_case. Consider, for instance, a getter for a member of enum type defined inside a class,
class bar
{
public:
enum class foo { a, b };
foo foo() const { return m_foo; }
void set_foo(foo new_foo) { m_foo = new_foo; }
private:
foo m_foo;
};
This won't compile since (if I understand correctly) enum foo is hidden in both the setter new_foo parameter type and the private m_foo member declaration by the prior foo() getter declaration. The obvious fix is to name the getter as get_foo, but as I said, I don't like it.
When I compile with Clang it suggests another "workaround":
error: must use 'enum' tag to refer to type 'foo' in this scope
void set_foo(foo new_foo) { m_foo = new_foo; }
^
enum
and the same for m_foo member. The following code indeed compiles fine
class bar
{
public:
enum class foo { a, b };
foo foo() const { return m_foo; }
void set_foo(enum foo new_foo) { m_foo = new_foo; }
private:
enum foo m_foo;
};
It looks like the elaborated type specifiers are even supposed to solve such kind of problems:
Elaborated type specifiers may be used to refer to a
previously-declared class name (class, struct, or union) or to a
previously-declared enum name even if the name was hidden by a
non-type declaration.
But is not that a misuse of a language feature? Have you ever seen anything like that in libraries that use snake_case, such as, for instance, the Standard Library or Boost, or write it yourself?
I have C++ code that boils down to something like the following:
class Foo{
bool bar;
bool baz;
Foo(const void*);
};
Foo::Foo(const void* ptr){
const struct my_struct* s = complex_method(ptr);
bar = calculate_bar(s);
baz = calculate_baz(s);
}
Semantically, the bar and baz member variables should be const, since they should not change after initialization. However, it seems that in order to make them so, I would need to initialize them in an initialization list rather than assign them. To be clear, I understand why I need to do this. The problem is, I can't seem to find any way to convert the code into an initialization list without doing one of the following undesirable things:
Call complex_method twice (would be bad for performance)
Add the pointer to the Foo class (would make the class size needlessly large)
Is there any way to make the variables const while avoiding these undesirable situations?
If you can afford a C++11 compiler, consider delegating constructors:
class Foo
{
// ...
bool const bar;
bool const baz;
Foo(void const*);
// ...
Foo(my_struct const* s); // Possibly private
};
Foo::Foo(void const* ptr)
: Foo{complex_method(ptr)}
{
}
// ...
Foo::Foo(my_struct const* s)
: bar{calculate_bar(s)}
, baz{calculate_baz(s)}
{
}
As a general advice, be careful declaring your data members as const, because this makes your class impossible to copy-assign and move-assign. If your class is supposed to be used with value semantics, those operations become desirable. If that's not the case, you can disregard this note.
One option is a C++11 delegating constructor, as discussed in other answers. The C++03-compatible method is to use a subobject:
class Foo{
struct subobject {
const bool bar;
const bool baz;
subobject(const struct my_struct* s)
: bar(calculate_bar(s))
, baz(calculate_baz(s))
{}
} subobject;
Foo(const void*);
};
Foo::Foo(const void* ptr)
: subobject(complex_method(ptr))
{}
You can make bar and baz const, or make the subobject const, or both.
If you make only subobject const, then you can calculate complex_method and assign to bar and baz within the constructor of subobject:
class Foo{
const struct subobject {
bool bar;
bool baz;
subobject(const void*);
} subobject;
Foo(const void*);
};
Foo::Foo(const void* ptr)
: subobject(ptr)
{}
Foo::subobject::subobject(const void* ptr){
const struct my_struct* s = complex_method(ptr);
bar = calculate_bar(s);
baz = calculate_baz(s);
}
The reason that you can't mutate const members within a constructor body is that a constructor body is treated just like any other member function body, for consistency. Note that you can move code from a constructor into a member function for refactoring, and the factored-out member function doesn't need any special treatment.
You may use delegate constructor in C++11:
class Foo{
public:
Foo(const void* ptr) : Foo(complex_method(ptr)) {}
private:
Foo(const my_struct* s) : bar(calculate_bar(s)), baz(calculate_baz(s)) {}
private:
const bool bar;
const bool baz;
};
If you don't want to use the newfangled delegating constructors (I still have to deal with compiler versions that don't know about them), and you don't want to change the layout of your class, you could opt for a solution that replaces the constructor with const void * argument by a static member function returning Foo, while having a private constructor that takes the output from complex_method as argument (that latter much like the delegating constructor examples). The static member function then does the necessary preliminary computation involving complex_method, and ends with return Foo(s);. This does require that the class have an accessible copy constructor, even though its call (in the return statement) can most probably be elided.
I have the following code
class foo
{
public:
foo() {}
private:
int foo_int;
friend class bar; //----->Statement A
};
class bar
{
public:
void someMethod()
{
foo f;
f.foo_int = 13;
}
};
Now I also read this answer on SO. However I cant put the pieces of puzzle together as to why
the compiler recognizes bar as a type. I was under the impression that it would complain of Bar being an incomplete type however that did not happen. My question is why ?
friend class bar;
is simply a declaration ... there's nothing for the compiler to complain about. The limitation on incomplete types is when the compiler needs information about the type that it doesn't have, such as its size or, for base classes, its members, but for friend it doesn't need anything other than its name.
Note that it doesn't matter where the friend declaration occurs in the class definition ... that it follows private: doesn't make it private. It's better to put it at the top of the class definition.
A friend specification of a class that has not been declared yet acts as a declaration of the class. It is perfectly fine to declare an incomplete type as a friend of a class because the compiler only needs to know about the type being declared.