G ++ 4.8.2 insists that simple variables are arrays
This issue only occurs with g ++ 4.8.2 for ARMv6 (pidora stock); it compiles without errors or warnings on x86_64 w / clang 3.4.2 and g ++ 4.8.3. It's hard for me not to see this as a compiler error, but I wanted to get other opinions.
It includes a simple member variable that g ++ keeps pushing for an array and
error: array must be initialized with a brace-enclosed initializer
The header for the class looks like this:
namespace SystemStateMonitor {
class ramInput : public input, public inputFile {
public:
typedef enum {
RATIO,
PERCENT,
KiBYTES,
MiBYTES
} style_t;
ramInput (
const std::string &label = "RAM",
style_t style = style_t::PERCENT
);
unsigned int getAvailable ();
double getDV ();
double ratio ();
protected:
style_t style;
unsigned int available;
void setStyle (style_t);
friend input* jsonInputRAM (jsonObject);
};
}
The constructor looks like this:
#define PROC_FILE "/proc/meminfo"
using namespace std;
using namespace SystemStateMonitor;
ramInput::ramInput (
const string &label,
ramInput::style_t s
) :
input (label),
inputFile (PROC_FILE),
style (s),
available (0)
{
setStyle(style);
}
And when I compile this with ARMv6 g ++ I get:
inputs/ramInput.cpp:19:14: error: array must be initialized with a brace-enclosed initializer
available (0)
^
There are no "members" available in superclasses; no potential weird collision. I wonder if I then change the constructor:
) :
input (label),
inputFile (PROC_FILE),
style (s)
{
available = 0;
setStyle(style);
}
Now I am getting the same error for style (s)
. If I then do the same with style
(move the initialization to the body), I get an error for inputFile (PROC_FILE)
, which is even weirder, because the call to the super constructor.
inputs/ramInput.cpp:17:22: error: array must be initialized with a brace-enclosed initializer
inputFile (PROC_FILE)
^
Unfortunately, but not surprisingly, SSCCE starting with this:
class test {
public:
test () : x(0) { };
unsigned int x;
};
Doesn't reproduce the problem.
What could be wrong here? Am I correct in thinking that this is not my fault?
source to share
As Mike Seymour points out in the comments on this question, the cascading nature of the error indicates that the compiler was simply pointing to the end of the problem initiation list rather than the correct entry. The array ended up in the default initializer of the superclass constructor:
std::array<double,2> range = { 0 }
This g ++ throttles on this and:
std::array<double,2> range = { 0.0, 0.0 }
But:
std::array<double,2> range = { }
Works. It's good that I don't need any non-zero values ...
source to share