Re: map (associative array) loses values?
On Sep 11, 10:43 pm, "Jim Langston" <tazmas...@rocketmail.com> wrote:
<jeroenv...@gmail.com> wrote in message
news:1189542044.096744.201450@e34g2000pro.googlegroups.com...
On 11 sep, 21:35, "Jim Langston" <tazmas...@rocketmail.com> wrote:
"BobR" <removeBadB...@worldnet.att.net> wrote in message
news:IMAFi.527207$p47.503263@bgtnsc04-news.ops.worldnet.att.net...
<jeroenv...@gmail.com> wrote in message...
On Sep 11, 5:59 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
[...]
The reason why I did not want to copy the entire map, was because I'm
going to use it for counting the words in
http://www-nlp.stanford.edu/fsnlp/statest/austen.txt
which is a 3,3 mb text file. ;)
Which isn't that relevant. What is relevant is that the file
probably contains a couple of thousand different words. Given
the performance of today's machines, I wouldn't worry too much
about copying it, provided you don't do it too often. It's
probably a good idea not to get in the habit of copying
containers all over the place, but an occasional copy, or a copy
of a container with relatively few members, isn't something to
overly worry about, if the design calls for it.
In this case, however...
[...]
I can understand not wanting to copy the map being 3.3
megabytes.
The map won't be 3.3 Megabyts. But more to the point, I can
understand not wanting to have different copies of the map, with
some counts going into one, and some into another. The
semantics of his program would seem to imply that the map has
identity (or is a member of an object which has identity), so
copying is wrong, period. It's not an optimization issue; the
program will not give the correct results if he e.g. counts the
word using a different copy each time.
Be aware,
however, that if you copy your class, the map will get copied also. So j=
ust
make sure you pass your class by reference than by value. One way to ens=
ure
this is to disable copying of your class. The normal way to do this is to
create a copy constructor ( and assignment operator) and make them private
to the class. That way if you accidently write some code that would crea=
te
a copy of the class, it won't compile and you will realize it.
Another solution is to derive from a class which inhibits copy
and assignment, something like boost::uncopiable. (In large
applications, this tends to happen more or less automatically,
since most objects with identity will derive from some sort of
EntityObject class, which defines the interface used for
transaction management and/or persistency, and which inhibits
assignment and copy, or restricts them to the transaction
manager. But he's not there yet.)
For the SearchText class that would be:
class SearchText
{
public:
// ...
private:
// Disable copy and assignment by making private.
SearchText( SearchText const&) {}
SearchText& operator=( SearchText const&) {}
}
Just empty copy constructor and assignment operator's private
to the class.
The usual solution is to not define them at all. That way, even
if a member function tries to use them, you get an error at link
time.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34