C++17 / C++20: Add an implementation for std::filesystem

[winspool]

Just an enhancement request to remember this project link, which I found today:

https://github.com/gulrak/filesystem

License: MIT implemented in: C++11 (Features of newer c++ versions are used) used test framework: catch2

[LowLevelMahn]

@winspool: can you explain your intention a little, all these issues/pulls for using Open Watcom for more recent C++ projects or non supported platforms

i always see the Open Watcom Compiler as a good manicured legacy thing - the compiler can hardly reach the diagnostic or optimization power of MSVC,clang or gcc - due to missing man-power - even lifting the C++ compiler to support C++11 is (to my understanding) a huge step

[winspool]

@winspool: can you explain your intention a little, all these issues/pulls for using Open Watcom for more recent C++ projects or non supported platforms

This issue here is just to remember the URL for an MIT implementation, which I found on github.

I want to use OpenWatcom with my own projects, in addition to tcc or gcc/clang.

The greatest advantage of OpenWatcom over gcc/glibc/libstdc++ is the total size of the program + runtime. ( Static linking with gcc produce really big files )

My ADSL Router is a mips machine. I did some things with my previous Router, but i didn't touches the current one yet.

And with cfarm (gcc compiler farm), i have also access to many other machines for testing.

I was hoping for a superfast clean build of OpenWatcom on the cfarm machines, but this does not work as expected:

• My old i7 laptop (2 core/4 threads)(12GB RAM) needs about 45-48 minutes (without building the docs)

• A cfarm machine (x86_64, 2 sockets, 12 core, 24 thread) (94 GB RAM) needed 38 min. Only a small speedup...

• I was hoping for a clean build in <5 min

some cfarm linux machines related to OpenWatcom ppc & mips are:

• ibm power10 (ppc64le): 24 cores, 192 threads and 2TB RAM.
• ibm power 9 (ppc64le): 32 cores, 128 threads and 251GB RAM
• mips64 machines with 2 cores/2 threads and 1.9 GB RAM
• mips64 machines with 4 cores/4 threads and 1GB RAM

i always see the Open Watcom Compiler as a good manicured legacy thing the compiler can hardly reach the diagnostic or optimization power of MSVC,clang or gcc - due to missing man-power - even lifting the C++ compiler to support C++11 is (to my understanding) a huge step

i tried to improve OpenWatcom, but failed so often, that i decided to take a break from submitting pull requests for a while.

tcc is just a c compiler/assembler/linker/ar/dll def tool, but in a single executable (and a runlime lib for support functions, similar to libgcc) but far more advanced as OpenWatcom in many areas:

compilation speed: a goal of tcc std: mostly C99, partial C11, a few C23 arch: i386, x86_64, arm, aarch64, riscv64 os: linux, windows, macoOS, [Open|Free|Net]BSD, Android c runtime: gnu glibc, musl libc, uclibc, msvcrt.dll

tcc handles many gcc command line args and supports some gcc extensions (attribute, asm).

[LowLevelMahn]

This issue here is just to remember the URL for an MIT implementation, which I found on github.

in think OpenWatcom is very far away from C++11 support (which is a complete differen beast compared to C11)

The greatest advantage of OpenWatcom over gcc/glibc/libstdc++ is the total size of the program + runtime. ( Static linking with gcc produce really big files )

so the runtime of Open Watcom is just smaller? are we talking about 50% smaller or 5%?

My ADSL Router is a mips machine. I did some things with my previous Router, but i didn't touches the current one yet.

i thought there is only MIPS support with the Watcom Assembler available, can the compiler emit MIPS code? and if not - it will take many many month of hard work/testing to get it into it

And with cfarm (gcc compiler farm), i have also access to many other machines for testing. I was hoping for a superfast clean build of OpenWatcom on the cfarm machines, but this does not work as expected:

no idea what you try to tell and why cfarm is relevant - how many times per day your need to rebuild the compiler - why is the building time of the compiler relevant in any form?

tcc is just a c compiler/assembler/linker/ar/dll def tool, but in a single executable (and a runlime lib for support functions, similar to libgcc) but far more advanced as OpenWatcom in many areas:

compilation speed: a goal of tcc std: mostly C99, partial C11, a few C23 arch: i386, x86_64, arm, aarch64, riscv64 os: linux, windows, macoOS, [Open|Free|Net]BSD, Android c runtime: gnu glibc, musl libc, uclibc, msvcrt.dll

tcc handles many gcc command line args and supports some gcc extensions (attribute, asm).

yeah still C is a complete different thing then C++

C99 or C11 support is 100 times easier to reach then C++11 conformity (its more or less a different language compared to C++98/03) - lambdas, constexpr, variadic templates, this is huge and the C versions are only small extensions compared to that could it be that you mistaken C11 with C++11?

