This is a very good table, thanks.
I think, [=, *this] could be the most easy way to solve the [=] problem. And dropping C++-14 compiler support (if I understand the topic).

Hello Mirek and Lance,

I agree with Lance that someday capture this by [=] might be compilation error instead of warning. Such precedence happened in the past. For example in C++17 std::auto_ptr had been removed. However for capturing this by [=], I do not see that it will be removed in C++23. So, disabling warning might give us 3-4 additional years...

Hello,

It looks like that in this thread we are talking about lot of things Backing to Mireks attention about lack of clang-format in our toolchaing on Windows. This executable can be downloaded from muttleyxd/clang-tools-static-binaries GitHub repository. On Windows when we will make decision to integrate this tool, we can put it under bin/clang-format directory or attached to bin/clang/bin/*.

Klugier

So we have to wait some years.
C++-20 is too new to be a requirement. Ubuntu 20.04 is actively used for example by many people and companies.

Hello Mirek and Klugier:

The following code is an excerpt from /usr/include/c++/11/bits/stl_vector.h

      iterator
      begin() _GLIBCXX_NOEXCEPT
      { return iterator(this->_M_impl._M_start); }

      /**
       *  Returns a read-only (constant) iterator that points to the
       *  first element in the %vector.  Iteration is done in ordinary
       *  element order.
       */
      const_iterator
      begin() const _GLIBCXX_NOEXCEPT
      { return const_iterator(this->_M_impl._M_start); }

      /**
       *  Returns a read/write iterator that points one past the last
       *  element in the %vector.  Iteration is done in ordinary
       *  element order.
       */
      iterator
      end() _GLIBCXX_NOEXCEPT
      { return iterator(this->_M_impl._M_finish); }

Without looking into the definition of _GLIBCXX_NOEXCEPT, most experienced c++ users(, all participants of this thread for sure,) can tell that it will expand to noexcept when the -std version supports it and vanishes otherwise.

It might not be pleasant or pretty, but it certainly works and can be argued as the most reasonable solution in this particular situation.

It's a common problem that libraries with some history need to support different versions; maintaining backward compatibility should not mean stay backward. U++ necessarily has done similar thing for similar purposes, I believe.

Why is it so hard to swallow in this particular case?

BR,
Lance

@Mirek: BTW, how about IDE: closing window moves it in Ctrl+Tab order after all opened documents.

I think we did discuss this few years back, and it was like by-design for you? But it keeps irritate me even after those years: I switch by Ctrl+Tab to file which I want to close, Ctrl+W to close it, and now I want to move to some other open file and hit Ctrl+Tab, and closed file is back... I'm just not used to this, and I don't see value in it, feels like wrong UX to me.

I can try to do pull request if you don't mind the change.

BTW you seem to mostly apply pull requests manually, but that way you make the contribution in git changed to your user, not sure if this is intentional, or just the way how you use git.

Lance wrote on Mon, 19 December 2022 00:41

Hello Mirek and Klugier:

The following code is an excerpt from /usr/include/c++/11/bits/stl_vector.h

      iterator
      begin() _GLIBCXX_NOEXCEPT
      { return iterator(this->_M_impl._M_start); }

      /**
       *  Returns a read-only (constant) iterator that points to the
       *  first element in the %vector.  Iteration is done in ordinary
       *  element order.
       */
      const_iterator
      begin() const _GLIBCXX_NOEXCEPT
      { return const_iterator(this->_M_impl._M_start); }

      /**
       *  Returns a read/write iterator that points one past the last
       *  element in the %vector.  Iteration is done in ordinary
       *  element order.
       */
      iterator
      end() _GLIBCXX_NOEXCEPT
      { return iterator(this->_M_impl._M_finish); }

Without looking into the definition of _GLIBCXX_NOEXCEPT, most experienced c++ users(, all participants of this thread for sure,) can tell that it will expand to noexcept when the -std version supports it and vanishes otherwise.

It might not be pleasant or pretty, but it certainly works and can be argued as the most reasonable solution in this particular situation.

It's a common problem that libraries with some history need to support different versions; maintaining backward compatibility should not mean stay backward. U++ necessarily has done similar thing for similar purposes, I believe.

Why is it so hard to swallow in this particular case?

BR,
Lance

Uhm, I guess we are presented with 2 more or less equivalently ugly options here. One of them requires a significant amount of work....

And some of the viable options if multi-c++-version support is a necessity (as proposed by Klugier and me):

1. [=] to [&] when necessary. Make local copies of variables that are originally captured by value with undesired modification, and refer only to the copy in the lambda body. A fictitious example:

struct MyApp : TopWindow {
   Button b;

   MyApp() {
       int j = 12;
       b << [&] { PromptOK(AsString(j)); };
   }
};

Lance wrote on Mon, 19 December 2022 19:10

And some of the viable options if multi-c++-version support is a necessity (as proposed by Klugier and me):

1. [=] to [&] when necessary. Make local copies of variables that are originally captured by value with undesired modification, and refer only to the copy in the lambda body. A fictitious example:

[&] does not help and the problem is not local copies.

This does not work:

struct MyApp : TopWindow {
   Button b;

   MyApp() {
       int j = 12;
       b << [&] { PromptOK(AsString(j)); };
   }
};

mirek wrote on Mon, 19 December 2022 14:22

Lance wrote on Mon, 19 December 2022 19:10

And some of the viable options if multi-c++-version support is a necessity (as proposed by Klugier and me):

1. [=] to [&] when necessary. Make local copies of variables that are originally captured by value with undesired modification, and refer only to the copy in the lambda body. A fictitious example:

[&] does not help and the problem is not local copies.

This does not work:

struct MyApp : TopWindow {
   Button b;

   MyApp() {
       int j = 12;
       b << [&] { PromptOK(AsString(j)); };
   }
};

I see. Reference to local variables invalidated out of function body. So this option is eliminated. We are left with only 2.

Lance wrote on Mon, 19 December 2022 23:14

mirek wrote on Mon, 19 December 2022 14:22

Lance wrote on Mon, 19 December 2022 19:10

And some of the viable options if multi-c++-version support is a necessity (as proposed by Klugier and me):

1. [=] to [&] when necessary. Make local copies of variables that are originally captured by value with undesired modification, and refer only to the copy in the lambda body. A fictitious example:

[&] does not help and the problem is not local copies.

This does not work:

struct MyApp : TopWindow {
   Button b;

   MyApp() {
       int j = 12;
       b << [&] { PromptOK(AsString(j)); };
   }
};

I see. Reference to local variables invalidated out of function body. So this option is eliminated. We are left with only 2.

3. Disable warning and hope that it will be deprecated for really long time. I bet it will.

See, this whole thing is rather unfortunate. There are 3 options, none of them really good. 2 of these require significant work and a chance of introducing new bugs....

Like Novo said, he and many similar-minded people are still using very old systems/compilers;

Lance wrote on Mon, 19 December 2022 12:43

Like Novo said, he and many similar-minded people are still using very old systems/compilers;

Systems I mentioned are not "very old".
Void Linux is a rolling distro (that means that you get latest versions of everything except of core packages like Clang). This is done for stability. I personally spent quite a lot of time dealing with bugs in compilers (code generators). And because of that I prefer to use a stable and well tested compiler even if it seems to be outdated.
Void Linux is ranked number five by DistroWatch.
Netflix runs on FreeBSD.
Almost all gaming consoles run FreeBSD.
So "very old systems/compilers" aren't that old