On Fri, Jun 2, 2017 at 5:46 PM, Michael Collison
<Michael.Collison@arm.com> wrote:
This implementation includes "arm_neon.h" when including the optimized <ext/random>. This has the effect of polluting the global namespace with the Neon intrinsics, so user macros and functions could potentially clash with them. Is this acceptable given this only happens when <ext/random> is explicitly included?
I don't think it is. Ideally the sfmt classes would get added to the
standard some day; they are much better performance-wise than the mt
classes. At that point you'd have no excuse anymore.
Why are the symbols in arm_neon.h not prefixed with an underscore as
it is the case for equivalent definitions of other platforms (notably
x86)? If you start adding such optimizations I suggest you create
headers which do not pollute the namespace and include it in
arm_neon.h and whatever other header is needed to define the symbols
needed for compatibility.
Nip the problem in the butt now, this is probably just the beginning.