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 #59324 is a reply to message #59249] Wed, 14 December 2022 12:56 Go to previous messageGo to next message
pvictor is currently offline  pvictor
Messages: 67
Registered: December 2015
Member
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
Re: 2022(?).2 beta [message #59325 is a reply to message #59324] Wed, 14 December 2022 14:04 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13980
Registered: November 2005
Ultimate Member
pvictor wrote on Wed, 14 December 2022 12:56
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


Logs hopefully removed.
Re: 2022(?).2 beta [message #59326 is a reply to message #59316] Wed, 14 December 2022 14:05 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13980
Registered: November 2005
Ultimate Member
zsolt wrote on Tue, 13 December 2022 17:39
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 


.icpp assist should be now fixed.
Re: 2022(?).2 beta [message #59343 is a reply to message #59326] Sun, 18 December 2022 05:07 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 527
Registered: March 2007
Contributor
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. I am not sure if changing affected code to get rid of all such warnings will affect c++14 compliance but it's easy to make both worlds(or maybe all 3 worlds if we want to refer to c++17 and c++20 separately) happy anyways.

With MSVC, it is a different story. It complains in many cases like
    return some_condition ? SomeString : "Some ASCIIZ String";


These, though tedious, are easy to fix. I am no language lawyer, cannot tell which of MSVC and GCC/CLANG is/are correct here. But MSVC changes its behaviour from accepting it in C++14 to rejecting it in C++17 and beyond may tell something. Anyway it's not hard to make all worlds happy by just a little bit more keystrokes.

There are some more errors when compiling TheIDE with MSVC (mine is MSBT 2019 I believe) and std set to C++20. Another one is caused by Upp::Moveable::AssertMovealbe0 or something like that.

I mainly use CLANG now but I feel more assured if my code compiles fine on Ubuntu with GCC & CLANG, and on Windows with MS c++ compiler. I don't know if other users think this kind of check has some value, but it likely will be welcomed if a user can use u++ with more recent standard if he/she wishes(so that he/she can embrace utilities like constexpr-if and concept), and with the compiler he/she choose (one of the 3 major), while the bulk of U++ is in c++14 and be backward compatible.

Correction and some detailed error message:
1. The MSVC I used is MSBT22x64
2. The error message with AssertMoveable0 is like
Quote:

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



BR,
Lance

[Updated on: Sun, 18 December 2022 05:59]

Report message to a moderator

Re: 2022(?).2 beta [message #59344 is a reply to message #59343] Sun, 18 December 2022 13:26 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13980
Registered: November 2005
Ultimate Member
Lance wrote on Sun, 18 December 2022 05:07
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.


You can have one or another. It looks like

[=, this] {}; // until C++20: Error: this when = is the default

which supercomplicates the stuff everywhere unfortunately. So this change will have to wait a couple of years it seems.
Re: 2022(?).2 beta [message #59346 is a reply to message #59344] Sun, 18 December 2022 14:48 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 527
Registered: March 2007
Contributor
Hi Mirek:

Thank you for your attention to this matter.

The following macro will perfectly pacify both GCC and CLANG.

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


And when using it
void ColorWindow::Paint(Draw& draw)
{
    auto f = [= CAPTURETHISBYVALUE]{ auto v = GetData(); };
    draw.DrawRect(GetSize(), White());
    auto v = f();
        ...
}


It should be easy to add support for MSVC similarly too.

This way, we only care that the U++ library can compiles with std=c++14, std=c++17, std=c++20 or later std. Whether a u++ library user decide to follow the practice so that his/her code is also multiple c++ standards compatible, or simply choose one of the standard to embrace, is not a concern of u++ library developers (like you and Klugier).

The philosophy here is: u++ can choose a stable and well supported c++ standard to embrace, but it should not limit or discourage its users from trying later standard. IMHO, comparing to package-wise c++ standard selection options(it will certainly confuse assist++ if at all doable), this kind of fix in the U++ library level is less painful.

BR,
Lance

PS:

Or probably even easier.
#if __cplusplus > 201703L
#    define CAPBYVALUETHIS =,this
#else
#    define CAPBYVALUETHIS =
#endif


Then do a find in files and replace from uppsrc root, it's almost done. I figure there are <=2 occassioins where [=] are not within a member function thus [=,this] is invalid which need be fixed after the find and replace.

[Updated on: Sun, 18 December 2022 15:30]

Report message to a moderator

Re: 2022(?).2 beta [message #59347 is a reply to message #59346] Sun, 18 December 2022 15:41 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1077
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
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 Smile

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 Smile

Klugier


U++ - one framework to rule them all.
Re: 2022(?).2 beta [message #59348 is a reply to message #59326] Sun, 18 December 2022 16:08 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 698
Registered: December 2005
Location: Budapest, Hungary
Contributor
mirek wrote on Wed, 14 December 2022 14:05

.icpp assist should be now fixed.

Thank you!
Re: 2022(?).2 beta [message #59349 is a reply to message #59347] Sun, 18 December 2022 18:50 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 527
Registered: March 2007
Contributor
Klugier wrote on Sun, 18 December 2022 09:41
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 Smile

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 Smile

Klugier


Hi Klugier:

Unfortunately it doesn't work. In a lot of occassions [=] captures more than just [this].

I will try my approach and report the result.

Regards,
Lance

PS:
It works perfectly in GCC/CLANG on Ubuntu.

Here is what I did:
1. Insert the definition of CAP_BY_VALUE_WITH_THIS after #include <utility>
#if __cplusplus > 201703L
#    define CAP_BY_VALUE_WITH_THIS = ,this
#else
#    define CAP_BY_VALUE_WITH_THIS =
#endif


2. Do a Replace in Files..., replace all occurrences of [=] with CAP_BY_VALUE_WITH_THIS, for all files under the folder uppsrc;

3. Compile some examples, eg. <Examples/Color>, fix all errors due to wrongful replacement in step 2. I believe there are 3-4 such occurrences.

4. Compile TheIDE, 2 more errors pop up. In <ide/Builders/Install.cpp>, replace
	auto Fix = [CAP_BY_VALUE_WITH_THIS](const char *s) {

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

And in <ide/Designers/HexView.cpp>, Ln 98, replace
	RegisterGlobalSerialize("FileHexViewPos", [CAP_BY_VALUE_WITH_THIS](Stream& s) {

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


and ide is ready to be built. Of course I fix problems as GCC complains to me. As I did nothing in between, any errors that stopped compiling would mean I need to replace [CAP_BY_VALUE_WITH_THIS] with [=] (where there is no `this` at all).

BR,
Lance

[Updated on: Sun, 18 December 2022 20:21]

Report message to a moderator

Re: 2022(?).2 beta [message #59350 is a reply to message #59249] Sun, 18 December 2022 19:46 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
@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 Wink )
Re: 2022(?).2 beta [message #59351 is a reply to message #59350] Sun, 18 December 2022 19:53 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13980
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.

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


OK, if rc1 fails, I will look into this Smile
Re: 2022(?).2 beta [message #59352 is a reply to message #59346] Sun, 18 December 2022 19:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13980
Registered: November 2005
Ultimate Member
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
Re: 2022(?).2 beta [message #59354 is a reply to message #59352] Sun, 18 December 2022 20:08 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 527
Registered: March 2007
Contributor
mirek wrote on Sun, 18 December 2022 13:55
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

Hi Mirek:

It doesn't. But this technique is widely used in standard library implementations. It's a necessary evil (if not in this particular situation where you can opt to turn off warnings).

For example, many std::vector member functions are now constexpr modified, what's a better way to provide cross-c++-standard support in this situation? I am not sure if there is one, but the one in practice is a MACRO that will vanish in a lower language/library standard.

BTW, there is no guarantee it will not be promoted to an error in some later days when U++ probably is in c++17. So chance is the problem is merely deferred instead of being solved by disabling warnings on it.

BR,
Lance

[Updated on: Sun, 18 December 2022 20:25]

Report message to a moderator

Re: 2022(?).2 beta [message #59355 is a reply to message #59354] Sun, 18 December 2022 21:54 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1077
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
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...

In accordance to table on nextptr article the only valid capture this that works with all standards is capture this as [this] and [&]:
index.php?t=getfile&id=6728&private=0
As, in my previous post, we should follow that approach. It won't be easy, but doable for our code base within 1-2 days. Whenever, we need to pass additional variable it should be pass explicitly [this, x] etc.. Alternatively, we can convert [=] to [&] as it is valid too. However, it might caused some unwanted bugs...

Using global macro is not an option to me as I wrote in my previous post.

Klugier
  • Attachment: Table.png
    (Size: 76.41KB, Downloaded 211 times)


U++ - one framework to rule them all.

[Updated on: Sun, 18 December 2022 21:59]

Report message to a moderator

Re: 2022(?).2 beta [message #59356 is a reply to message #59355] Sun, 18 December 2022 22:33 Go to previous messageGo to next message
zsolt is currently offline  zsolt
Messages: 698
Registered: December 2005
Location: Budapest, Hungary
Contributor
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).
Re: 2022(?).2 beta [message #59357 is a reply to message #59355] Sun, 18 December 2022 22:35 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 527
Registered: March 2007
Contributor
Hello Klugier,

I can confirm that all U++ currently uses are [=].

Out of which, some(I expect it to be a total of less than 10) need to remain as [=] prior or beyond c++20; while the majority rest can be changed to [=,this] to make the code compliant to c++20 (which, unfortunately will displease prior c++20 world).

I cannot really tell how many out of the second lot can be replaced by [this] without creating noise when they need more than just `this`, eg, also capturing some local variables, etc.

Do you mean to differentiate from the second lot the ones that actually require some other variables, and list each of them manually so that prior and beyond c++20 worlds will be happy with their capture lists?

It certainly is doable, but it might be a bit too much effort, IMHO, just for the sake of avoiding an unwanted MACRO.

Otherwise the quickest & dirtiest solution is to change all [=] to [&], with possibly undesired side-effects.

It's totally up to you and Mirek though. We will be happy with a standard-tolerant U++ library however achieved Smile

BR,
Lance

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

Report message to a moderator

Re: 2022(?).2 beta [message #59358 is a reply to message #59356] Sun, 18 December 2022 22:55 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 527
Registered: March 2007
Contributor
zsolt wrote on Sun, 18 December 2022 16: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).


Hello Zsolt:

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

BR,
Lance
Re: 2022(?).2 beta [message #59359 is a reply to message #59299] Sun, 18 December 2022 23:03 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
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.
Re: 2022(?).2 beta [message #59360 is a reply to message #59359] Sun, 18 December 2022 23:14 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 527
Registered: March 2007
Contributor
mdelfede wrote on Sun, 18 December 2022 17:03
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.


Hi mdelfede:

Astyle's last activity is probably a few years old. Like I mentioned before, formatting code with bitfields with the old formatting utility is a disaster. It takes a lot of work to bring bitfields in order every time one formats <CtrlCore/CtrlCore.h>. bitfields is something c++ inherited from old c, present since day 1 of the language. It's surprising that this actually happened.

Go with the big guy, here llvm-org/LibFormat, is a more future proof decision.

BR,
Lance

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

Report message to a moderator

Re: 2022(?).2 beta [message #59361 is a reply to message #59358] Sun, 18 December 2022 23:29 Go to previous messageGo to previous message
zsolt is currently offline  zsolt
Messages: 698
Registered: December 2005
Location: Budapest, Hungary
Contributor
Lance wrote on Sun, 18 December 2022 22:55


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

BR,
Lance


Yes, you are right. I never used [*this] and didn't know that is gives a copy of the object. Always learning Smile

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.
Previous Topic: New Assist features
Next Topic: 2022.3rc3
Goto Forum:
  


Current Time: Tue May 28 10:02:16 CEST 2024

Total time taken to generate the page: 0.01805 seconds