Easy lookup/access to members in "an array" of different datatypes if possible
category: code [glöplog]
gloom: oh, yes its what ive been trying to figure out for the last 10 (or fewer) years, after making several demoengines, i really want to find an easier solution. if that was the question then: it should have been time for a demo. but, i dont have anything worth working on/releasing until i get this very important part of code done. it is the core of the "demoengine" issue. it should be easy do this in code rather than using a tool that has all the crazy things I really dont need. making a demo wasting too much energy on things that just mess up things more is not what i want to do anymore. about time to release a demo soon, i've not just been inactive, i was busy doing some small intro-coding not long ago. that took some time. and, i just took up the demo-coding bit lately. and of course i have some real-life issues that takes time as well for the time being.
let me try plek :)
rudi: kan du forklare, på engelsk, hva _hele_ programmet ditt handler om? Det er det de har forsøkt å spørre deg om 20 ganger.
Altså, svaret er ikke "jeg koder pointere", men "jeg lager et program som skal gjøre x.."
rudi: kan du forklare, på engelsk, hva _hele_ programmet ditt handler om? Det er det de har forsøkt å spørre deg om 20 ganger.
Altså, svaret er ikke "jeg koder pointere", men "jeg lager et program som skal gjøre x.."
leijaa: tror du de skjønner det hvis jeg sier det på norsk? :P
plek: im trying to make a demoengine that should integrate new stuff without much hassle. for the past 10 years i made three or four demoengines. but now i want the easiest and best one!?
plek: im trying to make a demoengine that should integrate new stuff without much hassle. for the past 10 years i made three or four demoengines. but now i want the easiest and best one!?
rudi: kan hende jeg skjønner det hvis du sier det på norsk! men la meg prøve igjen. Gi et eksempel på et konkret problem du ser for deg at du kan løse med denne funksjonen.
leijaa: koden blir mindre kaotisk. jeg slipper å kode B, C og D, hvis jeg bare trenger A. hvis jeg har en variabel(et tall eller whatever), i runtimen som jeg vil endre på trenger jeg en tabell med pekere, som peker til disse variablene. jeg er ikke ute etter å løse et konkret problem med denne funksjonen. funksjonen (eller hva man nå vil kalle det) har ikke noe med noe problem å gjøre egentlig. fordi det er en del av kjærnen til "demoverktøyet". det blir som en hjelpende hånd som kan si til X, Y, Z.. at de skal gjøre det og det. uten at flere hender sier at X, Y og Z..(whatever) skal gjøre det og det fordi de er spesifisert til å gjøre det disse ubrukelige funksjonene sier til dem.
Right.
So basically it's just a function he wants in the demo engine in case he needs it. Which he envisions he does. To change variables on the fly. (I think)
So basically it's just a function he wants in the demo engine in case he needs it. Which he envisions he does. To change variables on the fly. (I think)
Thanks :) And I can read most of that!
I'll give you one tip, born out of both hobbyist and professional experience (sounds cocky but perhaps you'll accept it this way): pragmatism. Code what you need, not what you think you might need.
Quote:
im trying to make a demoengine that should integrate new stuff without much hassle. for the past 10 years i made three or four demoengines. but now i want the easiest and best one!?
I'll give you one tip, born out of both hobbyist and professional experience (sounds cocky but perhaps you'll accept it this way): pragmatism. Code what you need, not what you think you might need.
your Danish genes are INDISPUTABLE!
Also, don't code engines. Code demos, it's easier and a lot more fun.
Rudi: I think i understand where you come from, you came up with an idea for a eloquent implementation and want to go with it.
But if you want to have an engine that's flexible and easy to expand.
Go for what DoomDoom said, abstract classes and a container with (shared) pointers.
Custom datasets and their functions have to be written anyway offcourse but attleast in this way you know where they stand.
But if you want to have an engine that's flexible and easy to expand.
Go for what DoomDoom said, abstract classes and a container with (shared) pointers.
Custom datasets and their functions have to be written anyway offcourse but attleast in this way you know where they stand.
leijaa: without calling this function nothing will work. since a function is just a placeholder for other code, its the internals that are important.
superplek: why do you think i asked this question in the first place? is all i am out after. not want useless functions at all. so after all this fuzz, can you deduce anything from this thread that suits what i am out after
Maali: haha :)
superplek: why do you think i asked this question in the first place? is all i am out after. not want useless functions at all. so after all this fuzz, can you deduce anything from this thread that suits what i am out after
Maali: haha :)
Deus: i see
That sounded a bit condescending so sorry about that, you have been doing this for longer then i have.
okay, let's not mix the definition of the functions here. what we talk about here is, there are two type of functions. the one which is called once in the loop code. this is NOT important at all! the other type of function is the one in the classes?. this option is not what i am out after. im out after the "pointers" option so i can call the variables i want. not a function. because its the parameters in to an eventual function that is more important.
Deus: no, its perfectly allright. its a good tip for that particular case when you need it.
Rudi, are you trying to make something like this?
Code:
struct Value {
// empty
};
class Variable {
public:
virtual void set(Value*) = 0;
virtual void get(Value*) = 0;
};
struct FloatValue : public Value {
float value;
};
class FloatVariable : public Variable {
public:
virtual void set(Value* v) { m_value = dynamic_cast<FloatValue*)(v)->value; }
virtual void get(Value*) { dynamic_cast<FloatValue*>(v)->value = m_value; }
private:
float m_value;
};
std::vector<Variable> variables;
variables.push_back(new FloatVariable);
FloatValue floatVal;
variables[0]->get(&floatVal);
floatVal.value += 3.14f;
variables[0]->set(&floatVal);
and,.. std::vector<Variable> should hold be std::vector<Variable*>
datsua: hmm. yes, maybe. let me just open up my compiler. it looks very similar, maybe it is.
thanks for posting it datsua!
Yes because that's not roughly what doomdoom posted before...
superplek: After browsing the previous page I see that doomdoom wrote about the same idea. So you're right :) But I used rudi's Norwegian explanation to guesstimate what he wanted.
I really wasn't commenting on you, no worries :) Props for the effort.
datsua: do you think this will do the same thing?
i get no compiler errors.
i get no compiler errors.
Code:
class Value {
public:
virtual ~Value() {};
};
class Variable {
public:
virtual void set(Value *) = 0;
virtual void get(Value *) = 0;
};
template <class T>class TValue : public Value {
public:
T value;
};
template <class T>class TVariable : public Variable {
public:
virtual void set(Value *v) { m_value = dynamic_cast<TValue<T>*>(v)->value; }
virtual void get(Value *v) { dynamic_cast<TValue<T>*>(v)->value = m_value; }
private:
T m_value;
};
std::vector<Variable *> variables;
variables.push_back(new TVariable<T>);
etc...
superplek: yes, but its easier when someone translate it into code. props for doomdoom. i know he allready said it too.