Constructing class objects using names from an array

Is there a way to construct class objects by using names which are stored in an array as the names of the objects. Here is it conceptually but this throws a conflicting declaration error. This code is only intended as an example.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class LEDSSS 
{
  public:
    int m_LEDPin{};
  
   void setPin(int pin) {
     m_LEDPin = pin;
   }

   int getPin(){
    return (m_LEDPin);
   
   }
 
};

//LEDSSS GAREEN;
//LEDSSS RAHEAD; 
char * LEDnames[2] = { "GAREEN", "RAHEAD" };
LEDSSS LEDnames[0];
LEDSSS LEDname[1]; 

Last edited on
Names of variables have a meaning only for the programmer, not for the operation of the executable.
What do you really want to achieve?
I am fairly sure you can do it with a C macro. Ill see if I can do it, my macros are getting rusty.

eg

1
2
3
4
5
6
7
8
#define makevar(a) int a;

 int main()
 {
   makevar(x);
   x = 3;   
	 
 }


honestly seems messy. Its going to obfuscate your code: it will be nearly unpossible to find the variable definition when debugging, and a nightmare to read and follow. It would be better by far to use something like notepad++ macros to generate the variable names into a cpp file, or write a little c++ program to generate the code you need, or something like that. This gains you nothing but trouble, but you CAN do it.

note that I am not sure how much head exploding will happen if you tried to do this from a user provided list. Remember that variables need to be created at COMPILE time, so that is a no-can-do on creating them after compile from a list. You CAN create dynamic variables (eg push back onto a vector) and give that a name (via smoke and mirrors) to accomplish this concept.
Last edited on
To answer "what do I really want to achieve?", of course the sample code I provided is only a simple example. What I am dealing with is having dozens of instances of a class object that need to be constructed. Rather than construct them one line at a time, I was hoping to do this in a loop. In my programming I have an interface class that allows me to use a looping structures to handle my long lists of class objects with very little code space. I'd like to do the same, or similar, when constructing (instantiating) the class objects. Does that clarify things?

As for "smoke and mirrors", well there is a lot of that available in C++, until of course you understand it, and then it becomes useful and powerful tools. I abhor "arm strong" coding when object-oriented coding make the code more universal, versatile, easier to change, and easy to expand. This is just he next step in that evolution which I am seeking.
a simple way out, using a more OOP approach:
enum varnames {one,two,three,four, max_vn};
vector<thing> vars(max_vn); //bulk object construction
vars[two].field=value;
here 'two' can be used like a variable name to keep them straight.
you can also use a <map> of <fakevariablenamestring, object>
and various other OOP tricks.
do any of them work for you? The macro is kind of a crude way, but it also does the job, at the cost of 'where the heck is that variable created'.

you are not saving anything code-wise.
lets compare the code:
thing a,b,c,d,e,f; //construct a bunch of things.
vs
vector<string>names(number){{"a"},{"b"},...};
for(val: ...) makevar val;

what will you gain there? It took an extra vector, an extra loop, and the drawbacks of the macro to do the same thing? Even if each thing had a constructor parameter or 3 each slightly different, a quick excel macro could generate the params if there is a pattern that could be looped over and generated, then copy and paste the code the macro made.

if you want a dynamic list of them (eg from a file), one way to do it is to put the name into the thing type class, so each one knows its own name, as the most simple approach. You can also do container tricks like the map, or template wrapper that adds the name, or pointer tricks, etc. Its totally doable. Do you need that?
Last edited on
Use a std::vector<LEDSSS> (or array, if you must) of LEDSSS.
See any beginner's tutorial, but preferably one from a reputable source.

This may be an contrived example, but this type probably shouldn't exist:
1
2
3
4
5
6
7
8
9
10
11
12
13
class LEDSSS 
{
  public:
    int m_LEDPin{};
  
   void setPin(int pin) {
     m_LEDPin = pin;
   }

   int getPin(){
    return (m_LEDPin);
   } 
};

The get/set functions are trivial; they offer no functionality. Do not write code that does nothing. Do not solve problems that you don't have. Either make the member data public, removing the getters and setters, or (preferably) replace LEDSSS with int.
There is a whole school of programming that would disagree. It is true that I am using trivial examples here to illustrate concepts. As the program becomes more complex, these methods make for much more understandable, maintainable, changeable, and extensible code. For example, I am working right now on a complex system involving the management of over 100 displays. By changing only one ("trivial") method while maintaining all the rest of the code, we can switch from one set of physical interfaces to another completely different interface method that uses different physical hardware. Or, we could change the display types, etc, etc.
Blindly ignoring the costs of
a.) writing code that does nothing; and
b.) solving problems that you don't have
is just bad design.

To argue for LEDSSS misapplies the argument. It simply (and inconveniently) wraps int with no preconditions, therefore if int is "inflexible" so is LEDSSS. It can barely be changed without affecting its interface, which defeats the point.

Code isn't made "flexible" merely by adding cursory getters and setters. When done properly it's significantly more expensive than straightforward obvious code and is therefore a bad investment except when it's really needed -- that is, in cases where
a.) an implementation is likely to change without affecting the interface;
b.) the interface is widely used.

Otherwise, don't waste your time investing effort with bad returns.
Last edited on
Topic archived. No new replies allowed.