Printable View
Hi to all, I m quite new to c++ and i try to compile this little program without success...
What is wrong with this code ?Code:class b;
class a;
class b
{
public:
a *aa;
b()
{
aa = new a();
}
~b();
};
class a
{
public:
b *bb;
a()
{
bb = new b();
}
~a();
};
void main(int argc, char *argv[])
{
a my_a;
b my_b;
}
Thank you for your coments and help.
you might be able to figure it out yourself, or have a better chance at it if you name your variables a little more descriptively!
The return type of main is int, not void, meaning it also needs a return value.Quote:
Originally Posted by ajoqiqu
I don't think there is a good way to do what you want here. Why? Because of some stupidity in the design of C++: for reasons of "safety", you cannot use a void* (or any other kind of pointer) generically the way you can in C. Your forward declarations of a and b are incomplete, but if you complete them, b will contain a reference to an undefined type.
So the trade-off for safety is dysfunction and awkwardness in this case. Sorry. You might be able to get out of it by making aa a static variable of a template function in b, since that function will only need a prototype in b's declaration (no reference to a). Actually that's not allowed either, template functions need to be defined in the declaration. Sorry again.
I do not know what exactly does ajoqiqu want to do here, but there may be an obvious solution: define the member functions of b after the definition of a.Quote:
Originally Posted by MK27
In fact, this solution is applicable to C: you would define functions that require the definition of a struct after the struct definition is in scope. It seems to me that once you come across something that you see as a "stupidity in the design of C++" (and as far as I can tell the premise of your rant is inaccurate to begin with), your mind goes blank and you forget even those techniques that can be carried over from C.Code:class a;
class b
{
public:
a* aa;
b();
~b();
};
class a
{
public:
b* bb;
a()
{
bb = new b();
}
~a()
{
delete bb;
}
};
int main()
{
a my_a;
b my_b;
}
b::b()
{
aa = new a();
}
b::~b()
{
delete aa;
}
EDIT:
Beyond this, ajoqiqu: are you are of the so-called rule of 3? That is, when you need to define a destructor yourself (other than trivially to declare it virtual), you typically need to declare the copy constructor and copy assignment operator?
Actually you can MK; look up static_cast<somePtrType>(void *argument)...anytime you have to interact with the pthread environment you need to do something like this and C++ likes it just fine:Quote:
Originally Posted by MK27
Code://********************************************
// Method:workFunc()
//
// Args:void *args - void ptr to data, def is NULL
//
// Return:void * - result code of this thread
//
// Desc:Wrapper fn to start a thread running
//********************************************
void *workFunc(void *args)
{
FoundationThreadBase *ptr =
static_cast<FoundationThreadBase *>(args);
int nRC = ptr->Run(ptr->GetData());
ptr->SetThreadRunningFlag(false);
ptr->SetThreadExitedState(true);
}
It's the purists that it ticks off and since none of them pays my wage, they can take a long walk off of a short pier :)
That was my first thought too, here's the code I tried which is near identical to yours (and they both compile fine but produce a segmentation fault):Quote:
Originally Posted by laserlight
The segfault has an identical cause too: a sort of infinitely recursive memory corruption (backtrace for your code):Code:class a;
class b;
class b {
public:
a* aa;
b();
};
class a {
public:
b* bb;
a();
};
b::b() {
aa = new a();
}
a::a(){
bb = new b();
}
int main() {
a my_a;
b my_b;
}
#0 _int_malloc (av=0x7ffff7633a00, bytes=<value optimized out>)
at malloc.c:4130
#1 0x00007ffff7342a08 in __libc_malloc (bytes=8) at malloc.c:3551
#2 0x00007ffff7b981ed in operator new (sz=8)
at ../../../../libstdc++-v3/libsupc++/new_op.cc:57
#3 0x0000000000400859 in a (this=0xa006b0) at test2.cpp:20
#4 0x0000000000400716 in b (this=0xa00690) at test2.cpp:37
#5 0x0000000000400866 in a (this=0xa00670) at test2.cpp:20
#6 0x0000000000400716 in b (this=0xa00650) at test2.cpp:37
#7 0x0000000000400866 in a (this=0xa00630) at test2.cpp:20
#8 0x0000000000400716 in b (this=0xa00610) at test2.cpp:37
#9 0x0000000000400866 in a (this=0xa005f0) at test2.cpp:20
#10 0x0000000000400716 in b (this=0xa005d0) at test2.cpp:37
#11 0x0000000000400866 in a (this=0xa005b0) at test2.cpp:20
[...etc]
Perhaps the reason is sort of obvious :p Not even a void* will save this logical flaw.
Hmm, can you use that to cast to an object too? I presume so...FoundationThreadBase is a class, no?Quote:
Originally Posted by jeffcobb
Still think that thing with C++ void* might be one of the single dumbest design choices I've ever heard of. It kind of smacks of a "business" move (to create an incompatibility with C API's).
Ah, but it is precisely because the members are pointers that, in a more fully developed class, one of the members could be a null pointer, thus ending this "infinitely recursive" problem, as how one might do it with a linked list implementation. As it stands, my example simulates the otherwise impossible situation of having a member of a class that has as a member an object of the current class. This is hardly a problem with the design of C++. It is a question of what ajoqiqu wants to do.Quote:
Originally Posted by MK27
Yes, you can. You can freely cast a pointer to an object to a pointer to void* and back.Quote:
Originally Posted by MK27
MK: FoundationThreadBase is an abstract base class I use (this is part of what will get mailed to you this weekend) to easily manage threads so basically all you need to do to create a thread is:Quote:
Originally Posted by MK27
And then supplying a Run() method:Code:#include "foundationthread.hpp"
// making a thread is as simple as deriving a class from Foundation
// ThreadBase, providing a run() method, creating an instance of this
// derived class and call start()
class ThreadTest:public FoundationThreadBase
{
private:
public:
ThreadTest()
{
//MT
}
~ThreadTest()
{
//MT
}
virtual int Run(void *ptrArgs);
};
Then in your main thread, to launch this it is as simple as:Code://********************************************
// Method:Run()
//
// Args:None
//
// Return:0 on success, -1 if fail
//
// Desc:Actual run routine for this thread
//********************************************
int ThreadTest::Run(void *ptrData)
{
int nResultCode = 0;
// supply the thread work functionality here...
return nResultCode;
}
Note: this is still a work in progress but to me this has always been the simplest way to launch threads and manage them effectively. You will see the whole code-base later this weekend.Code:ThreadTest myThread;
myThread.Start(false);
myThread.Join();
Laser: you are too fast for me :)Quote:
Originally Posted by laserlight
Grr... now that I read your quote, I see that my original statement was correct. The edit that changed void to void* is wrong.Quote:
Originally Posted by jeffcobb
The real problem and one that can be solved in C++ is an incorrect use of the langugage. Had the implementation of said classes been in a separate file then the forward declare would have worked fine. You can forward declare anything you want so long as you don't actually use the class you are forward declaring. So if A needs B and B needs A and A has both a header and an impl and B has both a header and an impl the forward declare works just fine. The problem arises from this section:
The pointer aa is fine b/c after all it's really just 4 bytes. The type is a compiler side feature but in the end it is still just 4 bytes. However the constructor for b is where the problem is.Code:class b;
class a;
class b
{
public:
a *aa;
b()
{
aa = new a();
}
~b();
};
How can the compiler instantiate aa when a has not been fully declared? class a is incomplete and therefore that line of code will generate the error that you received. As well there is no reason to forward declare b since b is declared fully prior to a. The only problem here is an incorrect use of the language and it is not related to any pointer problems or fundamental problems in the design of C++.
Had b had a header where a was forward declared and b had an impl where a was included and used this would have worked just fine. Plain and simple you cannot use (read: instantiate) a class you have not fully declared.
Thank you for all your comment, your reflexion help me to better understand the problem.
my goal is to modelize an object !
an object have some properties !
a property is an object !
and the problem start...
thanks
Okay, so what exactly are you trying to model?Quote:
Originally Posted by ajoqiqu
well, i model an object by a list of property and i model a property as a type ( a type is a reference to an object ) but also i model an object without any property just his name, its a base_type !
I have an object : object_1
object_1 have some properties : property_1, property_2
the type of propertry_1 is 2 that s mean property_1 refere to object_2
the type of propertry_2 is 3 that s mean property_2 refere to object_3
object_2 is base_type
object_3 is base_type
Do you understand ?
Not exactly. I was hoping for a more concrete example. Some people like to use things like animals, other people might talk about cars, but the point is to have something concrete to work with. It may be best if you provided the actual example of the things that you are trying to model.Quote:
Originally Posted by ajoqiqu
At the moment, I would be inclined to write:
Code:class Base
{
// ...
};
class X
{
// ...
private:
Base* property1;
Base* property2;
};
int main()
{
X object1;
// ...
}
Thank you, for your interest and your patience...
I have some thing like this in my mind...
Code:class object
{
int id;
string name;
property property_1;
///...
property property_n;
bool is_base_type;
variant value;
// if base_type is true : value is set
// if base_type is false : the property are set
};
class property
{
int id;
string name;
int type_id;
object type;
};
int main()
{
object my_house;
my_object.id=1;
my_object.name="house";
my_object.is_base_type = 0;
object roof;
roof.id=2;
roof.name="roof";
roof.is_base_type = 1;
roof.value = red;
object key;
key.id=3;
key.name="key";
key.is_base_type = 1;
key.value = secret;
property a_roof;
a_roof.id = 0;
a_roof.name = "roof";
a_roof.type_id = 2;
a_roof.type = roof;
property a_key;
a_key.id = 1;
a_key.name = "key";
a_key.type_id = 3;
a_key.type = key;
my_house.property_1 = a_roof;
my_house.property_2 = a_key;
}
but my code refuse to compile... !
Is it more clear with these few line ?
You should also describe your idea in words.Quote:
Originally Posted by ajoqiqu
I note that variant and string are not defined. You use the property class before it is defined. Furthermore, the object class has members of type property, but the property class has members of type object. This is akin to you placing a bag A into a bag B, and then placing B into A, without removing A from B.Quote:
Originally Posted by ajoqiqu
I suggest that you take some time to learn about the use of inheritance and polymorphism, e.g., from a book. Accelerated C++ by Koenig and Moo could give you a better foundation in the basics of C++, including this area.
You need to take a few steps back. Now, don't be offended: There are some rather glaringly obvious reasons that code will not compile, such as the issue of "namespaces" (you aren't using any).Quote:
Originally Posted by ajoqiqu
This kind of indicates this is one of the first programs you have ever written in C++. That being the case, you should not write 50-100 lines of code and then try to compile it. That is a HUGE mistake. You should write maybe 5-10 lines of code, and then compile it, even if the code does not do anything, to make sure you do not just repeat the same error over and over again. So, starting from scratch, let's just try and compile this part -- notice I added the necessary includes and namespace directive:
Also, I swapped the order of the class definitions around so that object can include property, but then of course we are still left with these errors:Code:#include <string>
using namespace std;
class property
{
int id;
string name;
int type_id;
object type;
};
class object
{
int id;
string name;
property property_1;
///...
property property_n;
bool is_base_type;
variant value;
// if base_type is true : value is set
// if base_type is false : the property are set
};
int main()
{
/* NOTHING HERE YET */
return 0;
}
test.cpp:10: error: ‘object’ does not name a type
test.cpp:23: error: ‘variant’ does not name a type
Because of course there's an object in property. This can be solved by forward declaring "object" at the top:
HOWEVER, this is an incomplete type, so the "object" in property must be a pointer instead of a real instance:Code:class object;
Now, we are only left with one error:Code:object *type;
test.cpp:24: error: ‘variant’ does not name a type
Sort of mysterious -- this is why you should always be test compiling your code, and not treating it as a sort of canvas for ideas. Ideas can compile, but they do not necessarily have to!
This is good advice for later as well when you are trying to debug a huge code base. It is best to attempt to isolate the code or isolate the file where the code is (only compile the cpp instead of the project or solution) and then work backwards from there.Quote:
That being the case, you should not write 50-100 lines of code and then try to compile it.
You really need to read a bit more about C++ before attempting to do something as complex as this. I do admire your willingess to jump in and get your feet wet so I really cannot fault you for at least trying. Another equally important skill is learning what it is that your compiler is trying to tell you. I still get errors from time to time that leave me at my desk scratching my head as to what the compiler is attempting to tell me. If you cannot decipher what the compiler is telling you then you really cannot address the issue. It might not be a bad idea to google the error code or warning code until you become comfortable with your compiler. I learned from the help files but I don't recommend that b/c finding the error and warning codes in help is like looking for a needle in a haystack.