[Scummvm-devel] Replacing Common::Map by std::map
Max Horn
max at quendi.de
Sat Jan 15 15:57:05 CET 2005
Am 15.01.2005 um 23:58 schrieb Marcus Comstedt:
>
> Max Horn <max at quendi.de> writes:
>
>> Indeed. Fully agreed. My point just was that the big bytes are mostly
>> lost in other spots, like in the half dozen engines we now
>> support. Furthermore, the good reasons are given in the part of the
>> mail you didn't quote.
>
> Well, you say that less code has to be maintained. But is there
> really much time spent on maintaining the Common::Map code now?
It's not so much about the time "we" (that is: I, as I am the only one
working on these things, it seems) spend on maintaining Common::Map --
it's only a small part of the whole common/ rat nest.
I spent a lot of time writing that code, which I could have spent on
more important things if we didn't use to have that silly policy of not
using the standard C++ lib. While that time is already lost now, I
refuse to waste any more of my time reimplementing things which are
available in every C++ system for free.
Furthermore, every capable C++ programmer should know the STL /
Standard C++ lib. It's part of the language. And so they all should be
able to understand code using std::map, std::string, etc.. Compared to
that, our Map/String/etc. classes are custom; coders have to learn
about them first. That makes it harder to maintain our code, and makes
it harder for newbies to participate in our project.
All in all, I see lots of real & theoretical advantages speaking for
using std::map & std::set, and only one drawback: a 0.25% increase in
the size of my binary. Hm.
> You also say that Common::Map does not use a balanced tree. That may
> be relevant if we're currently having performance issues with
> Common::Map, but are we?
It *is* slow, but not in a way that we have a problem. Mainly because
no time sensitive coded uses it right now, since it is bad :-). I had
to undo some changes recently, reverting the use of the map class,
because of its deficiencies.
Anyway, this discussion seems quite silly to me. I mean, we are talking
a 10 KB increase in an unoptimized build, even less in a release build
(7 KB over here). I just checked in another code change (make use of
the new class Common::Mutex) which reduced the code size by 5 KB. We
have code fluctuations of that size all the time. ScummVM grows every
day because e.g. the saga code gets developed further.
Do I have to do byte bookkeeping on every checkin I make now? And would
have anybody noticed/bothered if I hadn't been stupid enough to mention
the 10 kb increase? <sigh>
Bye,
Max
More information about the Scummvm-devel
mailing list