basictypes.h revision 5821806d5e7f356e8fa4b058a389a808ea183019
1// Copyright (c) 2011 The Chromium Authors. All rights reserved. 2// Use of this source code is governed by a BSD-style license that can be 3// found in the LICENSE file. 4 5#ifndef BASE_BASICTYPES_H_ 6#define BASE_BASICTYPES_H_ 7 8#include <limits.h> // So we can set the bounds of our types 9#include <stddef.h> // For size_t 10#include <string.h> // for memcpy 11 12#include "base/port.h" // Types that only need exist on certain systems 13 14#ifndef COMPILER_MSVC 15// stdint.h is part of C99 but MSVC doesn't have it. 16#include <stdint.h> // For intptr_t. 17#endif 18 19typedef signed char schar; 20typedef signed char int8; 21typedef short int16; 22// TODO: Remove these type guards. These are to avoid conflicts with 23// obsolete/protypes.h in the Gecko SDK. 24#ifndef _INT32 25#define _INT32 26typedef int int32; 27#endif 28 29// The NSPR system headers define 64-bit as |long| when possible, except on 30// Mac OS X. In order to not have typedef mismatches, we do the same on LP64. 31// 32// On Mac OS X, |long long| is used for 64-bit types for compatibility with 33// <inttypes.h> format macros even in the LP64 model. 34#if defined(__LP64__) && !defined(OS_MACOSX) && !defined(OS_OPENBSD) 35typedef long int64; 36#else 37typedef long long int64; 38#endif 39 40// NOTE: unsigned types are DANGEROUS in loops and other arithmetical 41// places. Use the signed types unless your variable represents a bit 42// pattern (eg a hash value) or you really need the extra bit. Do NOT 43// use 'unsigned' to express "this value should always be positive"; 44// use assertions for this. 45 46typedef unsigned char uint8; 47typedef unsigned short uint16; 48// TODO: Remove these type guards. These are to avoid conflicts with 49// obsolete/protypes.h in the Gecko SDK. 50#ifndef _UINT32 51#define _UINT32 52typedef unsigned int uint32; 53#endif 54 55// See the comment above about NSPR and 64-bit. 56#if defined(__LP64__) && !defined(OS_MACOSX) && !defined(OS_OPENBSD) 57typedef unsigned long uint64; 58#else 59typedef unsigned long long uint64; 60#endif 61 62// A type to represent a Unicode code-point value. As of Unicode 4.0, 63// such values require up to 21 bits. 64// (For type-checking on pointers, make this explicitly signed, 65// and it should always be the signed version of whatever int32 is.) 66typedef signed int char32; 67 68const uint8 kuint8max = (( uint8) 0xFF); 69const uint16 kuint16max = ((uint16) 0xFFFF); 70const uint32 kuint32max = ((uint32) 0xFFFFFFFF); 71const uint64 kuint64max = ((uint64) GG_LONGLONG(0xFFFFFFFFFFFFFFFF)); 72const int8 kint8min = (( int8) 0x80); 73const int8 kint8max = (( int8) 0x7F); 74const int16 kint16min = (( int16) 0x8000); 75const int16 kint16max = (( int16) 0x7FFF); 76const int32 kint32min = (( int32) 0x80000000); 77const int32 kint32max = (( int32) 0x7FFFFFFF); 78const int64 kint64min = (( int64) GG_LONGLONG(0x8000000000000000)); 79const int64 kint64max = (( int64) GG_LONGLONG(0x7FFFFFFFFFFFFFFF)); 80 81// A macro to disallow the copy constructor and operator= functions 82// This should be used in the private: declarations for a class 83#define DISALLOW_COPY_AND_ASSIGN(TypeName) \ 84 TypeName(const TypeName&); \ 85 void operator=(const TypeName&) 86 87// An older, deprecated, politically incorrect name for the above. 88// NOTE: The usage of this macro was baned from our code base, but some 89// third_party libraries are yet using it. 90// TODO(tfarina): Figure out how to fix the usage of this macro in the 91// third_party libraries and get rid of it. 92#define DISALLOW_EVIL_CONSTRUCTORS(TypeName) DISALLOW_COPY_AND_ASSIGN(TypeName) 93 94// A macro to disallow all the implicit constructors, namely the 95// default constructor, copy constructor and operator= functions. 96// 97// This should be used in the private: declarations for a class 98// that wants to prevent anyone from instantiating it. This is 99// especially useful for classes containing only static methods. 100#define DISALLOW_IMPLICIT_CONSTRUCTORS(TypeName) \ 101 TypeName(); \ 102 DISALLOW_COPY_AND_ASSIGN(TypeName) 103 104// The arraysize(arr) macro returns the # of elements in an array arr. 105// The expression is a compile-time constant, and therefore can be 106// used in defining new arrays, for example. If you use arraysize on 107// a pointer by mistake, you will get a compile-time error. 108// 109// One caveat is that arraysize() doesn't accept any array of an 110// anonymous type or a type defined inside a function. In these rare 111// cases, you have to use the unsafe ARRAYSIZE_UNSAFE() macro below. This is 112// due to a limitation in C++'s template system. The limitation might 113// eventually be removed, but it hasn't happened yet. 114 115// This template function declaration is used in defining arraysize. 116// Note that the function doesn't need an implementation, as we only 117// use its type. 118template <typename T, size_t N> 119char (&ArraySizeHelper(T (&array)[N]))[N]; 120 121// That gcc wants both of these prototypes seems mysterious. VC, for 122// its part, can't decide which to use (another mystery). Matching of 123// template overloads: the final frontier. 124#ifndef _MSC_VER 125template <typename T, size_t N> 126char (&ArraySizeHelper(const T (&array)[N]))[N]; 127#endif 128 129#define arraysize(array) (sizeof(ArraySizeHelper(array))) 130 131// ARRAYSIZE_UNSAFE performs essentially the same calculation as arraysize, 132// but can be used on anonymous types or types defined inside 133// functions. It's less safe than arraysize as it accepts some 134// (although not all) pointers. Therefore, you should use arraysize 135// whenever possible. 136// 137// The expression ARRAYSIZE_UNSAFE(a) is a compile-time constant of type 138// size_t. 139// 140// ARRAYSIZE_UNSAFE catches a few type errors. If you see a compiler error 141// 142// "warning: division by zero in ..." 143// 144// when using ARRAYSIZE_UNSAFE, you are (wrongfully) giving it a pointer. 145// You should only use ARRAYSIZE_UNSAFE on statically allocated arrays. 146// 147// The following comments are on the implementation details, and can 148// be ignored by the users. 149// 150// ARRAYSIZE_UNSAFE(arr) works by inspecting sizeof(arr) (the # of bytes in 151// the array) and sizeof(*(arr)) (the # of bytes in one array 152// element). If the former is divisible by the latter, perhaps arr is 153// indeed an array, in which case the division result is the # of 154// elements in the array. Otherwise, arr cannot possibly be an array, 155// and we generate a compiler error to prevent the code from 156// compiling. 157// 158// Since the size of bool is implementation-defined, we need to cast 159// !(sizeof(a) & sizeof(*(a))) to size_t in order to ensure the final 160// result has type size_t. 161// 162// This macro is not perfect as it wrongfully accepts certain 163// pointers, namely where the pointer size is divisible by the pointee 164// size. Since all our code has to go through a 32-bit compiler, 165// where a pointer is 4 bytes, this means all pointers to a type whose 166// size is 3 or greater than 4 will be (righteously) rejected. 167 168#define ARRAYSIZE_UNSAFE(a) \ 169 ((sizeof(a) / sizeof(*(a))) / \ 170 static_cast<size_t>(!(sizeof(a) % sizeof(*(a))))) 171 172 173// Use implicit_cast as a safe version of static_cast or const_cast 174// for upcasting in the type hierarchy (i.e. casting a pointer to Foo 175// to a pointer to SuperclassOfFoo or casting a pointer to Foo to 176// a const pointer to Foo). 177// When you use implicit_cast, the compiler checks that the cast is safe. 178// Such explicit implicit_casts are necessary in surprisingly many 179// situations where C++ demands an exact type match instead of an 180// argument type convertable to a target type. 181// 182// The From type can be inferred, so the preferred syntax for using 183// implicit_cast is the same as for static_cast etc.: 184// 185// implicit_cast<ToType>(expr) 186// 187// implicit_cast would have been part of the C++ standard library, 188// but the proposal was submitted too late. It will probably make 189// its way into the language in the future. 190template<typename To, typename From> 191inline To implicit_cast(From const &f) { 192 return f; 193} 194 195// The COMPILE_ASSERT macro can be used to verify that a compile time 196// expression is true. For example, you could use it to verify the 197// size of a static array: 198// 199// COMPILE_ASSERT(ARRAYSIZE_UNSAFE(content_type_names) == CONTENT_NUM_TYPES, 200// content_type_names_incorrect_size); 201// 202// or to make sure a struct is smaller than a certain size: 203// 204// COMPILE_ASSERT(sizeof(foo) < 128, foo_too_large); 205// 206// The second argument to the macro is the name of the variable. If 207// the expression is false, most compilers will issue a warning/error 208// containing the name of the variable. 209 210template <bool> 211struct CompileAssert { 212}; 213 214#undef COMPILE_ASSERT 215#define COMPILE_ASSERT(expr, msg) \ 216 typedef CompileAssert<(bool(expr))> msg[bool(expr) ? 1 : -1] 217 218// Implementation details of COMPILE_ASSERT: 219// 220// - COMPILE_ASSERT works by defining an array type that has -1 221// elements (and thus is invalid) when the expression is false. 222// 223// - The simpler definition 224// 225// #define COMPILE_ASSERT(expr, msg) typedef char msg[(expr) ? 1 : -1] 226// 227// does not work, as gcc supports variable-length arrays whose sizes 228// are determined at run-time (this is gcc's extension and not part 229// of the C++ standard). As a result, gcc fails to reject the 230// following code with the simple definition: 231// 232// int foo; 233// COMPILE_ASSERT(foo, msg); // not supposed to compile as foo is 234// // not a compile-time constant. 235// 236// - By using the type CompileAssert<(bool(expr))>, we ensures that 237// expr is a compile-time constant. (Template arguments must be 238// determined at compile-time.) 239// 240// - The outer parentheses in CompileAssert<(bool(expr))> are necessary 241// to work around a bug in gcc 3.4.4 and 4.0.1. If we had written 242// 243// CompileAssert<bool(expr)> 244// 245// instead, these compilers will refuse to compile 246// 247// COMPILE_ASSERT(5 > 0, some_message); 248// 249// (They seem to think the ">" in "5 > 0" marks the end of the 250// template argument list.) 251// 252// - The array size is (bool(expr) ? 1 : -1), instead of simply 253// 254// ((expr) ? 1 : -1). 255// 256// This is to avoid running into a bug in MS VC 7.1, which 257// causes ((0.0) ? 1 : -1) to incorrectly evaluate to 1. 258 259 260// bit_cast<Dest,Source> is a template function that implements the 261// equivalent of "*reinterpret_cast<Dest*>(&source)". We need this in 262// very low-level functions like the protobuf library and fast math 263// support. 264// 265// float f = 3.14159265358979; 266// int i = bit_cast<int32>(f); 267// // i = 0x40490fdb 268// 269// The classical address-casting method is: 270// 271// // WRONG 272// float f = 3.14159265358979; // WRONG 273// int i = * reinterpret_cast<int*>(&f); // WRONG 274// 275// The address-casting method actually produces undefined behavior 276// according to ISO C++ specification section 3.10 -15 -. Roughly, this 277// section says: if an object in memory has one type, and a program 278// accesses it with a different type, then the result is undefined 279// behavior for most values of "different type". 280// 281// This is true for any cast syntax, either *(int*)&f or 282// *reinterpret_cast<int*>(&f). And it is particularly true for 283// conversions betweeen integral lvalues and floating-point lvalues. 284// 285// The purpose of 3.10 -15- is to allow optimizing compilers to assume 286// that expressions with different types refer to different memory. gcc 287// 4.0.1 has an optimizer that takes advantage of this. So a 288// non-conforming program quietly produces wildly incorrect output. 289// 290// The problem is not the use of reinterpret_cast. The problem is type 291// punning: holding an object in memory of one type and reading its bits 292// back using a different type. 293// 294// The C++ standard is more subtle and complex than this, but that 295// is the basic idea. 296// 297// Anyways ... 298// 299// bit_cast<> calls memcpy() which is blessed by the standard, 300// especially by the example in section 3.9 . Also, of course, 301// bit_cast<> wraps up the nasty logic in one place. 302// 303// Fortunately memcpy() is very fast. In optimized mode, with a 304// constant size, gcc 2.95.3, gcc 4.0.1, and msvc 7.1 produce inline 305// code with the minimal amount of data movement. On a 32-bit system, 306// memcpy(d,s,4) compiles to one load and one store, and memcpy(d,s,8) 307// compiles to two loads and two stores. 308// 309// I tested this code with gcc 2.95.3, gcc 4.0.1, icc 8.1, and msvc 7.1. 310// 311// WARNING: if Dest or Source is a non-POD type, the result of the memcpy 312// is likely to surprise you. 313 314template <class Dest, class Source> 315inline Dest bit_cast(const Source& source) { 316 // Compile time assertion: sizeof(Dest) == sizeof(Source) 317 // A compile error here means your Dest and Source have different sizes. 318 typedef char VerifySizesAreEqual [sizeof(Dest) == sizeof(Source) ? 1 : -1]; 319 320 Dest dest; 321 memcpy(&dest, &source, sizeof(dest)); 322 return dest; 323} 324 325// Used to explicitly mark the return value of a function as unused. If you are 326// really sure you don't want to do anything with the return value of a function 327// that has been marked WARN_UNUSED_RESULT, wrap it with this. Example: 328// 329// scoped_ptr<MyType> my_var = ...; 330// if (TakeOwnership(my_var.get()) == SUCCESS) 331// ignore_result(my_var.release()); 332// 333template<typename T> 334inline void ignore_result(const T&) { 335} 336 337// The following enum should be used only as a constructor argument to indicate 338// that the variable has static storage class, and that the constructor should 339// do nothing to its state. It indicates to the reader that it is legal to 340// declare a static instance of the class, provided the constructor is given 341// the base::LINKER_INITIALIZED argument. Normally, it is unsafe to declare a 342// static variable that has a constructor or a destructor because invocation 343// order is undefined. However, IF the type can be initialized by filling with 344// zeroes (which the loader does for static variables), AND the destructor also 345// does nothing to the storage, AND there are no virtual methods, then a 346// constructor declared as 347// explicit MyClass(base::LinkerInitialized x) {} 348// and invoked as 349// static MyClass my_variable_name(base::LINKER_INITIALIZED); 350namespace base { 351enum LinkerInitialized { LINKER_INITIALIZED }; 352 353// Use these to declare and define a static local variable (static T;) so that 354// it is leaked so that its destructors are not called at exit. If you need 355// thread-safe initialization, use base/lazy_instance.h instead. 356#define CR_DEFINE_STATIC_LOCAL(type, name, arguments) \ 357 static type& name = *new type arguments 358 359} // base 360 361#endif // BASE_BASICTYPES_H_ 362