Yeah, I reported that to James but he's pretty busy. When you say 64 bit MinGW, is that MinGW-w64 or a custom build? I noticed you went through a lot of trouble to build boost - nuwen MinGW is 64 bit native and includes pre-built boost ;)
My MinGw have a long history of changing compiler builds, replacing parts of it, updating parts of standard library to fixed versions of it, so I am not sure what exactly I am running now. But it is mostly MinGW-w64.
Your fork compiles and work fine. Aside from the fact that when I tried to look if you have implemented castling I noticed that you can capture your own pieces.
Fun fact: with -w switch compilation takes about 2 minutes. Without it, it is ≈10 min. Most of the warnings is boost ones. I should probably look how to shut them up. They hides useful information.
That's why I generally try and avoid boost for projects if it is possible. Granted they have a bunch of great things in them but they bloat up your program so much and greatly increase the compile times :(.
Even using only a few things from boost in a few of my projects have increased the compile times by 30% or more.
As for the project I'll try grabbing a up to date version of it and compiling it when I get home from work. Got a few different builds I can test it on to give a little more testing coverage.
Ignore duplicates, Code::Blocks isn't smart enough to eliminate them.
Most of project warnings is due to -Wshadow and -Wmissing-parameter. There MIGHT be something else if not for boost warnings dominating above everything.
PS: Log I posted earlier was from a) Earlier version of C::B, b) from original repo.
Now it reports only 1468 warnings and have a build time of 2:35 most of which are spent on displaying warnings.
Code::Blocks can't be smart enough to eliminate them, as sometimes the order of parameters affects the precedence of effect (e.g. "-Wno-inline -Winline -Wno-inline" if it removes the duplicate the behavior is changed).
Anyway, test my latest commit - I removed a lot of warnings. I used your argument list but without -Winline (you should probably add -Wno-inline). The only warning I get at all now is the json-parser one.
EDIT: I also fixed capturing your own pieces - can you confirm?
I get "unused parameter" from unimplemented functions (Which is fine) and a whole heap of json and boost ones. Capturing your own pieces is fixed.
PS: Tried to enable Weff-C++ and Wzero-as-null-pointer-constant. Did not noticed any new project wanings. but amount of Boost warnings had increased compilation time to 33 minutes. Do not use these flags with boost.
That's so weird, I don't get any warnings at all from boost and I only get the one warning from json-parser - I wonder why you're getting so many? We're using the same flags (besides -Wno-unused-parameter and -Wno-inline) and we're both using Boost 1.54.0, so I'm confused. It could be any combination of Code::Blocks, your CMake parameters, or whatever custom-molded MinGW you have. Since you said you made changes to your standard library headers, maybe this is affecting boost?
Try renaming your MinGW installation folder by adding an underscore at the end, and try out nuwen MinGW to see if you have the same problem.
Also, on a side note, I'm writing a tutorial page for compiling with MinGW: https://github.com/cpluspluscom/ChessPlusPlus/wiki/MinGW-Build-Tutorial
If it still has the NOTICE: at the top, that means I've not finished writing it.
If it is finished, I encourage everyone who reads this to try it out - I've targeted it at people with little experience. If you think some part needs clarification, let me know!
nuwen MinGW is 64 bit native and includes pre-built boost
That it. looks like nuwen is set to threat boost directory as containing system headers.
Made the same with my preferences and everything is set: only json-parser warnings are left
If it will help anyone, option is -isystem dir
Since you said you made changes to your standard library headers, maybe this is affecting boost?
It is mostly threading fixes and addition from later versions of gcc.
If CMake supports Dev-C++, you would still have to use the command line to run CMake to generate the Dev-C++ project. And I'm assuming you mean the updated Dev-C++, not the years-old-outdated-deprecated Dev-C++.
I reworked the board and piece interfaces, now the board no longer tracks piece positions, and instead the pieces know their positions. Piece positions can be freely changed without worry of invalidating iterators - in fact all the containers I am using don't invalidate iterators upon inserting/removing elements.
The way to use the board and piece interfaces is all iterator-based now, but because of all the layers it's kind of annoying to work with, so I'm going to keep working on making it more streamline.
As soon as I get SFML working on Fedora I'll be able to help out again. I saw SFML2.0 was in the repos so I got excited, only to realize that it sticks everything in weird non-standard paths, and the naming conventions are slightly different than expected.
Anyways, going to be building it and I'll be good to go.