1

My problem is the use of const_cast<>. I have a class which inherits from vector. Now in one of its member functions when I use this->begin(), this being a const pointer, it returns a constant iterator but I want to obtain a non-const iterator. The code looks something like ...

class xyz : private std::vector<//something>
{
public:
 xyz();
 void doSomething();
}

void doSomething()
{
    xyz::iterator it;
    it = this->begin();
    *it.insert(something); //here is the problem and this where I need to use const_cast 
                           // and in a lot more places
}

In the above function, since this->begin() returns a const iterator, I am forced to use a constant iterator and do a typecasting whenever I need to insert an element.

I thought of using const_cast at this->begin() but my friend told me that it is a bad idea to remove the constness of the this pointer. If it is so, then what is the way around?

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
ken
  • 816
  • 1
  • 9
  • 25
  • 5
    Actually, You opened a can of worms with *I have a class which inherits from vector*, Why do you inherit from `std::vector`? It is not meant for Inheritance. – Alok Save Mar 29 '12 at 07:37
  • 1
    @Als : necessity i need a class which inherits from vector so that class itself acts as a vector and can you be more specific about why it is not a good idea to inherit i am new so please help me. – ken Mar 29 '12 at 07:42
  • [Why should not I subclass/inherit standard containers?](http://stackoverflow.com/questions/6806173/why-should-not-i-subclass-inherit-standard-containers) You should use containershipp rather than Inheritance. – Alok Save Mar 29 '12 at 07:45
  • 1
    @Als :well i am bound to use it that way, but is there a solution to the const_cast problem i am facing? – ken Mar 29 '12 at 07:52
  • @Als: " It is not meant for Inheritance." [Nonsense](http://stackoverflow.com/questions/9667292/refactoring-a-class-which-inherited-from-a-stdcontainer/9669406#9669406). There are situations when it is useful. "no virtual destructors" won't cause problems as long as don't delete derived class using pointer to vector (there's no reason to that anyway). – SigTerm Mar 29 '12 at 07:53
  • It's sometimes valid to inherit privately from a standard container, but certainly never publicly. If you want a class that acts as a vector, then you have one: `std::vector`. If you want a class with slightly different semantics, you can define one. If you want a class which has some of the functionality of vector, but does other things differently, it's possible to inherit privately, and use `using` to hoist the functionality you want up into the derived class. – James Kanze Mar 29 '12 at 07:56
  • @SigTerm: I am sorry for the reasons mentioned in-plenty in the answer I linked above, I do not agree to your (invalid)contention & No I won't call your contention *Nonesense*, eventhough it is because you are free to have your (Incorrect)opinions, it's a free world. – Alok Save Mar 29 '12 at 07:57
  • 1
    @Als: The answer you linked contains highly debatable personal belief that is not convincing. In practice not every class needs virtual destructor and for every feature people try to avoid there's specific situation when this feature is useful. Same applies to inheriting from containers. – SigTerm Mar 29 '12 at 08:05
  • Aside from the std::vector public inheritance issue, the const_cast issue seems unconnected to your code. Can you provide a small code sample that reproduces the problem? Also, there is a non-const std::vector::begin() method returning iterator. – juanchopanza Mar 29 '12 at 08:05
  • 1
    @SigTerm: "won't cause problems as long as don't delete derived class using pointer to vector". And how do you know that your fellow programmers or users of your API won't do this? My opinion is that its better to avoid any chances of object slicing. – Rolle Mar 29 '12 at 09:50
  • @Rolle: "And how do you know" And how do you know that "your fellow programmers" won't static_cast it into something like char* and `delete[]` it? It is said that determined fool can break any system that is said to be fool-proof. Sane usage is safe. Unsafe usage requires dangerous design decisions, and if your colleagues use something that deletes standard containers by pointers, you're screwed anyway. – SigTerm Mar 29 '12 at 10:13

1 Answers1

1

If the vector is part of the state of the class, either as a member or as a base (although it's really bad practice to publicly inherit from vector), then a const member function should not modify it. If the vector is part of the state, and a function modifies it, the function should not be const.

Generally. There are special cases where, for example, the vector represents cached state, that is logically calculated, but whose calculation is expensive. In such cases, you can make the vector a mutable member. But do be sure that the vector really doesn't represent "observable state".

And finally, the code you post doesn't seem to have anything to do with the problem. For starters, the only function is non-const. And the code won't compile, for several reasons (use of this in a non-member function, invocation of a member function insert on an iterator, which doesn't have such a member, etc.).

James Kanze
  • 150,581
  • 18
  • 184
  • 329