Hi,
in this Thread i want to discuss about: "Should OC switch over to Boost and C++11 (or even C++14)"?

If i put some References in here about TrinityCore then i wan't tell that we should do this because TC has done this, NO.
I put this only for more information or detailed discussions devs had made on TC on valid argumentes (Pro and Contra)!

First of all the Link to TC Forum with reference to github:
http://community.trinitycore.org/topic/ … nt-branch/

i could write 10 Pages about this, but noone would read this (i generaly write to long posts tongue ) for this reason i keep it short!

Pro:
* We can replace a lot of ACE stuff with native code (c++11) this will be faster and more stable
* Why we should use Boost for the rest of not native implemented stuff? because Boost uses the same patterns as c++11 (c++14 and future specs) will use so it's easyer to migrate from boost to native code later
* Boost will be developed more frequently than ACE (Last ACE Rev  6.2.4 (09.01.2014)) Latest Boost (1.58 (17.04.2015))
* According to TC Boost is running more stable then ACE was running
* I personaly like the boost pattern more then the ace one (code pattern style)
* at least it will make easyer to backport stuff from TC
* a lot of language features like auto, nullptr, lambda expressions, strongly typed enums, smart pointers, static_assert and many more
* faster compile cause boost is referenced as external lib and ACE is builded with the project by default in OC

