Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » U++ community news and announcements » 2022(?).2 beta
Re: 2022(?).2 beta [message #59362 is a reply to message #59360] Sun, 18 December 2022 23:35 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1077
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello,

It looks like that in this thread we are talking about lot of things Smile 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


U++ - one framework to rule them all.

[Updated on: Sun, 18 December 2022 23:35]

Report message to a moderator

Re: 2022(?).2 beta [message #59363 is a reply to message #59356] Mon, 19 December 2022 00:15 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13986
Registered: November 2005
Ultimate Member
zsolt wrote on Sun, 18 December 2022 22:33
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).


Except it is not the same thing. Please check the semantics....
Re: 2022(?).2 beta [message #59364 is a reply to message #59355] Mon, 19 December 2022 00:18 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13986
Registered: November 2005
Ultimate Member
Klugier wrote on Sun, 18 December 2022 21:54
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...



Yep, exactly. When this is error, we can move on to C++20. Until then, disable warning.

This is not ideal situation. But best that can be done.

That said, I think C++ commitee is a little bit out of touch here...

Mirek
Re: 2022(?).2 beta [message #59365 is a reply to message #59361] Mon, 19 December 2022 00:41 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 536
Registered: March 2007
Contributor
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
Re: 2022(?).2 beta [message #59366 is a reply to message #59362] Mon, 19 December 2022 00:46 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 536
Registered: March 2007
Contributor
Klugier wrote on Sun, 18 December 2022 17:35
Hello,

It looks like that in this thread we are talking about lot of things Smile 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


OK. I was writing my last post before seeing this reply.
Re: 2022(?).2 beta [message #59367 is a reply to message #59361] Mon, 19 December 2022 05:36 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1363
Registered: December 2006
Ultimate Contributor
zsolt wrote on Sun, 18 December 2022 17:29

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.

I'm actively using Void linux which is based on Clang 12.
FreeBSD 12 is based on Clang 10.
FreeBSD 13 is based on Clang 13.
32-bit versions of Linux and BSD are quite popular Smile


Regards,
Novo
Re: 2022(?).2 beta [message #59373 is a reply to message #59365] Mon, 19 December 2022 10:08 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13986
Registered: November 2005
Ultimate Member
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....
Re: 2022(?).2 beta [message #59378 is a reply to message #59350] Mon, 19 December 2022 12:20 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13986
Registered: November 2005
Ultimate Member
mr_ped wrote on Sun, 18 December 2022 19:46
@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.


Hopefully fixed.

Re: 2022(?).2 beta [message #59382 is a reply to message #59373] Mon, 19 December 2022 18:43 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 536
Registered: March 2007
Contributor
mirek wrote on Mon, 19 December 2022 04:08
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....


Hello Mirek and Klugier:

Another drawback for the disable-warnings option: Like Novo said, he and many similar-minded people are still using very old systems/compilers; people are different. What if in 4 years' horizon you decide that time has mature for switching to c++20 but there are still a significant number of users who wish to be able to have c++14 as an option?

From the point of smoother user experience, I am not quite sure if it's a good idea that the mainstream version today will become completely unusable the next day because it's upgraded. You likely need to deprecate it and keep it going for a couple of more years so people have time to transit to the new mainstream version/standard.

If this will be the case, we end up still need to be able to support both c++14 and c++20 at the same time for at least a period of time: trouble is deferred instead of solved. And as times goes, more [=] cases will be added to U++ (not in a significant number, but it's a non-decreasing function of time), chance is it will take more time and effort at the postponed switch date.

BR,
Lance

[Updated on: Mon, 19 December 2022 18:49]

Report message to a moderator

Re: 2022(?).2 beta [message #59383 is a reply to message #59382] Mon, 19 December 2022 19:10 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 536
Registered: March 2007
Contributor
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:
void ClassName::FunctionName()
{
    int i = 0; 
    auto f = [=]{ this->DoSomething(); ++i; };
    ....
}

should be rewrite to
void ClassName::FunctionName()
{
    int i = 0; 
    int j = i;
    auto f = [&]{ this->DoSomething(); ++j; };
    ....

}


pros: concise capture list; no unwanted GLOBAL MACRO;

cons: it's time consuming and error-prone for the change. Majority of affected lambda bodys need to be analysed individually to make copy& refer only to copy manually for affected variables. You get no help from the compiler. If you miss changing one of the reference to old variable name, or miss to change one of the variable you don't want to be modified, a bug arise. And it could be subtle to discover and fix all the errors. And there is no mechanism to enforce the rule, developers/maintainers (mainly both of you atm) has to watch out and be disciplined;

option 2: list individual variable in the capture list.

Pro and cons are quite similar to option 1. Less chance of subtle bugs. Potentially long and tedious capture list.

option 3: MACRO
pros: clean, fast, standard practice. Other u++ users can choose to use the MACRO in their own code to smoothen future transition form c++14 to c++20.

cons: both of you abhor the MACRO that needs to be introduced. Smile come on guys, if it's just because you don't like the name, feel free to choose a better one.

Or shall we start a poll-like thing so that more input can be received? I particularly are interested to hear what @Oblivion and @Koldo have to say on this topic.

[Updated on: Mon, 19 December 2022 19:42]

Report message to a moderator

Re: 2022(?).2 beta [message #59385 is a reply to message #59383] Mon, 19 December 2022 20:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13986
Registered: November 2005
Ultimate Member
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)); };
   }
};

Re: 2022(?).2 beta [message #59388 is a reply to message #59385] Mon, 19 December 2022 23:14 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 536
Registered: March 2007
Contributor
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.
Re: 2022(?).2 beta [message #59389 is a reply to message #59388] Mon, 19 December 2022 23:35 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13986
Registered: November 2005
Ultimate Member
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....
Re: 2022(?).2 beta [message #59390 is a reply to message #59389] Mon, 19 December 2022 23:54 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 536
Registered: March 2007
Contributor
mirek wrote on Mon, 19 December 2022 17:35
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....


1. Disable warnings option: almost effortless. but like I mentioned in a previous post, when you eventually decide to move to c++20, everybody else need to move with you overnight, or otherwise there will be the same problem of supporting pre- & post-c++20 world simultaneously. I am fine with that but not sure if other people will like it.

2. Klugier's other proposal ([this, a,b,c]). Heavy work, chance of bugs.

3. My proposal. Majority work can be done in 20 minutes. Other examples or packages, etc can be left until a bug is reported (mainly in the case old [=] doesn't involve a `this`, just change back to [=], can be fixed without thinking). I don't expect other subtle bug be introduce because of this approach. And it should settle down in a time span of months, but involves little work on maintainers/users' part after the initial 20 minutes or so.

In a previous post, I have listed procedures I took. Replace in files, then compiler will tell the case where original [=] doesn't involves `this`, in which cases we change them back to [=]. I fail to see any chance a subtle bug will be introduced as they mean exactly same thing, just added compliance to c++20.

BR,
Lance

PS: you probably understand my approach fully. but let me explain it once more.

Context:
we have around 120ish [=] lambda capture in u++ source tree, majority of which should be changed to [=,this] from c++20 onwards. Unfortunately [=,this] is not valid pre-c++20. We want a way to make both worlds happy.

Conditional Macro: one apparent approach is to use a macro that expands to [=] with std = pre-c++20 and [=, this] when std>=c++20. If we do it properly, no bug will be introduced because of this: they are functionally equivalent.

Now suppose we have such a macro named MY_MACRO, which will be expanded to = or =,this, depending on c++ standard used.

Recommended Procedure
1. Do "Replace in Files" for all files under $UPPSRC, replace all occurences of [=] with [MY_MARCO]

2. Open a less involving package to fix the cases where no `this` were captured originally. The one I used is <examples/Color>. F7 to compile it, with -std=c++20, preferably in debug mode to save time. There will be like 3-4 cases where we have wrongfully replaced [=] with [=,this], locate them, change back to [=]. Now the bulk of jobs are done;

3. Open package `theide`, do the same thing as in step 2. We will encounter 2 other cases where we have wrongfully made the replacement. Fix them, theide will compile fine;

4. We can do a buildall on the u++ src tree(I remember we have something like that), then we can fix all such wrongful replacements at once. Or we can leave it until it's be compiled and reported by users.

5. We have a clean uppsrc that's c++-version-smart on existing lambda captures.

[Updated on: Tue, 20 December 2022 00:38]

Report message to a moderator

Re: 2022(?).2 beta [message #59391 is a reply to message #59382] Tue, 20 December 2022 00:19 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1363
Registered: December 2006
Ultimate Contributor
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 Smile


Regards,
Novo
Re: 2022(?).2 beta [message #59392 is a reply to message #59391] Tue, 20 December 2022 00:48 Go to previous message
Lance is currently offline  Lance
Messages: 536
Registered: March 2007
Contributor
Novo wrote on Mon, 19 December 2022 18:19
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 Smile


ok, they are not that old.

My point is, say, one day, Mirek decides c++20 is stable enough to switch to, and c++14 support will be abandoned at the same time. Do you expect you undoubtedly have the same judgement on the stability of c++20? And you will be ready to make the move simultaneously? If your answers to both questions are yes and significantly most users also agree, then disable-warning is the surest way to take.
Previous Topic: New Assist features
Next Topic: 2022.3rc3
Goto Forum:
  


Current Time: Thu Jun 20 16:53:59 CEST 2024

Total time taken to generate the page: 0.01932 seconds