C++11 brought type inference so these days it would be either

    auto whatever = new std::map<int, std::vector<int>>();

or

    std::map<int, std::vector<int>> whatever;

depending on if you want heap or stack allocated variable, stack allocation usually being preferred as the default solution (and thus being the tersest form).

But lets look a bit deeper why C++ is more verbose in this case. One central reason is the idea that standard library should not be special/privileged in the language syntax. The upside from that is that almost all syntax sugar can be applied to user defined types. A relevant example would be uniform initializer lists in C++11, which allow you to write eg.

    std::vector<int> foo {1,2,3};

but also

    MyFunkyDatastructure bar {1,2,3};

as long as suitable constructors are defined. In comparison afaik in Python you can not define a class that can be initialized with sugared syntax.

The theme of non-privileged standard library also extends to global namespace pollution. In C++ stdlib does not get to reserve names at global namespace, which leads slightly increased verbosity (std:: -prefixes or using-statements).

So when you ask why you cant make a map/dict in C++ with just 'd = {}', know that there are actually good reasons for (some/most) of the verbosity. The tradeoffs might make it less suitable in your usecases, but there is no absolute/general superiority in either way.

>> know that there are actually good reasons for (some/most) of the verbosity.

This is why I talked about the philosophy of the language. I wasn't arguing about whether it was good or bad.

That being said, for my own use cases, verbosity is a big deal.

>> In C++ stdlib does not get to reserve names at global namespace, which leads slightly increased verbosity (std:: -prefixes or using-statements).

I understand and agree, but you'd have to agree with me that if you start naming your classes Map and Vector, you're looking for problems ;-)

Well to be honest,

  d = {}

is absolutely not equivalent to a map of int to a vector of ints. Sure in javascript, you can indeed use an object as a map, but you are lacking the type safety that the C++ version provide and all the nice API. Also, in C++11, you can shorten it with auto :

  auto whatever = new std::map<int, std::vector<int>>();

and to be fair with the js, if you want it as short as possible, you could use a using namespace statement for std (although not really recommended) :

  auto whatever = new map<int, vector<int>>();

or maybe not use new :

  map<int, vector<int>> whatever;

I don't think it's that bad. But sure, any dynamic language will be less verbose that a static language because, well, you are removing information...

This isn't really a fair criticism because:

1. You picked probably the most verbose way to do it.

2. It's not valid C++ because you're assigning a pointer to a value.

3. Idiomatic C++ doesn't use `new` explicitly anyway

4. The `d = {}` of Python is not really equivalent.

My feeling is that python gains brevity in exchange for putting a heavier mental load on the programmer, which is manageable for small programs but becomes unwieldy for larger ones.

Does idiomatic C++ do heap allocations with malloc then?

Idiomatic C++ would allocate everything possible on the stack, and if that wasn't possible, use `make_shared`/`make_unique`. So maybe I will change it to say "doesn't use `new` directly".

No. Idiomatic C++ allocates everything at compile time by means of template metaprogramming magic (just joking).

No that is D and it is with CTFE. Also joking... mostly.

Why not: using namespace std; map<int, vector<int>> whatever;

It's a lot shorter, actually correct, and it's totally cool to import whole namespaces in a .cpp implementation file where you're likely to actually declare something like that.

If you're going to critique the language you should try to learn it first.

This works just fine:

    map<int, vector<int>> d = {{0, {1,2,3,4,5}},
                               {1, {6,7,8,9,10}}};

In D it would be:

   int[int] whatever;

Actually wouldn't it be

    int[][int] whatever;

? Because I think we should be getting an array out whenever we do

    whatever[1]

and not just an int.

(You were questioning the language designer there)

I know, I think he misread the C++ code.

Yes, you're right.