|
|
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 message Go to previous message](theme/default/images/up.png) ![Go to next message Go to next message](theme/default/images/down.png) |
![](https://www.ultimatepp.org/forums/images/custom_avatars/1517.jpg) |
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 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 #59378 is a reply to message #59350] |
Mon, 19 December 2022 12:20 ![Go to previous message Go to previous message](theme/default/images/up.png) ![Go to next message Go to next message](theme/default/images/down.png) |
![](https://www.ultimatepp.org/forums/images/custom_avatars/3.png) |
mirek
Messages: 14003 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 message Go to previous message](theme/default/images/up.png) ![Go to next message Go to next message](theme/default/images/down.png) |
Lance
Messages: 542 Registered: March 2007
|
Contributor |
|
|
mirek wrote on Mon, 19 December 2022 04:08Lance wrote on Mon, 19 December 2022 00:41Hello 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 message Go to previous message](theme/default/images/up.png) ![Go to next message Go to next message](theme/default/images/down.png) |
Lance
Messages: 542 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. 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 #59390 is a reply to message #59389] |
Mon, 19 December 2022 23:54 ![Go to previous message Go to previous message](theme/default/images/up.png) ![Go to next message Go to next message](theme/default/images/down.png) |
Lance
Messages: 542 Registered: March 2007
|
Contributor |
|
|
mirek wrote on Mon, 19 December 2022 17:35Lance wrote on Mon, 19 December 2022 23:14mirek wrote on Mon, 19 December 2022 14:22Lance wrote on Mon, 19 December 2022 19:10And 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 #59392 is a reply to message #59391] |
Tue, 20 December 2022 00:48 ![Go to previous message Go to previous message](theme/default/images/up.png) |
Lance
Messages: 542 Registered: March 2007
|
Contributor |
|
|
Novo wrote on Mon, 19 December 2022 18:19Lance 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](images/smiley_icons/icon_smile.gif)
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.
|
|
|
Goto Forum:
Current Time: Sun Sep 01 06:55:32 CEST 2024
Total time taken to generate the page: 0.00607 seconds
|
|
|