468,503 Members | 2,003 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,503 developers. It's quick & easy.

about STL sort

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?

Sep 12 '06 #1
11 3351
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?
Sep 12 '06 #2
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
Sep 12 '06 #3
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?

Sep 12 '06 #4
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
Sep 12 '06 #5

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!

Sep 12 '06 #6

"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?
Sep 12 '06 #7

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.

Sep 13 '06 #8
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.
Sep 13 '06 #9
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?
Sep 13 '06 #10
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?

Sep 13 '06 #11
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.
Sep 13 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

220 posts views Thread by Brandon J. Van Every | last post: by
54 posts views Thread by Brandon J. Van Every | last post: by
39 posts views Thread by Marco Aschwanden | last post: by
3 posts views Thread by Marco Aschwanden | last post: by
99 posts views Thread by Shi Mu | last post: by
3 posts views Thread by neilcancer | last post: by
30 posts views Thread by gaoxtwarrior | last post: by
20 posts views Thread by Steven D'Aprano | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.