[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