Thread: Rewrote my cMap class. Looking for more criticism

Originally Posted by Raigne

I doubt that the underscore thing will matter if it is a member.

I doubt you'd run into a problem either, but then again, it's also possible that the compiler's header files could use macros with underscores, which would mess up names whether they're part of a class or in a separate namespace...
I remember having to #undef the min & max macros when I include the <windows.h> header and I also want to use the std::min() or std::max() functions; and that's not even using any underscores!

Originally Posted by cpjust

Actually only names that begin with two underscores, or a single underscore and either a capital or small letter (I can never remember which it is) are reserved for the compiler.

More accurately, names that contain two consecutive underscores, or begin with an underscore followed by an uppercase letter, are reserved to the implementation for any use. Names that begin with an underscore are reserved to the implementation for use as a name in the global namespace.

Consequently, the name _Copy is reserved even with respect to class members, but a user is free to use the name _copy for a class member.

Additionally, why create a function name beginning with an underscore to begin with? It just looks weird...

If you want to know how much memory it uses, then the answer is some constant multiplied by the maps size(). You don't need to track anything yourself. So you may as well rip out all the unnecessary stuff you've got to try and track memory usage. The constant I mention should be about 3 times the size of a pointer plus the size of your item type (if stored by value).

Storing objects in a map by pointer does not increase speed regardless of what crap someone has fed you. If you stopped doing that then you could eliminate your _Copy function and your copy-constructor and assignment operators.

The whole m_cList is totally unnecessary. If you want to store items in a map by an integer cookie, then you can probably get away with each new cookie being equal to the highest cookie currently in use plus one. Or another tecnhique is to have a loop that generate a random int, tests if that index is in use and exits when it finds that index is not in use, which most of the time means it wont even loop.

If I haven't removed the need for this class entirely yet then I've probably left something out.