Simple Object Management System
I am attempting to create a fast & robust object management system that allows adding, removing and retrieving objects from a "scene". I am trying to wrap my head around the best way to do this regarding ownership and object lifecycle. Code:
main.cpp:
int main()
{
r3d::scene main_scene;
game_object& obj = main_scene.create_object("obj", glm::vec3(0, 0, 0), glm::vec3(-90, 0, -90), glm::vec3(1, 1, 1));
main_scene.remove_object("obj");
return 0;
}
scene.hpp:
namespace r3d
{
class scene
{
public:
scene::scene() { }
game_object& create_object(std::string name,
glm::vec3 position = glm::vec3(0, 0, 0),
glm::vec3 euler_angles = glm::vec3(0, 0, 0),
glm::vec3 scale = glm::vec3(1, 1, 1));
void remove_object(std::string);
game_object& get_object(std::string);
private:
std::map<std::string, r3d::game_object> game_objects;
};
}
scene.cpp:
game_object& scene::create_object(std::string name, glm::vec3 position, glm::vec3 euler_angles, glm::vec3 scale)
{
game_objects.emplace(name, game_object { name, position, euler_angles, scale });
return game_objects[name];
}
void scene::remove_object(std::string name)
{
game_objects.erase(name);
}
game_object& scene::get_object(std::string name)
{
return game_objects[name];
}
game_object.hpp
namespace r3d
{
class game_object
{
public:
std::string name;
game_object() {}
// constructor
game_object(std::string name, glm::vec3 position, glm::vec3 euler_angles, glm::vec3 scale)
: name(name),
position(position),
euler_angles(euler_angles),
scale(scale)
{
printf("New game_object: %s [address: %p]n", name.c_str(), this);
}
// destructor
~game_object()
{
printf("Delete game_object: %s [address: %p]n", name.c_str(), this);
}
// copy constructor
game_object(const game_object& source)
: name { source.name },
position { source.position },
euler_angles { source.euler_angles },
scale { source.scale }
{
printf("Copy game_object: %s [from: %p to: %p]n", source.name.c_str(), &source, this);
}
// move constructor
game_object(game_object&& source)
: name { source.name },
position { source.position },
euler_angles { source.euler_angles },
scale { source.scale }
{
printf("Move game_object: %s [from: %p to: %p]n", source.name.c_str(), &source, this);
}
protected:
glm::vec3 position;
glm::vec3 euler_angles;
glm::vec3 scale;
};
}
c++ pointers
|
show 2 more comments
I am attempting to create a fast & robust object management system that allows adding, removing and retrieving objects from a "scene". I am trying to wrap my head around the best way to do this regarding ownership and object lifecycle. Code:
main.cpp:
int main()
{
r3d::scene main_scene;
game_object& obj = main_scene.create_object("obj", glm::vec3(0, 0, 0), glm::vec3(-90, 0, -90), glm::vec3(1, 1, 1));
main_scene.remove_object("obj");
return 0;
}
scene.hpp:
namespace r3d
{
class scene
{
public:
scene::scene() { }
game_object& create_object(std::string name,
glm::vec3 position = glm::vec3(0, 0, 0),
glm::vec3 euler_angles = glm::vec3(0, 0, 0),
glm::vec3 scale = glm::vec3(1, 1, 1));
void remove_object(std::string);
game_object& get_object(std::string);
private:
std::map<std::string, r3d::game_object> game_objects;
};
}
scene.cpp:
game_object& scene::create_object(std::string name, glm::vec3 position, glm::vec3 euler_angles, glm::vec3 scale)
{
game_objects.emplace(name, game_object { name, position, euler_angles, scale });
return game_objects[name];
}
void scene::remove_object(std::string name)
{
game_objects.erase(name);
}
game_object& scene::get_object(std::string name)
{
return game_objects[name];
}
game_object.hpp
namespace r3d
{
class game_object
{
public:
std::string name;
game_object() {}
// constructor
game_object(std::string name, glm::vec3 position, glm::vec3 euler_angles, glm::vec3 scale)
: name(name),
position(position),
euler_angles(euler_angles),
scale(scale)
{
printf("New game_object: %s [address: %p]n", name.c_str(), this);
}
// destructor
~game_object()
{
printf("Delete game_object: %s [address: %p]n", name.c_str(), this);
}
// copy constructor
game_object(const game_object& source)
: name { source.name },
position { source.position },
euler_angles { source.euler_angles },
scale { source.scale }
{
printf("Copy game_object: %s [from: %p to: %p]n", source.name.c_str(), &source, this);
}
// move constructor
game_object(game_object&& source)
: name { source.name },
position { source.position },
euler_angles { source.euler_angles },
scale { source.scale }
{
printf("Move game_object: %s [from: %p to: %p]n", source.name.c_str(), &source, this);
}
protected:
glm::vec3 position;
glm::vec3 euler_angles;
glm::vec3 scale;
};
}
c++ pointers
3
Do you really want to use pointers here (even smart)? can't you deal with inplace object and references? Also, did you triedstd::maporstd::unordered_map(with name as a key) instead of astd::set? Can't you emplace thegame_object?
– Calak
Dec 4 at 15:46
1
Responding to those questions might help people to provide good reviews.
– Calak
Dec 8 at 14:37
Thanks for pointing (xD) me in the right direction, was under the assumption that it’s good practice to use pointers to all objects in cpp. After doing some more research I have improved my solution (edited above).
– zooooom
Dec 21 at 16:31
Please add the relevant#includes to the code listings and make sure your code compiles and runs correctly. I'd be surprised if this compiles, since std::map operator requires a default constructor and game_object doesn't have one.
– user673679
Dec 21 at 17:07
1
Your code is essentially a wrapper around a dictionary. What is your use-case for string lookup of the objects? If it's configuration-file-based, then fine. But if there are no exterior files expected to refer to objects, and this is intended for static code only, then I don't understand how this approach benefits you.
– Reinderien
Dec 21 at 17:15
|
show 2 more comments
I am attempting to create a fast & robust object management system that allows adding, removing and retrieving objects from a "scene". I am trying to wrap my head around the best way to do this regarding ownership and object lifecycle. Code:
main.cpp:
int main()
{
r3d::scene main_scene;
game_object& obj = main_scene.create_object("obj", glm::vec3(0, 0, 0), glm::vec3(-90, 0, -90), glm::vec3(1, 1, 1));
main_scene.remove_object("obj");
return 0;
}
scene.hpp:
namespace r3d
{
class scene
{
public:
scene::scene() { }
game_object& create_object(std::string name,
glm::vec3 position = glm::vec3(0, 0, 0),
glm::vec3 euler_angles = glm::vec3(0, 0, 0),
glm::vec3 scale = glm::vec3(1, 1, 1));
void remove_object(std::string);
game_object& get_object(std::string);
private:
std::map<std::string, r3d::game_object> game_objects;
};
}
scene.cpp:
game_object& scene::create_object(std::string name, glm::vec3 position, glm::vec3 euler_angles, glm::vec3 scale)
{
game_objects.emplace(name, game_object { name, position, euler_angles, scale });
return game_objects[name];
}
void scene::remove_object(std::string name)
{
game_objects.erase(name);
}
game_object& scene::get_object(std::string name)
{
return game_objects[name];
}
game_object.hpp
namespace r3d
{
class game_object
{
public:
std::string name;
game_object() {}
// constructor
game_object(std::string name, glm::vec3 position, glm::vec3 euler_angles, glm::vec3 scale)
: name(name),
position(position),
euler_angles(euler_angles),
scale(scale)
{
printf("New game_object: %s [address: %p]n", name.c_str(), this);
}
// destructor
~game_object()
{
printf("Delete game_object: %s [address: %p]n", name.c_str(), this);
}
// copy constructor
game_object(const game_object& source)
: name { source.name },
position { source.position },
euler_angles { source.euler_angles },
scale { source.scale }
{
printf("Copy game_object: %s [from: %p to: %p]n", source.name.c_str(), &source, this);
}
// move constructor
game_object(game_object&& source)
: name { source.name },
position { source.position },
euler_angles { source.euler_angles },
scale { source.scale }
{
printf("Move game_object: %s [from: %p to: %p]n", source.name.c_str(), &source, this);
}
protected:
glm::vec3 position;
glm::vec3 euler_angles;
glm::vec3 scale;
};
}
c++ pointers
I am attempting to create a fast & robust object management system that allows adding, removing and retrieving objects from a "scene". I am trying to wrap my head around the best way to do this regarding ownership and object lifecycle. Code:
main.cpp:
int main()
{
r3d::scene main_scene;
game_object& obj = main_scene.create_object("obj", glm::vec3(0, 0, 0), glm::vec3(-90, 0, -90), glm::vec3(1, 1, 1));
main_scene.remove_object("obj");
return 0;
}
scene.hpp:
namespace r3d
{
class scene
{
public:
scene::scene() { }
game_object& create_object(std::string name,
glm::vec3 position = glm::vec3(0, 0, 0),
glm::vec3 euler_angles = glm::vec3(0, 0, 0),
glm::vec3 scale = glm::vec3(1, 1, 1));
void remove_object(std::string);
game_object& get_object(std::string);
private:
std::map<std::string, r3d::game_object> game_objects;
};
}
scene.cpp:
game_object& scene::create_object(std::string name, glm::vec3 position, glm::vec3 euler_angles, glm::vec3 scale)
{
game_objects.emplace(name, game_object { name, position, euler_angles, scale });
return game_objects[name];
}
void scene::remove_object(std::string name)
{
game_objects.erase(name);
}
game_object& scene::get_object(std::string name)
{
return game_objects[name];
}
game_object.hpp
namespace r3d
{
class game_object
{
public:
std::string name;
game_object() {}
// constructor
game_object(std::string name, glm::vec3 position, glm::vec3 euler_angles, glm::vec3 scale)
: name(name),
position(position),
euler_angles(euler_angles),
scale(scale)
{
printf("New game_object: %s [address: %p]n", name.c_str(), this);
}
// destructor
~game_object()
{
printf("Delete game_object: %s [address: %p]n", name.c_str(), this);
}
// copy constructor
game_object(const game_object& source)
: name { source.name },
position { source.position },
euler_angles { source.euler_angles },
scale { source.scale }
{
printf("Copy game_object: %s [from: %p to: %p]n", source.name.c_str(), &source, this);
}
// move constructor
game_object(game_object&& source)
: name { source.name },
position { source.position },
euler_angles { source.euler_angles },
scale { source.scale }
{
printf("Move game_object: %s [from: %p to: %p]n", source.name.c_str(), &source, this);
}
protected:
glm::vec3 position;
glm::vec3 euler_angles;
glm::vec3 scale;
};
}
c++ pointers
c++ pointers
edited Dec 21 at 17:40
asked Dec 4 at 14:08
zooooom
564
564
3
Do you really want to use pointers here (even smart)? can't you deal with inplace object and references? Also, did you triedstd::maporstd::unordered_map(with name as a key) instead of astd::set? Can't you emplace thegame_object?
– Calak
Dec 4 at 15:46
1
Responding to those questions might help people to provide good reviews.
– Calak
Dec 8 at 14:37
Thanks for pointing (xD) me in the right direction, was under the assumption that it’s good practice to use pointers to all objects in cpp. After doing some more research I have improved my solution (edited above).
– zooooom
Dec 21 at 16:31
Please add the relevant#includes to the code listings and make sure your code compiles and runs correctly. I'd be surprised if this compiles, since std::map operator requires a default constructor and game_object doesn't have one.
– user673679
Dec 21 at 17:07
1
Your code is essentially a wrapper around a dictionary. What is your use-case for string lookup of the objects? If it's configuration-file-based, then fine. But if there are no exterior files expected to refer to objects, and this is intended for static code only, then I don't understand how this approach benefits you.
– Reinderien
Dec 21 at 17:15
|
show 2 more comments
3
Do you really want to use pointers here (even smart)? can't you deal with inplace object and references? Also, did you triedstd::maporstd::unordered_map(with name as a key) instead of astd::set? Can't you emplace thegame_object?
– Calak
Dec 4 at 15:46
1
Responding to those questions might help people to provide good reviews.
– Calak
Dec 8 at 14:37
Thanks for pointing (xD) me in the right direction, was under the assumption that it’s good practice to use pointers to all objects in cpp. After doing some more research I have improved my solution (edited above).
– zooooom
Dec 21 at 16:31
Please add the relevant#includes to the code listings and make sure your code compiles and runs correctly. I'd be surprised if this compiles, since std::map operator requires a default constructor and game_object doesn't have one.
– user673679
Dec 21 at 17:07
1
Your code is essentially a wrapper around a dictionary. What is your use-case for string lookup of the objects? If it's configuration-file-based, then fine. But if there are no exterior files expected to refer to objects, and this is intended for static code only, then I don't understand how this approach benefits you.
– Reinderien
Dec 21 at 17:15
3
3
Do you really want to use pointers here (even smart)? can't you deal with inplace object and references? Also, did you tried
std::map or std::unordered_map (with name as a key) instead of a std::set? Can't you emplace the game_object ?– Calak
Dec 4 at 15:46
Do you really want to use pointers here (even smart)? can't you deal with inplace object and references? Also, did you tried
std::map or std::unordered_map (with name as a key) instead of a std::set? Can't you emplace the game_object ?– Calak
Dec 4 at 15:46
1
1
Responding to those questions might help people to provide good reviews.
– Calak
Dec 8 at 14:37
Responding to those questions might help people to provide good reviews.
– Calak
Dec 8 at 14:37
Thanks for pointing (xD) me in the right direction, was under the assumption that it’s good practice to use pointers to all objects in cpp. After doing some more research I have improved my solution (edited above).
– zooooom
Dec 21 at 16:31
Thanks for pointing (xD) me in the right direction, was under the assumption that it’s good practice to use pointers to all objects in cpp. After doing some more research I have improved my solution (edited above).
– zooooom
Dec 21 at 16:31
Please add the relevant
#includes to the code listings and make sure your code compiles and runs correctly. I'd be surprised if this compiles, since std::map operator requires a default constructor and game_object doesn't have one.– user673679
Dec 21 at 17:07
Please add the relevant
#includes to the code listings and make sure your code compiles and runs correctly. I'd be surprised if this compiles, since std::map operator requires a default constructor and game_object doesn't have one.– user673679
Dec 21 at 17:07
1
1
Your code is essentially a wrapper around a dictionary. What is your use-case for string lookup of the objects? If it's configuration-file-based, then fine. But if there are no exterior files expected to refer to objects, and this is intended for static code only, then I don't understand how this approach benefits you.
– Reinderien
Dec 21 at 17:15
Your code is essentially a wrapper around a dictionary. What is your use-case for string lookup of the objects? If it's configuration-file-based, then fine. But if there are no exterior files expected to refer to objects, and this is intended for static code only, then I don't understand how this approach benefits you.
– Reinderien
Dec 21 at 17:15
|
show 2 more comments
1 Answer
1
active
oldest
votes
the idea being that any other class can access a game_object by name if given a reference to main_scene, even if it doesn't hold a reference to the actual object
You've stated that one of your primary goals is speed. Based on your description above, you can still achieve object lookup and avoid the performance hit of a string dictionary.
One of the easiest ways to do this is to add a header file to the application that defines an enum of numeric, sequential object IDs. This will allow for much faster lookup, and depending on how you define and load your data, you wouldn't even need a map - simply a fixed array.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209000%2fsimple-object-management-system%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
the idea being that any other class can access a game_object by name if given a reference to main_scene, even if it doesn't hold a reference to the actual object
You've stated that one of your primary goals is speed. Based on your description above, you can still achieve object lookup and avoid the performance hit of a string dictionary.
One of the easiest ways to do this is to add a header file to the application that defines an enum of numeric, sequential object IDs. This will allow for much faster lookup, and depending on how you define and load your data, you wouldn't even need a map - simply a fixed array.
add a comment |
the idea being that any other class can access a game_object by name if given a reference to main_scene, even if it doesn't hold a reference to the actual object
You've stated that one of your primary goals is speed. Based on your description above, you can still achieve object lookup and avoid the performance hit of a string dictionary.
One of the easiest ways to do this is to add a header file to the application that defines an enum of numeric, sequential object IDs. This will allow for much faster lookup, and depending on how you define and load your data, you wouldn't even need a map - simply a fixed array.
add a comment |
the idea being that any other class can access a game_object by name if given a reference to main_scene, even if it doesn't hold a reference to the actual object
You've stated that one of your primary goals is speed. Based on your description above, you can still achieve object lookup and avoid the performance hit of a string dictionary.
One of the easiest ways to do this is to add a header file to the application that defines an enum of numeric, sequential object IDs. This will allow for much faster lookup, and depending on how you define and load your data, you wouldn't even need a map - simply a fixed array.
the idea being that any other class can access a game_object by name if given a reference to main_scene, even if it doesn't hold a reference to the actual object
You've stated that one of your primary goals is speed. Based on your description above, you can still achieve object lookup and avoid the performance hit of a string dictionary.
One of the easiest ways to do this is to add a header file to the application that defines an enum of numeric, sequential object IDs. This will allow for much faster lookup, and depending on how you define and load your data, you wouldn't even need a map - simply a fixed array.
answered Dec 21 at 17:52
Reinderien
2,724619
2,724619
add a comment |
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209000%2fsimple-object-management-system%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Do you really want to use pointers here (even smart)? can't you deal with inplace object and references? Also, did you tried
std::maporstd::unordered_map(with name as a key) instead of astd::set? Can't you emplace thegame_object?– Calak
Dec 4 at 15:46
1
Responding to those questions might help people to provide good reviews.
– Calak
Dec 8 at 14:37
Thanks for pointing (xD) me in the right direction, was under the assumption that it’s good practice to use pointers to all objects in cpp. After doing some more research I have improved my solution (edited above).
– zooooom
Dec 21 at 16:31
Please add the relevant
#includes to the code listings and make sure your code compiles and runs correctly. I'd be surprised if this compiles, since std::map operator requires a default constructor and game_object doesn't have one.– user673679
Dec 21 at 17:07
1
Your code is essentially a wrapper around a dictionary. What is your use-case for string lookup of the objects? If it's configuration-file-based, then fine. But if there are no exterior files expected to refer to objects, and this is intended for static code only, then I don't understand how this approach benefits you.
– Reinderien
Dec 21 at 17:15