strange std::map behavior

Quote:

---

map::operator[] public member function

T& operator[] ( const key_type& x );

Access element

If x matches the key of an element in the container, the function returns a reference to its mapped value.

If x does not match the key of any element in the container, the function inserts a new element with that key and returns a reference to its mapped value. Notice that this always increases the map size by one, even if no mapped value is assigned to the element (the element is constructed using its default constructor).

---

Why insert a new element and return a default value? Why not just raise an exception here? This really seems bad.

On a side note: Ditto behavior in Qt's QMap as well. Why such practice?

To simplify the usage of the map in some cases. Where you do not want this behaviour, you would use member find().

absolutely silly behavior i think.
thank god that Python handles it better :)

Code:

---

m = { 1:'uno', 2:'duo' }
print m[3]

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    m[3]
KeyError: 3

---

Quote:

---

absolutely silly behavior i think.

---

Consider this code snippet that counts the frequency of words in a vector:

Code:

---

std::map<std::string, std::size_t> word_count;
for (std::vector<std::string>::const_iterator i = words.begin(),
    end = words.end(); i != end; ++i)
{
    ++word_count[*i];
}

---

Quote:

---

Originally Posted by manav

Why insert a new element and return a default value? Why not just raise an exception here? This really seems bad.

---

How the heck could this work:

Code:

---

map[x] = y;

---

Unless map[x] returned a non-const reference? And how can map[x] possibly return a non-const reference without ensuring that the element exists?

Quote:

---

Originally Posted by manav

absolutely silly behavior i think.
thank god that Python handles it better :)

---

Uh, C++ is not Python.

operator[] is a convenience function. If you do not want to accidentally construct an element, use find() instead of operator[].

The problem is how you are trying to use the tool, not the tool itself.

EDIT: Also, having operator[] works different in l-value contexts vs. r-value contexts is simply not possible in C++. It MUST return a non-const reference, which means the element MUST exist.

>> And how can map[x] possibly return a non-const reference without ensuring that the element exists?
By throwing an exception if the element is not found?

But I agree that the current behavior makes sense and is very useful.

Quote:

---

Originally Posted by Daved

>> And how can map[x] possibly return a non-const reference without ensuring that the element exists?
By throwing an exception if the element is not found?

---

That would render operator[] completely pointless. If you had to insert() an element before accessing it with operator[], then the only possible use of operator[] would be for lookup. I hardly see the point of even having an operator[] unless I can do this:

Code:

---

a[b] = c;

---

I'm not arguing with you about the usefulness of the feature, but you're point doesn't make sense. The vector class has similar syntax, and it isn't pointless.

Quote:

---

That would render operator[] completely pointless. If you had to insert() an element before accessing it with operator[], then the only possible use of operator[] would be for lookup. I hardly see the point of even having an operator[] unless I can do this:

---

You certainly would be able to do that, just that there has to be a valid key with b's value already in the map. It would just make it inconvenient for insertion, so my example would become the rather horrible:

Code:

---

for (std::vector<std::string>::const_iterator i = words.begin(),
    end = words.end(); i != end; ++i)
{
    try
    {
        ++word_count[*i];
    }
    catch (const std::out_of_range& e)
    {
        word_count.insert(std::make_pair(*i, 1));
    }
}

---

... which would be about the same as just writing:

Code:

---

for (std::vector<std::string>::const_iterator i = words.begin(),
    end = words.end(); i != end; ++i)
{
    std::map<std::string, std::size_t>::iterator iter = word_count.find(*i);
    if (iter != word_count.end())
    {
        ++iter->second;
    }
    else
    {
        word_count.insert(std::make_pair(*i, 1));
    }
}

---

Quote:

---

Originally Posted by Daved

I'm not arguing with you about the usefulness of the feature, but you're point doesn't make sense. The vector class has similar syntax, and it isn't pointless.

---

Well, two responses to that:

