Best Variable to Use

Hello. I have a question that is more of a general programming question.

I am making a class and I ran into a data member that I am having trouble deciding what variable type to use.

I have a data that can only be one of two values. They are strings, say "black" and "White".

I was thinking of just using the string type, but then I thought it might be better to use a bool since the value can take only one of two values.

The data will be used to do so decision making as well as be displayed on the screen, possibly.

What would be the optimum data type to use in this situation, because I can see the use of several?

Quote:

---

Originally Posted by VelvetTLeopard

I have a data that can only be one of two values. They are strings, say "black" and "White".

I was thinking of just using the string type, but then I thought it might be better to use a bool since the value can take only one of two values.

---

You can have both. This is just off the top of my head without putting a lot of thought into it:

Code:

---

#include <map>
#include <string>
#include <iostream>

typedef std::map<bool, std::string> BoolMap;

using namespace std;

int main()
{
  BoolMap myMap;
  // Initialize the map
  myMap.insert(make_pair(true,"White"));
  myMap.insert(make_pair(false,"Black"));

  // Prove it works
  cout << "The value of true is " << myMap[true] << "\n";
  cout << "The value of false is " << myMap[false];
}

---

I'm sure others will add alternatives to the above.

Regards,

Paul McKenzie

That seems like a lot of unnecessary work. I am not trying to pair them. I just wanted to know what data type is best for a piece of data that can only two values. I thought since a bool is just a true or false, is it stored as a single bit or does it take an entire byte? Should I use a string and get it or an integer and convert to a string?

Quote:

---

Originally Posted by VelvetTLeopard

That seems like a lot of unnecessary work.

---

I don't see any unnecessary work. The goal is to make the program understandable, easy to maintain, and unbreakable.

In your original post, not only did you mention the variable type, but strings that are to be used with those types. By placing emphasis on not just the types, but what they will be used for in various parts of the program, you can encapsulate the entire concept in one type, i.e. a map. This is how you think in C++, and not low-level bits and bytes.

By encapsulation, the concept of both the boolean and the string are kept in one place, instead of strewn all over in disjoint functions, types, etc. with no coherence. In one place, everyone knows what "true" means and what "false" means, instead of looking in various parts of the code and possibly making an error if they get the types reversed.

Quote:

---

Should I use a string and get it or an integer and convert to a string?

---

And who will write this conversion function? Those two lines of code I posted does all of what you've just explained.

Regards,

Paul McKenzie

Code:

---

#include <map>
#include <string>
#include <iostream>

typedef std::map<bool, std::string> BoolMap;

using namespace std;

bool BigFunction()
{
  bool bReturnValue = false;

  // a lot of complex work not shown here
  //...
  //...
  return bReturnValue;
}

int main()
{
  BoolMap myMap;
  // Initialize the map
  myMap.insert(make_pair(true,"White"));
  myMap.insert(make_pair(false,"Black"));

  cout << "The color I want is " << myMap[BigFunction()];
}

---

So the map is the "conversion function" you're looking for. The return value (whether it was true or false) was converted to the proper string name.

Regards,

Paul McKenzie

Ok here is what I am trying to do. I have a class. In this class I want a data member that holds a value, one of two possible values, that will be used by the main program or other classes to determine other things. All I was wanting to know is what variable data type would be the best, as in most efficient, one to use. I never meant to say I had set a type and value. That was an example. I have not decided what type to use and those "strings" were only an example of one way this data COULD be represented. The whole issue was what data type is most efficient to use when the data can be only one of two possible values in general no matter what the data is. And I would write the code to convert from int to sting and vice versa.

Quote:

---

Originally Posted by VelvetTLeopard

Ok here is what I am trying to do. I have a class. In this class I want a data member that holds a value, one of two possible values, that will be used by the main program or other classes to determine other things. All I was wanting to know is what variable data type would be the best, as in most efficient, one to use.

---

An integral type such as bool will always be more efficient than a string type, since each character of a string must be compared to know the final value.

Even the example I showed you uses the bool to hold the integral type in the map. So my example not only answered your question, it shows how to associate that bool with strings without any need for conversion functions if you know the association between the bool and the string.

