Is there a good reason for this?
Printable View
Is there a good reason for this?
>Is there a good reason for this?
Because you already know where the item is and can acquire an iterator for it with ease. Why do you need it to return an iterator?
>> Because you already know where the item is and can acquire an iterator for it with ease.
Well sure, you can do:
But that's just fugly.Code:iterator
push_back(T b)
{
base::push_back(b);
iterator c = end();
return --c;
}
>> Why do you need it to return an iterator?
I'm storing the iterator for a future erase() operation.
>But that's just fugly.
It works though. :) Better to use a fugly but working solution than to complain about the decisions of the standard library and not get a solution.
>Well sure, you can do:
Or better yet:
Saves you a temporary.Code:iterator push_back(T b)
{
base :: push_back(b);
return --end();
}
>I'm storing the iterator for a future erase() operation.
Are you doing this with every item you push? A search operation to get the proper iterator may be the cleaner option if you don't save these iterators frequently.
According to the standard, if push_back generates an exception (possible as the vector or other container may need to allocate more memory) there will be no effect....it either works or it doesnt....this is due to exception safety promises that allow clients of the containers to use them without worrying that the container code will throw (some members do indeed throw, but they are specifically documented).....if the code does generate an exception and you assign the returned object to something in your code, then you may well be assigning to something that is wrong or not there.
Herb Sutter discusses this in his articles about "Exception Safe" containers
Hmmm, ok, thanks Fordy, but...push_back() internally uses insert(), which...returns an iterator! Weird, right?
>> Or better yet:
O.K., that's a bit cleaner, thanks. :) (though I'm not sure it really saves on a temporary)
>> Are you doing this with every item you push?
No. depending on the 'mode' we're in, a 'purge' list of iterators (which can't be immediately erased due to other dependancies) is built.
Not at all. Just because your STL implementation uses insert internally doesn't mean that any other does.Quote:
Originally posted by Sebastiani
Hmmm, ok, thanks Fordy, but...push_back() internally uses insert(), which...returns an iterator! Weird, right?
By the way, its hard to tell based on your example solution, but if you are considering creating a derived container class that publicly inherits from one of the STL containers so that you can have this alternate push_back I would recommend considering a different solution. This is because, among other things, the STL containers were not designed to be publicly derived from.
Quote:
Originally posted by jlou
By the way, its hard to tell based on your example solution, but if you are considering creating a derived container class that publicly inherits from one of the STL containers so that you can have this alternate push_back I would recommend considering a different solution. This is because, among other things, the STL containers were not designed to be publicly derived from.
Why would you say that?
I'm not really an expert in this - I am merely regurgitating things I have read elsewhere - but basically, if a class doesn't have any virtual functions (and therefore has a non-virtual destructor), then it should not be inherited from.
If you do that, then depending on how your code is used, it could lead to errors and/or undefined behavior. I believe the standard states that using delete on a pointer of a base type without a virtual destructor, whose actual dynamic type is a derived class, is undefined. For example:On my machine (MSVC++ 6.0 with upgraded Dinkumware libraries), the base class destructor is called and the derived class destructor is not in the default Release build. In the Debug build I get an error. Clearly, if there is anything important happening in the derived destructor, even in my Release configuration that doesn't crash, that code will not be executed.Code:#include <iostream>
#include <vector>
class BaseClass
{
public:
BaseClass() { }
// Non-virtual destructor
~BaseClass() { std::cout << "In Base Destructor." << std::endl; }
};
class DerivedClass : public BaseClass
{
public:
DerivedClass() { }
// Virtual does not matter here.
virtual ~DerivedClass() { std::cout << "In Derived Destructor." << std::endl; }
};
typedef std::vector<BaseClass*> BaseClassPtrArray;
void EmptyAndDelete(BaseClassPtrArray& objList);
int main()
{
BaseClassPtrArray myObjList;
myObjList.push_back(new DerivedClass);
myObjList.push_back(new DerivedClass);
EmptyAndDelete(myObjList);
}
void EmptyAndDelete(BaseClassPtrArray& objList)
{
BaseClassPtrArray::iterator iterObjPtr = objList.begin();
BaseClassPtrArray::iterator iterEnd = objList.end();
for(; iterObjPtr != iterEnd; ++iterObjPtr)
{
BaseClass* pDeadObj = *iterObjPtr;
delete pDeadObj; // Undefined behavior
}
objList.clear();
}
I have seen some that have argued that they don't do anything in their derived destructor and that they "know" that a base class pointer to the derived object will never be deleted. I personally don't think that makes it any smarter, but I guess that is for you to decide.
If you only want to add functionality to the container (i.e. enhance it with new functions) then you can use containment: have a member variable of the base type and write a bunch of wrapper functions; or use global functions, possibly in a separate namespace, that take the container as template parameter. For example, something like this might work for you:I used the typedefs in the example to show that you can try putting other containers in there without changing the push_back function. I'm sure there is an even better way to do that (I don't think the T template parameter is needed), but you get the idea. I believe this is the same idea used by algorithms in <algorithm>, among other things, which are nice because they work for any compatible container.Code:#include <iostream>
#include <vector>
#include <list>
// This is your new push_back which works with any
// push_back(), end(), and -- compatible container.
template<class C, class T>
C::iterator my_push_back(C& container, T object)
{
container.push_back(object);
return --container.end();
}
// Example usage:
#if 1
typedef std::vector<int> TestContainer;
#else
typedef std::list<int> TestContainer;
#endif
int main()
{
TestContainer intArray;
TestContainer::iterator iterPushed = my_push_back<TestContainer, int>(intArray, 1);
if (iterPushed == intArray.begin())
std::cout << "Success!" << std::endl;
else
std::cout << "Failure!" << std::endl;
iterPushed = my_push_back<TestContainer, int>(intArray, 1);
if (iterPushed == ++intArray.begin())
std::cout << "Success!" << std::endl;
else
std::cout << "Failure!" << std::endl;
}
Hope that helps clarify things and hopefully if I misstated anything somebody will correct me.
I've also used private inheritance from a container, and using declarations to expose some of the members. Since you may not cast an object pointer to a pointer to a private base, this is perfectly safe.
jlou: of all virtual functions, only the destructor is of any interest. If a class doesn't have a virtual destructor but other virtual functions, it has a grave design error. I believe GCC issues a warning on this.
Thanks CornedBee.
By the way, here is an updated version of the global push_back that doesn't require the second template parameter. It was just bugging me before so I went ahead and looked up the value_type typedef.Code:#include <iostream>
#include <vector>
#include <list>
#include <string>
template<class C>
C::iterator my_push_back(C& container, const C::value_type& object)
{
container.push_back(object);
return --container.end();
}
// Example usage:
//typedef std::vector<char> TestContainer;
//typedef std::list<char> TestContainer;
typedef std::string TestContainer;
int main()
{
TestContainer charContainer;
TestContainer::iterator iterPushed = my_push_back<TestContainer>(charContainer, 'j');
if (iterPushed == charContainer.begin())
std::cout << "Success!" << std::endl;
else
std::cout << "Failure!" << std::endl;
}
Something just occurred to me. I believe this implementation would be more efficient:
Always be careful of storing iterators to vectors though, they are easily invalidated.Code:template<class C>
C::iterator my_push_back(C& container, const C::value_type& object)
{
return container.insert(container.end(), object);
}