Every time I see something like that done with C++, I think of all the horrendous template code that must be behind it. Good example!
– Greg HewgillSep 26 '08 at 10:22

5

It is implemented "basically" as an overloaded operator, but if you ever have a syntax error, enjoy that line of code. It pulls in 15 different .hpp's for something that would take you a minute or two. Code for fun? Use it; otherwise, consider the cost to time/size.
– hazzenSep 26 '08 at 14:23

27

The beauty of all the horrendous template code that implements these utilities is that it is neatly encapsulated in a library and the end user rarely needs to deal with the complexity.
– Steve GuidiNov 13 '09 at 18:09

43

@QBziZ: If your company declines using Boost on the grounds of it not being "standard enough", I wonder what C++ library would be "standard enough". Boost is the standard companion for the C++ coder.
– DevSolarJan 5 '12 at 13:04

37

My problem with Boost (here, and elsewhere) is that you can often get on without it (in this case with C++11 or before C++11 with a function). Boost adds a significant compile time overhead, had tons of files to park into your repository (and to have to copy around/zip/extract if you are making an archive). That's the reason I try not to use it. I know you can choose what files to include/not include, but you usually don't want to have to worry about Boost's cross dependencies with itself so you just copy the whole thing around.
– boboboboJun 1 '13 at 0:43

Why is this the 'best'? Why for example is it better than @Dreamer's answer?
– user207421May 6 '13 at 23:40

6

I think it's "best" because it's really simple and doesn't depend on other structures existing (such as the Boost::Assign or a reimplementation of it). And compared to @Dreamer's answer, well, I avoid creating a whole structure only for initializing a map ...
– PierreBdRMay 10 '13 at 14:54

2

Note there is a danger here. extern variables will not have their correct values in this "before main run-time constructor" if the compiler only saw the extern declaration, but has not run into the actual variable definition yet.
– boboboboJun 1 '13 at 16:04

4

No, the danger is that there is nothing saying in which order the static variables should be initialized (at least across compilation units). But this is not a problem linked to this question. This is a general problem with static variables.
– PierreBdRJun 4 '13 at 9:06

5

no boost AND no C++11 => +1. Notice that function can be used to initialize a const map<int,int> m = create_map() (and so, initialize const members of a class in the initialization list: struct MyClass {const map<int, int> m; MyClass(); }; MyClass::MyClass() : m(create_map())
– ribamarMar 13 '15 at 10:00

The above code works best for initialization of global variables or static members of a class which needs to be initialized and you have no idea when it gets used first but you want to assure that the values are available in it.

If say, you've got to insert elements into an existing std::map... here's another class for you.

You have some very good answers here, but I'm to me, it looks like a case of "when all you know is a hammer"...

The simplest answer of to why there is no standard way to initialise a static map, is there is no good reason to ever use a static map...

A map is a structure designed for fast lookup, of an unknown set of elements. If you know the elements before hand, simply use a C-array. Enter the values in a sorted manner, or run sort on them, if you can't do this. You can then get log(n) performance by using the stl::functions to loop-up entries, lower_bound/upper_bound. When I have tested this previously they normally perform at least 4 times faster than a map.

The advantages are many fold...
- faster performance (*4, I've measured on many CPU's types, it's always around 4)
- simpler debugging. It's just easier to see what's going on with a linear layout.
- Trivial implementations of copy operations, should that become necessary.
- It allocates no memory at run time, so will never throw an exception.
- It's a standard interface, and so is very easy to share across, DLL's, or languages, etc.

I could go on, but if you want more, why not look at Stroustrup's many blogs on the subject.

Performance is not the only reason for using a map. For example, there are many cases, where you want to link values together (for example, an error code with an error message), and a map makes the use and access relatively simple. But a link to these blog entries may be interesting, maybe I'm doing something wrong.
– MatthiasBJul 21 '14 at 12:59

5

An array is much easier and has higher performance if you can use it. But if the indices (keys) are not contiguous, and widely spaced, you need a map.
– KarlUOct 28 '14 at 16:48

1

A map is also a useful form for representing a partial function (function in the mathematical sense; but also, kind of, in the programming sense). An array does not do that. You can't, say, lookup data from an array using a string.
– einpoklumJul 20 '15 at 19:21

2

Your answer does not attempt to answer the valid question, and instead speculates on the limitations of the language, proposes solutions to different problems, hence downvote. A real scenario - mapping (continuous or not) library error codes to text strings. With array, search time is O(n), which can be improved by static maping to O(log(n)).
– ToshaJan 22 '16 at 11:41

2

If indeed "there is no good reason to ever use a static map..." then it is very strange that syntax (initializer lists) that make them easy to use was added in C++11.
– ellisbbenJul 1 '16 at 15:09