Re: [Dev-C++] Optimizing using the STL
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
|
From: Hossein H. <ult...@em...> - 2003-07-31 16:12:47
|
Hi David,
> Some interesting ideas there. ...
Some? Just some? Oh my Goodness! Thanks for that! I could except any
description expect that one.
> ... You are right I am not too
> familar with the
> STL.
You will become! For now on, just don't panic when you see powerful
STL codes.
> ... What is the difference
> between passing a
> refrence and passing a const refrence? Is that to ensure
> that the original
> can never be changed(as would happen of I passed by value)?
Hmmm... Yep in the sense that the original beast wouldn't be changed,
but nop in the sense that there is big differnce between passing by
value and passing by reference: The former copies the argument at the
moment of being called, whilst the later doesn't copy, it, in turn,
works on the same object, by creating a reference out of the
argument.
> My other comment is that current_players is a member of
> pc_char. It is
> static and thus shared by all instances of pc_char. So I am
> guessing the
> function signature stays the same.
Well, if you mean the same as what it now is, yes, it does. But the
important point here is that this is the first time I see a class
having a map (in fact, a container) of pointers to itself. My
recommendation is to change this strange design, unless you have
very plausible reasons for adhering to it. It is very likely to
result in sophisticated problems that are all hard to debug. (Amongst
them, one of the most important and vexing ones is the "Circular
Dependancies" problem.)
> From the looks of it using for_each may not be worth it
> especially since the
> function is not finished.
I read the bellow changes you want to be made. From my viewpoint,
that doesn't difere much the dicision wheather to use or not to use
for_each. Assuming that you are going to do the changes, you still can adhere to for_each. Especially because, that way, the only
change is needed to be done is inside that Functor, and no where
else. (Read on ...)
> ...
> void pc_char::write_to_all_pc(const string& to_send, bool
> add_eoln)
> {
> for(map<string, pc_char *>::iterator i =
> current_players.begin();
> i != current_players.end(); ++i)
> if((*i).second != this)
> (*i).second->write_to_player(to_send, add_eoln);
> }
At the moment beeing, the only very subtle bug I can see in it is the
one in the following line:
> if((*i).second != this)
Just think about it for a moment. You are storing pc_char* objects
in that map, right? But you are, probabely, just working with a copy
of the addresses of the original objects, huh? So those nifty-looking
pointers, which are beeing stored in the map, and are objects by
themselves, are copies of the "this" objects, and not the same ones!
Hence, althouge they point to the same location in the memory, they
are not the same, by themselves. Therefore, it is very likely that
the test fails, even if the semantic is right. In fact, you should be
very lucky if the code works. The solution I suggest (if it is OK
under your algorithm), is to replace it with the following one.
if(*(i->second) != (*this))
This way, you are checking if they are pointing to the same location,
and not if they are the same pointers! (And that's presumably what
you need!)
> With respect to the books. I will look into getting my
> hands on a copy.
Do it, ASAP.
Regards,
--Hossein
--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers
|