Hi Klugier and Mirek,

I agree. Tried to change the #if on line 219 of Ops.h:

#if defined(__SIZEOF_INT128__) && (__GNUC__ > 5 || __clang_major__ >= 5) && !defined(CPU_ARM)

Adding "&& !defined(CPU_ARM)", in the end of the line, enabled successful compilation on current Raspberry OS (64-bit). However, I do not know if this change would cause issues on some other platform.

Best regards,

Tom

Hi Mirek,

Good point. Your code compiles and seems to work fine on Raspberry. I'm just wondering if CPU_X86 is defined for 64-bit AMD architecture, or should you include CPU_AMD64 flag too?

Best regards,

Tom

Hi Mirek,

With the commit d3ef160f104a181eba9aed10173762382838f39f (TabBar: ConfirmCloseSome) I'm not able to compile TheIde. I got error

/Develop/upp/./uppsrc/Core/Function.h:17:50: error: no matching function for call to object of type '(lambda at /Develop/upp/uppsrc/TabBar/TabBar.cpp:334:21)'
                virtual Res Execute(ArgTypes... args) { return fn(args...); }
                                                               ^~
/Develop/upp/./uppsrc/Core/Function.h:19:3: note: in instantiation of member function 'Upp::Function<bool (Upp::ValueArray)>::Wrapper<(lambda at /Develop/upp/uppsrc/TabBar/TabBar.cpp:334:21)>::Execute' requested here
                Wrapper(F&& fn) : fn(pick(fn)) {}
                ^
/Develop/upp/./uppsrc/Core/Function.h:56:57: note: in instantiation of member function 'Upp::Function<bool (Upp::ValueArray)>::Wrapper<(lambda at Develop/upp/uppsrc/TabBar/TabBar.cpp:334:21)>::Wrapper' requested here
        template <class F> Function(F fn)          { ptr = new Wrapper<F>(pick(fn)); }
                                                               ^
/Develop/upp/uppsrc/TabBar/TabBar.cpp:334:21: note: in instantiation of function template specialization 'Upp::Function<bool (Upp::ValueArray)>::Function<(lambda at /Develop/upp/uppsrc/TabBar/TabBar.cpp:334:21)>' requested here
        ConfirmCloseSome = []() { return true; };
                           ^
Develop/upp/uppsrc/TabBar/TabBar.cpp:334:21: note: candidate function not viable: requires 0 arguments, but 1 was provided
Develop/upp/uppsrc/TabBar/TabBar.cpp:334:21: note: conversion candidate of type 'bool (*)()'

clang -v
Ubuntu clang version 12.0.1-++20211029101322+fed41342a82f-1~exp1~20211029221816.4
Target: x86_64-pc-linux-gnu
Thread model: posix

uname -a
Linux 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

BR, Radek

pvictor wrote on Mon, 07 March 2022 18:08

mirek wrote on Sun, 06 March 2022 20:13

OK, not too much happy about this late new feature, but done... Pls check.

I've checked it on Linux.
It works OK.
Thank you.

Victor

FileSelNative works fine both in Linux and Windows.
However the public interfaces aren't the same:

           Windows                                                Linux

void Serialize(Stream& s);                              
void New();                                             
bool IsNew() const;                                     

bool Execute(bool open, const char *title = NULL);      bool Execute(bool open, const char *title = NULL);
bool ExecuteOpen(const char *title = NULL);             bool ExecuteOpen(const char *title = NULL);
bool ExecuteSaveAs(const char *title = NULL);           bool ExecuteSaveAs(const char *title = NULL);
bool ExecuteSelectDir(const char *title = NULL);        bool ExecuteSelectDir(const char *title = NULL);
String Get() const;                                     String Get() const;
void Set(const String& s);                              void Set(const String& s);
operator String() const;                                operator String() const;
void operator=(const String& s);                        void operator=(const String& s);
String operator~() const;                               String operator~() const;
void operator<<=(const String& s);                      void operator<<=(const String& s);
int GetCount() const;                                   int GetCount() const;
const String& operator[](int i) const;                  const String& operator[](int i) const;

bool GetReadOnly() const;                              
String GetActiveDir() const;                            

FileSelNative& Type(const char *name, const char *ext); FileSelNative& Type(const char *name, const char *ext);
FileSelNative& AllFilesType();                          FileSelNative& AllFilesType();
FileSelNative& ActiveDir(const String& dir);            FileSelNative& ActiveDir(const String& dir);
FileSelNative& ActiveType(int i);                       FileSelNative& ActiveType(int i);

FileSelNative& DefaultExt(const char *ext);             

FileSelNative& Multi(bool b = true);                    FileSelNative& Multi(bool b = true);

FileSelNative& ReadOnlyOption(bool b = true);           

FileSelNative& Asking(bool b = true);                   FileSelNative& Asking(bool b = true);
FileSelNative& NoAsking();                              FileSelNative& NoAsking();

                                                        FileSelNative& ShowHidden(bool b = true);

Best regards,
Victor

LLVM 14.0.0 was released several days ago.
IMHO, it makes sense to ship UPP with llvm-mingw compiler based on LLVM 14.

Hello Mirek,

I also proposed bumping C++ standard from c++14 to c++17. However, this could be done in the next release. There are a lot of risks here in context of compilation on various platforms.

Even if we do not have any features that particularly targets c++17 we should compile with that standard and our users should have access to it by default. Also, maybe this is a bug, but for MSVC we do not force any standard. It is always latest. I think it should change and we should target exactly the same standard as for GCC and CLANG.

Klugier

Novo wrote on Thu, 31 March 2022 04:10

LLVM 14.0.0 was released several days ago.
IMHO, it makes sense to ship UPP with llvm-mingw compiler based on LLVM 14.

Unfortunately:

https://github.com/mstorsjo/llvm-mingw/issues/271

mirek wrote on Sun, 03 April 2022 13:33

Novo wrote on Thu, 31 March 2022 04:10

LLVM 14.0.0 was released several days ago.
IMHO, it makes sense to ship UPP with llvm-mingw compiler based on LLVM 14.

Unfortunately:

https://github.com/mstorsjo/llvm-mingw/issues/271

I just double-checked that (added -fno-limit-debug-info to "Debug options").
Everything compiles just fine ...
The only "problem" that I see is a lot of "clang-14: warning: argument unused during compilation: '-mthreads' [-Wunused-command-line-argument]"...

P.S. I checked that on Linux.

You are right, it was my fault. Tomorrow nightly should be clang-14 (pls check)

Klugier wrote on Sun, 03 April 2022 15:43

Hello Mirek,

I also proposed bumping C++ standard from c++14 to c++17. However, this could be done in the next release. There are a lot of risks here in context of compilation on various platforms.

Even if we do not have any features that particularly targets c++17 we should compile with that standard and our users should have access to it by default. Also, maybe this is a bug, but for MSVC we do not force any standard. It is always latest. I think it should change and we should target exactly the same standard as for GCC and CLANG.

Klugier

Yeeah, I was thinking about it a lot, problem is we have so far universal package for Posixes and we are not 100% sure c++17 compliant compiler is there. I think we would need to add detection code before adding -std=c++17 to options, which is sort of complicated and quirky.

You are right, it was my fault. Tomorrow nightly should be clang-14 (pls check)

C:\upp\bin\clang\bin>clang.exe --version
clang version 11.0.0 (https://github.com/llvm/llvm-project.git 176249bd6732a8044d457092ed932768724a6f06)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:\upp\bin\clang\bin

C:\upp\bin\clang\bin>