Hi,

theide.log gets stuffed with hundreds of identical strings:

11:46:54:638 ERROR MakeBuild::IsAndroidMethod(): Failed to find builder.
11:46:54:891 ERROR MakeBuild::IsAndroidMethod(): Failed to find builder.
11:46:55:318 ERROR MakeBuild::IsAndroidMethod(): Failed to find builder.
11:46:57:764 ERROR MakeBuild::IsAndroidMethod(): Failed to find builder.
11:46:57:765 ERROR MakeBuild::IsAndroidMethod(): Failed to find builder.
11:47:00:340 ERROR MakeBuild::IsAndroidMethod(): Failed to find builder.
11:47:00:342 ERROR MakeBuild::IsAndroidMethod(): Failed to find builder.
11:47:03:259 ERROR MakeBuild::IsAndroidMethod(): Failed to find builder.
11:47:03:318 ERROR MakeBuild::IsAndroidMethod(): Failed to find builder.

Best regards,
Victor

An other bug:
Assist goes mad on .icpp files. Try opening Painter/PainterInit.icpp
It is just trying to parse it without success endlessly:

C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp parsed in 15 ms
C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp parser output processed in 0 ms
Failed commandline: C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp -DflagDEBUG -DflagDEBUG_FULL -DflagMAIN -DflagCLANG  -std=c++14 -xc++ -Wno-logical-op-parentheses 
C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp parsed in 0 ms
C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp parser output processed in 0 ms
Failed commandline: C:\Download\Upp\upp\uppsrc\Painter\PainterInit.icpp -DflagDEBUG -DflagDEBUG_FULL -DflagMAIN -DflagCLANG  -std=c++14 -xc++ -Wno-logical-op-parentheses 

    return some_condition ? SomeString : "Some ASCIIZ String";

C:\upp\uppsrc\Core\Topt.h (157): error C2100: illegal indirection
C:\upp\uppsrc\Core\Topt.h (172): note: see reference to function template instantiation 'void Upp::AssertMoveable0<T>(T *)' being compiled
with
[
T=double
]ChWin32.cpp

Hi Mirek:

I understand that U++ currently aims to be compliant with c++14. Overall, U++ is very close to c++20 compliant.

IIRC, the only kind of complaints gcc/clang make when building TheIDE with std=c++20 is about caputuring `this` by default is deprecated in c++20 for a lambda.

.icpp assist should be now fixed.

Hello Lance,

Quick question, what about replacing [=] with [this]. Does it produce warning with C++20? It compiles fine with C++14 and I think in most cases we can replace it. We are using [=] to capture local variables very really, however this can be overcome by explicit argument capture.

The solution with CAPTURETHISBYVALUE is ugly and very impractical especially for U++ maintainers

I agree that we should be compatible with C++20 as much as we can. On the other hand, I also think it is a good moment to change default standard from c++14 to c++17. c++14 is 8/9 years old standard and on most of currently supported system compilers with c++17 support are present. For example I like auto [x, error] = GetTuple() that can not be used in c++14 word. Very useful feature when you want to back-propagate error without using exceptions. I remember, we discussed this transition some time ago, but maybe it is good to discuss it one more time

Klugier

#if __cplusplus > 201703L
#    define CAP_BY_VALUE_WITH_THIS = ,this
#else
#    define CAP_BY_VALUE_WITH_THIS =
#endif

	auto Fix = [CAP_BY_VALUE_WITH_THIS](const char *s) {

	auto Fix = [=](const char *s) {

	RegisterGlobalSerialize("FileHexViewPos", [CAP_BY_VALUE_WITH_THIS](Stream& s) {

	RegisterGlobalSerialize("FileHexViewPos", [=](Stream& s) {

@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.

And one more very minor IDE bug/quirk: when I Ctrl+M to select main package, open one, it re-opens all tabs which were open during working on that package = nice. But current state seems to be saved only when leaving IDE, not when I do another Ctrl+M and switch to other package. That's IMHO unexpected UX, if the state loads upon Ctrl+M, it should also save updated state of open tabs on it?

(sorry if these requests are out of scope for 2022.3, but as I'm lately using IDE daily, I'm pressing the stuff which nags me )

#if __cplusplus > 201703L
#    define CAPTURETHISBYVALUE ,this
#else
#    define CAPTURETHISBYVALUE
#endif

Lance wrote on Sun, 18 December 2022 14:48

#if __cplusplus > 201703L
#    define CAPTURETHISBYVALUE ,this
#else
#    define CAPTURETHISBYVALUE
#endif

It does not feel nicer than disabling the warning...

Mirek

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

I was the one adding Astyle *many* years ago... and it's true that it has not been updated since years.
But, IMHO, a tool to format code is quite useful. I still use it, even if it's broken on new code.
Ok for removing, but also ok for adding a new one.

Copying might not be desirable or doable (deleted copy ctor etc). Big no-no.

BR,
Lance

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