I'm trying to define a public struct inside a C++ class, and can't figure out how to make it compile. In my header, I have the following:
class AtomUtility
{
public:
struct BoundingBox;
void doWork(struct AtomUtility::BoundingBox bounds);
};
And in the source:
#include"AtomUtility.h"
struct AtomUtility::BoundingBox
{
double xMin, xMax;
};
int main()
{
AtomUtility::BoundingBox *myBox = new AtomUtility::BoundingBox;
myBox->xMin = 0;
myBox->xMax = 10;
AtomUtility *myUtility = new AtomUtility;
myUtility->doWork(*myBox);
delete myUtility;
}
void AtomUtility::doWork(struct AtomUtilty::BoundingBox bounds)
{
//do things...
}
When I attempt to compile this, I get an error: "class "AtomUtility" has no tag member named "BoundingBox".
You've missed the semi-colon after the definition of AtomUtility::BoundingBox and your compiler is getting confused and giving a poor diagnostic.
You're also trying to pass a AtomUtility::BoundingBox* to a function expecting a AtomUtility::BoundingBox
If your compiler gives poor diagnostics it's often useful to try your code on a different compiler. Several are available online, e.g. Comeau, Clang, or a pastebin that compiles, such as http://codepad.org
Quoting https://stackoverflow.com/a/6368118/1483826:
you can only declare pointer or reference to the later class (...). You cannot have objects of later class.
To fix this, you'd need to declare the struct before the class using it as a field.
Related
Lets say I have a class with two member functions.
class Dummy {
public:
void procedure_1();
void procedure_2();
};
At compile time, I want to be sure that, procedure_1 is called before procedure_2. What is the correct way do implement this?
Maybe you could do it with a proxy-class. The idea is, that procedure_2 can't be accessed directly from outside (for example by making it private). procedure_1 would return some kind of proxy that allows the access to procedure_2.
Some code below, allthough I don't consider it clean or safe. And if you want, you can still break the system.
IMO such requirements should be handled without explicit validation, because it's quite cumbersome and impossible to make it absolutely safe.
Instead, the dependency should be well documented, which also seems idiomatic in C++. You get a warning that bad things might happen if a function is used incorrectly, but nothing prevents you from shooting your own leg.
class Dummy {
private:
void procedure_2() { }
class DummyProxy
{
private:
Dummy *parent; // Maybe use something safer here
public:
DummyProxy(Dummy *parent): parent(parent) {}
void procedure_2() { this->parent->procedure_2(); }
};
public:
[[nodiscard]] DummyProxy procedure_1() {
return DummyProxy{this};
}
};
int main()
{
Dummy d;
// d.procedure_2(); error: private within this context
auto proxy = d.procedure_1(); // You need to get the proxy first
proxy.procedure_2(); // Then
// But you can still break the system:
Dummy d2;
decltype(d2.procedure_1()) x(&d2); // only decltype, function is not actually called
d2.procedure_2(); // ooops, procedure_1 wasn't called for d2
}
Instead of "checking" it, just do not allow it. Do not expose an interface that allows to call it in any other way. Expose an interface that allows to only call it in specified order. For example:
// library.c
class Dummy {
private:
void procedure_1();
void procedure_2();
public:
void call_Dummy_prodedure_1_then_something_then_produre_2(std::function<void()> f){
procedure_1();
f();
procedure_2();
}
};
You could also make procedure_2 be called from destructor and procedure_1 from a constructor.
#include <memory>
struct Dummy {
private:
void procedure_1();
void procedure_2();
public:
struct Procedures {
Dummy& d;
Procedures(Dummy& d) : d(d) { d.procedure_1(); }
~Procedures() { d.procedure_2(); }
};
// just a simple example with unique_ptr
std::unique_ptr<Dummy::Procedures> call_Dummy_prodedure_1_then_produre_2(){
return std::make_unique<Dummy::Procedures>(*this);
}
};
int main() {
Dummy d;
auto call = d.call_Dummy_prodedure_1_then_produre_2();
call.reset(); // yay!
}
The above are methods that will make sure that inside one translation unit the calls will be ordered. To check between multiple source files, generate the final executable, then write a tool that will go through the generated assembly and if there are two or more calls to that call_Dummy_prodedure_1_then_produre_2 function that tool will error. For that, additional work is needed to make sure that call_Dummy_prodedure_1_then_produre_2 can't be optimized by the compiler.
But you could create a header that could only be included by one translation unit:
// dummy.h
int some_global_variable_with_initialization = 0;
struct Dummy {
....
};
and expose the interface from above into Dummy or add only the wrapper declaration in that library. That way, if multiple souce files include dummy.h, linker will error with multiple definitions error.
As for checking, you can make prodedure_1 and procedure_2 some macros that will expand to something that can't be optimized by the compiler with some mark, like assembly comment. Then you may go through generated executable with a custom tool that will check that the call to prodedure_1 comes before procedure_2.
I want to build a somewhat flexible inheritance for different HLSL-Shaders. Sadly my planned route did not work, and i am wondering why. Here is what i am doing:
I have a base-struct and some structs which inherit from it:
struct baseStruct {};
struct childStruct1 : public baseStruct {
int someInt1;
int someInt2;
}
struct childStruct2 : public baseStruct {
float someFloat1;
bool someBool1;
}
And an abstract class with pure virtual functions declared like this:
class BaseClass {
virtual void Function1(baseStruct& structVal) = 0;
virtual void Function2(baseStruct& structVal) = 0;
}
This is the according child class:
class ChildClass {
void Function1(baseStruct& structVal);
void Function2(baseStruct& structVal);
}
Now i want to be able to call either of those functions with different structs, which have baseStruct as a parent like this:
childStruct1 cS1;
cS1.someInt1 = 5;
CS1.someInt2 = -3;
Function1(cS1);
The compiler is not complaining, but when i step through my program i noticed that the struct is filled with values before the function, but as soon as i step into my function the struct is empty. Now my first impression would be, that this happens because it gets "casted" to a baseStruct, which is empty.
Is there a way to achieve something like this, or am i doing something wrong? Maybe this is even possible and i fucked up somewhere else, but then why does the debugger say its empty?
Thank you!
The struct you see in the debugger is empty because when you enter Function1 the debugger 'forgets' any info about cs1 and knows just about baseStruct (which is empty).
If you do something like
childStruct *cs1 = reinterpret_cast<childStruct1>(&structVal) ;
yoy should see everything there.
But this takes to the real problem of you design: how do you tell, inside Funtion1 if you have received a childStruct1 or childStruct2?
I have a C++ class using Core Audio structs on OS X.
My initial implementation was like this:
class MyClass
{
private:
AUNode _converterNode;
AURenderCallbackStruct _renderCBStruct;
public:
MyClass();
~MyClass();
inline AUNode* getConverterNode() { return &_converterNode; }
inline AURenderCallbackStruct* AURenderCallbackStruct() { return &_renderCBStruct; }
};
After reading the Poco style guides, I wanted to change the order of the private/public blocks. It then looked like this:
class MyClass
{
public:
MyClass();
~MyClass();
inline AUNode* getConverterNode() { return &_converterNode; }
inline AURenderCallbackStruct* AURenderCallbackStruct() { return &_renderCBStruct; }
private:
AUNode _converterNode;
AURenderCallbackStruct _renderCBStruct;
};
The compiler now tells me that the type AURenderCallbackStruct is unknown and tells me to replace the type name with ::AURenderCallbackStruct. When I do that, there are no compiler errors.
Weirdly, this only appears for the `AURenderCallbackStruct and not the AUNode.
The AURenderCallbackStruct is defined like this:
typedef struct AURenderCallbackStruct {
AURenderCallback inputProc;
void * inputProcRefCon;
} AURenderCallbackStruct;
and AUNode is defined like this:
typedef SInt32 AUNode;
Can anyone explain why the change of order of private/public block produces a compiler error and why the error disappears when adding a ::in front of the type?
First of all it is not clear why you named the member function as AURenderCallbackStruct that coincides with the corresponding structure's name and looks like the structure constructor.
The problem is this stupid name.
in the first case the compiler thinks that you indeed define the member function that hides the corresponding name of the structure.
In the second case the compiler thinks that you trying to call the constructor of the structure.
Simply rename the function that there would not be an ambiguity.
I have a library that is all tested thoroughly through google test suite. I am trying to keep it "pimpl" clean, but I'm running into a segfault I can't quite figure out.
Relevant Code:
Interface.h:
class Interface{
public:
Interface();
void Function(const int argument);
private:
std::unique_ptr<Implementation> Implement;
std::unique_ptr<DependencyInjection> Injection1, Injection2;
};
Interface.cpp:
Interface::Interface()
: Injection1(new DependencyInjection()),
Injection2(new DependencyInjection()),
Implement(new Implementation(*Injection1, *Injection2)) {}
void Interface::Function(const int argument){ Implement->Function(argument); }
Implementation.h:
class Implementation{
public:
Implementation(AbstractInjection &injection1, AbstractInjection &injection2);
void Function(const int argument);
private:
AbstractInjection Injection1, Injection2;
};
Implementation.cpp
Implementation::Implementation(AbstractInjection &injection1, AbstractInjection &injection2)
: Injection1(injection1),
Injection2(injection2) {}
void Implementation::Function(const int argument){
injection1.Function(argument); } // code from here out is all well tested and works
So when I create the interface and call Interface.Function() the code segfaults when it tries to evaluate Implementation.Function(). I've ran gdb through everything I can think of, all the pointers are non-null.
If I just create a test that looks like
std::unique_ptr<DependencyInjection1> injection1(new DependencyInjection());
std::unique_ptr<DependencyInjection2> injection2(new DependencyInjection());
std::unique_ptr<Implementation> implement(new Implementation(*injection1, *injection2));
implement->Function(0);
The code works fine and does not segfault
But if I create a test like
Interface iface;
iface.Function(0);
it will segfault.
I am new to the whole unique_ptr thing, but I have a suspicion that isn't the larger problem. It may be a red herring, I don't know.
The problem should actually pop as as a warning.
Initializers are done in the order in which they appear in the class definition, not in which they appear in the constructor!
Switch it to:
class Interface{
public:
Interface();
void Function(const int argument);
private:
std::unique_ptr<DependencyInjection> Injection1, Injection2;
std::unique_ptr<Implementation> Implement;
};
From here: C++: Initialization Order of Class Data Members, this is "12.6.2 of the C++ Standard"
You've got a wrong order of member fields, they are initialized in order they are declared in the class. So implement is initialized before both injections. Use -Werror=reorder to get compiler error (for GCC and probably CLang)
Working on a collaborative project (was hoping two would be easier than one - how wrong was I...?)
Basically, what we're trying to do is a bit like this:
class first
{
first(int * num);
};
class second
{
second(first * frst);
first * frt;
};
first::first(int * num)
{
}
second::second(first * frst)
{
frt = frst;
}
There is a bit of an issue though, we can't include our Core.h file, since that contains includes to the files we're already including (there is sense somewhere there). Short version is, we're having to do something a bit more like this:
#ifndef PLAYERSTRUCTURE
#define PLAYERSTRUCTURE
// DO NOT INCLUDE CORE IN THIS FILE
class Core;
struct PlayerMem
{
int cid;
int y, x, z;
};
class Player
{
public:
Player::Player(Core * coar);
Player::Player(void);
Player::~Player(void);
};
#endif
The Core class is declared but not defined, will this cause issues if we try to access it from within the Player class, using Core->GetSomething() etc?
Thanks
You're forwarding declaration. It's OK.
When you can use Core->GetSomething() without any compilation error then it means class Core is defined and it's not an incomplete type. So, there is no issue to use it. Just make sure you're passing a valid pointer to Core when constructing Player.
Note: In your code you're passing a pointer to a class type not a reference.