Hello Mirek,

It's good to hear that the new release is on the radar. For the C++17 I repeated it many times that we should adopt it. Probably starting in 2020, but finally we have it

Threads with C++17:
- https://www.ultimatepp.org/forums/index.php?t=msg&th=111 41&goto=54751&
- https://www.ultimatepp.org/forums/index.php?t=msg&th=117 72&goto=58266&#msg_58266

Klugier

Hi Mirek,

Looking forward to the release...

Meanwhile, can you take a look at the MSC compilation (MSBT22x64 in my case):

C:\upp-git\upp.src\uppsrc\Core\Topt.h(168): error C7525: inline variables require at least '/std:c++17'
C:\upp-git\upp.src\uppsrc\Core\Topt.h(172): error C7525: inline variables require at least '/std:c++17'
C:\upp-git\upp.src\uppsrc\Core\Tuple.h(170): error C7525: inline variables require at least '/std:c++17'
C:\upp-git\upp.src\uppsrc\Core\Tuple.h(174): error C7525: inline variables require at least '/std:c++17'
C:\upp-git\upp.src\uppsrc\Core\Tuple.h(179): error C7525: inline variables require at least '/std:c++17'
C:\upp-git\upp.src\uppsrc\Core\Complex.h(58): error C7525: inline variables require at least '/std:c++17'

EDIT: Adding '/std:c++17' to Common options in build methods for MSC helped here.

Best regards,

Tom

A compiler warning popped up on 32-bit MSBT22:

C:\upp-git\upp.src\uppsrc\Core\FileMapping.h (18): warning C4244: 'argument': conversion from 'Upp::int64' to 'size_t', possible loss of data

BTW: which condition flags should I use to include specific libraries only for 64-bit targets in TheIDE Package organizer? E.g. WIN64 or _WIN64 does not seem to work here.

Best regards,

Tom

Tom1 wrote on Mon, 09 September 2024 15:07

A compiler warning popped up on 32-bit MSBT22:

C:\upp-git\upp.src\uppsrc\Core\FileMapping.h (18): warning C4244: 'argument': conversion from 'Upp::int64' to 'size_t', possible loss of data

Thanks, fixed.

Quote:

BTW: which condition flags should I use to include specific libraries only for 64-bit targets in TheIDE Package organizer? E.g. WIN64 or _WIN64 does not seem to work here.

Best regards,

Tom

That is suprisingly complicated problem... Build method actually does not really know / care about that. And frankly, so far, there were no specific library names for 64-bit, usually in win32, they are just placed to different folders.

If you think this is really worth fixing, the simple way is to put something into Common fixed flags in the build method. I can do that in automatic build method setup... I guess placing "M32" to 32-bit build methods should do the job.

Mirek

mirek wrote on Tue, 10 September 2024 15:40

Tom1 wrote on Mon, 09 September 2024 15:07

A compiler warning popped up on 32-bit MSBT22:

C:\upp-git\upp.src\uppsrc\Core\FileMapping.h (18): warning C4244: 'argument': conversion from 'Upp::int64' to 'size_t', possible loss of data

Thanks, fixed.

Quote:

BTW: which condition flags should I use to include specific libraries only for 64-bit targets in TheIDE Package organizer? E.g. WIN64 or _WIN64 does not seem to work here.

Best regards,

Tom

That is suprisingly complicated problem... Build method actually does not really know / care about that. And frankly, so far, there were no specific library names for 64-bit, usually in win32, they are just placed to different folders.

If you think this is really worth fixing, the simple way is to put something into Common fixed flags in the build method. I can do that in automatic build method setup... I guess placing "M32" to 32-bit build methods should do the job.

Mirek

Hi,

Some external libraries (and DLLs) I use come with just different names for 32/64 bit variants. It would be helpful to have a way to use e.g. "WIN32 M32" or "WIN32 !M32" to link with the correct variant and avoid linking errors.

Best regards,

Tom

Mirek,

I started to have trouble seeing some of the TheIDE packages' names properly. Then I noticed that the Dark theme coloring has changed.

