Re: C++ Frequently Questioned Answers
On Nov 5, 5:08 pm, Kirit S?lensminde <kirit.saelensmi...@gmail.com>
wrote:
Yossi Kreinin wrote:
Here's real code from a social network back-end :)
class Lamer { public: const LameComments& getLameComments(); };
void getTheMostLameComments(
vector<const LameComments*>& comments, //which type would you use?
const vector<Lamer>& lamers
)
{
//or we could use iterators...
for(int i=0; i<(int)lamers.size(); ++i)
{
const LameComments& lc = lamers[i].getLameComments();
if(lc.areTotallyPointless()) {
//lamers write lots of comments, better copy
//by reference... Has to be const - can't modify
//the lamer's precious comments, and we can't
//have vectors of references, so it's either a dumb
//const pointer or some non-standard smart pointer
comments.push_back(&lc);
}
}
}
I think this is a pretty common pattern with code massaging data
structures with even minor levels of nesting/indirection.
As you've discovered, just because it is a common pattern doesn't make
it good.
The thing that I want to compute is certainly not "bad" by itself - it
is a completely trivial filter, it should be trivial to implement, and
it is trivial to implement in all popular programming languages. It is
also pretty trivial in C++, except for the const part; my point was to
show that sometimes you naturally end up with vectors of const
pointers in very simple code, contrary to the arguments in this NG.
I think we should all ignore the completely unnecessary C cast and
move on.
I don't know which cast you mean; the code has no cast. A typing
problem lurking at the horizon is that now we have a vector<const T*>,
so a function written to process it would accept an argument of this
type. We then won't be able to pass a vector<T*> to this function,
which is what about 4 sub-threads somehow converged to discuss. Now, /
this/ problem should certainly not be solved by a C cast because that
would be undefined behavior; it should be solved by copying the
vector. We could have /prevented/ it by a C cast to the example code;
is that (currently invisible) cast the one you meant?
It could be that we're already on the same page, and thus I wasted
space on this description; I justed wanted to make sure we really were
on the same page.
This is a filter on top of a data structure. The C++ way of doing this
is to write an iterator that understands the filter rule. A bit more
advanced is to write an iterator adaptor which can be used to wrap
both const and non-const iterators on the underlying data structure.
I'm sure there's an implementation that takes a plug-in filter
predicate somewhere already.
They're not hard to write and have O(1) memory overhead compared to
the code shown above. They also side step many of the problems you
describe with the data types, const handling etc.
As you mention yourself later, sometimes it's a bad idea since I
really want to create a container in memory. For example, there could
be lots of Lamer objects but only few comments which are
isTotallyPointless, and these comments later undergo heavy processing.
I wouldn't want to scan through the whole data structure again and
again.
Still, while we're at the process of exchanging "real code", it would
be nice if you contributed an example implementation of your idea for
the cases when it is appropriate in terms of run time (there are few
Lamer objects and/or most comments are isTotallyPointless). The
readers could then judge whether what you call "The C++ way of doing
this" (trivial) thing is really "not hard to write" compared to the
(primitive as I think it should be) code I posted. BTW, here's how you
do it in Python - an example of a language with built-in support for
this kind of thing:
comments = [l.getLameComments() for l in lamers \
if l.getLameComments().isTotallyPointless()]
If you could extend the test to also compare the date of the comment
to a threshold, I'd be happy to post my version of this so that people
can compare the readability.
If you really need a copy of part of the container then
std::remove_copy_if is what you want. Again it sidesteps all of the
type problems, but I'd have to say that std::copy_if would be a more
useful name to have.
But I /can't/ use remove_copy_if or otherwise modify the container,
because it's typed const vector<Lamer>&, bringing us back to the
subject of the downsides of C++ const correctness. To use
remove_copy_if, I'd have to create a vector of const pointers to Lamer
objects (or LameComments objects or I could use
vector<Lamer>::const_iterator instead of const Lamer*), since this is
the only kind of pointer to the objects I can obtain without a cast.
And having a vector of const pointers or const_iterators brings us
back to square one. Or I'd have to copy the Lamer objects or all of
the LameComments objects, which has its run time cost.
What I'm saying is, to work around this you need to const_cast
pointers or copy objects or copy code (ultimately have two functions
somewhere later, one for vector<const T*> and another one for
vector<T*>). All of these mean that const gets in your way in this
example.
For this sort of code you want to be drawing your inspiration from
functional programming, not from OO programming.
There's another angle: the problem is prosaic and trivial, as the code
solving it should be.
BTW, Boost.Bind or Boost.Lambda will take care of the function
composition if you don't want to do it yourself.
Well, I certainly don't (I had my share of this years ago); but if you
do, please post example code so people can see what it looks like.
Boost.Lambda is not at all simple from the user's perspective:
http://yosefk.com/c++fqa/function.html#fqa-33.10
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]