1. For std::vector, operator[] is much more necessary than for std::map. A vector inherently "keys" its contents by their indices. Whereas with std::map, operator[] exists only for convenience, and the container would still be quite usable without it.

2. The original argument was, should operator[] throw an exception when accessing an out-of-bounds key or index. The answer, for both std::vector and std::map, is no. It's not valid to go out of bounds on a vector, but it doesn't throw an exception when you do it.

It would be a completely valid interface if it did, though. The at() function throws an exception, why couldn't an operator[]?

Your first point backs me up. The operator[] exists only for convenience, so a slightly less convenient usage would not be pointless, just less convenient.

Quote:

---

Originally Posted by Daved

It would be a completely valid interface if it did, though. The at() function throws an exception, why couldn't an operator[]?

---

Because the only difference between the two is whether it throws? ;)

Quote:

---

Your first point backs me up. The operator[] exists only for convenience, so a slightly less convenient usage would not be pointless, just less convenient.

---

Decreasing the convenience of a convenience function makes it not a convenience function anymore, IMHO, simply a redundant one.

EDIT: Eh, I have a feeling I'm being obnoxious.

Although using the operator[] in a vector can produce undefined behavior if the specified element does not exist.

And thank goodness Microsoft created a safe-guard for that. By default, it throws and assert if an out-of-bound access is made, in debug.

A good interface is one where your guess as to what things do is what they actually do. A large part of that is function naming too. Unfortunately the [] convenience function for a map doesn't have a descriptive name, and many people that guess its behaviour, get it wrong.
That said, it is terribly convenient, and many of us would be lost without it.

Always conduct the documentation first ;)

Quote:

---

Unfortunately the [] convenience function for a map doesn't have a descriptive name, and many people that guess its behaviour, get it wrong.

---

The interface design of vector::operator[] is perfectly intuitive for people who learned C arrays. Migrating C programmers have always been an important target for the designers of C++ and its standard library.

Quote:

---

Originally Posted by CornedBee

The interface design of vector:: operator[] is perfectly intuitive for people who learned C arrays. Migrating C programmers have always been an important target for the designers of C++ and its standard library.

---

Oh certainly the vector one is, but I was talking about the map one.
And in all fairness, if all your code ever does is uses the [] operator on the map, in-effect treating it like an ultra large array, then it pretty much will act like just an ultra large array.

Quote:

---

Oh certainly the vector one is, but I was talking about the map one.

---

That's a more weird case. map's [] works the way it does because there is simply no other way it could work. It's not exactly intuitive to newbs, but when you think it through, you find that there's no alternative.

Well, it could throw an exception if the key doesn't exist, so it was an interface design decision to make it work as it does?

Anyway, when comparing C++ to Python, then the good practices concerning use of exception is rather different. In Python, heavy usage of exception is encouraged. It is encouraged to try an operation without previous checks, catch any possible exceptions and carry on. For example, even the for construct uses exceptions under the hood to stop looping, if I'm not mistaken.

In addition the dict type is probably not quite the same as std::map in C++. In C++ it is just an associative container. In Python it is a built-in object, there's even special syntax for unpacking dictionaries in function arguments, so its usage seems a bit different.

Indeed - exceptions are very expensive in many C++ implementations, and the standard explicitly encourages implementors to optimize the non-exception case at the expense of the exception case. (Or was it the Speed TR? Not sure.)

If [] threw an exception on a missing element, you couldn't do this:

Code:

---

m[key] = value;

---

and have it set the map element at key to value, no matter if it's already there or not.

Quote:

---

If [] threw an exception on a missing element, you couldn't do this:

and have it set the map element at key to value, no matter if it's already there or not.

---

Of course, but it throwing an exception on a missing element implies that that (cumbersome) behaviour is intended. It becomes about as convenient as using find() and insert(), with possibly worse performance due to the exception handling, but that is different from saying that there is no alternative.

hats off to the strange behavior of C++ in the name of ... i don't know whom

