How to make a std::map return null when there is nothing "at" a certain position?

[monarch_dodra]

That's typical feature overuse. Something a pumped up newbie would put in to show off. You get the worst of two worlds:

As implementation it's too much. What's wrong with a simple free function?

As abstraction it's too little. What's wrong with a class? Proper encapsulation is always worthwhile also in a limited scope.

The advantage here is simply locality. You avoid poluting your namespace/class with single use helpers. Furthermore, when using said helper, you don't need to look very far to find its definition.

If you could simply define nested functions, that would be even better, but C++ doesn't allow it.

[razzle]

The advantage here is simply locality.

Locality? It beats me why you consider this,

void foo() {
   auto unitColors_at_or_zero = [&]( auto id ){ auto it = unitColors.find(id); return it != unitColors.end() ? *it : 0; };
   DWORD color1 = unitColors_at_or_zero(unit->id);
   // ...
}

more local than this,

void foo() {
   auto it = unitColors.find(id);
   DWORD color1 = (it != unitColors.end()) ? *it : 0;
   // ...
}

I'd say the first one is typical feature overuse.

[superbonzo]

If you could simply define nested functions, that would be even better

why ? functions and "pure" lambdas are *almost* equivalent ( ignoring ADL issues ), what would buy you a local function wrt a "pure" local lambda ? locality aside, note that the point here is also code fluentness and clarity, so the ability of capturing local data is important in this case ( the excessive verbosity of writing local classes ( especially if they need state ) is one of the reasons lambdas were added to c++ I think ).

The advantage here is simply locality. You avoid poluting your namespace/class with single use helpers. Furthermore, when using said helper, you don't need to look very far to find its definition.

I'd also add code fluentness and expressivity, compare

auto foo_color = unitColors.find( foo );
auto bar_color = unitColors.find( bar );

if( ( foo_color == unitColors.end() && bar_color == unitColors.end() ) ||
	( foo_color == unitColors.end() && *bar_color == 0 ) ||
	( bar_color == unitColors.end() && *foo_color == 0 ) ||
	( *foo_color == *bar_color )
	)
{
	// ... ^^ hard to read condition ^^
}

// or

auto foo_color_iter = unitColors.find( foo );
auto foo_color = foo_color_iter != unitColors.end() ? *foo_color_iter : 0;
auto bar_color_iter = unitColors.find( bar );
auto bar_color = bar_color_iter != unitColors.end() ? *bar_color_iter : 0;

if( foo_color == bar_color )
{
	// ... ^^ easy to read, but is it really clear what's going on ? ^^
}

// with

auto unitColors_at_or_zero = [&]( auto id ){ auto it = unitColors.find(id); return it != unitColors.end() ? *it : 0; };

// ... few lines

if( unitColors_at_or_zero( foo ) == unitColors_at_or_zero( bar ) )
{
	// ... ^^ easy to read, immediately suggests the intention, just look few lines above to see the implementation ^^
}

obviously, which one is actually better ( including higher abstractions ) should be decided on a case by case basis ...
and more obviously, as everything one should not abuse it ( excluding obvious functors ( like sorting predicates ) I find hard to follow lambdas that are not defined few lines away )