C++17 creates a practical use of the backward array index operator

Re:C++17 creates a practical use of the backward array index... by olliej on Monday April 03, 2023 @04:23PM (#35430734)

Better question: why did C and C++ not define this as left to right (the answer is perf claims decades ago, that are not really valid now, and questionable even then).

The example

   a[b]

doesn't really exhibit the unexpected, but as I understand it

   f()->a[b()]

could evaluate as

   temp = b()
   f()->a[temp]

which it seems reasonable to consider unexpected. The lack of left to right sequencing here seems not-dissimilar to the lack of sequencing in call arguments, which was also realized to be a needless footgun and fixed.

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by TremendousJudge on Monday April 03, 2023 @04:43PM (#35430997)

Half of the new features of "modern" C++ editions leave me agreeing with the change but wondering what they were thinking before. Another example: std::map::contains was introduced in C++20; why did they go decades thinking it wasn't necessary to have such an operator (instead providing only count() even though a map has unique keys), and why did they change their minds only now? Did the old guard literally die off or something?

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by tubs on Monday April 03, 2023 @05:27PM (#35431519)

Problem with contains is we are now going to see more code like

    if (map.contains(foo)) {
       bob(map[foo]);
    }

over the (vastly uglier) more efficient:

   if (auto it = map.find(foo); it != map.end()) {
       bob(*it);
   }

Of course languages like C# manage this in a more elegant way with out parameters declarable at the call site.

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by JonChesterfield on Monday April 03, 2023 @05:43PM (#35431717)

A pity the c++ compiler has no way to recognise calls to the c++ library in order to do rewrites like that automatically. It's CSE at the stdlib level, should definitely be possible to do that.

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by eklitzke on Monday April 03, 2023 @06:38PM (#35432326)

Hard coding behavior like for the STL that seems pretty questionable, especially given that std::map and std::unordered_map have poor performance compared to other alternatives (e.g. absl::btree_map and absl::flat_hash_map, and likewise folly has better implementations).

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by im3w1l on Monday April 03, 2023 @09:15PM (#35433710)

if let is such a nice way to express this

    if let Some(x) = map.get(foo) {
        bob(x)
    }

One subtle but noteworthy thing is that the idiom only mentions map by name once, which is nice if you have a very long map name, and prevents copy paste bugs where you only update one of the two mentions.

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by paulddraper on Tuesday April 04, 2023 @12:26AM (#35435068)

Scala:

    for (x <- map.get(foo)) {
      bob(x)
    }

    // or

    map.get(foo).foreach(bob)

    // or

    map.get(foo) match {
      case Some(x) => bob(x)
    }

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by olliej on Tuesday April 04, 2023 @02:59PM (#35444381)

This pattern exists in C++ as well. The specific issue here is that all these STL APIs are in terms of C++'s iterator model, and can't be replaced with a more modern "optional" style that allows this cleaner coding style :-/

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by PaulDavisThe1st on Monday April 03, 2023 @05:09PM (#35431327)

  std::map::find (item) != map.end()  <=> std::map::contain (item)

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by zimpenfish on Tuesday April 04, 2023 @04:05AM (#35436520)

I think the problem is that with `std::map::find(item)` you get the value back but you don't with `std::map::contain(item)` - which means a second lookup to actually retrieve the value, no?

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by olliej on Monday April 03, 2023 @04:47PM (#35431041)

The historical lack of sequencing is because they were unsequenced in C, and C++ thus inherited it.

And yes, it does seem that there were a lot more people hell bent on resisting correcting unnecessary UB in the past than today, but they’re still around.

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by TremendousJudge on Monday April 03, 2023 @04:57PM (#35431183)

I get it, but then, why change it now? (or 6 years ago I guess)

[ Parent | on HN ]

Re:C++17 creates a practical use of the backward array index... by olliej on Monday April 03, 2023 @05:02PM (#35431233)

Sorry, I had an unsaved edit above. It seems the resistance to removing unnecessary UB has reduced over the years.

[ Parent | on HN ]