about STL sort

[Magcialking]

I wanna sort a pointer vector with the algorithm "sort" in STL like
this:

"
int compare(vector<string*>::iterator a,vector<string*>::iterator b){
return (**a)<(**b);
}

sort(iter,iter_end,compare);
"


but this dosen't work,and I really don't know why.
Could anyone show me how to use this correctly?

 

[red floyd]

I wanna sort a pointer vector with the algorithm "sort" in STL like
this:

"
int compare(vector<string*>::iterator a,vector<string*>::iterator b){
return (**a)<(**b);
}

should be:

int compare(const string *a, const string *b)
{
return *a < *b;
}

 

[Nate Barney]

I wanna sort a pointer vector with the algorithm "sort" in STL like
this:

"
int compare(vector<string*>::iterator a,vector<string*>::iterator b){
return (**a)<(**b);
}

sort(iter,iter_end,compare);
"

You don't specify the type of iter and iter_end, but I am going to

but this dosen't work,and I really don't know why.
Could anyone show me how to use this correctly?

The problem is that your comparison function takes iterators as
parameters, when it should take values. Additionally, it should return
a bool. For example:

bool compare(string *a,string *b) {
return (*a) < (*b);
}

Another thing you might consider is writing a generic dereferencing
binary predicate adapter:

#include <functional>

template <typename It,typename Pred>
class deref_pred : public std::binary_function<It,It,bool>
{
public:

deref_pred() {}
deref_pred(const Pred &pred) : pred(pred) {}

bool operator()(const It &a,const It &b) const
{ return pred(*a,*b); }

private:

Pred pred;
};

Then you would call sort like:

std::sort(iter,iter_end,
deref_pred<std::string*,std::less<std::string> >());

This is a bit more work on the front end, but it's much easier to reuse.

Hope this helps,
Nate

 

[Magcialking]

Another thing you might consider is writing a generic dereferencing

binary predicate adapter:

#include <functional>

template <typename It,typename Pred>
class deref_pred : public std::binary_function<It,It,bool>
{
public:

deref_pred() {}
deref_pred(const Pred &pred) : pred(pred) {}

bool operator()(const It &a,const It &b) const
{ return pred(*a,*b); }

private:

Pred pred;
};

Then you would call sort like:

std::sort(iter,iter_end,
deref_pred<std::string*,std::less<std::string> >());

it seems that deref_pred is just a wrapping paper,the real compare
function need to be pass to it when used?so, what's deref_pred doing
here?

and I am also confuse about the inheritance hereublic
std::binary_function<It,It,bool>,
what's it for?

 

[Nate Barney]

it seems that deref_pred is just a wrapping paper,the real compare
function need to be pass to it when used?so, what's deref_pred doing
here?

It dereferences the pointers/iterators passed as arguments, which allows
it to work on containers of pointers/iterators, like the
std::vector<std::string*> container you have. The reason for the Pred
parameter is that you can change the predicate to, say, std::greater, if
you wish to reverse the sort.

and I am also confuse about the inheritance hereublic
std::binary_function<It,It,bool>,
what's it for?

This base class does nothing other than define a few typedefs that allow
it to be used more easily with other parts of the STL.

See http://www.sgi.com/tech/stl/functors.html, specifically the third
paragraph of the Description section.

Nate

 

[Magcialking]

Nate Barney 写é“：

It dereferences the pointers/iterators passed as arguments, which allows
it to work on containers of pointers/iterators, like the
std::vector<std::string*> container you have. The reason for the Pred
parameter is that you can change the predicate to, say, std::greater, if
you wish to reverse the sort.


This base class does nothing other than define a few typedefs that allow
it to be used more easily with other parts of the STL.

See http://www.sgi.com/tech/stl/functors.html, specifically the third
paragraph of the Description section.

Nate

OK, I got it. Thanks a lot!

 

[Gernot Frisch]

I wanna sort a pointer vector with the algorithm "sort" in STL like
this:

"
int compare(vector<string*>::iterator a,vector<string*>::iterator
b){
return (**a)<(**b);
}

sort(iter,iter_end,compare);

struct MySort
{
bool operator() (const string*& p1, const string*& p2)
{
return *p1 < *p2;
}
};

int main()
{
std::vector<std::string*> vec;
// fill vector
std::sort(vec.begin(), vec.end(), MySort() );
}

Question: Why are you holding a string* instead of a string in your
vector?

 

[Magcialking]

Gernot Frisch 写é“：

struct MySort
{
bool operator() (const string*& p1, const string*& p2)
{
return *p1 < *p2;
}
};

int main()
{
std::vector<std::string*> vec;
// fill vector
std::sort(vec.begin(), vec.end(), MySort() );
}

Question: Why are you holding a string* instead of a string in your
vector?

Cause I think this will save time than to push string itself into a
vector.

 

[Jerry Coffin]

[ ... ]

Cause I think this will save time than to push string itself into a
vector.

A string object isn't usually a _whole_ lot more than a wrapper around a
pointer and a couple of size_t's. Depending on implementation, it may
also include a _small_ array of elements, but it's still usually pretty
fast to copy around and such.

 

[Gernot Frisch]

Question: Why are you holding a string* instead of a string in your
vector?

Cause I think this will save time than to push string itself into a
vector.


And you know you have to delete the strings themselfes some day?? The
string you forgot, because you put it's pointer in the vector?
It's OK if you do, but are you aware if it?

 

[persenaama]

A string object isn't usually a _whole_ lot more than a wrapper around a

pointer and a couple of size_t's. Depending on implementation, it may
also include a _small_ array of elements, but it's still usually pretty
fast to copy around and such.

Doesn't mean that it isn't (in the context) expensive to construct, I
believe a copy means the contents are also copied?

 

[Jerry Coffin]

Doesn't mean that it isn't (in the context) expensive to construct, I
believe a copy means the contents are also copied?

You clearly have one copy that takes place when you put the string into
the vector. From there it depends: when the vector expands, it can copy
construct all the strings into the newly expanded area, then destroy the
old ones -- which (as you suggest) would result in a (relatively slow
deep copy of each of the existing strings -- not to mention temporarily
using a lot of extra memory.

For nearly anything that uses remote ownership (i.e. anything with a
difference between shallow and deep copy), however, that's not usually
the best way. Instead, you can create your new, expanded memory full of
empty items (strings in this case), and then use swap to put the real
ones into the new memory and the empty ones into the old memory, without
copying the actual data.

Of course, on a platform where it get away with it (i.e. most) the
library can just do a shallow copy from the old space to the new, and be
done with it. It's not portable, but the library doesn't need to be
portable internally -- it just has to provide a portable interface. This
is the sort of thing for which template specialization was invented...