0

Forgive/correct me if my nomenclature is incorrect.

I have never understood the use of const_cast. Generally speaking, it seems to me that if you must use const_cast then your class/methods is probably fundamentally flawed unless you're using legacy functions that aren't const-correct. I may have stumbled on a case where its use is appropriate, however. I have a large class with a couple members that are assigned during construction and remain constant for the useful life of the object.

Because these objects are destroyed and constructed frequently, I would like to experiment with what I believe is called the Factory Model: instead of creating/destroying the object, I would like to retrieve/return it to a cache of unassigned objects. For example (simplified, of course):

class PersonFactory {
public:
    const Person* getPerson(const QString& newname) {
    //I can't assign the new name because it's const
        if(m_personCache.isEmpty())
            return createNewPerson();
        else
            return m_personCache.pop();
    }
    void returnPerson(Person* person) { m_personCache.push(person); person = 0; }
    static PersonFactory* instance;
private:
    Person* createNewPerson() const { return new Person(""); }
    QStack<Person*> m_personCache;
}

class Person {
public:
    friend Person* PersonFactory::createNewPerson();

    const QString& name() const {
        return m_name;
    }

    void destroy() {
        PersonFactory::returnPerson(this);
    }
private:
    Person(QString name) : m_name(name) {}
    //m_name is const and should remain that way to prevent accidental changes
    const QString m_name;
}

I can't assign a new name because it is const. Is this a good case for const_cast or am I missing an obvious alternative? Would using const_cast result in a performance hit?

Community
  • 1
  • 1
Phlucious
  • 3,704
  • 28
  • 61
  • `mutable` is not a sign of a design flaw. It's there so that objects can, for example, cache values instead of recalculating them every time they're needed. – Pete Becker Dec 13 '12 at 23:24
  • I removed the reference to `mutable` since it contributed nothing to the question. There are certainly occasions when its use is called-for. – Phlucious Dec 13 '12 at 23:30
  • instead of fiddling with Java design patterns, consider just using a C++ **small objects allocator** such as the one in the Loki library. for example, with the Java approach you cannot use the defaults for `std::unique_ptr` and `std::shared_ptr`. thus it has a negative impact on correctness and amount of work – Cheers and hth. - Alf Dec 14 '12 at 00:53

1 Answers1

0

Would using const_cast result in a performance hit?

Maybe. Casting away const to store a value when an object is in fact const produces undefined behavior. Undefined behavior can manifest as, among other things, a performance hit.

Pete Becker
  • 74,985
  • 8
  • 76
  • 165
  • "Casting away `const` to store a value when an object is in fact `const` produces undefined behavior." Can you clarify what you mean by undefined behavior? – Phlucious Dec 13 '12 at 23:34
  • I mean that the language definition does not impose any requirements on what an implementation does. A simple example that many beginners run into is: `int main() { const int i = 3; const_cast(i) = 4; std::cout << i << '\n'; return 0; }` and they're surprised that the program outputs `3`. As undefined behavior goes, that's pretty innocuous. – Pete Becker Dec 13 '12 at 23:37
  • Understood. So using the Factory Pattern as implemented negates the option for `m_name` to remain a `const QString`? I suppose I could make it non-`const`, make `PersonFactory` a `friend class`, and then assign it directly. Is that the correct OOP technique? – Phlucious Dec 14 '12 at 00:03
  • Nevermind. [This link](http://stackoverflow.com/questions/12322179/c-why-i-cant-compile-this-code-what-is-wrong-with-removing-constness-using?rq=1) seems to answer that question clearly. This use case for `const_cast` appears to be fundamentally wrong. Thanks! – Phlucious Dec 14 '12 at 00:09