# How can I use a char* value in the name of a variable?

This topic is 3866 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

say I want to call a function with a char* as a parameter and in that function I want to create a variable using the value of that char*. i.e. function("string goes here"); OR function(charVariable); and in the function it would do something like... function(char* charvalue) { int charvalue; } so the int variable would be the name of whatever the string in charvalue is. sorry if it isn't the easiest to understand, but that is the jist of what I am looking to do. EDIT: I forgot to mention that I am using c/c++ NOT c#

##### Share on other sites
you can't. variable names don't exist once the code is compiled.

Why are you trying to do this? There's probably a "correct" solution to your problem.

-me

##### Share on other sites
You want the variable name to be the value of another variable? You can't do that sorry. The variable name is only there as a means for you as the programmer to reference the data is represents. The actual name vanishes when the application is compiled. Also think about it, how are you going to reference the variable within the function when you don't know it's name before run-time?

EDIT: too slow [smile]

##### Share on other sites

Ok, here is the problem. I have a base class and quite a number of derived classes. I also have functions that any of these classes can use that aren't part of the class itself. So when I am passing a reference of the class that is using it, I need to know what TYPE the class is when I am using it so I can typecast. The idea is the have onetypecast to whatever my type is rather than having to determine my type (I store a type ID) then choose the correct typecast.

My example is the following:
Object - base class.
Box, Circle, Triangle - derived classes;

For some reason I use an external script to rotate the item, but Triangle uses a variable that is specific to it and not the other classes, therefore I need to cast it to a triangle in order to access it. Prior to this everyhting would just be cast to an object. I know the basic answer is "just check the type and cast it" but when I end up having 20 types and multiple different variables, some that might be shared across a few types, it would be much easier to just autocast to its type. The reason I figured I could do this is because if I had a define like this

#define cast ((objectType) object)

with objecttype being the string, when I passed in a string to that function then it would cast it to what I wanted. But since that seems impossible, then I am out of luck I guess.

##### Share on other sites
Go further: tell us, why triangle is so different for this function [smile]? Might you need to look at such techniques as double dispatch perhaps?

When you need to know the difference between types it shows weaknesses in your inheritance hierarchy.

##### Share on other sites
casts are the sign of a defect somewhere. Is the defect in the programming language that you are using or is it in your code?

Consider one of the following solutions:

not using inheritance
using virtual functions

also using char* is generally the wrong thing to do. C++ has a string class, use it.

##### Share on other sites
The problem is more like the boss/lead scripter who wants things his way and I can't really argue with the boss. So the classes have an instance of a script. But each script can be used by multiple object types. Sometimes I script will do something specific when the object is of a certain type and will use a variable that only that type has. Of course this could be solved by putting that in the base class but then every class would have an unneccessary instance of a variable. We pass into the scripts the base object, no matter which type it is. As of now we are simply typecasting if we need it to be a certain type. It truly is not ideal in my mind, but I don't make the final decisions around here. I would love to not have to typecast. I obviously can't speak too indepth about it because it's kind of confidential, but the theory is the same no matter how I am using it.

##### Share on other sites
It sounds like you might be able to use the visitor design pattern *shudder*.

I say that because it seems like you want to perform some special action on only one type in a hierarchy.

But I might be wrong; it's really hard to see what you mean without an actual example. Can you cast the problem into some actual code that you can paste here?

Edd

##### Share on other sites
Ok, I'll try and see if I can do it in code

class Object{public: Object(); ~Object(); eID GetType(); eID eType;};class Box : public Object{public: Box(); ~Box(); float m_fRotationTimer;};class Script{public: Script(); ~Script(); void Rotate(Object* pObject);};void Script :: Rotate(Object* pObject){ if(pObject->GetType() == Box)   float m_fRotationTimer += 1; else   pObject->Rotate(0,0,1);}Box* pBox;Script* pScript;pScript->Rotate((Object*)pBox);

With this here I can tell what the type is but the object itself does not have access to the m_fRotationTimer. I would have to typecast it to a Box. And what if I had a circle in there that had an angle value stored that I needed to mess with? Another typecast.

##### Share on other sites
I'm still a little bit confused. How are virtual functions not a solution, for example?

Edd

##### Share on other sites
Given that you cannot change the fundamental architecture (which is horrible, btw):

Another possibility would be giving the base class a std::map of variables indexed by std::string of the variable name. That way scripts can check to see if a given class variable exists in the map and make logic flow decisions that way. yada yada.

The real problem, of course, is that the current design violates object encapsulation. Each class should be in charge of updating its own data. The reason you are having such a hard time is that you have n scripts and m objects and each script updates the data of all m types of objects. That's le supar bad.

Honestly, it's your job as an engineer to point out deficiencies in design. If you see something horribly wrong and don't point it out, it's your fault when it fails. If your lead is hostile to criticism of his design, find another job.

Couple better architectures off the top of my head would be:

1) all objects share a common virtual interface (declared in the base class). Scripts may access objects only via that interface. A properly written script would never care about how functions in the interface are implemented.

2) each script is tied to a specific level of the object hierarchy. In this system the script has a pointer to the specific class for which it was implemented. (this is kinda-sorta how unreal script works; except in unreal script the object is actually defined on the script side of things)

But, basically, what you have is just an awful implementation of a scripting system. There are plenty of great scripting systems already developed whose architectures enforce good design on your side: lua and angelscript, for instance.

-me

##### Share on other sites
So, if I understand this correctly, let's say you have a triangle and a box, and both call script "ObjectScript", which would be like:

void ObjectScript(Object* obj){    obj->DoSomeStuff();    if (obj->type==TYPE_TRIANGLE) (Triangle*)obj->DoSomeTriangleStuff();    if (obj->type==TYPE_BOX) (Box*)obj->DoSomeBoxStuff();}

Right? The answer is pretty obvious. Break the above script into 3 scripts,placing the common code into "ObjectScript":

void ObjectScript(Object* obj){  obj->DoSomeStuff();}void TriangleScript(Triangle* triangle){  ObjectScript(triangle);  triangle->DoSomeTriangleStuff();}void BoxScript(Box* box){  ObjectScript(box);  box->DoSomeBoxStuff();}

Have the triangle call the TriangleScript, and the box calling BoxScript. I don't see any reason for all the code to be in 1 script and switching based on argument type, that's pretty stupid.

##### Share on other sites
Look up polymorphism.

##### Share on other sites
Quote:
 Original post by Palidine[everything]

Quoted for extreme emphasis.

##### Share on other sites
Thank you guys for all the help. It does definately seem as if there is no solution with the current setup outside of having seperated scripts for different types. I will have to make this clear to my lead/boss and maybe we can rework some structure to make it more efficient, logical, and overall better as far as code practice is concerned. I am glad everyone pretty much agrees that the setup is just plain stupid, as it has been a concern of mine and another programmers for a while that we have brought up atleast once or twice. Again, thanks.

##### Share on other sites

This topic is 3866 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628728
• Total Posts
2984417

• 25
• 11
• 10
• 16
• 14