Regards,

Paul McKenzie

So a simple bool will suffice. And once again I did not say the data WAS a string. I said the data COULD BE REPRESENTED as a string or bool or int, etc. The important fact was that the data type, what ever it was, would only have two possible values. I never asked for code in the first place. I know the basics of coding and always try to write my own code before asking for anything. Your example uses more than 13 lines of code BEFORE compilation, including an unnecessary #include in my opinion, that would result in a ton of lines just to store a piece of data that can be stored in a single bit. Plus, you never used any references, pointers, or inlining for such small functions and this would have dumbed down performance if I was looking at large numbers of interactions for this data member. And your example never answered my question because my question was "What data type is the most efficient one to hold data that can be only one of two values?" not "What data type or structure would I use to convert between an integer and a string depending on what the input was?".

Quote:

---

Your example uses more than 13 lines of code BEFORE compilation, including an unnecessary #include in my opinion, that would result in a ton of lines just to store a piece of data that can be stored in a single bit.

---

What does an #include have to do with storage of data? So you write programs without #include files?

The #include is for the map and for the cout. It is there to so that you or anyone else can copy and paste it into any compiler and run it without having to edit any lines.

Quote:

---

Plus, you never used any references, pointers, or inlining for such small functions

---

What function? I just showed you that you can get the string value given the bool without writing any functions to convert back and forth between the bool and string. So you get the best of both worlds.

Where does inlining and pointers come into play? As a matter of fact, it is good that no pointers are used -- this is the advantage of using high-level constructs, as pointers just become more maintenance.

Quote:

---

and this would have dumbed down performance if I was looking at large numbers of interactions for this data member.

---

With C++, you cannot optimize by sight. This is the mistake that a lot of coders make, and that is judging C++ by what they see instead of actually compiling the code (with optimizations on) and running the program.

Regards,

Paul McKenzie

Another thing to consider is that if you have several true/false variables, then consider the std::bitset<> class instead of separate bools.

Regards,

Paul McKenzie

I actually was thinking of a way to create a sort of "flag" word, but didn't know how to do it in C++. Assembly is no problem. I know what preprocessor directives are and I know how to use them. Do not assume I am new to programming. I am new to efficiency and performance. I just don't see why anyone would add an include, in this case #include<map>, to store a value because that single include file is going to add more lines than necessary. And you have 5 functions. You have a call to BigFunction(), two calls to insert(), and two calls to make_pair(). And as for pointers, I know they are becoming more outdated in lieu of references, but they can still be useful. You are passing variables by value in all five of the functions in your code. This means you are making copies of all the argument variables passed to them. Since you are merely displaying the data in these functions and not actually changing them, you really should pass them by reference, so they can not be changed. Plus, passing by reference does not make a copy of a variable's value, but creates a sort of pointer to that value instead. And as for judging optimization by sight, I can't do it yet, but people experienced can. All it takes is knowing the intricacies of thee variables and other parts of the code, how the lexicon and parser work, how the compiler works and a bit of Big O use. Yes, you can judge the "size" of a function by looking at it. You simply do the math of how often the function is called as well as what the functions does. Those two calls to make_pair() are creating in memory four more variable values plus the two they used to copy. That means your code snippet has allocated memory for six variables and that is for each time the snippet runs.

Quote:

---

Originally Posted by VelvetTLeopard

I just don't see why anyone would add an include, in this case #include<map>, to store a value because that single include file is going to add more lines than necessary.

---

Are you going to attempt to write a C++ program without using the standard library, which means you must #include files?

Quote:

---

You have a call to BigFunction()

---

Which I am using just as an example

Quote:

---

two calls to insert(), and two calls to make_pair().

---

Those are done to initialize the map. Once the map is initialized, there is no need for further initialization. The new version of C++ has nicer initialization syntax -- would that have changed your take on the code if I used C++ 11? What you're concentrating on is moot, as again, it is there to initialize the map, nothing else.

Quote:

---

You are passing variables by value in all five of the functions in your code.

---

Where are variables passed by value? Can you point out where values are passed by value?

Quote:

---

