Re: #define - in header or cpp
Paul Brettschneider <paul.brettschneider@yahoo.fr> wrote in
news:df02d$4e291d6e$506c0d9c$28226@news.chello.at:
Hm, I would not say totally. But there clearly are differences which
stem from the fact POD vs. non-POD. For example this works:
#define CONTROL_SEQUENCE "\xde\xad\xbe\xef"
constexpr const char *f1()
{
return "Test " CONTROL_SEQUENCE " string";
}
while this doesn't:
static const std::string control_sequence = "\xde\xad\xbe\xef";
constexpr std::string f2()
{
return "Test " + control_sequence + " string",
}
// error: return type ???std::string??? is not literal type
Interestingly, this *does* work:
static const std::string control_sequence = "\xde\xad\xbe\xef";
constexpr const char *f2()
{
static std::string s = "Test " + control_sequence + " string";
return s.c_str();
}
But the code is more ugly than the macro version.
What is the problem with concatenating string literals at compile
time, anyway?
Macros are evil. :) For example there is no scoping. I wish I could
put those control sequences inside a class, an enum or at least a
namespace. And I think it's curious that in times of templates where
whole algorithms are resolved at compile time, simple string literal
concatenation is pushed in the opposite direction from compile to
runtime. Personally, I probably will stay with the macro version,
since it is not very intrusive and doesn't have the usual problems of
multiple evaluation of arguments, etc.
Thank you for all the comments so far.
The problem is that
static const std::string control_sequence = "\xde\xad\xbe\xef";
is not a literal. It is a constant object of type string and as such is limited by the interface
that a normal object is allowed to present. The compiler doesn't usually know anything special about
strings. By design, they are a library concern and not a compiler concern. Of course, since
std::string is standard, the compiler could know something and generate the code you want without any
special tricks, but that would be an optimization and you couldn't count on every compiler doing
that. On the otherhand, literals like "blah" are known by every compiler and provision is made in
the language such that "blah" "blech" can be combined by the compiler to "blahblech" at compile time.
As soon as you throw an object instance into mix (even a constant one), the compiler can't do much
with it because object instances provide runtime behavior and not compile time behavior. I haven't
really had an opportunity/need to use constexpr yet, but I suspect that the first doesn't work
because you are asking it to construct a new object each time. The second works because it can
create the string statically once and then just return its address. Have you considered just:
static const std::string control_sequence = "\xde\xad\xbe\xef";
static const std::string f2 = "Test " + control_sequence + " string";
That should work too. Of course, it's not trully generating a literal like the macros would, but
this would be evaluted once and reused everywhere. I doubt the runtime costs would be be measurable.
joe