give an out of range index to [] operator of vector class and it gives garbage!
give a non-existing key to [] operator of map class it creates stupid stuff!

C++ is an excellent language, you can do everything, anyway you like, with it.
but the mind of the people who have already implemented so much stuff (and ready availability of such stuff is a must), i can't understand what they were thinking of! :(

Quote:

---

but the mind of the people who have already implemented so much stuff (and ready availability of such stuff is a must), i can't understand what they were thinking of!

---

That's easy:

Quote:

---

give an out of range index to [] operator of vector class and it gives garbage!

---

They were thinking of efficiency, and provided the alternative of at() if efficiency is not desired.

Quote:

---

give a non-existing key to [] operator of map class it creates stupid stuff!

---

As we have been trying to tell you, it does not create stupid stuff. It creates an object using the default constructor. If this is stupid, it implies that your usage of it is stupid, since you should use member find() instead.

why there is not a has_key() function? so sad :(

Quote:

---

why there is not a has_key() function?

---

has_key() is equivalent to m.find(key) != m.end(), for a map named m.

Quote:

---

Originally Posted by manav

why there is not a has_key() function? so sad :(

---

Isn't that what "find()" is for?

--
Mats

thanks!
there are kludgey ways. alright. there are ways around every problem. ok.
but the thinking of original implementers is still lacking ... i feel :(

Quote:

---

but the thinking of original implementers is still lacking ... i feel

---

Explain why you think the thinking of the library designers is lacking.

Note that find() is more powerful than a has_key() function. Not only that, but the use case of not inserting an element if one exists implies searching for an element with that key. It is a waste of time to check if the map has a key, and then search for the element with that key, because the act of checking if the map has a key involves searching for it.

Quote:

---

Originally Posted by manav

thanks!
there are kludgey ways. alright. there are ways around every problem. ok.
but the thinking of original implementers is still lacking ... i feel :(

---

But what would (internally) m.has_key(somekey) do different from m.find(somekey) != m.end()?

It serves no real purpose to implement a function that does the has_key() when it's trivial to make such a function from the existing functions - where do you draw the limit for this sort of feature-creep and resulting code-bloat?

--
mats

there are such trivial functions:
why use printf when there is fprintf?
why use scanf when there is fscanf?
just a trivial matter of giving stdin as argument! what say?

Quote:

---

there are such trivial functions:
why use printf when there is fprintf?
why use scanf when there is fscanf?
just a trivial matter of giving stdin as argument! what say?

---

The use cases for those functions are far more common than has_key() without a find() for std::map.

Quote:

---

Originally Posted by laserlight

The use cases for those functions are far more common than has_key() without a find() for std::map.

---

And would even hazard a guess that the code size difference for the average C program (assuming it uses printf at least a little bit), the printf(...) function vs. fprintf(stdout, ...) would be noticeable.

If you use has_key often enough, maybe you would want to implement a function to do that.

--
Mats

My vote goes to a function

m.has_key(somekey)

Instead of

m.find(somekey) != m.end()

Because it's easier to read and it looks better.

Quote:

---

Originally Posted by Elysia

My vote goes to a function

m.has_key(somekey)

Instead of

m.find(somekey) != m.end()

Because it's easier to read and it looks better.

---

Yes, but you can easily do:

Code:

---

bool has_key(std::map<...> m, KEYTYPE key)
{
  return m.find(somekey) != m.end();
}

---

--
Mats

Quote:

---

And would even hazard a guess that the code size difference for the average C program (assuming it uses printf at least a little bit), the printf(...) function vs. fprintf(stdout, ...) would be noticeable.

---

I was thinking of that too, but I am too young to know what kind of impact that would have made with respect to hard disk capacity in the 1970s. It probably does not matter nowadays.

Quote:

---

Originally Posted by matsp

And would even hazard a guess that the code size difference for the average C program (assuming it uses printf at least a little bit), the printf(...) function vs. fprintf(stdout, ...) would be noticeable.

---

Sorry! What you mean actually? (I did not understand)

Quote:

---

If you use has_key often enough, maybe you would want to implement a function to do that.

---

Of course! I would even like to extend the class std::map.
But some would advice against it, just like they did in case of mystring class example!

The typical use case isn't m.find(somekey) != m.end(), though. It's

Code:

---

mymap::iterator it = m.find(somekey);
if(it != m.end()) {
  std::cout << it->second;
}

---

[quote=matsp;740658]Yes, but you can easily do:

Code:

---

bool has_key(std::map<...> m, KEYTYPE key)
{
  return m.find(somekey) != m.end();
}

---

What is somekey here? Where do i get it from?

Quote:

---

Originally Posted by manav

Sorry! What you mean actually? (I did not understand)

---

I mean that the size of some decent size project (not a "Hello, World" program) would be significantly larger by simply replacing all printf's with fprintf's - because it passes one extra argument, which requires at the very least one more instruction for EVERY printf - and there are often quite a few printf in any non-trivial (console) application, which means that the benefit of having the simplified function is valuable.

As laserlight points out, the benefit is probably less noticeable in todays world, when applications are:
1. more often graphical, so printf() isn't very important for that reason.
2. disk/memoy space is counted in gigabytes rather than kilobytes, so saving a few thousand bytes in one application is not quite so important.

You would need to use has_key a lot for an equivalent benefit, and if you do, then you probably would want to provide such a function in one way or another.

--
Mats

[QUOTE=manav;740663]

Quote:

---

Originally Posted by matsp

Yes, but you can easily do:

Code:

---

bool has_key(std::map<...> m, KEYTYPE key)
{
  return m.find(somekey) != m.end();
}

---

What is somekey here? Where do i get it from?

---

Stupid typo (copy'n'paste, actually):

Code:

---

bool has_key(std::map<...> m, KEYTYPE key)
{
  return m.find(key) != m.end();
}

---

--
Mats

Quote:

---

My vote goes to a function

---

But you see, if you want to do what manav wants to do (print the element corresponding to a key, as per the Python example), has_key() is a complete waste of time. You would just write something along these lines:

Code:

---

std::map<K,V>::iterator iter = map.find(key);
if (iter != map.end())
{
    std::cout << iter->second << std::endl;
}
else
{
    std::cout << "No such key: " << key << std::endl;
}

---

If you write:

Code:

---

if (map.has_key(key))
{
    std::cout << map[key] << std::endl;
}
else
{
    std::cout << "No such key: " << key << std::endl;
}

---

... you would be finding the key twice, assuming the key exists.

Quote:

---

Of course! I would even like to extend the class std::map.
But some would advice against it, just like they did in case of mystring class example!

---

There is nothing wrong with extending std::map by providing free functions that extend its interface, or by wrapping it in another class. However, you should not inherit from std::map since it was not designed to be a base class and thus its destructor is non-virtual.

Quote:

---

What is somekey here? Where do i get it from?

---

A working example would be:

Code:

---

template<typename K, typename V>
bool has_key(const std::map<K,V>& map, const K& key)
{
    return map.find(key) != map.end();
}

---

Quote:

---

Originally Posted by laserlight

A working example would be:

Code:

---

template<typename K, typename V>
bool has_key(const std::map<K,V>& map, const K& key)
{
    return map.find(key) != map.end();
}

---

---

Thanks, my template writing skills are still low - we don't use templates much where I work, so I didn't want to produce something that wasn't correct - and it backfired.

--
Mats

thanks laser!
that utility function deserves to be in my toolbox!

Quote:

---

Originally Posted by manav

thanks laser!
that utility function deserves to be in my toolbox!

---

Yes, but beware that if you then use either find or [], you _WILL_ perform another search for the key - which is a waste of useful processing power.

--
Mats

Quote:

---

Originally Posted by laserlight

But you see, if you want to do what manav wants to do (print the element corresponding to a key, as per the Python example), has_key() is a complete waste of time. You would just write something along these lines:

Code:

---

std::map<K,V>::iterator iter = map.find(key);
if (iter != map.end())
{
    std::cout << iter->second << std::endl;
}
else
{
    std::cout << "No such key: " << key << std::endl;
}

---

If you write:

Code:

---

if (map.has_key(key))
{
    std::cout << map[key] << std::endl;
}
else
{
    std::cout << "No such key: " << key << std::endl;
}

---

... you would be finding the key twice, assuming the key exists.


There is nothing wrong with extending std::map by providing free functions that extend its interface, or by wrapping it in another class. However, you should not inherit from std::map since it was not designed to be a base class and thus its destructor is non-virtual.


A working example would be:

Code:

---

template<typename K, typename V>
bool has_key(const std::map<K,V>& map, const K& key)
{
    return map.find(key) != map.end();
}

---

---

Yes, unfortunately, the usability ends there. But as the name suggests, it looks if the key exists, but does not return it.
If you wanted it returned, I would find it easier to check like

Code:

---

std::map<K,V>::iterator iter = map.find(key);
if (iter)
{
    std::cout << iter->second << std::endl;
}
else
{
    std::cout << "No such key: " << key << std::endl;
}

---

Just like a pointer.

Quote:

---

Originally Posted by matsp

Stupid typo (copy'n'paste, actually):

Code:

---

bool has_key(std::map<...> m, KEYTYPE key)
{
  return m.find(key) != m.end();
}

---

--
Mats

---

I'm dead against this kind of encapsulation. has_key is supposed to be a member function of std::map instead, not broken into bits outside.

Actually, I think there's a limitation: suppose you have a std::map<std::string, std::size_t>, as per my word count example. If you try a has_key(map, "word"), the code will not compile since the string literal's type does not match the map's key type.

One solution is to change the call to has_key(map, std::string("word")). A possibly better solution is to change the function template to:

Code:

---

template<typename T>
bool has_key(const T& map, const typename T::key_type& key)
{
    return map.find(key) != map.end();
}

---

EDIT:

Quote:

---

I'm dead against this kind of encapsulation. has_key is supposed to be a member function of std::map instead, not broken into bits outside.

---

This is the same thing as discussed in the "std::string is a monolithic type" article by Sutter. has_key() can be implemented as a non-member non-friend.

Quote:

---

Originally Posted by matsp

Yes, but beware that if you then use either find or [], you _WILL_ perform another search for the key - which is a waste of useful processing power.

---

Really Mats?
Offo! That just increases my pain over lack of implementations in std stuff! :(
I think it would not be that case if the has_key() was a member function working with internals directly! Alas!

Quote:

---

Originally Posted by Elysia

Just like a pointer.

---

Are you sure that there is no need to compare the iterator to map.end(), i.e., the one past the end iterator is guaranteed to evaluate to false?

Quote:

---

Originally Posted by manav

I think it would not be that case if the has_key() was a member function working with internals directly! Alas!

---

No, turning it into a member function would make no difference in terms of efficiency. The problem is simply that the iterator to the element is discarded.

Quote:

---

Originally Posted by manav

Really Mats?
Offo! That just increases my pain over lack of implementations in std stuff! :(
I think it would not be that case if the has_key() was a member function working with internals directly! Alas!

---

No, whether you implement has_key as a direct function in the class implementation or you do it as a external function, it will have to search for that key. [] or find will ALSO have to search for that key - the only way to avoid that would be to cache the searches inside the class, which would only help if you often do things like the above example of

Code:

---

if(m.has_key(key)) ... m[key] ...

---

The point being that if you use find() correctly, then you do NOT need to search twice, because you use the original find result to determine if the data is there or not.

I may not be a template (or map) demon, but I do understand that the key would have to be searched for each of those cases.

--
Mats

Okay so now i got it! due to some strange reasons, i have to, and i will, avoid the more clear syntax of accessing map elements.
and will be using find(), forever ... big alas! :(

Quote:

---

Originally Posted by laserlight

This is the same thing as discussed in the "std::string is a monolithic type" article by Sutter. has_key() can be implemented as a non-member non-friend.

---

Well, as I said, I don't like it. It may be good, it may have advantages, but I'm not forced to like it. My philosophy is that if it's part of the object, then it's a member function, end of story. Other views differ, of course, this is just my own view.

Quote:

---

Originally Posted by laserlight

Are you sure that there is no need to compare the iterator to map.end(), i.e., the one past the end iterator is guaranteed to evaluate to false?

---

I don't know, but the optimal implementation in my eyes, is that if operator bool returns true, it guarantees that the iterator is valid and if false, then invalid.

I don't see why you think std classes so lacking.

In Python you might write something like this:

Code:

---

try:
    print map[key]
except KeyError:
    print "No such key"

---

In C++ that would be:

Code:

---

map<A, B>::iterator it = map.find(key);
if (it != map.end())
    cout << it->second << '\n';
else
    cout << "No such key\n";

---

The main difference is that in C++ you normally check before jumping, and in Python it is OK to jump first and then handle the consequences (you could check first but that would mean the dictionary is searched twice).
The C++ code also requires a bit more typing (the iterator declarator could be shortened with a typedef - and the auto keyword in the next standard would make it more convenient), but the basic structure is still quite the same.

speak about has_key() efficiency, even java has the function, and also another one:

Quote:

---

containsKey(Object key), containsValue(Object value)

---

C++ people are sick with efficiency concerns, no doubt, since they are from the older days of scarce resources!
modern technologies, alas, when will C++ people awake!
the standard itself is 10 years old now!

anon: not too much trouble, if, c++ people could just think about it like this:

Code:

---

put(key, val);
get(key,defval=...);

---

Quote:

---

even java has the function

---

Apples to oranges. Java doesn't have free functions, so they're not an alternative.

Quote:

---

modern technologies, alas, when will C++ people awake!

---

Bla, bla, bla.

Quote:

---

the standard itself is 10 years old now!

---

That's why a new one is in development.

Quote:

---

Originally Posted by CornedBee

Apples to oranges. Java doesn't have free functions, so they're not an alternative.

---

there are namespace, classes, structs, unions, just to avoid free functions i guess :)

Quote:

---

Bla, bla, bla.

---

:D

Quote:

---

That's why a new one is in development.

---

i just wish it does not take another ten years.

Quote:

---

Originally Posted by manav

speak about has_key() efficiency, even java has the function, and also another one:

C++ people are sick with efficiency concerns, no doubt, since they are from the older days of scarce resources!
modern technologies, alas, when will C++ people awake!

---

I personally am not forcing you to use C++. I presume that if you work for a company for example that they may take an interest in what language you use.

But strictly speaking, efficiency is one reason to use C++ - if you don't care about it, that's another matter. Providing functions that promote efficient use of the underlaying data structures make sense, however.

Yes, modern hardware has lots of memory and lots of clockcycles per second (at least in a PC), which allows the use of "slower" coding practices when that's suitable. Fine - that doesn't mean that C++ should be changed to be slow always, does it?

--
Mats

Quote:

---

Originally Posted by matsp

I personally am not forcing you to use C++. I presume that if you work for a company for example that they may take an interest in what language you use.

---

i am already *forced* to use C++ by my project! :)

Quote:

---

Yes, modern hardware has lots of memory and lots of clockcycles per second (at least in a PC), which allows the use of "slower" coding practices when that's suitable. Fine - that doesn't mean that C++ should be changed to be slow always, does it?

---

that's not what i meant. don't make the stuff slower deliberately. i just meant that java, by design, is slow language.
hashing, by principle, i think, needs a lot of processor time. if interpreted (by design, there are improvements, but C++ is still more close to processor) java can bear a little in-efficiency, then why can't this be done in super fast (actually fastest possible OO language) language C++.

Quote:

---

Originally Posted by manav

i am already *forced* to use C++ by my project! :)


that's not what i meant. don't make the stuff slower deliberately. i just meant that java, by design, is slow language.
hashing, by principle, i think, needs a lot of processor time. if interpreted (by design, there are improvements, but C++ is still more close to processor) java can bear a little in-efficiency, then why can't this be done in super fast (actually fastest possible OO language) language C++.

---

Hashing a string shouldn't be terribly inefficient - obviously if the string is VERY LONG, then it will be, but in essence it's (most often) just a combination of 32-bit shift and xor operations, and then a truncation to the size of the hash-table.

Java is inefficient because it's an interpreted (through the byte-code form) language, more than because the classes that are implemented in it are inefficient. Properly compiled (to native machine language) Java should be only marginally slower than C++ (commonly because of language structure/implementation differences - e.g. Java has only virtual functions, C++ allows for non-virtual when the programmer so desires, which helps the speed of function calls).

--
Mats

you ignored my question, why C++ people care so much for efficiency?
i bet you don't have templates on embedded systems compilers.
then what's the point? different platforms can have differently optimized c++.

Quote:

---

Originally Posted by manav

you ignored my question, why C++ people care so much for efficiency?
i bet you don't have templates on embedded systems compilers.
then what's the point? different platforms can have differently optimized c++.

---

The compiler for embedded systems should be fully C++ compliant - certainly the one we use is. We choose to not use templates (much) due to the fact that they often produce quite inefficient and often lead duplicated code in many places (because every time you include the template in one project, it gets a complete set of all the template code compiled into that source file).

But even for PC's there is code that needs to be efficient - your code may not belong in that category, but certainly game developers will "care" if the frame-rate is high or not, and inefficient code will not give good frame-rate.

Likewise, if you are working on a large database-project or some such (e.g you implement the functions in MySQL or some such), any extra time spent there should be avoided.

--
Mats

Quote:

---

Originally Posted by matsp

The compiler for embedded systems should be fully C++ compliant - certainly the one we use is. We choose to not use templates (much) due to the fact that they often produce quite inefficient and often lead duplicated code in many places (because every time you include the template in one project, it gets a complete set of all the template code compiled into that source file).

---

but you certainly avoid such stuff, mainly, because of scarce resources and, mostly because of little need of over complicating the stuff :)

Quote:

---

But even for PC's there is code that needs to be efficient - your code may not belong in that category, but certainly game developers will "care" if the frame-rate is high or not, and inefficient code will not give good frame-rate.

---

they go far beyond what can be expected, they use inline assembly, then gfx cards help, then a library using all the hardware features etc. etc. some even avoid C++.

Quote:

---

Likewise, if you are working on a large database-project or some such (e.g you implement the functions in MySQL or some such), any extra time spent there should be avoided.

---

if i am doing such a big stuff then std stuff is negligible compared to my large implementation, i will re write the stuff i need, the way i want it! :)

Template-avoidance is a combination of "trying to get everything to fit in memory" and "don't help much anyways", yes. We have a "budget" of 32MB to fit "everything" into memory - that's OS, drivers, apps, data and anything else needed in our system. If it doesn't fit in 32MB, then it's time to "go on a diet".

I very much doubt you can find any game that "avoid C++" - they may well not use for example STL, but the code for current games is almost certainly written using C++ - it makes the code so much neater when doing vector operations for example, and using macros/functions for vector operations would just make the code unreadable and slower. But the game programmers certainly care about what happens "under the hood".

Rewriting "anything I need" is not a good philosophy, although sometimes it's necessary to write your own functions to do things - but it should not be done "because it's such a large system", but because there is a CLEAR AND REAL need to write your own functions.

--
Mats