This means you are making copies of all the argument variables passed to them. Since you are merely displaying the data in these functions and not actually changing them, you really should pass them by reference, so they can not be changed.

---

I wish I knew what you are referring to.

Quote:

---

And as for judging optimization by sight, I can't do it yet, but people experienced can.

---

I guess 20+ years of doing C++ isn't experience enough. OK.

The code I posted is a sample of how a map operates. Nothing more, nothing less. It's there so you can see the syntax and the higher-level constructs that can be used to make the program maintainable.

Quote:

---

All it takes is knowing the intricacies of thee variables and other parts of the code, how the lexicon and parser work, how the compiler works and a bit of Big O use.

---

You are talking about bare algorithms. I am talking about looking at C++ higher extractions and classes such as map, vector, bitset, functors, etc. and attempting to judge "Big O" based on that information. It has been proven time and time again that you cannot take C++ code using these constructs and firmly state what is fast or slow unless you run the program and time it.

Quote:

---

Yes, you can judge the "size" of a function by looking at it. You simply do the math of how often the function is called as well as what the functions does. Those two calls to make_pair() are creating in memory four more variable values plus the two they used to copy. That means your code snippet has allocated memory for six variables and that is for each time the snippet runs.

---

OK, what about this:

Code:

---

int main()
{
  BoolMap myMap;
  // Initialize the map
  myMap[true] = "White";
  myMap[false] = "Black";
}

---

The question -- is this faster than using make_pair()?

Regards,

Paul McKenzie

Using bitset:

Code:

---

#include <bitset>

int main()
{
    std::bitset<8> myBitSet;  // this makes room for 8 on/off values.
    myBitSet.set(0, false);  // sets bit 0 to false
    // or
    myBitSet[0] = false;  // sets bit 0 to false
}

---

The bitset class takes less space on the whole, since it is optimized to use a bit instead of an entire bool as a "true/false" value. So for example, something like sizeof(bitset<16>) is more than likely smaller than sizeof(bool) * 16.

Again, look at the set() function, and look at the alternate syntax using []. Which is faster? Or does it matter? Isn't it a case as to which one is readable or understandable to you or your fellow programmers, and not a matter of speed (and to be honest, there is not a question on speed, since both methods are comparable).

Regards,

Paul McKenzie

Quote:

---

Originally Posted by VelvetTLeopard

I just wanted to know what data type is best for a piece of data that can only two values.

---

It's to use a bool.

Restriction is a very general principle of good programming. The purpose is to reduce complexity. The fewer the possibilities the fewer the things that can go wrong. Code becomes easier to read and comprehend. Compilers can make better optimization decisions.

So declare types and variables in the narrowest scope possible. If it is a constant make it a constant. Limit outcomes to possible outcomes. Have just one entry and one exit point. Be brief. Don't waste resources. Etcetera.

bitset seems the way to go then, but I would want to come up with more flags for the program, which shouldn't be hard.

For performance, it may matter or it may not, but the class this is part of will be instantiated for many, many, and maybe many, many more agents in the system, all of which may test this value for each and every other instance of the class so if there are, say, 100 agents in the program, each one would check this value of each other instance, giving you 9,900 checks for the value, and this class was designed to check this value whenever another class satisfies the check's requirements, say time of day, and if all instances are online at the same time, worst case scenario, 9,900 checks. Now assume this check is part of an overhead loop for the program and each class makes this check every second. Now this value check is happening, again with a worst case scenario, 9,900 times per second, or 594,000 times per minute. That is why I want the most efficient data type.

I will look into bitset, but I would like to ask more question on the subject: Would inline assembly for C++ help me with manipulating single bits better than C++ alone does? I already know assembly and enjoy it.

nuzzle posted before I got this post done. That makes a lot of sense. I am ok with using a bool because the data will never be interpreted in a way the human will see except for possibly one or two instances, where a simple conversion can be made.

bitset seems the way to go then, but I would want to come up with more flags for the program, which shouldn't be hard.

