I agree with Lukas in that if we are going to use C++11 that should not imply just sprinkling features over the code that are wrapped in some C++98 forward compatible macro construct.
For C++11 usage I think however that we do need to: - list the things we want to use (std::bind, std::thread) and how they are supported in our target compilers / platforms. - figure out what parts of blender and supporting 3rd party libraries can be build in c++11 mode. - Agree on what (sub)set of features (both language and library) we can safely use. I am not sure if we should make a wiki page or a dev.b.o ticket to help guide this process and provide all stakeholders insight in what this language upgrade will entail. On Fri, Jun 13, 2014 at 10:19 AM, Lukas Tönne <[email protected]> wrote: > I don't think using fallback implementations or stubs for C++11 features > would work, it just shouldn't be necessary. For a function attribute like > override it could work, but what about more crucial features like > std::bind? These could not be replaced by a stub without breaking the code, > you'd have to use an alternative implementation, e.g. boost. > > So if we allow C++11 it would have to be supported by all relevant > compilers as well. > > Afaik we can enable it selectively for now, e.g. only use it in depsgraph, > cycles, etc.. This way we avoid compiler issues from parts like Bullet > which may not be quite ready for C++11 (it has a bit stricter syntax rules > for some features and gives a bunch of non-critical warnings). > > > On Wed, Jun 11, 2014 at 10:10 AM, Sergey Sharybin <[email protected]> > wrote: > > > It's more clear now, but i'm really skeptical about the proposal. > > Especially about stuff which has "where possible". "Where needed" or > "where > > helps" is what i meant. I wouldn't want to start > > just-another-wave-of-"cleanup" in blender which would start using c++11 > > just because it's possible. > > > > Would rather first use really crucial stuff (like bindings in depsgraph > > project). In this particular example i'm not sure how you'll smooth the > > transition. > > > > P.S. Message got too long, zapping loads of the history. > > > > On Wed, Jun 11, 2014 at 1:45 PM, Konrad Wilhelm < > > [email protected]> wrote: > > > > > Hi Sergey, > > > > > > no no I'm not voting for some library or emulation to use. I voted for > > > smooth transitioning to C++11 with the help of automation and clever > > macro > > > definition. Let me quickly sketch out the things one would have to do > to > > > implement my idea... > > > > > > I just picked one feature from C++11, namely the "override" specifier, > to > > > show that it is safe to implement even if not everybody switches to > > C++11. > > > > > > Just add something like this to some top-level CMakeLists.txt file: > > > > > > # Test if C++11 "override" specifier is supported by current > compiler. > > > # (See http://en.cppreference.com/w/cpp/language/override) > > > check_cxx_source_compiles(" > > > struct A { virtual void foo() {} }; > > > struct B : A { void foo() override {} }; > > > int main(int argc, char * argv[]) { B b; return 0; }" > > > HAVE_CXX11_OVERRIDE_SPECIFIER) > > > if(HAVE_CXX11_OVERRIDE_SPECIFIER) > > > message(STATUS "Using C++11 override specifier where > possible.") > > > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} > > > -DHAVE_CXX11_OVERRIDE_SPECIFIER") > > > endif(HAVE_CXX11_OVERRIDE_SPECIFIER) > > > > > > Then in a global header file, use the HAVE_CXX11_OVERRIDE_SPECIFIER to > > > define a macro that can be used instead of "override" directly: > > > > > > #ifdef HAVE_CXX11_OVERRIDE_SPECIFIER > > > # define BF_OVERRIDE override > > > #else > > > # define BF_OVERRIDE > > > #endif > > > > > > With just these two modifications in place, one can use BF_OVERRIDE in > > > places where one would normally use the "override" keyword directly. It > > > does no harm but adds a maintainability value to the code. > > > > > > To automate the process of using BF_OVERRIDE in places where it makes > > > sense, I voted for using the clang-modernize tool. You run the tool and > > it > > > changes your code, not more but not less. It does no emulation nor puts > > it > > > a library in your code. > > > > > > Besides the "override" specifier the clang-modernize tool can also be > > used > > > to replace auto_ptr with unique_ptr, and more, which seems to be what > you > > > were looking for. > > > > > > Here's a list of transformations, clang-modernize can apply to your > > source > > > code: > > > > > > - Make use of override specifier where possible > > > - Make use of range-based for loops where possible > > > - Pass parameters by value where possible > > > - Replace std::auto_ptr (deprecated) by std::unique_ptr > (EXPERIMENTAL) > > > - Use of 'auto' type specifier > > > - Make use of nullptr keyword where possible > > > > > > Let me emphasize that this is not a library approach. It is just a > smart > > > tool that helps transitioning to C++11. > > > > > > I hope, this clarifies my idea. > > > > > > - Konrad > > > > > > > > -- > > With best regards, Sergey Sharybin > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
