Add CMakeLists file for sample plugin

[BlackPhrase]

• Fixed akane again
• atexit_handler is broken and outside of VS the app shuts down right after opening (it was intended to fix that)

[RinGotou]

change header to cstddef and move this line into akane_util.h will be better(I move it a few days ago but changes are overwrote by old branch's code after my force pulling operation and I didn't notice that)

[RinGotou]

I think we don't need to pause the app on every exit(it's too annoying). I will add startup parameter options to enable this behavior in a few days,so I disable the handler temporarily. and,I will implement plugin feature with another method in a few days,although it will be limited because of some reason but stable enough to replace this.I can only write my project in spare time of study so update frequency is very low,sorry for that.

[BlackPhrase]

change header to cstddef and move this line into akane_util.h will be better(I move it a few days ago but changes are overwrote by old branch's code after my force pulling operation and I didn't notice that)

It's used by the whole library Almost every other file uses size_t so it definitely will be better to place it into the main akane header If other headers are meant to be used separately then everyone should include the file

I think we don't need to pause the app on every exit(it's too annoying).

It doesn't work even in debug build

[RinGotou]

It's used by the whole library Almost every other file uses size_t so it definitely will be better to place it into the main akane header If other headers are meant to be used separately then everyone should include the file

akane_util is included by all basic header in akane,it's no need to place cstddef in collection header.

It doesn't work even in debug build

There's no ploblem in Visual Studio 2017 with Windows SDK 10.0.17134.0 and handler works well.I will test handler later in Debian with Clang++ compiler.

[BlackPhrase]

There's no ploblem in Visual Studio 2017 with Windows SDK 10.0.17134.0 and handler works well.I will test handler later in Debian with Clang++ compiler.

It doesn't work using CMake and MinGW, should I enable the debugging option?

[BlackPhrase]

Also, I don't recommend to modify (remove the commits) the master branch history when working with collaborators Master should remain the same for everyone and modified only by pull requests There is a revert function in git that will create a new commit that will cancel the previous commit(s) changes That is the recommended way when working on a project with someone else

[RinGotou]

It doesn't work using CMake and MinGW, should I enable the debugging option?

No, there's no other association with this.

Also, I don't recommend to modify (remove the commits) the master branch history when working with collaborators Master should remain the same for everyone and modified only by pull requests There is a revert function in git that will create a new commit that will cancel the previous commit(s) changes That is the recommended way when working on a project with someone else

Sorry for my experience lacking of this.I wlll open a branch to work for now.

[BlackPhrase]

Sorry for my experience lacking of this.I wlll open a branch to work for now.

Nah, it's ok Usually, the master branch contains the latest stable state (suitable for release) of the codebase And the work on the further improvements is going on inside the dev branch There also might be a stabilization branch which will be used as an intermediate level between dev and master branches There is also a GitFlow branching model which recommends developers to create custom branches to work on features and bugfixes/hotfixes It's ok to delete commits which contains something sensitive, like your private information (your passwords and such), and you can freely remove your commits when you are working in your own branch, because usually, you're the only one that's making changes in it, other developers are forking the dev branch and making changes there, so that way changes in history won't affect each other (while you change the history of your newly created commits (of your child branch) and not touching the commits that also present in parent branches, it will be absolutely fine)

[RinGotou]

I correct all compiling issues in debian with g++ and make a test with AtExitHandler enabled, it works well in this environment.MinGW and Cygwin is not tested in my laptops.

[BlackPhrase]

Nice And you don't need to merge with master after every change, it only should contain the stable buildable state of the codebase, it might a bit outdated You can work in your testing branch and periodically merge with master (once in a day/week/month/whatever) if everything is fine Other developers will use the testing branch as a base for their changes, in such case That's, of course, up to you to decide about your merging/branching strategy, I'm only telling about what other developers are using