[Bf-codereview] Pepper to trunk merge (issue 4934047)

[mp.theeth at gmail.com]

http://codereview.appspot.com/4934047/diff/6043/intern/audaspace/FX/AUD_BaseIIRFilterReader.cpp
File intern/audaspace/FX/AUD_BaseIIRFilterReader.cpp (right):

http://codereview.appspot.com/4934047/diff/6043/intern/audaspace/FX/AUD_BaseIIRFilterReader.cpp#newcode36
intern/audaspace/FX/AUD_BaseIIRFilterReader.cpp:36: #define CC
m_specs.channels + m_channel
It will actually affect the whole of the compilation unit, so it depends
how the build system is setup (if it calls the compiler on individual
files or if it lumps them together).

http://codereview.appspot.com/4934047/diff/6043/intern/audaspace/intern/AUD_3DMath.h
File intern/audaspace/intern/AUD_3DMath.h (right):

http://codereview.appspot.com/4934047/diff/6043/intern/audaspace/intern/AUD_3DMath.h#newcode160
intern/audaspace/intern/AUD_3DMath.h:160: inline AUD_Vector3
operator*(const float& op) const
The inline keyword is only a hint to the compiler, it's not forced to do
it.

In any case, not a bit deal, I was just asking to see if there was a
specific reason (which could be the case with template specification but
that's obviously not the case here).

http://codereview.appspot.com/4934047/diff/6043/intern/audaspace/intern/AUD_Reference.h
File intern/audaspace/intern/AUD_Reference.h (right):

http://codereview.appspot.com/4934047/diff/6043/intern/audaspace/intern/AUD_Reference.h#newcode123
intern/audaspace/intern/AUD_Reference.h:123: m_original = 0;
NULL is defined in stddef.h, you can just include that. I don't feel
like wanting to minimize external includes is a good enough reason in
this case. Especially since it affects code clarity a lot.

http://codereview.appspot.com/4934047/diff/6043/release/scripts/startup/bl_ui/properties_data_speaker.py
File release/scripts/startup/bl_ui/properties_data_speaker.py (right):

http://codereview.appspot.com/4934047/diff/6043/release/scripts/startup/bl_ui/properties_data_speaker.py#newcode32
release/scripts/startup/bl_ui/properties_data_speaker.py:32: return
context.speaker and (engine in cls.COMPAT_ENGINES)
I meant that as a general remark. No need to change anything here as
Campbell said.

http://codereview.appspot.com/4934047/diff/6043/source/blender/makesdna/DNA_speaker_types.h
File source/blender/makesdna/DNA_speaker_types.h (right):

http://codereview.appspot.com/4934047/diff/6043/source/blender/makesdna/DNA_speaker_types.h#newcode42
source/blender/makesdna/DNA_speaker_types.h:42: short flag;
It's not that big a deal, I just prefer padding at the end of a struct
than in the middle. When it's in the middle, it happens often that
people add new members at the end without reusing the padding space,
growing the struct more than they would need.

http://codereview.appspot.com/4934047/