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