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]

Magcialking wrote:

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;
}

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?

[Nate Barney]

Magcialking wrote:

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
assume that they're of type vector<string*>::iterator.

>
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 here:public
std::binary_function<It,It,bool>,
what's it for?

[Nate Barney]

Magcialking wrote:

>#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?

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 here:public
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 写�：

Magcialking wrote:

#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?

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 here:public
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

OK, I got it. Thanks a lot!

[Gernot Frisch]

"Magcialking" <ma********@163.comschrieb im Newsbeitrag
news:11**********************@m73g2000cwd.googlegr oups.com...

>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 写�：

"Magcialking" <ma********@163.comschrieb im Newsbeitrag
news:11**********************@m73g2000cwd.googlegr oups.com...

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?

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

[Jerry Coffin]

In article <11*********************@i3g2000cwc.googlegroups.c om>,
ma********@163.com says...

[ ... ]

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.

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.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[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]

In article <11*********************@e3g2000cwe.googlegroups.c om>,
ju***@liimatta.org says...

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?

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...

--
Later,
Jerry.

The universe is a figment of its own imagination.