For performance, it may matter or it may not, but the class this is part of will be instantiated for many, many, and maybe many, many more agents in the system, all of which may test this value for each and every other instance of the class so if there are, say, 100 agents in the program, each one would check this value of each other instance, giving you 9,900 checks for the value, and this class was designed to check this value whenever another class satisfies the check's requirements, say time of day, and if all instances are online at the same time, worst case scenario, 9,900 checks. Now assume this check is part of an overhead loop for the program and each class makes this check every second. Now this value check is happening, again with a worst case scenario, 9,900 times per second, or 594,000 times per minute. That is why I want the most efficient data type.

I will look into bitset, but I would like to ask more question on the subject: Would inline assembly for C++ help me with manipulating single bits better than C++ alone does? I already know assembly and enjoy it.

Quote:

---

Originally Posted by VelvetTLeopard

bitset seems the way to go then, but I would want to come up with more flags for the program, which shouldn't be hard.

---

OK. The bitset is a template class, so you only pay for the overhead at compile time (so a bitset<10000> is no different than a bitset<1> in terms of runtime speed).

Quote:

---

For performance, it may matter or it may not, but the class this is part of will be instantiated for many, many, and maybe many, many more agents in the system, all of which may test this value for each and every other instance of the class so if there are, say, 100 agents in the program, each one would check this value of each other instance, giving you 9,900 checks for the value, and this class was designed to check this value whenever another class satisfies the check's requirements, say time of day, and if all instances are online at the same time, worst case scenario, 9,900 checks. Now assume this check is part of an overhead loop for the program and each class makes this check every second. Now this value check is happening, again with a worst case scenario, 9,900 times per second, or 594,000 times per minute. That is why I want the most efficient data type.

---

The check will come down to either calling a function to check a bool, an int, a bit, whatever.

The real issue is the higher-level design and maintainability. I think this is more important than the data type at this stage. Once you have a working design, you profile the code and determine where the bottlenecks occur (again, you can't optimize by sight). Changing the data type is the easiest task (and could even be made transparent if using templates).

Also, "over-pointerizing" the code doesn't necessarily make the code faster, especially in this day and age of C++ optimizing compilers. There are cases where using pointers (where the coder is trying to be smarter than the compiler), leads to slower code. The reason being that the compiler's optimizer can't make heads or tails of the pointer manipulations, and the pointer-aliasing renders the optimizer useless.

Quote:

---

I will look into bitset, but I would like to ask more question on the subject: Would inline assembly for C++ help me with manipulating single bits better than C++ alone does? I already know assembly and enjoy it.

---

Look into this after you have a running program and it has been profiled.

Regards,

Paul McKenzie

Would you be able to tell me how to profile a program? Tools needed, etc?

What OS? If it's Windows, you can use various profiling tools.

IBM Rational Quantify
http://www.semdesigns.com/Products/P...pProfiler.html

There are profilers built into Visual Studio, but I haven't used them since I have use commercial products similar to the ones above. Also see this link for free profilers (don't know the quality of them though):

http://stackoverflow.com/questions/6...s-if-there-are

Regards,

Paul McKenzie

Quote:

---

Originally Posted by VelvetTLeopard

nuzzle posted before I got this post done. That makes a lot of sense. I am ok with using a bool because the data will never be interpreted in a way the human will see except for possibly one or two instances, where a simple conversion can be made.

---

Separation of concerns is another very general principle of good programming. Internal data handling is one thing and user display is another. Keeping them well separated will increase flexibility. The program becomes more modular.

http://en.wikipedia.org/wiki/Separation_of_concerns

If you think you can determine the efficiency of a piece of C++ code just 'by looking' then you should maybe read this.

http://blog.knatten.org/2011/08/26/d...-optimization/

Quote:

---

Originally Posted by VelvetTLeopard

For performance, it may matter or it may not, but the class this is part of will be instantiated for many, many, and maybe many, many more agents in the system, all of which may test this value for each and every other instance of the class so if there are, say, 100 agents in the program, each one would check this value of each other instance, giving you 9,900 checks for the value

---

