|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On March 06 2015 03:20 heartlxp wrote:
hi guys, anyone else have problem with frontend caching?
we make changes to html/js, but we have to clear cache in our browsers to see them. this happens generally for modals and dropdown menus. we use Angularjs/nginx if that's relevant at all.
when developing it's trivial to refresh, but we can't force all users to clear cache every time we update...any ideas?
you should probably configure your nginx webserver to send appropriate Cache http headers for your files.
|
does anybody know how I can get the pointer to the struct?
void PrintAllComponents(Entity entity){
auto comp= entity.GetComponent(1);
cout << comp->HP << endl;
}
class Component
{
public:
int GetComponentID();
Entity* GetParent();
void SetParent(Entity* entity);
void SetComponentID(int ComponentID);
int ComponentID;
Entity* m_Parent;
};
struct Health : public Component
{
Health(int HP, int max);
int HP;
int max;
};
Health::Health(int maxhp , int hp){
HP=hp;
max=maxhp;
SetComponentID(1);
}
void Entity::AddComponent(Component* cmp){
m_components[cmp->GetComponentID()] = cmp;
cmp->SetParent(this);
}
struct Entity
{
Component* GetComponent(int id);
virtual void AddComponent(Component* Component);
std::map<int,Component *>m_components;
};
int main(){
Entity one;
Health test(50,30);
one.AddComponent(&test);
PrintAllComponents();
}
|
On March 06 2015 07:15 sabas123 wrote:does anybody know how I can get the pointer to the struct?
void PrintAllComponents(Entity entity){
auto comp= entity.GetComponent(1);
cout << comp->HP << endl;
}
class Component
{
public:
int GetComponentID();
Entity* GetParent();
void SetParent(Entity* entity);
void SetComponentID(int ComponentID);
int ComponentID;
Entity* m_Parent;
};
struct Health : public Component
{
Health(int HP, int max);
int HP;
int max;
};
Health::Health(int maxhp , int hp){
HP=hp;
max=maxhp;
SetComponentID(1);
}
void Entity::AddComponent(Component* cmp){
m_components[cmp->GetComponentID()] = cmp;
cmp->SetParent(this);
}
struct Entity
{
Component* GetComponent(int id);
virtual void AddComponent(Component* Component);
std::map<int,Component *>m_components;
};
int main(){
Entity one;
Health test(50,30);
one.AddComponent(&test);
PrintAllComponents();
}
Why not just initialize it as Entity* one = new Entity();
?
|
Because this isn't the 90's? You [almost always] shouldn't have raw new/deletes floating around outside of constructors/destructors, especially once exceptions start coming into play. A more modern approach for a heap object would be:
std::unique_ptr<Entity>(new Entity()) entity;
// if you need a raw pointer, either assign it, or use entity.get() directly
auto rawPtr = entity.get();
|
In any case there's a lot of other things wrong with the code sample that I'm not sure what the question is asking... seems pretty straightforward since they've already used the &test but yeah
|
On March 06 2015 03:20 heartlxp wrote:
hi guys, anyone else have problem with frontend caching?
we make changes to html/js, but we have to clear cache in our browsers to see them. this happens generally for modals and dropdown menus. we use Angularjs/nginx if that's relevant at all.
when developing it's trivial to refresh, but we can't force all users to clear cache every time we update...any ideas?
Afaik people do cache busting by having some random number as part of query parameter. You have you webserver turn request for asset.css?cachebust=12345 to serve back asset.css.
|
On March 06 2015 07:47 Rollin wrote:Because this isn't the 90's? You [almost always] shouldn't have raw new/deletes floating around outside of constructors/destructors, especially once exceptions start coming into play. A more modern approach for a heap object would be: std::unique_ptr<Entity>(new Entity()) entity;
// if you need a raw pointer, either assign it, or use entity.get() directly
auto rawPtr = entity.get();
Why not just Entity *p = &one ?
|
std::shared_ptr<Entity> entity(new Entity());
is where it's at
or even
std::shared_ptr<Entity> entity = std::make_shared<Entity>()
For school assignments and stuff unless the project is pretty big I prefer just raw pointering. At some point I'll switch over to smart pointers if the project gets large large and I'm doing thread dangerous stuff, but normal pointers and references are less verbose and easier to use - I don't have to search up documentation on whether I want shared_ptr, unique_ptr, weak_ptr, swap(), reset(), get(), use_count() or other stuff. Yes I know just use shared_ptr everywhere but at that point it's almost the same as use raw pointers - I very rarely get burned from allocations and forgetting about deleting memory from the way I code and if I do it's usually because I've been overly zealous with deleting and I'm deleting a pointer twice.
|
edit: nevermind solved it
|
On March 06 2015 08:48 Blisse wrote:
In any case there's a lot of other things wrong with the code sample that I'm not sure what the question is asking... seems pretty straightforward since they've already used the &test but yeah
well im trying to acces the variable of struct hp, that I linked to an entity. I can get the adress of hp but somehow not the variable members
|
On March 06 2015 16:19 sabas123 wrote:Show nested quote +On March 06 2015 08:48 Blisse wrote:
In any case there's a lot of other things wrong with the code sample that I'm not sure what the question is asking... seems pretty straightforward since they've already used the &test but yeah well im trying to acces the variable of struct hp, that I linked to an entity. I can get the adress of hp but somehow not the variable members
Sorry I can't debug the code unless I ask, does your code compile? I'm really hoping what you posted is just random snippets of some other system...
you didn't pass the entity one to printallcomponents, entity::addcomponent is defined before you declared the entity struct, things, i can't look at that code and suggest a solution when there's just so much wrong/inconsistent already, a lot of potentially broken pathways... if you link the entire source i could be more specific...
Just looking at your code, I'd assume because you're mixing passing by value with passing pointers you're not setting things properly, just throw couts everywhere or step through gdb and you'll find somethings not set and saved properly
|
ok I found the problem, kinda
I am passing a Component * so I can't access the derived members variablesT_T
|
that makes sense :p
really surprised the compiler let that compile though
|
On March 06 2015 19:08 Blisse wrote:
that makes sense :p
really surprised the compiler let that compile though
now just have to find a way to typecast everything:/
|
On March 06 2015 20:32 sabas123 wrote:Show nested quote +On March 06 2015 19:08 Blisse wrote:
that makes sense :p
really surprised the compiler let that compile though now just have to find a way to typecast everything:/
Instead of casting, try finding a better design.
|
On March 06 2015 21:08 spinesheath wrote:Show nested quote +On March 06 2015 20:32 sabas123 wrote:On March 06 2015 19:08 Blisse wrote:
that makes sense :p
really surprised the compiler let that compile though now just have to find a way to typecast everything:/ Instead of casting, try finding a better design.
the whole design is ok in my opinion, just this part is annoying as fuck.
|
On March 06 2015 10:18 Blisse wrote:+ Show Spoiler +std::shared_ptr<Entity> entity(new Entity()); is where it's at or even std::shared_ptr<Entity> entity = std::make_shared<Entity>() For school assignments and stuff unless the project is pretty big I prefer just raw pointering. At some point I'll switch over to smart pointers if the project gets large large and I'm doing thread dangerous stuff, but normal pointers and references are less verbose and easier to use - I don't have to search up documentation on whether I want shared_ptr, unique_ptr, weak_ptr, swap(), reset(), get(), use_count() or other stuff. Yes I know just use shared_ptr everywhere but at that point it's almost the same as use raw pointers - I very rarely get burned from allocations and forgetting about deleting memory from the way I code and if I do it's usually because I've been overly zealous with deleting and I'm deleting a pointer twice.
Shared pointer just has a threadsafe reference count attached. For projects that aren't under performance constraints, as you say, using shared pointer indiscriminately isn't an issue in the slightest. All unique pointer does is free resources when it goes out of scope (rather than when all references to it go out of scope in shared_ptr), although the lack of make_unique in c++11 obfuscates the initialisation syntax somewhat. However for the single ownership model (most of the time code can be made to fit this), unique_ptr is the wrapper of choice.
|
nevermind again lol
figure out the answers to my own questions as i post them. sorry everyone
|
On March 07 2015 05:02 travis wrote:
nevermind again lol
figure out the answers to my own questions as i post them. sorry everyone
haha it's all part of the Rubber Ducky process don't worry
|
On March 06 2015 21:54 sabas123 wrote:Show nested quote +On March 06 2015 21:08 spinesheath wrote:On March 06 2015 20:32 sabas123 wrote:On March 06 2015 19:08 Blisse wrote:
that makes sense :p
really surprised the compiler let that compile though now just have to find a way to typecast everything:/ Instead of casting, try finding a better design. the whole design is ok in my opinion, just this part is annoying as fuck.
Nope, it's not. The whole idea of using derived classes when a base class is expected is that you respect interface. An interface is like a contract. Derived classes can have different behaviour but interface shouldn't be violated. On a funny note, this applies to your case. 
![[image loading]](http://i2.wp.com/www.devtec.com/wp-content/uploads/2013/04/LSP.jpg?resize=600%2C450)
Anyway, if it's the HP field that you want to access, then make it a protected field in the base class. If this isn't what you want, you should indeed reconsider design.
On March 06 2015 07:31 Acrofales wrote:
Why not just initialize it as Entity* one = new Entity();
?
As far as I know, C++ prefers stack objects as much as possible. Don't be mistaken with languages like Java and C# where 'new' is a no-brainer.
|
|
|
|
|
|
EPT
