1

I'm not asking how to convert an enum to a string. I'm asking why the scope of the fully qualified class name cannot be used in this particular case of converting an enum to a string.

I'm running into a problem with a macro that converts an enumeration to a string. For example color_class.h

class color_class
{
  public:
     enum colors_e { RED, GREEN, BLUE};
};

#define colors__TO_STRING(color) \
(color == color_class::RED) ? "RED" : \
(color == color_class::GREEN) ? "GREEN" : \
(color == color_class::BLUE) ? "BLUE" : "";

The trouble I'm having is that sometimes "color_class::RED" is the correct expression to use, but sometimes the color_class prefix is wrong. That's what I cannot figure out. I don't know why the fully qualified name does not always work. Certainly I could redefine the macro to check for both color_class::RED and RED, but if I'm always assigning a value of type colors a fully qualified name, why would that name get lost? Thanks for the explanation.

To further clarify, when I use gdb, I see the following output:

ptype test_color
type = enum color_class::colors_e {RED, GREEN, BLUE}
p test_color == RED
$1 = true
p test_color == color_class::RED
There is no field named 'RED'
p colors__TO_STRING(test_color)
There is no field named 'RED'

macro define color__SIMPLE_STRING(color) (color == RED) ? "RED" : (color==GREEN) ? "GREEN" : (color == BLUE) ? "BLUE" : "";
p color__SIMPLE_STRING(test_color)
$2 = ""
Patrick Markiewicz
  • 41
  • 3
  • Possible duplicate of [Is there a simple script to convert C++ enum to string?](http://stackoverflow.com/questions/201593/is-there-a-simple-script-to-convert-c-enum-to-string) – Constantin Oct 21 '15 at 03:57
  • Are you sure that whatever header file color_class is declared in is loaded before using the macro? – Jerry Jeremiah Oct 21 '15 at 04:27
  • 1
    Is there an issue with namespaces? Macros don't know about namespaces, but the main compiler does. If the color class is defined inside an namespace, using the macro outside the namespace could lead to trouble, could it not? – Jonathan Leffler Oct 21 '15 at 04:28
  • 1
    Define "doesn't work". Do you get a compiler error? If so, show the code you are compiling, and the exact text of the error. – Igor Tandetnik Oct 21 '15 at 04:36
  • @IgorTandetnik Based on GDB output, I ultimately get a segmentation fault because RED != color_class::RED. There is no compiler error. I'm not sure why the macro doesn't return "" in the case of RED. – Patrick Markiewicz Oct 21 '15 at 18:18
  • @JonathanLeffler Yeah, I had to add color_class::RED or it doesn't compile outside of the namespace. So I would think that case would be covered. – Patrick Markiewicz Oct 21 '15 at 18:19
  • @JerryJeremiah If the header were not included, I would think a statement like the following would not compile: colors_e test_color = color_class::RED; – Patrick Markiewicz Oct 21 '15 at 18:22
  • I'm going to double check my macro isn't generally broken. I don't really understand why I would get a segmentation fault unless the string falls out of the macro without being defined. I definitely intended to have a default check. – Patrick Markiewicz Oct 21 '15 at 18:23
  • 1
    If `RED != color_class::RED`, that means you have another entity named `RED` somewhere in your program, unrelated to `color_class::RED` – Igor Tandetnik Oct 21 '15 at 20:52
  • I'm pretty sure the problem I'm seeing is a GDB issue and not the root of why my code is broken. I no longer think this macro is a problem. – Patrick Markiewicz Oct 21 '15 at 22:42

0 Answers0