That sounds like you could get a massive performance improvement by finding a smarter algorithm that just comparing all pairs. When you are talking about optimization, the first thing to consider is algorithms and data structures. Making the right choices here can make your program several times as fast. Only then should you look at lower-level issues, such as how to avoid redundant copies (where the compiler doesn't do it for you already) or how to improve cache performance. The really low-level stuff is something you hardly ever have to touch, in my experience. Compilers nowadays are great at handling the low-level things to make your code as fast as it can be. The exception might be when you are targeting a specific platform.

Regarding the use of booleans, my 2 cents is that you should be careful to use booleans when the meaning of true or false may not be clear in the context where it is used, especially when using several in parallel. E.g. if you have the function

Code:

---

void DoSomething(bool option1, bool option2);
// that will be called like
void foo()
{
    DoSomething(true, false);
}

---

It is not clear what the true and false mean in the function call, even if you give the function and its arguments meaningful names. You can use enums instead to make the code self-documenting.

Code:

---

enum Option1 {
    EOff,
    EOn
};
enum Option2 {
    EDisabled,
    EEnabled
};
void DoSomething(Option1 option1, Option2 option2);

void foo()
{
    DoSomething(EOn, EDisabled);
}

---

Also, if I now mess up the order of the arguments in my call to DoSomething, I will get a compiler error rather than a hard-to-find bug in my program.

I wanted to add to always, always, be very very careful with values "that can only hold two states". Unless your variable actually holds a representation of "true/false", more often that not, it ends up being able to hold 3 or more states.

If you created an interface based on bools, you'll be f'ed beyond belief.

In these cases I recommend to always go for an enum. As long as you have only two states, it'll be just as efficient anyways. But the day your variable holds a third "grey" state, you'll have some hope that your program can handle it...

D_Drmmr and monarch_dodra, thank you for more clarification. I guess I was too concern with the low level stuff due to my assembly education. So I can trust my Visual C++ 2008 Express Edition compiler to optimize as best it can for me? And now that you mention the enumeration for the states possibly having a third, I rethought my data and I could stretch it a bit for maybe a third state. It could cause a nice bit of confusion or lols in the program and it would make the class more modular. Thanks for your help.

Quote:

---

Originally Posted by VelvetTLeopard

D_Drmmr and monarch_dodra, thank you for more clarification. I guess I was too concern with the low level stuff due to my assembly education. So I can trust my Visual C++ 2008 Express Edition compiler to optimize as best it can for me?

---

You can trust the optimizer to do a great job after you have fixed the project settings. In all its wisdom, Microsoft decided that it was a good idea to turn off optimizations in release builds by default. This was fixed in later versions, but if you use VS2008, you're stuck with the bad default settings. The most important ones are under 'C/C++ -> Optimization' and 'C/C++ -> Code Generation' in the project settings. Also, make sure you define _SECURE_SCL as 0 in release builds. See http://msdn.microsoft.com/en-us/libr...(v=vs.90).aspx.

Quote:

---

Originally Posted by VelvetTLeopard

So I can trust my Visual C++ 2008 Express Edition compiler to optimize as best it can for me?

---

ok, but you should not trust the compiler passively; as Paul said, you should ask yourself how to write C++ code that enables the compiler to produce optimized code. In c++, this is neither obtained by excessively using pointers, reducing calls, packing data structures or whatever, nor by writing Java-like code; this is obtained by leveraging the type system.

For example, if you want to copy a range of data in STL you write something like

Code:

---

std::copy( source.begin(), source.end(), dest.begin() );

---

indipendently of what's the nature of those ranges. Now, if those begin()/end() return pointers to POD's than memcpy will be called, if they are iterators of some special kind then some other copy-strategy will be used, etc... . Do you see it ? the compiler is using the information embedded in the types to automatically select the more efficient method for you. And note that this happens at no readability/maintenance cost. And it's scalable in the sense that the more abstraction you add the more information the compiler will have to optimize your code ( for example, have you ever heard of linear algebra expression templates libraries ? these can make c++ code better performing than numerically-oriented languages like fortran ... ).

This is in contrast with low-level optimizations which, albeit useful in the specific context in which they were thought, don't scale with even innocuous code changes resulting in high mantainability costs. Of course, you can/should use them wherever no type information is possible or required ( for example, this can happen deep inside the implementations of those higher level constructs ), but with monarc_dodra's remarks in mind, of course.