Talk:cpp/container/map

From the History page (https://en.cppreference.com/mwiki/index.php?title=cpp/container/map&action=history), I'd like to discuss this comment:

15:26, 25 January 2022‎ Cubbi (Talk | contribs)‎ . . (6,101 bytes) (-1,410)‎ . . (when the example made sense, it showed four three basic operations: create, insert, iterate (was missing erase but ok). Now it's 90% history lesson/beginner tutorial) (undo)

Regarding "Now it's 90% history lesson/beginner tutorial)", which was an assessment of this version (https://en.cppreference.com/mwiki/index.php?title=cpp/container/map&oldid=137507), is that such a bad thing? cppreference.com is frequently written so esoterically that only the most-expert, astute, and experienced programmers can read and understand it. The version I posted brought it down to a level any decent programmer could appreciate and understand. Is that not desired on this site?

ERCaGuy (Gabriel Staples) (talk) 20:30, 25 January 2022 (PST)

It became a demonstration of exactly what scares people way from C++: incomprehensible syntax and multiple layers of historic baggage (not even starting on the novel uses of the word 'iterator' in the comments). --Cubbi (talk)

I would disagree that the edits adding lots of text were any good for decent programmers too. My issue with the extra text is that, w.r.t. making a demonstrative example, it's misplaced and noisy. The key ideas needing to be demoed on a map page are map operations with minimal language-based boilerplate as to best show off the library features. Anything not directly showing off the relevant operations should be limited to only what's needed to make the example more interesting in application. If we wrote about how auto is used to deduce a type and how structured bindings have a corresponding vintage alternative, basically every page would end up talking about it, and then it's clear that it just gets in the way.

The place for talking about auto is on its page, and the place to talk about structured bindings is on its page. But even then, and I don't mean to gatekeep, but I do tend to agree that this wiki is primarily a reference rather than a tutorial, and would delegate tutorial-esque prose to other websites that are better at it (such as learncpp.com, which I'm a fan of). The utility of being a reference with minimal clutter is that you can look things up / get to the point quicker; eventually you're going to "know" the feature you're looking at, and the reference is your means to double-check the fine print.

Hope you can see where we're coming from at least. --Ybab321 (talk) 03:13, 26 January 2022 (PST)

I see what you're both saying. I disagree in particular with this part though. Regarding "scares people way from C++: incomprehensible syntax...", that's how I feel about the extensive usage of the word auto in C++. Can we at least shy away from using auto everywhere and use more-explicit types where able instead? Ex: I really think this obfuscates the language and makes it more-difficult to understand:

   for (const auto& n : m) {
       std::cout << n.first << " = " << n.second << "; ";
   }

...whereas this is easy to read and understand, and makes it clear where n magically gets the .first member from: it's a std::pair<>:

   for (const std::pair<const std::string, int>& n : m) {
       std::cout << n.first << " = " << n.second << "; ";
   }

...In other words, if I replace usages of auto with more-explicit types in cases like this, would you block my changes? Excessive usage of the word auto is bad for readability and understandability. ERCaGuy (Gabriel Staples) (talk) 11:41, 26 January 2022 (PST)

Regarding structured bindings, however, I don't think they even can be done without usage of the word auto, can they? ERCaGuy (Gabriel Staples) (talk) 11:45, 26 January 2022 (PST)

auto is a tricky one, some believe it aides readability, some believe it hurts readability, with varying degrees of compromise. For the purposes of examples on cppreference, I would be inclined to agree that auto is generally worse for understandability, though in some cases much more readable. Structured bindings on the other hand - and you are right that they require use of the auto token - I look at much more favourably, I just think they're so good for readability that it's hard to justify not using them. Ultimately though that's all my personal opinion and everyone's mileage varies, I'm not sure if it makes sense to have a policy that favours using auto or straying away from it. Tricky, tricky, tricky. I also quite like to rely on class template argument deduction where possible, even though it's potentially a tidbit harder to understand, which I think comes into this category of readability vs understandability.

Certainly wouldn't want to force my personal view onto the site. Though, I would like to claim that auto is always better than spelling out an iterator type, and that using structured bindings is always better than accessing a pair or tuple manually. Otherwise, I think avoiding auto is always better if it makes sense for the type to be spelt out for the hyperlinker to kick in. And in all other cases I don't think I would care about whether auto is used or not (i.e. wouldn't make or revert edits either way). --Ybab321 (talk) 12:19, 26 January 2022 (PST)

IMO auto dramatically improves code readability (and don't forget, avoids accidental type conversions), especially for programmers who previously encountered other languages. but as far as cppreference examples goes, I'd concede to Core Guidelines ES.11, which ask to limit use of auto to where it avoids repeating a type name (thus, if you already spelled out map<A,B>, don't write map<A,B>::iterator - it won't auto-link anyway. And this for (const std::pair<const std::string, int>& n : m) is just mind-boggling. Even in the 1990s we'd write map_t::value_type. --Cubbi (talk) 21:01, 27 January 2022 (PST)