Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 ;-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: