Re: [Bf-committers] Towards C++11
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@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.kle...@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@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Towards C++11
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.toe...@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@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.kle...@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] Blender 2.71 needs VC2013-Redistributable on Windows
It seems Blender 2.71 does not run on older Windows (tested on XP) without VC2013-Redistributable. We have to update the advise on the download page to: If Blender reports an error on startup, please install the Visual C++ 2013 Redistributable Package. 32bit / 64bit thanks, migius ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows
Hi, I will update the download page once we release the final version of 2.71. Thanks for the info! Thomas Am 13.06.2014 16:10, schrieb Remigiusz Fiedler: It seems Blender 2.71 does not run on older Windows (tested on XP) without VC2013-Redistributable. We have to update the advise on the download page to: If Blender reports an error on startup, please install the Visual C++ 2013 Redistributable Package. 32bit / 64bit thanks, migius ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Git is open
Hello everyone, All the Release Candidate builds are ready now so let's open the Git for geenral development. Would ask to avoid major code/whitespace cleanups for until final release is out. It'll help a lot backporting crucial fixes to the tag. Thanks everyone! -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows
Thomas, I think we could inform about such changes even earlier - for testbuilds and RC-builds already. thanks 2014-06-13 16:15 GMT+02:00 Thomas Dinges blen...@dingto.org: Hi, I will update the download page once we release the final version of 2.71. Thanks for the info! Thomas Am 13.06.2014 16:10, schrieb Remigiusz Fiedler: It seems Blender 2.71 does not run on older Windows (tested on XP) without VC2013-Redistributable. We have to update the advise on the download page to: If Blender reports an error on startup, please install the Visual C++ 2013 Redistributable Package. 32bit / 64bit thanks, migius ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows
this is strange, but even with VC2013-Redistributable installed I am not able to run 2.71 builds on Windows XP SP2, in opposite to 2.70a and olders. A hint from someone succeeded would be great :) migius ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows
Is there an error message? Maybe intall Service Pack 3 for XP. - Reply message - Von: Remigiusz Fiedler mig...@gmx.net An: bf-blender developers bf-committers@blender.org Betreff: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows Datum: Fr., Jun. 13, 2014 17:13 this is strange, but even with VC2013-Redistributable installed I am not able to run 2.71 builds on Windows XP SP2, in opposite to 2.70a and olders. A hint from someone succeeded would be great :) migius ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows
Hi I can confirm the RC build is in some way bad when compared to todays buildbot (build on the same machine with the same settings). I will investigate. On Fri, Jun 13, 2014 at 6:10 PM, blen...@dingto.org blen...@dingto.org wrote: Is there an error message? Maybe intall Service Pack 3 for XP. - Reply message - Von: Remigiusz Fiedler mig...@gmx.net An: bf-blender developers bf-committers@blender.org Betreff: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows Datum: Fr., Jun. 13, 2014 17:13 this is strange, but even with VC2013-Redistributable installed I am not able to run 2.71 builds on Windows XP SP2, in opposite to 2.70a and olders. A hint from someone succeeded would be great :) migius ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows
it looks like VC2013 redistributable needs SP3 on Win XP home 32bit. I will upgrade and try again. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows
continuing tests with WinXP home 32bit upgraded to SP3 with VC2013 redistributable installed: - daily build blender-2.71-169c95b-win32 works! - but RC1-build-win32 still gives the same error at start: blender.exe ist keine zulässige 32-bit Anwendung ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] error building with scons after recent sse41
hi error building with scons after git d0573ce9 specs mingw 4.7.1 x64, windows 8.1 enterprise, default profile test with git 746f0ad25 log: -- Compiling == 'kernel_sse41.cpp' In file included from intern\cycles\kernel\kernel_compat_cpu.h:24:0, from intern\cycles\kernel\kernel_sse41.cpp:34: intern\cycles\util/util_simd.h: In function 'int ccl::__popcnt(int)': intern\cycles\util/util_simd.h:73:27: error: '_mm_popcnt_u32' was not declared in this scope intern\cycles\util/util_simd.h: In function 'unsigned int ccl::__popcnt(unsigned int)': intern\cycles\util/util_simd.h:78:27: error: '_mm_popcnt_u32' was not declared in this scope intern\cycles\util/util_simd.h: In function 'long long int ccl::__popcnt(long long int)': intern\cycles\util/util_simd.h:84:27: error: '_mm_popcnt_u64' was not declared in this scope intern\cycles\util/util_simd.h: In function 'size_t ccl::__popcnt(size_t)': intern\cycles\util/util_simd.h:87:27: error: '_mm_popcnt_u64' was not declared in this scope In file included from intern\cycles\kernel\geom/geom.h:37:0, from intern\cycles\kernel\kernel_path.h:27, from intern\cycles\kernel\kernel_sse41.cpp:39: intern\cycles\kernel\geom/geom_triangle.h: In function 'void ccl::triangle_intersect_subsurface(ccl::KernelGlobals*, ccl::Intersection*, ccl::float3, ccl::float3, int, int, float, ccl::uint*, ccl::uint*, int)': intern\cycles\kernel\geom/geom_triangle.h:377:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] In file included from intern\cycles\kernel\geom/geom.h:38:0, from intern\cycles\kernel\kernel_path.h:27, from intern\cycles\kernel\kernel_sse41.cpp:39: intern\cycles\kernel\geom/geom_motion_triangle.h: In function 'void ccl::motion_triangle_intersect_subsurface(ccl::KernelGlobals*, ccl::Intersection*, ccl::float3, ccl::float3, float, int, int, float, ccl::uint*, ccl::uint*, int)': intern\cycles\kernel\geom/geom_motion_triangle.h:373:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] In file included from intern\cycles\kernel\geom/geom_bvh.h:69:0, from intern\cycles\kernel\geom/geom.h:43, from intern\cycles\kernel\kernel_path.h:27, from intern\cycles\kernel\kernel_sse41.cpp:39: intern\cycles\kernel\geom/geom_bvh_subsurface.h: In function 'ccl::uint ccl::bvh_intersect_subsurface(ccl::KernelGlobals*, const Ray*, ccl::Intersection*, int, ccl::uint*, int)': intern\cycles\kernel\geom/geom_bvh_subsurface.h:210:24: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] In file included from intern\cycles\kernel\geom/geom_bvh.h:75:0, from intern\cycles\kernel\geom/geom.h:43, from intern\cycles\kernel\kernel_path.h:27, from intern\cycles\kernel\kernel_sse41.cpp:39: intern\cycles\kernel\geom/geom_bvh_subsurface.h: In function 'ccl::uint ccl::bvh_intersect_subsurface_instancing(ccl::KernelGlobals*, const Ray*, ccl::Intersection*, int, ccl::uint*, int)': intern\cycles\kernel\geom/geom_bvh_subsurface.h:210:24: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] In file included from intern\cycles\kernel\geom/geom_bvh.h:75:0, from intern\cycles\kernel\geom/geom.h:43, from intern\cycles\kernel\kernel_path.h:27, from intern\cycles\kernel\kernel_sse41.cpp:39: intern\cycles\kernel\geom/geom_bvh_subsurface.h:236:30: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] In file included from intern\cycles\kernel\geom/geom_bvh.h:81:0, from intern\cycles\kernel\geom/geom.h:43, from intern\cycles\kernel\kernel_path.h:27, from intern\cycles\kernel\kernel_sse41.cpp:39: intern\cycles\kernel\geom/geom_bvh_subsurface.h: In function 'ccl::uint ccl::bvh_intersect_subsurface_hair(ccl::KernelGlobals*, const Ray*, ccl::Intersection*, int, ccl::uint*, int)': intern\cycles\kernel\geom/geom_bvh_subsurface.h:210:24: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] In file included from intern\cycles\kernel\geom/geom_bvh.h:81:0, from intern\cycles\kernel\geom/geom.h:43, from intern\cycles\kernel\kernel_path.h:27, from intern\cycles\kernel\kernel_sse41.cpp:39: intern\cycles\kernel\geom/geom_bvh_subsurface.h:236:30: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] In file included from intern\cycles\kernel\geom/geom_bvh.h:87:0, from intern\cycles\kernel\geom/geom.h:43, from intern\cycles\kernel\kernel_path.h:27,
