const char* address and string literals. Should I rely on this behaviour?

[camelCase]

Consider the following:

class Base {
    public:
        Base (char const* s) :
            str (s)
        {}
        char const* str;
};
class Derived : public Base {
    public:
        Derived () :
            Base("Test")
        {}
};
int main () {
    Derived d1;
    Derived d2;
    Derived d3;
    Derived d4;
    bool b =
        (d1.str == d2.str) &&
        (d1.str == d3.str) &&
        (d1.str == d4.str);
    std::cout<<b;
    return 0;
}

The result is "true".
This is awesome because I can save memory usage when I use this to create a debugging module for my game objects.

But should I expect this behaviour on standards-compliant compilers?

 

[s3rius]

The C++ standard says:

Whether all string literals are distinct (that is, are stored in
nonoverlapping objects) is implementation-defined. The effect of
attempting to modify a string literal is undefined.

I guess all common compilers use string pooling as it's easy to implement and useful to have. But it's not necessary.
In Visual Studio you have the compiler switch /GF to turn string pooling on/off. g++ probably has something similar.

 

[s3rius]

Since I can't use the Edit feature (God knows why, it's broken) I'll make an addendum here:

The only thing that changes if string pooling is disabled is the way you have to check for equality. Instead of d1.str == d2.str you'll have to strcmp(d1.str, d2.str).

So you don't have to code for memory consumption, only for speed of execution (as a single ptr comparison is obviously faster than a strcmp). But since it's debugging you generally don't have to care about speed all that much anyway.

If you wanna keep it that way but fear that your program might be run through a compiler that doesn't have string pooling you could put a static_assert("Test" == "Test") somewhere. I doubt that there is a compiler that uses string pooling - but only sometimes.

 

[camelCase]

static_assert() with char const*, genius. Too bad string pooling isn't a requirement =/
Thanks =)

This compile-time address stuff reminds me of something. A friend had this weird problem but I don't remember it clearly. It had to do with two functions having the same signature and code but he had a reason to have them separate and not just have one function; I don't remember why.

But when he built it, the compiler optimized away the second function, making his function pointers always point to the first function even when he explicitly told it to point to the second..

 

[TheDamien]

Saving memory in a debug module should really be the last of your concerns. It is not worth introducing undefined behavior into your code.