[Accepted] SDL 0044 - Use Boost library in SDL about sdl_evolution HOT 16 CLOSED

1. This is a difficult proposal to understand grammatically and has a number of spelling errors. I believe the committee should consider how clear proposals need to be in order to be accepted.

2. I'm not certain, but this appears to be dependent on SDL-0043. In my research, the boost library is only available at C++11. This proposal should not have been simultaneously in review with it.

3. Although this proposal doesn't state it, the Boost library's license appears to be MIT. Before this would be accepted, I think this would have to be cleared by the SDLC lawyers. The MIT is very permissive, so it should be okay.

With that said, the overall idea of this proposal seems good. Having well-tested library support for common functions that are broadly cross-platform seems like a good addition. If a platform is not supported however, will having this library be more of a burden than our own custom code?

from sdl_evolution.

@joeljfischer

I'm not certain, but this appears to be dependent on SDL-0043. In my research, the boost library is only available at C++11. This proposal should not have been simultaneously in review with it.

The boost library available for c++98 as well. Basically, it has different parts(sub-libraries), some of them indeed are available only together with c++11 whereas other are working fine with c++98.

Additional note: since version 1.56 Boost library officially supports QCC4.2 which is default compiler for QNX6.5 and based on gcc4.2. The gcc4.2 does not support c++11.

Thus, I don't see any dependency on SDL-0043 at all.

from sdl_evolution.

Overall

• I support the use of boost libraries in the core project. Boost is a well established library with high quality code and a permissive license.
• As stated, the amount of features we could leverage will depend on if we move to c++11 or stay at c++98, but there are enough features at the c++98 level that make this addition worthwhile.

Concerns

• If this is accepted, we will have to weigh out if we wish to refactor the different parts of the project to use the Boost API's over our custom classes.
• If we don't believe refactoring certain code with the Boost API's would be worthwhile, we will need to consider if we should always use our custom implementation of those specific classes/features. We should avoid getting into situations where sometimes we use one and sometimes we use the other.
• If the steering committee accepts this proposal we will need to then take it through the SDLC legal team to ensure we can add it to the project.

from sdl_evolution.

Is there any sort of guess on timeline or lines of code changed for this?

from sdl_evolution.

I believe it would depend on which aspect you wanted to attempt to refactor to use the Boost APIs. Maybe like, refactor to use Boosts Async features over custom Threads as an example?

from sdl_evolution.

I agree with Joey and Joel's comments. Also the best advantage of these changes would be for future portability of SDL Core. Other than that, I don't see what is currently broken with the utilities that boost aims to replace.

I would also be interested in a timeline or an estimate for the amount of work for these changes. I am under the impression that the amount of refactoring to make these changes worthwhile will be astronomical. Also a plan would need to be developed for mitigating bugs introduced by removing existing utilities and replacing with boost.

from sdl_evolution.

@JackLivio @joeljfischer @joeygrover
The main idea in this proposal is to describe what is boost, what advantages it has and why it could be useful for SDL.
If committee will accept this proposal and allow to use boost in SDL we are going to prepare several proposals for the future refactoring.

To me, it looks like following

1. Substitute own implementation of the FileSystem and DateTime classes in SDL
2. Remove own timer's, which is not sufficient enough, in favor of the boost's
3. Use Asio for the threads management and async operations - this one could be split to several small pieces
4. Use Boost's synchronization primitives

from sdl_evolution.

The Steering Committee has deferred this proposal, as they've agreed the author will need to prepare a more specific proposal, with which exact components could be replaced with the Boost library. The revised proposal should also clarify which specific version of the Boost library would be used.

from sdl_evolution.

The pull request for the additional proposal is located at the following link
#148

from sdl_evolution.

The proposed version of the Boost library of 1.56

from sdl_evolution.

Can I ask why 1.56 as this is a quite old version? (1.64 being the newest)

from sdl_evolution.

@tpulatha This is the first version which is officially supported QCC4 for QNX6.5. and almost all its features are working with the old compilers. The newest versions of the boots library contain some number of sub-libraries which could be compiled only with newest c++ compiler as they required some specific c++11/14 features.

In order to avoid confusion about features set between hardware which uses legacy QNX and regular Linux(like Ubuntu 16) I proposed to start at least from 1.56 to be able to use the same version under all systems we have to support.

from sdl_evolution.

I must admit to still being leery about this. It seems like a lot of work for relatively small gains. As I am not a Core developer, however, I will defer to others' judgment.

from sdl_evolution.

@joeljfischer As I highlighted in the proposal the main goal is to substitute our own implementation of the different algorithms and primitives we are currently using in SDL with some stable and production ready solution which will not require any efforts for re-working and/or extension during porting to any other platform. As the example, I show the FileSystem class where we way

1. Reduce code amount
2. Make the code more stable and error free
3. Simplify the portability

So the advantage is quite obvious in this case - if we have a good framework which provides us ready functionality, we have to prefer to use it instead of writing own implementation for the same

from sdl_evolution.

The Steering Committee has noted that there may be overlapping benefits of Boost and C++11 once C++11 has been implemented. However, as a date for C++11 implementation has not yet been determined, the benefits of using Boost library in the interim warrant this proposal's acceptance.

from sdl_evolution.

Issue entered: [SDL 0044] Use Boost library in SDL

from sdl_evolution.