[Bf-committers] Towards C++11

[Martijn Berger]

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 <lukas.toenne at gmail.com>
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 <sergey.vfx at gmail.com>
> 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 <
> > konrad.wilhelm.kleine at gmail.com> 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
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>