Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
Basically I want to convert abstract class reference or object to pointer of that object, I couldn't find anything on the internet. I know i can do just &object but i want to make a function that takes object and returns pointer. For example:
GameObject * convert(GameObject & object)
I need a function for that becouse i have a lua scripts that handle objects so i can mod my game easier.
Thanks in advance.
.This function is in the standard library. It is called std::addressof.
It was introduced in C++11, so in case your standard library is too old, then:
I know i can do just &object
Simply write a function and use the address of operator there, as you just know you can do. (The trivial implementation has a caveat that the addressof operator may be overloaded to not return the address. This can be avoided, but I feel is out of scope of my answer).
The problem is GameObject is an abstract class so it will give an error: cannot instantiate abstract class.
That is not a problem with getting the address of a GameObject. That is a problem with creating an instance of GameObject. You cannot instantiate objects of an abstract class except as base class sub object.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 10 months ago.
Improve this question
I have a template class with an instantiation parameter.
I have another class that has a member parameter of that class.
The follow does not compile because it says instantiation method is deleted...
class MyClass {
public:
MyTClass<AClass> tclass;
}
The following works but I am not sure if it is the correct way...
class MyClass {
public:
MyTClass<AClass> tclass = MyTClass<AClass>(1234);
}
It seems the member paramter is instantiated but is it tidied up on owner class destruction?
I wish to avoid new and delete if I can to keep my code tidy so I am thinking I wish to take advantance of member parameter instantiation on class instantiation. As I have added explicit instantiation, do I need to fall back to new and delete to ensure it is destructed?
No, you do not need to do anything extra here. The destructor of MyClass invokes the destructor of all members, regardless of how they were originally constructed.
(This is true even if the member is a pointer. But the destructor of a pointer does nothing, which is why you'd need a delete call to destruct and free the thing it points to.)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
But by using what variable as a parameter, a function may change a variable that is defined in another function?
The phrasing of this question suggests it is from a test. Most likely, the intended answer is that declaring a parameter as a reference provides access to the passed object.
Access to an object can also be obtained by any means that provides its address. For things passed through parameters, this includes:
Pass a pointer.
Pass (the address of) some helper function that returns a pointer or reference.
Pass a pointer or reference to an object with a known relation to the object (for example, pass a pointer to the first element of the array and the index of the array element to be accessed).
Pass an integer or string properly converted from a pointer, so that it may be converted back.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Should I put a lot of initialization work in constructor or in a member method ?
class A {
public:
A() {
//a lot of initialization work...
}
~A() = default;
//or put those work in it
void init() {
/*
After creating object of this class, I invoke
init method to do some heavy initialization work...
*/
}
}
I really like the following way of looking at this, but, as mentioned at the bottom of this post, it has a single, massive, drawback:
The constructor's job is to establish the class invariant.
A class invariant is the description of the legal state a class can be in in between calls to public member functions, and each and every public member function should be well-behaved for any and all possible invariant state. So it's always a good idea to keep your class invariants as strict as possible.
In light of all this: the amount of work being done in a constructor should be whatever is needed to set up as strict an invariant as reasonably possible for the class.
For example:
If I have a class that holds a pointer to an OS window:
class Window {
native_window* w_;
...
};
The class invariant could be "w_ is always either null, or points to an instance of a window.", but that's annoying, since it means that most member functions will have to perform a null check. If the invariant was "w_ points to a valid window handle", then you can rely on that assumption and greatly simplify the rest of the class.
However! This means that should the constructor fail to establish an invariant (the OS call to create the window failed because of reasons), then the only way you can handle the failure is to throw an exception. So if you are operating in a codebase where exceptions are not permitted, then this whole approach to class design is moot.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Suppose we declare A to be of type Type:
Type A;
Question: is the Type constructor for A called at this point? Or is it only after we initialize A that a constructor is called?
is the Type constructor for A called at this point? Or is it only after we initialize A that a constructor is called?
You are initializing A here, whether you explicitly provided a value for that process or not.
There is no opportunity to initialise A "later"; you can only assign to it later. (Early C texts talk about "initialising" numeric values long after declaration, but that's a different language, a different century, and a different set of descriptive idioms.)
So, yes, the constructor is called as soon as the object's lifetime begins. That's either right there and then, on that line, or if a class member then of course it's when the encapsulating class is being initialised and it's this member's turn.
Of course you could have proven this with a simple std::cout pair.
Yes, it is called immediately. When you assign it a value, the assignment operator is called instead.
The only exception is this:
Type a = value;
Here some compiler with some settings may relax it and call constructor directly with the value as parameter. But it still needs to be part of declaration.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I've noticed this weird behaviour/bug where a class method is called before the actual object is initialized. I have a wrapper object, which has operator->() method. Now, when I'm passing the object to another object as constructor parameter in a constructor using the operator->() method, the actual wrapper object doesn't get constructed, but rather just runs the operator->() method.
As the actual code sample is pretty complicated and depends on many other things, I'll just show C++ code snippet which may not compile properly:
template<typename T>
class wrapper_object_type
{
public:
wrapper_object_type() {/*does not run*/}
T* operator->() {/*does run*/}
};
class bad_behaviour
{
public:
bad_behaviour() : another_object(wrapper_object->t_object)
{/*crashes(0xccc access violation*/}
};
So is there something defined in the standard that may allow such behaviour? Or more accurately, are there some implicit constructions etc. which could bypass the default construction?
Probably you use wrapper_object before it gets initialized. Member variables are constructed in the same order in which they are declared in the class, so make sure wrapper_object is declared before another_object.
(Assuming wrapper_object and another_object are members variables of bad_behaviour, but without a more reasonable code sample it's hard to say.)
Well I did it the hardway; I switched the objects from stack to heap and initialized them explicitly via new keyword rather than in initializer list. As I thought, that didn't reproduce the weird behaviour, so it worked as intended. What I'm thinking now, is that it may be actually a compiler bug, since the way I did it via initializer list is analog to how I fixed the problem. Only thing that changed was the fact that I didn't allocate them in heap before.
I also tried to provide working code which reproduces the bug, but the bug wasn't shown there. It may be because the actual code where the bug was noticed, relies quite heavily to template types and wrapper objects. As it works now when the objects are allocated in heap, the bug isn't in the code but rather in the compiler.