🔒 Locked

std::remove?

Started by LilBudyWizer Dec 26, 2005 at 9:56 PM 10 replies 3.4k views

Original Post

Dec 26, 2005 at 9:56 PM

My compiler seems to be picking up std::remove in rather than . The relevant code is basically:


std::vector<int> col1;
std::vector<int>::iterator pos;
// elements loaded here
pos = std::remove(col1.begin(), col1.end(), 5);

It tells me extra paramters in call std::remove(const char *). If I try:


std::vector<int> col1;
std::vector<int>::iterator pos;
// elements loaded here
pos = std::remove<std::vector<int>::iterator, int>
                 (col1.begin(), col1.end(), 5);

it tells me invalid use of typedef std::vector::iterator and expression syntax presumably due to still hitting std::remove in . Anyone see something I'm going wrong or have any suggestions for a work around? is included, no errors on remove_if. I don't directly include and I assume it is being brought in with . Grrr, why's it doing that to me . Grrr, grrr, figures now it quits.

bytecoder

Dec 26, 2005 at 10:40 PM

Works fine for me with gcc. It might be caused if you include iostream/cstdio after including algorithm. This is the source file I tested:

#include <algorithm>#include <iostream>#include <vector>int main() {	std::vector<int> col1;	std::vector<int>::iterator pos;	// elements loaded here	pos = std::remove(col1.begin(), col1.end(), 5);	return 0;}[/quote]

taby

Dec 26, 2005 at 10:42 PM

I'm not familiar with this function, though I do use STL very often.

If one is trying to remove an iterator-defined series of elements from a vector, the vector's erase() member function does the job perfectly.

It's in .

bytecoder

Dec 26, 2005 at 10:48 PM

Quote:
Original post by taby
I'm not familiar with this function, though I do use STL very often.

If one is trying to remove an iterator-defined series of elements from a vector, the vector's erase() member function does the job perfectly.

It's in .

Maybe. They both do (somewhat) different things. Here's a useful comment on sgi's reference to std::remove:

Quote:

[1] The meaning of "removal" is somewhat subtle. Remove does not destroy any iterators, and does not change the distance between first and last. (There's no way that it could do anything of the sort.) So, for example, if V is a vector, remove(V.begin(), V.end(), 0) does not change V.size(): V will contain just as many elements as it did before. Remove returns an iterator that points to the end of the resulting range after elements have been removed from it; it follows that the elements after that iterator are of no interest, and may be discarded. If you are removing elements from a Sequence, you may simply erase them. That is, a reasonable way of removing elements from a Sequence is S.erase(remove(S.begin(), S.end(), x), S.end()).

Mainly, the difference between std::remove and S.erase is that 1) remove doesn't actually remove anything and 2) it "removes" items equal to a given value instead of just a range.

EDIT:
All this from a person who hasn't used C++ in a year! It's amazing how google can make you look more knowledgeable than you really are ;)

LilBudyWizer

Dec 26, 2005 at 11:42 PM

Well, it's not actually but rather and it's brought in by as well. Interestingly the following is in

#if ! defined (_STLP_USE_NAMESPACES)// remove() conflicts, <cstdio> should always go first#  include <cstdio>#endif

except it doesn't actually include it. Specifically including before and made no differance. Adding "using std::remove" after was included and prior to including and if I called remove rather than std::remove.

load_bitmap_file

Dec 26, 2005 at 11:55 PM

Quote:
Original post by LilBudyWizer
My compiler seems to be picking up std::remove in rather than .

That won't happen in C++. Don't forget about function overloading! is most likely not #include'd in time.

LilBudyWizer

Dec 27, 2005 at 12:45 AM

Well, it did happen in C++. I'm not sure if it is a compiler bug or if a non-templated function is suppose to take precedence over a templated function by the same name even when one would be an error and the other wouldn't.

It also seems the unique_copy in this version of stlport is wrong. The destination has to be the same type of iterator as the source. So I can't copy to a stream iterator, use an inserter or copy the duplicates to a differant type of container.

SiCrane

Dec 27, 2005 at 7:53 AM

What compiler and STL implementation are you using?

Fruny

Dec 27, 2005 at 8:38 AM

Quote:
Original post by taby
If one is trying to remove an iterator-defined series of elements from a vector, the vector's erase() member function does the job perfectly.

They're typically used together. First remove gets rid of the unwanted values (without changing the number of elements in the container), then erase cleans up the vector, discarding the 'garbage' elements.

std::vector<int> vec;std::vector<int>::iterator begin_garbage;begin_garbage = std::remove(vec.begin(), vec.end(), 42);vec.erase(begin_garbage, vec.end());

LilBudyWizer

Dec 27, 2005 at 9:17 AM

Borland C++ Builder patched to 10.166. The bcc32 itself is 5.6.4.0. The STL implementation is STLport 4.5. At least that's what the documentation says. I'm not sure how to check version on a template library. It seems to be the most recent version from looking at their website.

I'm working my way throught "The C++ Standard Library" by Josuttis. So it's rather unusual in that I'm pretty well using everything at least once. I'm pretty sure the code is exactly right. Each example is fairly short, he does a verable explaination afterwards and shows the programs output. In 380 pages I've yet to encounter any errors. Remove is a conflict in names and unique_copy seems an error the stl implementation so I would still say he hasn't made any mistakes in the example code.

RDragon1

Dec 27, 2005 at 9:21 AM

remove doesn't "get rid of the unwanted values" - it moves the wanted values to the beginning (and it doesn't move the unwanted values to the end - that would be a partition sort).

LilBudyWizer

Dec 27, 2005 at 9:50 AM

Found a bug report. Apparently this arrises because parts of RogueWare's implementation is used. STLPort actually uses the _STL namespace which is aliased as stlport and _STLP_STD. So it resolves stlport::remove just fine, but std::remove resolves to the only remove actually in the std namespace. _STL is in std as well by a using, but apparently that causes the remove actually in std to be selected.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.