What is the purpose of the Common directory in the EABase include path?
This is for historical reasons. It was simply set that way early on and while we don't do things that way any more, we didn't want to change backward compatibility. But you can hide this in the build file, as virtually all build files around EA do.
Either way, user code #includes <EABase/eabase.h> and the builds are set so that 'common' is the base. I would again vote for removing 'common' if studios wouldn't mind changing their build scripts.
Can I #include just EABase/config/eaplatform.h instead of EABase/eabase.h?
You can do this starting with EABase 2.0.14, but it wasn't supported in previous versions.
Why do we have EA_PLATFORM_XENON instead of EA_PLATFORM_XBOX360? Ditto for REVOLUTION instead of Wii.
The XBox 360 was called Xenon by Microsoft until soon before shipping, but we were developing for it as much as two years ahead of the name change. The situation is similar for Revolution and Wii. EAPLATFORM_PS3 is the same name as the shipping product because Sony always used one name: PS3.
Why do we have EA_PLATFORM_PLAYSTATION2 but then have EA_PLATFORM_PS3?
This is for historical reasons. People prefer the shorter name but didn't want to change old names. All future names will likely use the shortest reasonable name.
What platforms/compilers does EABase support?
EABase supports at least the following compilers:
EABase supports the following platforms:
GCC is giving me warnings regarding INT64_C/UINT64_C.
This is because you are using GCC 3.x (probably 3.4) and that version of GCC's INT64_C definition is simply broken. EABase doesn't try to rectify the broken behavior as any rectification attempt may well collide with GCC library code that is dependent on the bug.
PRId8 (and similar) are broken on VC++.
Correct, and this is due to weakness in VC++ up to at least VC 7.1. Perhaps a later version will rectify this problem. In the meantime, you can expect compiler warnings and/or incorrect behaviour when working with this type on VC++.
Why does EABase's own headers prefix internal #includes with <EABase/...>?
Because this makes it more portable. Strictly speaking, when #including a header, the compiler doesn't necessarily look first in the same directory as the #including file, so unless you fully prefix your headers you could end up #including some other unintended header.
EABase is pretty slow to adopt user suggestions. Why is that?
EABase is a rather core package and is used by a large number of users around EA. We are very concerned about code bloat in packages at as low a level as this. As a result, changes don't tend to occur in EABase until months after they are suggested, and even then only if the changes are simple, beneficial, and universally usable.
Why is EABase implemented with per-platform #ifdefs inside the headers instead of having individual per-platform #included headers
For ease of maintenance. EABase supports a fairly large number of platforms, compilers, and compiler versions. Much of EABase is the same between platforms and so it's much easier to maintain via a small number of files with #ifdefs and avoids the orphaning of platforms and compilers to a much greater extent than otherwise. The downside is that the EABase headers take a little longer to compile, though this is unlikely to have a measurable impact in real projects.
It's a boolean type guaranteed to be 8 bits. It's defined to be bool on platforms that have an 8 bit bool and defined to be int8_t on platforms that have a larger bool size. However, bool8_t is hard to use in a portable way and it's often best just to stick with int8_t.
What are float_t and double_t?
float_t are C99 data types that have a precision that is by design determined by compiler settings. float_t may be defined as any of float, double, or long double. double_t may be defined as any of these as well. About the only thing you can count on is that sizeof(double_t) >= sizeof(float_t). You probably don't want to use float_t and double_t in your code and are probably better off providing your own typedef if you want your floating point types to be variable.
What are intptr_t and uintptr_t?
intptr_t is a signed integer type that is defined as being at least as big as a pointer type. In all known compilers it is exactly as bit as a pointer type. intptr_t is not the same thing as a pointer to an int, despite that the name sounds like so. On a platform with 32 bit pointers, intptr_t will be equivalent to int32_t, whereas on a platform with 64 bit pointers it will be equivalent to int64_t. However, you should use intptr_t and uintptr_t whenever possible, as some compilers (e.g. VC++) treat them differently from simply int32_t and int64_t.
Yes, this is supported.
The PRId32, PRIx64, etc. macros are annoying to use.
These macros are defined because the C99 standard defines them and they are the only way to accomplish portable printf usage with the standard library implementations of the printf family of functions. Alternative implementations of the printf family such as that found in the UTFFoundation package provide a portable means to specify sized types these functions.
I am having problems with __STDC_CONSTANT_MACROS, stdint.h, and macros like UINT64_C.
The basic problem here is due to a weakness in the C99 standard. The problem is that the C99 standard (possibly for backward compatibility reasons) requires the user to #define __STDC_CONSTANT_MACROS before #including stdint.h if the user wants C99 stdint functionality to work. So you either need to predefine this in your build file or you need to manually define it in your source before #including stdint.h for the first time in any compilation unit. The problem with the latter solution is that it requires all code which #includes stdint.h to cooperate and agree to #define __STDC_CONSTANT_MACROS before including stdint.h. All code has to cooperate in doing this because once stdint.h gets #included by somebody, any further #includes of it will of course be ignored. EABase (and for that matter most EA users) needs to have C99 functionality working, so either it needs to define __STDC_CONSTANT_MACROS and #include stdint.h, or the user needs to define __STDC_CONSTANT_MACROS in the make file, or all users of stdint.h must agree to manually #define __STDC_CONSTANT_MACROS before including stdint.h. EABase provides a slight convenience in that it promises to define __STDC_CONSTANT_MACROS, but #including it first is not always feasible.
I am having problems with char16_t under VC++ 2010 or VS2012.
VS2010 through at least VS2013 unilaterally defines the C++11 Standard char16_t and char32_t in its yvals.h header unless _HAS_CHAR16_T_LANGUAGE_SUPPORT or _CHAR16T are defined. However, VC++ does not support C++11 Standard u"" or U"" string literals which go with char16_t and char32_t, which makes its definition of char16_t and char32_t nearly useless and causes headaches for us, since we depend on the char16_t type.
To avoid compile errors related to this, you need to have code either #include <EABase/eabase.h> before #including standard library headers or you need to define _CHAR16T globally in your project defines. You can do both, though what's best depends on your situation. However, you can in some cases still get linker errors when your project includes std STL, because defining _CHAR16T causes the compiler to ignore the char16_t definition in yvals.h, yet sometimes the linker wants to link in VC++ char16_t definitions of some templates. If you have that problem then your best solution until Microsoft fixes this is to make sure _CHAR16T is not defined, and don't use EABase and EABase-using code in the same source files as you use VC++ STL headers. This is not a great solution, but there isn't much choice.
Microsoft postings have suggested that support of u"" and U"" string literals may come with VS2015.