[Bf-committers] Towards C++11

Lukas Tönne lukas.toenne at gmail.com
Fri Jun 13 10:19:37 CEST 2014


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
>


More information about the Bf-committers mailing list