I'd like to see the changes upstream, any plans?

Fixed up more stuff so you can do "cd src ; make CXX=clang++" to build with clang too. And took and adapted Georg Seifert's xcode proj stuff too, so it should build on macs whether you want to use xcode gui or plain make.

I just signed the cla for a pull, and as it stands, I think it does everything it claims to do (within reasons) and does not affect visual studio builds, so this can indeed be a pull.

But one reason of not creating a pull, besides the objection of signing a CLA, is issue with CLA by-pass and random crap being added by somebody else: not thinking about CLA and pulls, means I can include things like Georg's xcode stuff on merits alone (Georg may object to signing CLAs...), I can do changes like converting comments from windows encoding to utf8 - not necessary, just a conveniences to utf-8 people at the expense of inconvenience to windows encoding people; and I can object to including random people's requests to add random crap, like a cmake-based build system - I honestly do no want it, and if upstream adds such thing, I will refuse to do a pull to donate my work to be sitting next to some random crap :).

For those who want to fix warnings, do "make ... CXXFLAGS=-Wall" . I don't want to put it into the Makefile yet, as the build already have warnings without it (and those are more important and should be looked at first)

I am splitting out "no need to debate" changes as individual pulls... But for example, I don't want to take bulk formatting /cosmetic or indentation changes at this stage, and the conversions from windows encoding to utf8 in the comments I did, I would find that objectionable if somebody else do that amount of changes in comments and try to push in my direction :). (it makes the comoments more readable to utf8 unix people, but less readable to windows visual studio people...)

I get an error when I try to build your fork on macOS:

$ make
c++    -c -o Area.o Area.cpp
c++    -c -o CvtManager.o CvtManager.cpp
In file included from CvtManager.cpp:8:
./pch.h:22:10: fatal error: 'span' file not found
#include <span>
         ^~~~~~
1 error generated.
make: *** [CvtManager.o] Error 1

I don't know a whole lot about C++, so I'm not sure what might cause this.

@jenskutilek how old is your default command-line c++ compiler (c++ --version)? That file is part of the compiler. On linux's clang it is at "/usr/include/c++/v1/span".

You might need to add c++ development if xcode have optional components?

If it helps, there is an xcode project too. I believe recent xcode put up-to-date compilers (and multiple of them) under private places and leave the system-wide command line at old versions or not accessible.

For gcc it is part of gcc's c++11 support, so you need a compiler that is less than 10 years old :).

Edit: on linux, I have two variants of that file, one at /usr/include/c++/v1/ and that belongs to clang, and another at /usr/include/c++/11/ and that belongs to gcc. The respective c++ compiler of each family uses its own versions.

Hm, thanks, my computer is out of support, the Apple developer tools for XCode 10.0.0 are the newest version that can be installed. I get this:

$ c++ --version
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Guess I have to wait until I can upgrade my computer :-/

When I reduced VTT for vttcompile, I was planning on using but then ended up using a different method given it's newness. I forgot to remove from pch.h.

One question/concern I have with a port is VTT and vttcompile dependence on pragmas particularly on #pragma pack (1) to set structure packing and also #pragma once in some headers to avoid multiple includes. I have read somewhere that CLang supports #pragma pack(1) but GCC does not. I don't know if that's still correct. I think #pragma once is supported on both.

I invite you to submit a PR to we can get the port changes upstream.

okay, at the current states, gcc -Wall gives

      4 -Wdangling-else
      1 -Wdeprecated-declarations
      1 -Wfree-nonheap-object
      2 -Wmisleading-indentation
     61 -Wmultichar
      6 -Wreorder
      7 -Wsign-compare
     12 -Wunused-but-set-variable
      1 -Wunused-value
     15 -Wunused-variable

and clang's -Wall gives:

      4 -Wdangling-else
      1 -Wdeprecated-declarations
      1 -Wlogical-not-parentheses
      2 -Wmisleading-indentation
      2 -Wreorder-ctor
      2 -Wshift-negative-value
      1 -Wtautological-constant-out-of-range-compare
      2 -Wunused-private-field
      1 -Wunused-value
     15 -Wunused-variable

At least one of the dangling else warning (in getopt.h) seems tricky, and -Wmisleading-indentation probably too , and there is no obvious workaround to gcc's 61 -Wmultichar warnings (clang does not complain...). In general I am against removing unused anything at this stage (and I have opted to not-merge the removed-dead-code change), so I think this is as far as it would go.

I'll stick a re-ordered version of it on a pull.

The support-for-opencompilers branch in the pull #15 has one less gcc -Wsign-compare warning, but no better with clang.

@jenskutilek in case you weren't reading the earlier details, we removed that unnecessary line and the code should build with older compilers than c++ 2020(!) - I just tried to get gcc to enforce c++14 and it still works, so the code should work with compilers about 7 years old now.

The code fails to build for c++11, so it must be built with a compiler less than 10 years old :).

Hm, I updated my Apple dev tools to the latest version (I am on a machine with the latest macOS today), and I still got errors when compiling. Turns out Apple’s clang uses the ISO C++ 2014 with amendments and GNU extensions standard by default. Choosing the latest supported standard works:

$ CPPFLAGS=--std=gnu++2a make

Both --std=gnu++14 and --std=c++14 work. Maybe the manpage for Apple's clang is wrong about what the default is ...

The errors when I run make without any options are a number of those:

In file included from CvtManager.cpp:8:
In file included from ./pch.h:26:
./FixedMath.h:78:14: error: unknown type name 'constexpr'
    explicit constexpr Fixed16_16(int32_t value = 0) : value_(value) {}

and

./FixedMath.h:228:37: error: no member named 'GetRawValue' in 'Fixed16_16'
    return lhs.GetRawValue() >= rhs.GetRawValue();

and

./VariationModels.h:102:31: error: a space is required between consecutive right angle brackets (use '> >')
                std::deque<std::vector<float>> GetDeltas(const std::deque<std::vector<int16_t>> &masterValues);
                                            ^~
                                            > >

Oh, apple's shipped clang seems different from linux clang (I have 12.0.1). Without anything the default it works, as well as passing CXXFLAGS="-std=c++14" (and 17). It fails with c++11. I'll update the build section of readme in the pull.

Opened a new pull for fixing the remaining warnings #17 . also found and fix a bug while testing (fix included in the pull). I think the pull is as far as I am happy with fixing warnings from gcc and clang, so when that pull merges, I'll close this.

The pull still generates these from clang (excluding unused-anything warnings):

      1 -Wdeprecated-declarations
      1 -Wlogical-not-parentheses
      2 -Wshift-negative-value
      1 -Wtautological-constant-out-of-range-compare

and these from gcc (again excluding unused-anything warnings):

      1 -Wdeprecated-declarations
      1 -Wfree-nonheap-object
     61 -Wmultichar
      6 -Wsign-compare

In general, I don't look at unused-anything warnings. The common deprecated-declaration warning looks non-trivial to fix, and would make unix ports differ more from the windows code also, so I don't want to touch that. Likewise, -Wlogical-not-parentheses and -Wfree-nonheap-object do not look to have an obvious direction to change. The -Wshift-negative-value and -Wsign-compare can be "fixed" by casts and inserting some signed/unsigned, but switching signed/unsigned is tricky, and adding casts do not add-value, so I'd rather not touch those. The -Wtautological-constant-out-of-range-compare and -Wmultichar can be "fixed" by some re-write or casts, but mostly to please a specific compiler and again, does not add value.

So this covers everything that could/should be changed according to -Wall from either gcc or clang.

When the pull get merged, I'll close this, but keep the branch for experiments - it will continue to have those unused routines removed upstream, for example.

We have #15 (buildable with open-source compilers), #17 (the more obvious problem with usage of "long" type), #22 (implicit cast to long and others). Now vttcompile more or less works on non-windows, and going onto the next stage of trying to fix specific issues with specific fonts when compared with vttshell - #23 . I think this can be closed, though my branch will carry on with interesting things - and we have already had one divergence of opinion: my branch retains unused and removed code. There are probably more to come, but hopefully not too many divergences.