Contra:
* you need a up to date compiler for c++11 (should be no problem at unix systems, for windows with the free VS2015 should be no problem as well)
* not well mergable with old code (this is bad for people who have large branches with custom stuff
* certain code standards will change


for me this will open the possability to rewrite threading and many more parts to get ready to implement more nice stuff for the future like more multithreading, more memory management and better resource usage, but the most of all i would like to use the new stuff to save time on development, cause good patterns will improve productivity.

I voted yes, only because a step forward is always a step in the right direction. I feel like ACE is an antiquated technology and we should be keeping up with the times. Of course there's a lot of stuff that's more higher priority then optimizing this specific part of the core in my mind.

We don't have any reports of instability or issues with high numbers of players yet so ACE isn't really affecting anyone currently. It's definitely ambitious, but would be better placed coming after an upgrade to c++11 (and on)

Can i have please some more feedback pls, the question is more then less for those who use OC active in "production env"
i think devs will have no problem with this refactoring wink

no offence to anybody, but may i kick in??
i dont mind changes, as long as its tested correctly and if something goes wrong its not ignored like i do have now with jemalloc upgrade.
I understand that most of you only use windows.. but mind the unix users also a bit please, since currently the core does only compile on windows and not on unix due problems with jemalloc.

So in short, a step forward in compile code is okay.. but if some part fails on either windows users as/or unix then it must not be ignored.

I think that there was already some code implemented 1 month ago that was not working and then changed back, since it was not compiling on unix..

my suggestion would be in this case, make separate branch do there your conversion, then ask both camps to at least if they compile it, then get those compile errors out before pushing to main branch.

Jemalloc is a unix thing. The person who updated it is a unix user and definitely compiled on a unix machine without issue. We don't have a dedicated 24/7 active team either. So for me to get someone to test something on Unix is usually a long process. Sometimes it won't even happen if the person is talking to me, usually because they're quite busy.

thats why i say put it in a separate branch, then let people compile it, then at least you have that out on various platforms, and yes it might compile on centos but not on ubuntu or debian and such distro.
for the rest im fine with everything tongue

The coding structures are outdated, and should be updated. Hell, Oregon isn't even running on full ACE singletons. So if we jump past that even, and move to more standard usage of c++11 (idk much about 13) we'll be slightly more up-to-speed with what Trinity is doing (they seem to be using native C++ now) as well as improve performance on the core.

TC2 is using as much native C++ (c++11) as possible, as far as i know not using c++14 already but boost is combatible to c++14 and upcomming c++17 (c++1y)

updating the c++ version and using new patterns and structures whoud not only benefit performance, its less boilerplate code and realy improved readablity of the code.

i also like the new TC2 opcode pattern (structure) but thats an other story...

if some devs are interested in this project i will start a side branch and we see if we can get the base running.

then we should do like TC has done, moving over piece by piece but not in a branch cause its hard to merge, but keeping ACE and BOOSt paralell in the project.

after all stuff is converted we can remove ACE... thats my plan

Remove ace? C++11 singletons are a problem

why C++11 singletons are a problem for you? Trinity uses this singletons always without any problems on any platform.

removing ACE would be the target if switching to boost, cause 2 libs doing the same are nonesense

dikkedeur wrote:

no offence to anybody, but may i kick in??
i dont mind changes, as long as its tested correctly and if something goes wrong its not ignored like i do have now with jemalloc upgrade.
I understand that most of you only use windows.. but mind the unix users also a bit please, since currently the core does only compile on windows and not on unix due problems with jemalloc.

So in short, a step forward in compile code is okay.. but if some part fails on either windows users as/or unix then it must not be ignored.

I think that there was already some code implemented 1 month ago that was not working and then changed back, since it was not compiling on unix..

my suggestion would be in this case, make separate branch do there your conversion, then ask both camps to at least if they compile it, then get those compile errors out before pushing to main branch.

What ?!

I did the update. I even compiled on the latest ubuntu like the issue described and everything was working. Rebuilding from scratch and/or reruning cmake will fix the problem.

Now back to the topic:

I'm not against C++11, but I don't like the idea of using Boost.

desteny wrote:

Pro:
* We can replace a lot of ACE stuff with native code (c++11) this will be faster and more stable

Not always true. Depends on the implementation.

desteny wrote:

* Why we should use Boost for the rest of not native implemented stuff? because Boost uses the same patterns as c++11 (c++14 and future specs) will use so it's easyer to migrate from boost to native code later

That's not much a concern since it's a one-time shot.

desteny wrote:

* Boost will be developed more frequently than ACE (Last ACE Rev  6.2.4 (09.01.2014)) Latest Boost (1.58 (17.04.2015))

What? Latest ACE is at version 6.3.2, released Thu May 07 10:14:44 CEST 2015
I currently use ACE 6.3.0 with OC having no problem.

desteny wrote:

* According to TC Boost is running more stable then ACE was running

Any relevant tests?

desteny wrote:

* I personaly like the boost pattern more then the ace one (code pattern style)

Not relevant I guess

desteny wrote:

* at least it will make easyer to backport stuff from TC

IMHO very poor point. Standard lib can replace boost quite well, or a better way to implement a particular feature may be found and we should not be dependent on TC

desteny wrote:

* a lot of language features like auto, nullptr, lambda expressions, strongly typed enums, smart pointers, static_assert and many more

As I said c++11 is a good move forward. I agree with this one.

desteny wrote:

* faster compile cause boost is referenced as external lib and ACE is builded with the project by default in OC

I use linux and ACE is used as external library too. Compiling time is about 2 minutes. Windows recompiles ACE and its packed into the main repository mainly for windows users who don't want to install many deps.

desteny wrote:

Contra:
* you need a up to date compiler for c++11 (should be no problem at unix systems, for windows with the free VS2015 should be no problem as well)
* not well mergable with old code (this is bad for people who have large branches with custom stuff
* certain code standards will change

I mostly agree. Although VS10 has support for c++11, it's not 100% support.
For c++14 vs c++11 I must say that even if a standard like c++11 is released it takes years for compiler vendors to make support for that so I won't go so far. We should use an adopted standard and c++11 should be fine for this now.

henhouse wrote:

The coding structures are outdated, and should be updated. Hell, Oregon isn't even running on full ACE singletons.

We chatted about this one. I consider our singletons much faster than ACEs or standard lib ones, since the implementation is almost the same with the difference that we return a reference instead of a pointer. Returning a pointer means that CPU has to dereference the object behind singleton each time its accessed - assuming that compiler doesn't optimize anything.

"A little hard-work never killed anyone important." - Abe

thanks for the feedback, i will not go point by point, else it will get to long.

i think we agree about c++11 (about visual studio for windows should be no problem that vs2010 doesn't support c++11, vs2015 is free and everyone can use it, so there is no need to support older vs versions, the IDE is much better in vs2015, more runtime code analysis and better auto suggest)

about ACE:
sorry i was looking only on wikipedia, there was written Last ACE Rev  6.2.4 (09.01.2014), but youre right, but honestly, to find ACE docs is realy hard, i know boost has not the best doku at all but better then ace, (i overlooked both a bit)

sure boost ore ace is a bit question of personal preferences, but i overlooked trinity, and i was knowing it as well before, they use it almost only for ASIO (asynchronous inout output (network)) i like this single threaded async pattern for networking, but how ever this is not the point. the other used things are boost threading, but this is almost like ACE, and the third thing they use is boost system, this are methods related to OS but OS differences are already implemented in boost framework. this is realy nice cause you don't need to do so much OS different stuff, and you don't need to take care about it, testing on one system is enought, all others will work out uf the box.

but how ever.

about stability, trinity had a problem with realy sporadic crashs in ACE part, hard or even not possible to debug, caused by some multithreaded scenarios.
this was like a crash each day or maybe each second day. i knowed that the old OC had even some problem, on network related code, strange crashs in ace with no realy usable dump, but dont know if this still exists in any case.
sure the problem is not ACE it self but user related code (oc related) but the way ACE needs to implement this trinity was never able to find whats wrong.

boost uses a much simpler pattern, cause its "simple and stupid" its not as wired to code certain things, but how ever trinity has done this change and the feedback from the community was that the strange sporadic crashes never occurred again. i used TC2 a lot as well and i can confirm it, you find related posts on TC forums but i realy beleave it can be done with ACE as well if somebody knows ace in the deep.

shortly about singletons:
if we can use our singletons not ACE, then we should do it, there is no need to use ACE for it.
btw. trinity uses as well raw c++ only for singletons, only thing to think about is if they are Initialized in a multi threading env, then it must be threadsafe, in single threaded its no problem at all...

Do you know approximately the version of ace that was unstable? As everything else it has been being developed and many bugs have been fixed - said that we could also finally update the acelite version for windows. I didn't have stability issues with ACE so far. We had also weird crashes but it lead to jemalloc and updating it fixed those.

About ASIO - i know whats in game but i don't think that changing our similar and imho great non-blocking IO will bring a boost to us. They have different mechanics/APIs but do practically the same.

Boost threading eh? You mean that boost is like abstraction layer for OS but ACE is too - but, anyway switching to c++11 will make both boost threading and ace threading useless since new standard library has very good support for threads and even for thread local storage and can replace both libraries.

I just think that boost is redundantly huge and it's like a new larger standard library.
I'm not against step into C++11 though, I quite like the idea to move forward.

"A little hard-work never killed anyone important." - Abe

sorry, its such a long time ago, i must find the history point in TC, but was 6.x ACE for sure.

about ASIO, its the same in output like ACE does, for this reason it can be replaced without major rewrite, but in this case it was only about the pattern, not only code pattern, the error handling was different resolving the problems, but if you know OC has no more problems on ACE even in multithreaded mode, then its no reason to change

boost threading are the <boost/thread/* libs, like <boost/thread/shared_mutex.hpp> are a lot of usefull stuff in there, but sure, its only a type ob abstraction framework and larger framework but much of boost stuff is implemented one by one in c++14 and with c++17 is almost all stuff from boost covered by native.

youre absolutly right that boost is a giant redundant "thing" to a lot of already native implemented stuff, and i dislike the big size as well, and ACE is smaller in this case, but its as well a big monster.

the one thing i diskile is that there is a lot of stuff in ACE but in OC (and as well in TC) done by OS specific stuff in our code, cause ACE code is hard to write cause some over the top extended patterns and missing documentation, thats the reason why c++11 (and with ith 14 and 17) decided to use (copy) the boost pattern (you convert stuff by replacing boost:: with std::) for this reason code style and patterns are aligned to the c++ standard and this is a huge benifit for all cpp newcomers and not ACE skilled people.

but how ever if you want to keep ACE and convert only c++11 stuff it would be a huge step in the right direction as well...

15 (edited by Espionage724 2015-10-14 07:34:12)

I'm not certain if Boost vs ACE is the result of this, but OC compiles significantly faster than TC for me, and this could also be reproduced with CMaNGOS classic vs TC.

I like faster compiles tongue But as for the actual differences between Boost and ACE, I'm not sure which would be better really.

For Unix systems should be no difference, cause ACE and Boost should be installed as external dependency (package)
For Windows systems, actualy OC compiles a included version of ACE, this takes longer then using the installed boost lib.

for this reason for windows boost would speed up the compiling process

but i don't know if c++11 compilers take longer then old c++ compiler, but i don't think so