Styleguide conformance

[LB--]

Mostly changed spacing for things, refactored the code a bit, etc. Make sure it compiles and runs properly for you!

[Thumperrr]

In SFMLEvent, if the destructor is to throw no exceptions, noexcept must be specified for every destructor for every child class (Application and AppStateGame), otherwise you should get a compiler error.

After fixing that the program compiles for me, but I get an segfault upon load from an unknown area (where an exception isn't thrown). I'll investigate further shortly.

[LB--]

All destructors are noexcept by default. What compiler are you using? There is an issue with some older versions of GCC.

[Thumperrr]

4.7.2 on ubuntu. I get "looser throw specifier" in dtors that inherit SFMLEvent.
By that logic, if destructors are noexcept by default, why declare SFMLEvent::~SFMLEvent to be noexcept in the first place?

[LB--]

Force of habit. But it is supposed to compile according to the C++11 standard, explicit or not.

[Thumperrr]

Hmm. Well, I either declare noexcept for daughter classes or I remove noexept from the SFLEvent destructor and it compiles.

I still need to figure out why she's segfaulting, though. :/

EDIT:
Just got out of class for the summer, so hopefully I'll be able to have more of a presence now.

[LB--]

I really wish I could test but I still can't link SFML. I've kind of given up on that :\ all I can do is see if it compiles.

Can you get any debug information about where it segfaults? Does anything ever get written to the log files?

[Thumperrr]

There's got to be something we're doing wrong.. I can link fine on Linux, but I still can't link SFML properly on Windows. I've given up as well, lol.

No debug output about the crash is logged, probably because it's not caused by an exception that we're intentionally trowing.
Interestingly, when I pump it into valgrind the program runs. But it does complain about "Conditional jump or move depends on uninitialized values" at GraphicsHandler::drawBoard.

[LB--]

No debug output about the crash is logged, probably because it's not caused by an exception that we're intentionally trowing.

I meant does the code even get to a point where stuff gets written to the log files? Do the log files even get created? I'm talking about the ones that std::clog, std::cerr, and std::cout go to.

[Thumperrr]

Yeah yeah, they get created. It loads all the images fine and generates piece positions. Then nothing.
https://gist.github.com/Thumperrr/5556194

[LB--]

So, it finishes Board::newGame, returns back to the ctor of AppStateGame, which returns back to the ctor of Application, then main calls Application::Exec.

If you can't deduce the crash in the debugger can you try putting debugs statements along that call stack to see where it stops? I'll investigate GraphicsHandler::drawBoard.

[Thumperrr]

Okay I've narrowed down the issue. I ran the program through gdb and (after stepping through a lot of stuff), the program segfaulted on calling Piece::getTrajectory.

Relevant GDB output:

chesspp::board::Piece::getTrajectory (this=0x18) at src/board/Piece.cpp:35
35              return trajectory;
(gdb) step
36          }
(gdb) step
std::vector<chesspp::board::Position, std::allocator<chesspp::board::Position> >::begin (this=0x30) at /usr/include/c++/4.7/bits/stl_vector.h:528
528       { return const_iterator(this->_M_impl._M_start); }
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x08050a85 in std::vector<chesspp::board::Position, std::allocator<chesspp::board::Position> >::begin (this=0x30) at /usr/include/c++/4.7/bits/stl_vector.h:528
528       { return const_iterator(this->_M_impl._M_start); }

This is occuring in GraphicsHandler::drawBoard, line 63.
Did you make any changes to Piece?

EDIT:
There appears to be a problem making the temporary object that's a const reference to std::vector<Position> trajectory.. Why that would happen, I do not yet know. But there's a segfault on vector::begin.

[LB--]

I only made spacing changes to Piece, I really have no idea what's going on here.

[Thumperrr]

Okay I've found the issue. The problem occurs in GraphicsHandler::drawBoard.

        void GraphicsHandler::drawBoard(const board::Board *b)
        {
            drawBackground();

            // Valid moves are drawn for the piece being hovered over
            // Or the piece that is currently selected
            board::Piece*pCurrent = b->getCurrent();
            board::Piece*pSelect  = b->getSelected();
            if (pSelect)
                for (auto &i: pSelect->getTrajectory())

On line 6 and 7 of the above snippet, pCurrent and pSelect are gotten from board. The first time this function is called (no pieces have been drawn on the board yet), pCurrent and pSelect should be null ~ the cursor is not over a piece, and the user hasn't clicked on a piece. However, if(pSelect) was evaluating true, and calling getTrajectory on an uninitialized piece pointer, causing the segfault.

I fixed this by changing the Board constructor to the following:

        Board::Board()
        : pieces(WIDTH*WIDTH),
          selectedPiece(nullptr),
          currentPiece(nullptr)
        {
        }

Those internal Piece pointers need to be initialized to nullptr.
Commit that change and i'll merge the PR.

EDIT: We should probably wrap selectedPiece and currentPiece with std::shared_ptr's

[LB--]

I committed the fix, make sure it works now.

EDIT: We should probably wrap selectedPiece and currentPiece with std::shared_ptr's

In my later code they don't even exist anymore :)

[Thumperrr]

It's all good in that commit.
Except the noexcept specifier in SFMLEvent - compiler complains about daughter classes having looser throw specifiers in their destructors. We should either make standard to declare all destructors noexcept, or to leave it out entirely because they're noexcept by default.