Especially Draw, PdfDraw and all <aux> packages are really hard to read for me. The screenshot is from Linux Mint using dark theme, but I'm having the same issue on Windows dark theme too, although the darker background helps there a little bit.

(I must remind you that I have red-green colorblindness, like 8 % of European men do. Not sure if this contributes to the issue I'm having now with those texts. To simulate red-green colorblindness to the people with normal color perception, try to flatten your red color channel to something like 0.. 10 % of the original and see how your GUI looks. Might be a good idea to do this test with any GUI design to ensure accessibility for guys like me.)

Best regards,

Tom

EDIT: Sorry, I seem to have misplaced this posting... Just found there's a thread for this at https://www.ultimatepp.org/forums/index.php?t=msg&th=123 29&goto=60794&#msg_60794 , so feel free to move this posting to that thread.

It probably would not hurt to have a M32 and/or M64 flags pre-defined for the corresponding builders to make this work out of the box.

...

For now, the changed to DarkTheme are rolled back. It will need some more research I guess...

double DarkTheme_c[3] = { 0.3, 0.5, 0.2 };
int    DarkTheme_middle = 155;

Quote:

It probably would not hurt to have a M32 and/or M64 flags pre-defined for the corresponding builders to make this work out of the box.

Done, but in the end I decided to change it to CPU_32.

Mirek

Another issue... On Linux Mint and UHD 4k display the console output (when compiling) is using a very tiny little font... And even if I zoom it in using Ctrl+Wheel, on next startup of TheIDE it has shrinked again back. All other panels in TheIDE seem to follow the UHD sizing.

// Tom

Tom1 wrote on Thu, 12 September 2024 11:48

Another issue... On Linux Mint and UHD 4k display the console output (when compiling) is using a very tiny little font... And even if I zoom it in using Ctrl+Wheel, on next startup of TheIDE it has shrinked again back. All other panels in TheIDE seem to follow the UHD sizing.

// Tom

What is in Setup/Settings? (Maybe screenshot...)

Also, TheIDE font sizes are set once on the very first start. Perhaps you started in HD and only later switched to UHD ?

Nightly build is stopped.

it seams that the builder host need update in order to use C++17

Thanks.

mirek wrote on Fri, 13 September 2024 20:42

Tom1 wrote on Thu, 12 September 2024 11:48

Another issue... On Linux Mint and UHD 4k display the console output (when compiling) is using a very tiny little font... And even if I zoom it in using Ctrl+Wheel, on next startup of TheIDE it has shrinked again back. All other panels in TheIDE seem to follow the UHD sizing.

// Tom

What is in Setup/Settings? (Maybe screenshot...)

Also, TheIDE font sizes are set once on the very first start. Perhaps you started in HD and only later switched to UHD ?

It's entirely possible that it was mixed up on the very first start. Cannot check right now as the issue surfaced at the office. My home installation seems to work just fine. Also, I did not know that changing console font by Ctrl+Wheel is not persistent. (In the code editor it seems to be.)

I guess this can be considered solved. I will let you know next week if this is not the case once I check my office setup.

Thanks and best regards,

Tom

First I tried to fix it by using 'Restore defaults' and then 'Close'. This caused TheIDE to crash on every attempt. Then I selected the same font sizes manually and the values were successfully updated after close. So, there must be some issue with 'Restore defaults'.
Tom

Tom1 wrote on Mon, 16 September 2024 10:21

First I tried to fix it by using 'Restore defaults' and then 'Close'. This caused TheIDE to crash on every attempt. Then I selected the same font sizes manually and the values were successfully updated after close. So, there must be some issue with 'Restore defaults'.
Tom

Should be now fixed.

Thank you mirek for all the hard work!

I have a question. In CoWork.h, line 186, etc,

		void Do(Function&& f, Args&&... args) { co.Do([=]() { ret = f(args...); }); }

shouldn't it be something like

void Do(Function&& f, Args&&... args) { co.Do([=]() { ret = f(std::forward<Args>(args)...); }); }

for perfect forwarding to actually work?

#include <Core/Core.h>

using namespace Upp;

CONSOLE_APP_MAIN
{
	auto a = Async([](int n) -> double {
		double f = 1;
		for(int i = 2; i <= n; i++)
			f *= i;
		return f;
	}, 100);
}

The current upp codebase works fine with std=c++20, except the warning: implicit capture of 'this' with a capture default of '=' is deprecated [-Wdeprecated-this-capture] issue. This can be fixed without much effort and without affecting the aimed standard of c++17. I was wondering if you would consider accepting it if I make a pull request for that.

Thank you mirek for all the hard work!

I have a question. In CoWork.h, line 186, etc,

		void Do(Function&& f, Args&&... args) { co.Do([=]() { ret = f(args...); }); }

shouldn't it be something like

void Do(Function&& f, Args&&... args) { co.Do([=]() { ret = f(std::forward<Args>(args)...); }); }

for perfect forwarding to actually work?

Lance wrote on Tue, 17 September 2024 17:34

The current upp codebase works fine with std=c++20, except the warning: implicit capture of 'this' with a capture default of '=' is deprecated [-Wdeprecated-this-capture] issue. This can be fixed without much effort and without affecting the aimed standard of c++17. I was wondering if you would consider accepting it if I make a pull request for that.

Nope, cannot do that with C++17. Requires [=, this], which is C++20 feature. And, frankly, while [=] capturing 'this' is perhaps confusing, everybody is used to it by now so to require longer code for the same thing is at this point is kind of pointless... But when we go C++20, we shall do it anyway. In 3 years...

c++23 however will break many String interfaces.

/home/lance/upp.src/uppsrc/Core/String.h (556): error: non-const lvalue reference to type 'String' cannot bind to a temporary of type 'String'

force_inline String& operator<<(String&& s, const char *x)
{
	s.Cat(x, strlen__(x));
	return s;
}

with clang
when compiler flags set to -std=c++23 -Wno-logical-op-parentheses

we have multiple errors with messages like
Quote:

/home/lance/upp.src/uppsrc/Core/String.h (556): error: non-const lvalue reference to type 'String' cannot bind to a temporary of type 'String'

And the relevant source is

force_inline String& operator<<(String&& s, const char *x)
{
	s.Cat(x, strlen__(x));
	return s;
}

Now c++23 is rejecting code like these.

/home/lance/upp.src/uppsrc/Core/Stream.cpp (1226): error: no viable conversion from returned value of type 'StringBuffer' to function return type 'String'

String LoadFile(const char *filename) {
	FindFile ff(filename);
	if(ff && ff.IsFile()) {
	#ifdef PLATFORM_POSIX
		if(ff.GetLength() == 0) { // handle special cases like /proc/...
			int fd = open(filename,O_RDONLY);
			if(fd >= 0) {
				const int CHUNK = 32768;
				StringBuffer s;
				for(;;) {
					int n = s.GetCount();
					s.SetCount(n + CHUNK);
					int len = read(fd, ~s + n, CHUNK);
					if(len != CHUNK) {
						if(len >= 0)
							s.SetCount(n + len);
						close(fd);
						return s;   <---This Line

Hi Mirek,

Would it be possible to clean up these annoying warnings?

uppsrc/RichText/ParaPaint.cpp (468): warning: unused variable 'pe' [-Wunused-variable]
uppsrc/ide/IconDes/Event.cpp (102): warning: unused variable 'c' [-Wunused-variable]
uppsrc/ide/IconDes/IconDes.cpp (130): warning: unused variable 'isz' [-Wunused-variable]
uppsrc/ide/IconDes/ImlFile.cpp (272): warning: unused function 'PutOctalString' [-Wunused-function]
uppsrc/ide/SelectPkg.cpp:661:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation]
  661 |                 for(int i = 0; i < dlg.list.GetCount(); i++)
      |                 ^
uppsrc/ide/SelectPkg.cpp:658:2: note: previous statement is here
  658 |         if(n)
      |         ^
1 warning generated.

Thank you, Radek