| Index: base/macros.h
|
| diff --git a/base/macros.h b/base/macros.h
|
| index fa12dd2e6bca88aa06a2e425dc3a66ab83e48207..46ee1dadb47472edc0b2f228c4b390c89f766854 100644
|
| --- a/base/macros.h
|
| +++ b/base/macros.h
|
| @@ -11,7 +11,6 @@
|
| #define BASE_MACROS_H_
|
|
|
| #include <stddef.h> // For size_t.
|
| -#include <string.h> // For memcpy.
|
|
|
| // Put this in the declarations for a class to be uncopyable.
|
| #define DISALLOW_COPY(TypeName) \
|
| @@ -49,70 +48,6 @@
|
| template <typename T, size_t N> char (&ArraySizeHelper(T (&array)[N]))[N];
|
| #define arraysize(array) (sizeof(ArraySizeHelper(array)))
|
|
|
| -// bit_cast<Dest,Source> is a template function that implements the
|
| -// equivalent of "*reinterpret_cast<Dest*>(&source)". We need this in
|
| -// very low-level functions like the protobuf library and fast math
|
| -// support.
|
| -//
|
| -// float f = 3.14159265358979;
|
| -// int i = bit_cast<int32_t>(f);
|
| -// // i = 0x40490fdb
|
| -//
|
| -// The classical address-casting method is:
|
| -//
|
| -// // WRONG
|
| -// float f = 3.14159265358979; // WRONG
|
| -// int i = * reinterpret_cast<int*>(&f); // WRONG
|
| -//
|
| -// The address-casting method actually produces undefined behavior
|
| -// according to ISO C++ specification section 3.10 -15 -. Roughly, this
|
| -// section says: if an object in memory has one type, and a program
|
| -// accesses it with a different type, then the result is undefined
|
| -// behavior for most values of "different type".
|
| -//
|
| -// This is true for any cast syntax, either *(int*)&f or
|
| -// *reinterpret_cast<int*>(&f). And it is particularly true for
|
| -// conversions between integral lvalues and floating-point lvalues.
|
| -//
|
| -// The purpose of 3.10 -15- is to allow optimizing compilers to assume
|
| -// that expressions with different types refer to different memory. gcc
|
| -// 4.0.1 has an optimizer that takes advantage of this. So a
|
| -// non-conforming program quietly produces wildly incorrect output.
|
| -//
|
| -// The problem is not the use of reinterpret_cast. The problem is type
|
| -// punning: holding an object in memory of one type and reading its bits
|
| -// back using a different type.
|
| -//
|
| -// The C++ standard is more subtle and complex than this, but that
|
| -// is the basic idea.
|
| -//
|
| -// Anyways ...
|
| -//
|
| -// bit_cast<> calls memcpy() which is blessed by the standard,
|
| -// especially by the example in section 3.9 . Also, of course,
|
| -// bit_cast<> wraps up the nasty logic in one place.
|
| -//
|
| -// Fortunately memcpy() is very fast. In optimized mode, with a
|
| -// constant size, gcc 2.95.3, gcc 4.0.1, and msvc 7.1 produce inline
|
| -// code with the minimal amount of data movement. On a 32-bit system,
|
| -// memcpy(d,s,4) compiles to one load and one store, and memcpy(d,s,8)
|
| -// compiles to two loads and two stores.
|
| -//
|
| -// I tested this code with gcc 2.95.3, gcc 4.0.1, icc 8.1, and msvc 7.1.
|
| -//
|
| -// WARNING: if Dest or Source is a non-POD type, the result of the memcpy
|
| -// is likely to surprise you.
|
| -
|
| -template <class Dest, class Source>
|
| -inline Dest bit_cast(const Source& source) {
|
| - static_assert(sizeof(Dest) == sizeof(Source),
|
| - "bit_cast requires source and destination to be the same size");
|
| -
|
| - Dest dest;
|
| - memcpy(&dest, &source, sizeof(dest));
|
| - return dest;
|
| -}
|
| -
|
| // Used to explicitly mark the return value of a function as unused. If you are
|
| // really sure you don't want to do anything with the return value of a function
|
| // that has been marked WARN_UNUSED_RESULT, wrap it with this. Example:
|
|
|