and TCC is in no way compareable to the optimization that gcc/clang does so all the code behinde is just way more simple but TCC is nice - im using libtcc for runtime code compilation of math expressions :)

[winspool]

This issue here is just to remember the URL for an MIT implementation, which I found on github. in think OpenWatcom is very far away from C++11 support (which is a complete differen beast compared to C11)

Yes, but i didn't check yet, which C++11 features are used by the linked project and how much is missing in wpp

The greatest advantage of OpenWatcom over gcc/glibc/libstdc++ is the total size of the program + runtime. ( Static linking with gcc produce really big files )

so the runtime of Open Watcom is just smaller? are we talking about 50% smaller or 5%?

a main with: puts("Hello World!"); ow: 8053 gcc -static: 702252

a main with: std::cout << "Hello World!" << std::endl ow: 13683 g++ -static: 1848618

results are from 'size hello_c' or 'size cout_cpp'

i thought there is only MIPS support with the Watcom Assembler available, can the compiler emit MIPS code? and if not - it will take many many month of hard work/testing to get it into it The compiler can produce object files , but the runtime library is missing.

how many times per day your need to rebuild the compiler - why is the building time of the compiler relevant in any form?

I do a clean build before i submit a patch for every change, with is more than a trivial typo fix.

tcc is just a c compiler/assembler/linker/ar/dll def tool, but in a single executable (and a runlime lib for support functions, similar to libgcc)

yeah still C is a complete different thing then C++ C99 or C11 support is 100 times easier to reach then C++11 conformity (its more or less a different language compared to C++98/03) - lambdas, constexpr, variadic templates, this is huge and the C versions are only small extensions compared to that could it be that you mistaken C11 with C++11?

I know the difference and the emense work needed for supporting a newer c++ standard

and TCC is in no way compareable to the optimization that gcc/clang does so all the code behinde is just way more simple

That's the goal of tcc. Simple codebase with a huge compilation speed. Optimizations are minimal:

• Merging constant values
• code supression in a few situations

[LowLevelMahn]

This issue here is just to remember the URL for an MIT implementation, which I found on github. in think OpenWatcom is very far away from C++11 support (which is a complete differen beast compared to C11)

Yes, but i didn't check yet, which C++11 features are used by the linked project and how much is missing in wpp

im using that library in two commercial projects - short said: way too much and even if we got std::filesystem to work - we still do not have a full C++11 compiler - why should someone use such compiler - half-cripple implemented standards have a long angry history in C++ development - no one will cope with that if there are alternatives

so the runtime of Open Watcom is just smaller? are we talking about 50% smaller or 5%?

a main with: puts("Hello World!"); ow: 8053 gcc -static: 702252 a main with: std::cout << "Hello World!" << std::endl ow: 13683 g++ -static: 1848618 results are from 'size hello_c' or 'size cout_cpp'

how can the static builds of OW be that small? does OW not use the standard lib but its own?

i thought there is only MIPS support with the Watcom Assembler available, can the compiler emit MIPS code? and if not - it will take many many month of hard work/testing to get it into it

so we talk again about years of development

I do a clean build before i submit a patch for every change, with is more than a trivial typo fix.

i don't think that the build times can be reduced (in ages) any form look at the other big ones - they take ages to build because of the code complexity - tcc is just not compareable (with its tiny-obfuscation-contest origin)

yeah still C is a complete different thing then C++ C99 or C11 support is 100 times easier to reach then C++11 conformity (its more or less a different language compared to C++98/03) - lambdas, constexpr, variadic templates, this is huge and the C versions are only small extensions compared to that could it be that you mistaken C11 with C++11?

I know the difference and the emense work needed for supporting a newer c++ standard

we talk about years of time - more or less a complete rewrite of many parts of the C++ compiler - and i don't think thats even possible with the given man-power - gcc,clang,MSVC took around 2-4 years to get fully C++11 compatible, with money and man-power like hell in comparison

[joncampbell123]

May I suggest something?

Apparently Open Watcom's linker, at least on Linux, can handle both the OMF/COFF it uses internally as well as the ELF object files generated by GCC, and I think it should be possible for calls from one to link into the other provided the calling convention is set up correctly. Obviously if you do this the linker must be tasked to generate a 32-bit executable and GCC should be compiled with -march=i386 or other appropriate 32-bit -march option, of course.

Until Open Watcom better implements these features, perhaps as an intermediate support step, a shim could be developed to allow the GCC side to use some or most std:: libraries and headers and link into an executable with Open Watcom. It would allow you to use some C++11 and C++14 features through GCC that way.

At the very minimum the DOSLIB project has an example of using Open Watcom and GCC together to try to write a VxD driver for Windows 3.1 in C. https://github.com/joncampbell123/doslib/tree/master/windrv/dosboxpi/win9x

@jmalak Think this is feasible given someone with enough interest to develop this way?