I've been busy setting up a local copy of EASTL mainly to have it compiled with waf, but as I compile with a really high warning level I came across this potential bug.
At https://github.com/electronicarts/EASTL/blob/master/include/EASTL/internal/char_traits.h#L60 a const wchar_t*& is cast to a const char16_t*&, this is undefined behavior according to clang.

I fixed it by making a local temporary in the form of: const char16_t** localPSrc = reinterpret_cast<const char16_t**>(&pSrc); and passing it as *localPSrc,
it retains the behavior and silences the clang warning, although I'm honestly not sure if this is undefined behavior either (type punning aside).

I am currently studying some old EA games, from the era just before EASTL writing, they use STLPORT 4.something (my guess is 4.6.2)

I noticed EASTL and STLPORT have very similar file structure and calls, and the third party licenses file looks like it came from STLPORT (including the mention to HP STL).

Can I suggest then that STLPORT is mentioned in the third party licenses?

Or was EASTL made from scratch without ever using STLPORT code?

In the attached file EASTLBenchmark output.txt you can see a lot of zeros and a lot of nans.
This is of course unacceptable when it comes to measuring any kind of performance.

An earlier bug report on the GNU tracker shows that this might be related to the chrono implementation with regards to pthreads. The OP points out that using steady_clock instead of high_resolution_clock yields more precise results and I can indeed confirm this, seen in the attached file: EASTLBenchmark steady_clock output.txt
One other interesting thing is how this is 0.06 seconds faster too.

The OP also links to the MingW mailing list where somebody notes how this issue doesn't occur when using boost's chrono implementation.

So there are a few ways on how we can fix this:

• We simply switch to steady_clock on MingW builds.

  However this feels like a band-aid fix where I'm not sure the times recorded are as accurate as MS's implementation or on the other platforms.

• We use boost's chrono instead.

  This is an undesirable solution, as this introduces a huge dependency.

• We use boost's chrono, but rip it out of boost instead of introducing it as a dependency.

  This is less undesirable depending on the size of boost's chrono and could introduce licensing issues.

• We fall back to C API entirely.

  If this can be done with standard C code, it's perhaps the most desirable of the solutions, as it is guaranteed to work on all platforms.

• We submit a patch to libstdc++.

  This is the most ideal solution in the long run, but this means the problem still remains, unless we combine it with one of the previous mentioned solutions.

Maybe an EASTL chrono is needed?
I think if we dig some deeper, the steady_clock switch might prove sufficient, if not, I think falling back to the C API might be the most desirable solution.

CMake generates files properly, but none of the header files is detected at the very start of the of the config.h so i need to point out to the directory manually

#ifndef EASTL_EABASE_DISABLED
    #include <EABase/eabase.h>
#endif
    #include <EABase/eahave.h>

on clang 3.9 (and probably others), I have to make sure to have

#define EA_HAVE_CPP11_INITIALIZER_LIST

before I include any eastl headers or I get redefinition of initializer_list. Is this normal?

Searching the eastl source on github for that string, I don't see anywhere it would be set automatically...

Thank you.

Hi,

evaluating this promising library, I read into your implementation of deque. Here are some more or less random comments:

As an easy to implement optimization:

Imagine we're backing a stack. Now we can run into that nasty situation where the structure fans out (push, pop, push, pop, push, pop... ) at a subarray boundary. In this case we will keep allocating and deallocating the topmost subarray.

To solve this problem we could make the deque less eager on freeing its subarrays; only freeing the second once there are two spare subarrays.

With this optimization in place, we could further steal a spare subarray from one end when the other end needs it. This will allow for zero-allocation when backing a real queue and enqueue/dequeue happens in a balanced fashion. Arguably an even more interesting use case.

I also read this
https://github.com/electronicarts/EASTL/blob/master/include/EASTL/deque.h#L2046-L2047
and it totally puzzles me. Why?!

A (standard STL) deque should guarantee pointer stability when growing at its ends.

Also, I don't see where your implementation does otherwise, so I guess you might be just fine without that extra copy? I might be missing something. However, if this is really an issue, would probably be something worth fixing.

Online discussion on pointer stability:

http://stackoverflow.com/questions/23871677/stable-memory-addresses-using-a-std-container-like-vector-list-queue#23872017

http://stackoverflow.com/questions/3287801/pointers-to-elements-of-stdvector-and-stdlist#3287828
(standard reference given in David Rodriguez' comment).

Constructor comment suggests you were struggling with an initialization scheme that doesn't need dynamic memory. I'm not really sure it's the tricky bit, but what has always worked for me is something like:

intra_subarray_index_head := 0
// so push_front will step to the last element in "previous" (yet nonexistent) node,
// and

intra_subarray_index_tail := max_intra_subarray_index
// so push_back will step to the first element in "next" (yet nonexistent) node,
// this way stepping into a cold code path where checking for the special case
// of initialization won't hurt (and the counting scheme can be changed).

I'm running Cmake 3.1.3 on my Mac OS X and the latest version available on homebrew for easy installation is 3.3.

Latest version on Ubuntu launchpad is 3.3.2.

Requiring an older version would make EASTL pain-free to build if no v3.4-specific feature is being used.

@Leandros introduced a CMake install command in 8be33d4 that can't install the EASTL.lib for different configs like Debug and Release in parallel. The last install will always overwrite any other lib because of the same name.

There are a few ways to make this possible in CMake.

One is to use set(CMAKE_DEBUG_POSTFIX "d") or set_property(TARGET EASTL PROPERTY DEBUG_POSTFIX "d") to change the name of the lib in Debug config to EASTLd.lib. Not a big fan of this and a breaking change for anyone using the Debug version. Beware set(CMAKE_DEBUG_POSTFIX "d")would change the postfix for all libs.

The other option would be to install the libs into sub-directories like:
lib/Debug
lib/Release

The modern CMake approach would be to use generator expressions like:
install(TARGETS EASTL DESTINATION lib/$<LOWER_CASE:$<CONFIG>>)
This would also allow transformations of the directory name to lower case or anything else generator expressions can do. Unfortunately the install(TARGET...) command only supports generator expressions with CMake v3.3+.

If increasing the minimum required CMake version is not an option, passing the BUILD_TYPE escaped to the install script (note the backslash in front of the ${...}) will also work:
install(TARGETS EASTL DESTINATION lib/\${BUILD_TYPE})

A trivial change to make yourself in any case, if there are no objections. Or let me know if you prefer a PR for one of the versions.

Tried to use a hash_map<int,int>.

When it moves out of scope, it fails in its destructor while trying to free the hashmap buckets.
Am I doing something wrong?

Platform: Win7, VS2015, x64
Expression: _CrtIsValidHeapPointer(block)

Call Stack:

delete_scalar.cpp: operator delete(void * block)
delete_array.cpp: operator delete[](void * block)
eastl::allocator::deallocate(void * p, unsigned __int64 __formal) Line 30
eastl::hashtable<int,eastl::pair<int const ,int>,eastl::allocator,eastl::use_first<eastl::pair<int const ,int> >,eastl::equal_to,eastl::hash,eastl::mod_range_hashing,eastl::default_ranged_hash,eastl::prime_rehash_policy,0,1,1>::DoFreeBuckets(eastl::hash_node<eastl::pair<int const ,int>,0> * * pBucketArray, unsigned __int64 n) Line 1525
eastl::hashtable<int,eastl::pair<int const ,int>,eastl::allocator,eastl::use_first<eastl::pair<int const ,int> >,eastl::equal_to,eastl::hash,eastl::mod_range_hashing,eastl::default_ranged_hash,eastl::prime_rehash_policy,0,1,1>::~hashtable<int,eastl::pair<int const ,int>,eastl::allocator,eastl::use_first<eastl::pair<int const ,int> >,eastl::equal_to,eastl::hash,eastl::mod_range_hashing,eastl::default_ranged_hash,eastl::prime_rehash_policy,0,1,1>() Line 1438

When exceptions are enabled you will miss out on possible optimizations when moving functions aren't noexcept.
This causes the compiler will complain about defaulted move constructors/move assignment operators not matching the calculated one. I'm not sure if ignoring this warning will still emit the optimizations, but I don't want to ignore it for cases where I do want the warning emitted and not litter my code full of static asserts.

I have done some work locally to add the noexcept specifications, but I haven't made sure to check if both eastl::string and eastl::vector are noexcept correct.

This fails to compile. Is this a problem with EASTL or in my understanding of how the hash_map can be used? I am using 3.05.00.

Thanks,
Benbuck

#include "eastl/hash_map.h"

class Key
{
public:
    Key() {}
    Key(Key && o) {}
    bool operator==(const Key& other) const { return true; }
private:
    Key(const Key & o) {}
};

struct Hash
{
    std::size_t operator()(const Key& k) const { return 0; }
};

int test(void)
{
    Key key;
    eastl::hash_map<Key, int, Hash> hm;
    return hm[eastl::move(key)];
}

The error emitted by my compiler is:

eastl\include\EASTL\utility.h(401,10): error 331-D: "Key::Key(const Key &)" (declared at line 10 of "test.cpp") is inaccessible
            detected during:
              eastl\include\EASTL\utility.h(47491,48): instantiation of "eastl::pair<T1, T2>::pair(const T1 &) [with T1=const Key, T2=int]" at line 1442 of "eastl\include\EASTL\internal\hashtable.h"
              eastl\include\EASTL\utility.h(48466,52): instantiation of "eastl::hashtable<Key, Value, Allocator, ExtractKey, Equal, H1, H2, H, RehashPolicy, bCacheHashCode, bMutableIterators, bUniqueKeys>::node_type *eastl::hashtable<Key, Value, Allocator, ExtractKey, Equal, H1, H2, H, RehashPolicy, bCacheHashCode, bMutableIterators, bUniqueKeys>::DoAllocateNodeFromKey(const eastl::hashtable<Key, Value, Allocator, ExtractKey, Equal, H1, H2, H, RehashPolicy, bCacheHashCode, bMutableIterators, bUniqueKeys>::key_type &) [with Key=Key, Value=eastl::pair<const Key, int>, Allocator=eastl::allocator, ExtractKey=eastl::use_first<eastl::pair<const Key, int>>, Equal=eastl::equal_to<Key>, H1=Hash, H2=eastl::mod_range_hashing, H=eastl::default_ranged_hash, RehashPolicy=eastl::prime_rehash_policy, bCacheHashCode=false, bMutableIterators=true, bUniqueKeys=true]" at line 2417 of "eastl\include\EASTL\internal\hashtable.h"
              eastl\include\EASTL\utility.h(49276,66): instantiation of "eastl::pair<eastl::hashtable_iterator<Value, <expression>, bCacheHashCode>, bool> eastl::hashtable<Key, Value, Allocator, ExtractKey, Equal, H1, H2, H, RehashPolicy, bCacheHashCode, bMutableIterators, bUniqueKeys>::DoInsertKey(eastl::true_type, const eastl::hashtable<Key, Value, Allocator, ExtractKey, Equal, H1, H2, H, RehashPolicy, bCacheHashCode, bMutableIterators, bUniqueKeys>::key_type &) [with Key=Key, Value=eastl::pair<const Key, int>, Allocator=eastl::allocator, ExtractKey=eastl::use_first<eastl::pair<const Key, int>>, Equal=eastl::equal_to<Key>, H1=Hash, H2=eastl::mod_range_hashing, H=eastl::default_ranged_hash, RehashPolicy=eastl::prime_rehash_policy, bCacheHashCode=false, bMutableIterators=true, bUniqueKeys=true]" at line 254 of "eastl\include\eastl\hash_map.h"
              eastl\include\EASTL\utility.h(49560,13): instantiation of "eastl::hash_map<Key, T, Hash, Predicate, Allocator, bCacheHashCode>::mapped_type &eastl::hash_map<Key, T, Hash, Predicate, Allocator, bCacheHashCode>::operator[](eastl::hash_map<Key, T, Hash, Predicate, Allocator, bCacheHashCode>::key_type &&) [with Key=Key, T=int, Hash=Hash, Predicate=eastl::equal_to<Key>, Allocator=eastl::allocator, bCacheHashCode=false]" at line 22 of "test.cpp"

On OSX run the following:
cmake -Bout -Hbenchmark
cd out
cmake --build . --config Release
ctest -C Release

There will be a crash due to the format sent to vprintf from EASTLBenchmark.cpp (Benchmark::PrintResultLine). On OSX it seems to not understand the "I64" formatter used for the times. I don't know what they're for which is why I'm leaving this in your capable hands.

As per appveyor/ci#679 your AppVeyor settings seem out-of-sync with the renamed build script and should be updated to reflect the new name .appveyor.yml.

Im getting a error C2440 when trying to use eastl::string_view

include\eastl/string_view.h(66): error C2440: "": "const char *const " cannot be converted to "eastl::reverse_iterator<char *>"

It points me to

EA_CONSTEXPR const_reverse_iterator crend() const EA_NOEXCEPT { return reverse_iterator(mpBegin); }

and after that to

const unsigned char* p = (const unsigned char*)x.data(); // To consider: limit p to at most 256 chars.

it also tells me the error appears when compiling the class template

eastl::reverse_iterator<const char *> eastl::basic_string_view<char>::crend(void) noexcept const

Commenting the reverse iterators resolves the issue the same does using const_cast before on the values

		EA_CONSTEXPR reverse_iterator rbegin() const EA_NOEXCEPT { return reverse_iterator(const_cast<pointer>(mpBegin + mnCount)); }
		EA_CONSTEXPR const_reverse_iterator crbegin() const EA_NOEXCEPT { return reverse_iterator(const_cast<pointer>(mpBegin + mnCount)); }
		EA_CONSTEXPR reverse_iterator rend() const EA_NOEXCEPT { return reverse_iterator(const_cast<pointer>(mpBegin)); }
		EA_CONSTEXPR const_reverse_iterator crend() const EA_NOEXCEPT { return reverse_iterator(const_cast<pointer>(mpBegin)); }

also
CharTypeStringRSearch
is not defined in string_view.h

#include <EASTL/vector_multimap.h>
#include <EASTL/string.h>
#include <string>

#include <map>

using namespace std;

#define USE_EASTL

int main(int argc, char **) {

#ifdef USE_EASTL
  eastl::vector_multimap</*eastl::*/string, int> a; // <== either std or eastl string,int cause failure, but int,int does not, all work with std::multimap
#else
  multimap<string,int> a;
#endif

  (void)(a==a);
}

Using eastl::vector_multimap, I get the following error when compiled with: /usr/bin/clang++ -std=c++14 deleteme.cpp -I/usr/local/include on os x sierra

/usr/local/include/EASTL/vector_multimap.h:779:36: error: call to 'equal' is ambiguous
                return (a.size() == b.size()) && equal(b.begin(), b.end(), a.begin());
                                                 ^~~~~
deleteme.cpp:20:11: note: in instantiation of function template specialization 'eastl::operator==<std::__1::basic_string<char>, int,
      eastl::less<std::__1::basic_string<char> >, eastl::allocator, eastl::vector<eastl::pair<std::__1::basic_string<char>, int>,
      eastl::allocator> >' requested here
  (void)(a==a);
          ^
/usr/local/include/EASTL/algorithm.h:1936:2: note: candidate function [with InputIterator1 = const
      eastl::pair<std::__1::basic_string<char>, int> *, InputIterator2 = const eastl::pair<std::__1::basic_string<char>, int> *]
        equal(InputIterator1 first1, InputIterator1 last1, InputIterator2 first2)
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1201:1: note: 
      candidate function [with _InputIterator1 = const eastl::pair<std::__1::basic_string<char>, int> *, _InputIterator2 = const
      eastl::pair<std::__1::basic_string<char>, int> *]
equal(_InputIterator1 __first1, _InputIterator1 __last1, _InputIterator2 __first2)

it it can not cmpile on gcc 4.4.4, some feature gcc4.4.4 not support, can it is may support that version?

Two character corruptions exist in EASTL header files.

• include/EASTL/optional.h
  U+2019 UTF8 character "’" exists in line 15. I suggest replace U+2019 by 0x27.
  // object of type T, referred to as the optional object’s contained value, is allocated
  suggest: ’ to '

• include/EASTL\internal/type_pod.h
  Illegal latin-1 tilde 0x98(U+02DC) is used in line 1670. Legal tilde is 0x7e.
  C4819 warning will occurs in non latin-1 version Visual Studio.
  I see this warning in Japanese version VS2017RC.
  // test<T>::˜test() is not deleted (C++11 "= delete").
  suggest: ˜ to ~

Hi,
I am using release 3.05.00 and I am seeing a linker error when i try to use hash_map on OSX platform, in xcode 8.2.1 using default compiler Apple LLVM 8.0. This is likely due to something I have done wrong as i have built EASTL and run the unit tests and all is good.

I have used vector and map containers so far with no problems but when I try to include and use hash_map in a project, I get linker error:

Undefined symbols for architecture x86_64:
"eastl::gpEmptyBucketArray", referenced from:

I looked at usage in the unit tests and I noticed that the code was included to force compilation:
// Template instantations.
// These tell the compiler to compile all the functions for the given class.
template class eastl::hash_map<int, int>;

When i try adding the template instantation above in my project, I get more linker errors (I can post full error trace if helpful):

"eastl::gpEmptyBucketArray", referenced from:
"eastl::prime_rehash_policy::GetBucketCount(unsigned int) const", referenced from:
"eastl::prime_rehash_policy::GetNextBucketCount(unsigned int) const", referenced from:

I would really appreciate if anybody could give me a hint of what I am doing wrong please. Thank you!

TargetConditionals.h doesn't seem to exist in 10.12

While attempting to add an is_function_pointer type trait, I seem to have found an inconsistency between EASTL's is_function and the STL's is_function when a function pointer type has an MSVC calling convention such as __stdcall.

In Visual Studio 2015 (with Update 3), the following code produces expected results with function pointer types:

template <typename T>
struct is_function_pointer
    : std::integral_constant<bool, std::is_pointer<T>::value &&
                                   std::is_function<typename std::remove_pointer<T>::type>::value>
{
};

However, the equivalent code using EASTL's implementations does not work for function pointer types that have MSVC calling conventions, such as __stdcall, associated with them.

For example, when working with OpenGL on Windows the function signature for glClearColor would be typedef void (APIENTRYP PFNGLCLEARCOLORPROC)(GLfloat red, GLfloat green, GLfloat blue, GLfloat alpha); where APIENTRYP evaluates to __stdcall * (note: this only seems to be the case with 32-bit builds, as I can compile 64-bit with no warnings/errors). is_function_pointer<PFNGLCLEARCOLORPROC>::value using the STL's functions evaluates to true, whereas the value is false using EASTL's implementations.

#include "EABase\eabase.h"
#include <inttypes.h>

produces warnings on VS2015, update 2:

1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(109): warning C4005: 'PRId8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(402): note: see previous definition of 'PRId8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(112): warning C4005: 'PRId64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(424): note: see previous definition of 'PRId64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(125): warning C4005: 'PRIdPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(432): note: see previous definition of 'PRIdPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(128): warning C4005: 'PRIi8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(403): note: see previous definition of 'PRIi8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(131): warning C4005: 'PRIi64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(425): note: see previous definition of 'PRIi64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(144): warning C4005: 'PRIiPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(433): note: see previous definition of 'PRIiPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(147): warning C4005: 'PRIo8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(404): note: see previous definition of 'PRIo8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(150): warning C4005: 'PRIo64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(426): note: see previous definition of 'PRIo64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(163): warning C4005: 'PRIoPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(434): note: see previous definition of 'PRIoPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(166): warning C4005: 'PRIu8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(405): note: see previous definition of 'PRIu8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(169): warning C4005: 'PRIu64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(427): note: see previous definition of 'PRIu64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(182): warning C4005: 'PRIuPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(435): note: see previous definition of 'PRIuPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(185): warning C4005: 'PRIx8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(406): note: see previous definition of 'PRIx8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(188): warning C4005: 'PRIx64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(428): note: see previous definition of 'PRIx64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(201): warning C4005: 'PRIxPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(436): note: see previous definition of 'PRIxPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(204): warning C4005: 'PRIX8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(407): note: see previous definition of 'PRIX8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(207): warning C4005: 'PRIX64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(429): note: see previous definition of 'PRIX64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(220): warning C4005: 'PRIXPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(437): note: see previous definition of 'PRIXPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(230): warning C4005: 'SCNd8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(462): note: see previous definition of 'SCNd8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(233): warning C4005: 'SCNd64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(481): note: see previous definition of 'SCNd64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(246): warning C4005: 'SCNdPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(488): note: see previous definition of 'SCNdPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(249): warning C4005: 'SCNi8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(463): note: see previous definition of 'SCNi8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(252): warning C4005: 'SCNi64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(482): note: see previous definition of 'SCNi64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(265): warning C4005: 'SCNiPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(489): note: see previous definition of 'SCNiPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(268): warning C4005: 'SCNo8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(464): note: see previous definition of 'SCNo8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(271): warning C4005: 'SCNo64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(483): note: see previous definition of 'SCNo64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(284): warning C4005: 'SCNoPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(490): note: see previous definition of 'SCNoPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(287): warning C4005: 'SCNu8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(465): note: see previous definition of 'SCNu8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(290): warning C4005: 'SCNu64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(484): note: see previous definition of 'SCNu64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(303): warning C4005: 'SCNuPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(491): note: see previous definition of 'SCNuPTR'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(306): warning C4005: 'SCNx8': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(466): note: see previous definition of 'SCNx8'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(309): warning C4005: 'SCNx64': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(485): note: see previous definition of 'SCNx64'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\inttypes.h(322): warning C4005: 'SCNxPTR': macro redefinition
1> C:\Users\johan.kotlinski\Desktop\EASTL\test\packages\EABase\include\Common\EABase\eabase.h(492): note: see previous definition of 'SCNxPTR'

The EA_WCHAR_UNIQUE define which is used to determine if wchar_t is a unique type is always defined in eabase.h even if it has already defined by the user
The current code does not check if EA_WCHAR_UNIQUE is defined before defining it.
(

Surrounding the block in an #ifndef EA_WCHAR_UNIQUE so that the block looks like

#ifndef EA_WCHAR_UNIQUE
    #if EA_CHAR16_NATIVE || EA_CHAR32_NATIVE
        #define EA_WCHAR_UNIQUE 1
    #else
        #define EA_WCHAR_UNIQUE 0
    #endif
#endif

would allow users to override the preprocessor check.

it seems like it should be and std::multimap::count is

http://en.cppreference.com/w/cpp/container/multimap/count

Looks like none of the vector_*::count methods are const.

I simply added const in the declaration/definition for vector_multimap and it seems happy..

any reason not to have these match the corresponding std:: types?

Some packages are only required for testing and it makes sense to leave them in the test folder but the generic ones could be moved to a packages folder in the root folder.

Tell me what you think and I'll send a PR with this change.

1>------ Rebuild All started: Project: Test, Configuration: Release x64 ------
1> In file included from Main.cpp
1> In file included from z:\vc\x64\include\eastl/bitvector.h:20:
1>z:\vc\x64\include\EASTL/internal/config.h(61,11): fatal error : 'EABase/eabase.h' file not found
1> #include <EABase/eabase.h>
1> ^
1> 1 error generated.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

#include <memory>
#include <vector>
#include <EASTL/vector.h>

int main(int, char**) {

  // Works                                                                                                                         
  std::vector<std::unique_ptr<int>> stdv1;
  std::vector<std::unique_ptr<int>> stdv2;
  stdv2 = std::move(stdv1);

  // Doesn't work                                                                                                                  
  eastl::vector<std::unique_ptr<int>> v1;
  eastl::vector<std::unique_ptr<int>> v2;
  v2 = std::move(v1);

}

The output on os x clang 3.9:

clang++ -std=c++14 eastl-vector-move.cpp 
In file included from eastl-vector-move.cpp:3:
In file included from /usr/local/include/EASTL/vector.h:42:
/usr/local/include/EASTL/memory.h:605:34: error: call to implicitly-deleted copy constructor of 'value_type' (aka
      'std::__1::unique_ptr<int, std::__1::default_delete<int> >')
                                        ::new((void*)&*currentDest) value_type(*first);
                                                                    ^          ~~~~~~
/usr/local/include/EASTL/memory.h:705:52: note: in instantiation of function template specialization
      'eastl::Internal::uninitialized_copy_impl<eastl::generic_iterator<std::__1::unique_ptr<int, std::__1::default_delete<int> >
      *, void>, eastl::generic_iterator<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, void> >' requested here
                const generic_iterator<Result, void> i(Internal::uninitialized_copy_impl(eastl::generic_iterator<First, voi...
                                                                 ^
/usr/local/include/EASTL/vector.h:578:18: note: in instantiation of function template specialization
      'eastl::uninitialized_copy_ptr<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::unique_ptr<int,
      std::__1::default_delete<int> > *, std::__1::unique_ptr<int, std::__1::default_delete<int> > *>' requested here
                mpEnd = eastl::uninitialized_copy_ptr(x.mpBegin, x.mpEnd, mpBegin);
                               ^
/usr/local/include/EASTL/vector.h:1733:13: note: in instantiation of member function 'eastl::vector<std::__1::unique_ptr<int,
      std::__1::default_delete<int> >, eastl::allocator>::vector' requested here
                this_type temp(*this);  // This is the simplest way to accomplish this, 
                          ^
/usr/local/include/EASTL/vector.h:685:5: note: in instantiation of member function 'eastl::vector<std::__1::unique_ptr<int,
      std::__1::default_delete<int> >, eastl::allocator>::DoClearCapacity' requested here
                                DoClearCapacity(); // To consider: Are we really required to clear here? x is going away so...
                                ^
eastl-vector-move.cpp:8:6: note: in instantiation of member function 'eastl::vector<std::__1::unique_ptr<int,
      std::__1::default_delete<int> >, eastl::allocator>::operator=' requested here
  v2 = std::move(v1);
     ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:2600:31: note: copy constructor is implicitly deleted because
      'unique_ptr<int, std::__1::default_delete<int> >' has a user-declared move constructor
    _LIBCPP_INLINE_VISIBILITY unique_ptr(unique_ptr&& __u) _NOEXCEPT
                              ^
In file included from eastl-vector-move.cpp:3:
In file included from /usr/local/include/EASTL/vector.h:40:
In file included from /usr/local/include/EASTL/algorithm.h:237:
/usr/local/include/EASTL/internal/copy_help.h:73:13: error: object of type 'std::__1::unique_ptr<int, std::__1::default_delete<int>
      >' cannot be assigned because its copy assignment operator is implicitly deleted
                                *result = *first;
                                        ^
/usr/local/include/EASTL/internal/copy_help.h:135:67: note: in instantiation of function template specialization
      'eastl::move_and_copy_helper<eastl::random_access_iterator_tag, false, false>::move_or_copy<const std::__1::unique_ptr<int,
      std::__1::default_delete<int> > *, std::__1::unique_ptr<int, std::__1::default_delete<int> > *>' requested here
                return eastl::move_and_copy_helper<IIC, isMove, canBeMemmoved>::move_or_copy(first, last, result); // Need ...
                                                                                ^
/usr/local/include/EASTL/internal/copy_help.h:143:32: note: in instantiation of function template specialization
      'eastl::move_and_copy_chooser<false, const std::__1::unique_ptr<int, std::__1::default_delete<int> > *,
      std::__1::unique_ptr<int, std::__1::default_delete<int> > *>' requested here
                return OutputIterator(eastl::move_and_copy_chooser<isMove>(eastl::unwrap_iterator(first), eastl::unwrap_ite...
                                             ^
/usr/local/include/EASTL/internal/copy_help.h:193:17: note: in instantiation of function template specialization
      'eastl::move_and_copy_unwrapper<false, const std::__1::unique_ptr<int, std::__1::default_delete<int> > *,
      std::__1::unique_ptr<int, std::__1::default_delete<int> > *>' requested here
                return eastl::move_and_copy_unwrapper<isMove>(eastl::unwrap_iterator(first), eastl::unwrap_iterator(last), result);
                              ^
/usr/local/include/EASTL/vector.h:1543:35: note: in instantiation of function template specialization 'eastl::copy<const
      std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::unique_ptr<int, std::__1::default_delete<int> > *>'
      requested here
                        pointer const pNewEnd = eastl::copy(first, last, mpBegin); // Since we are copying to mpBegin, we d...
                                                       ^
/usr/local/include/EASTL/vector.h:1480:3: note: in instantiation of function template specialization
      'eastl::vector<std::__1::unique_ptr<int, std::__1::default_delete<int> >, eastl::allocator>::DoAssignFromIterator<const
      std::__1::unique_ptr<int, std::__1::default_delete<int> > *, false>' requested here
                DoAssignFromIterator<InputIterator, bMove>(first, last, IC());
                ^
/usr/local/include/EASTL/vector.h:660:4: note: in instantiation of function template specialization
      'eastl::vector<std::__1::unique_ptr<int, std::__1::default_delete<int> >, eastl::allocator>::DoAssign<const
      std::__1::unique_ptr<int, std::__1::default_delete<int> > *, false>' requested here
                        DoAssign<const_iterator, false>(x.begin(), x.end(), eastl::false_type());
                        ^
/usr/local/include/EASTL/vector.h:1393:10: note: in instantiation of member function 'eastl::vector<std::__1::unique_ptr<int,
      std::__1::default_delete<int> >, eastl::allocator>::operator=' requested here
                        *this = x;                   // itself call this member swap function.
                              ^
/usr/local/include/EASTL/vector.h:686:5: note: in instantiation of member function 'eastl::vector<std::__1::unique_ptr<int,
      std::__1::default_delete<int> >, eastl::allocator>::swap' requested here
                                swap(x);           // member swap handles the case that x has a different allocator than ou...
                                ^
eastl-vector-move.cpp:8:6: note: in instantiation of member function 'eastl::vector<std::__1::unique_ptr<int,
      std::__1::default_delete<int> >, eastl::allocator>::operator=' requested here
  v2 = std::move(v1);
     ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:2600:31: note: copy assignment operator is implicitly deleted
      because 'unique_ptr<int, std::__1::default_delete<int> >' has a user-declared move constructor
    _LIBCPP_INLINE_VISIBILITY unique_ptr(unique_ptr&& __u) _NOEXCEPT
                              ^
In file included from eastl-vector-move.cpp:3:
In file included from /usr/local/include/EASTL/vector.h:42:
/usr/local/include/EASTL/memory.h:605:34: error: call to implicitly-deleted copy constructor of 'value_type' (aka
      'std::__1::unique_ptr<int, std::__1::default_delete<int> >')
                                        ::new((void*)&*currentDest) value_type(*first);
                                                                    ^          ~~~~~~
/usr/local/include/EASTL/memory.h:705:52: note: in instantiation of function template specialization
      'eastl::Internal::uninitialized_copy_impl<eastl::generic_iterator<const std::__1::unique_ptr<int,
      std::__1::default_delete<int> > *, void>, eastl::generic_iterator<std::__1::unique_ptr<int, std::__1::default_delete<int> >
      *, void> >' requested here
                const generic_iterator<Result, void> i(Internal::uninitialized_copy_impl(eastl::generic_iterator<First, voi...
                                                                 ^
/usr/local/include/EASTL/vector.h:1551:19: note: in instantiation of function template specialization
      'eastl::uninitialized_copy_ptr<const std::__1::unique_ptr<int, std::__1::default_delete<int> > *, const
      std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::unique_ptr<int, std::__1::default_delete<int> > *>'
      requested here
                        mpEnd = eastl::uninitialized_copy_ptr(position, last, mpEnd);
                                       ^
/usr/local/include/EASTL/vector.h:1480:3: note: in instantiation of function template specialization
      'eastl::vector<std::__1::unique_ptr<int, std::__1::default_delete<int> >, eastl::allocator>::DoAssignFromIterator<const
      std::__1::unique_ptr<int, std::__1::default_delete<int> > *, false>' requested here
                DoAssignFromIterator<InputIterator, bMove>(first, last, IC());
                ^
/usr/local/include/EASTL/vector.h:660:4: note: in instantiation of function template specialization
      'eastl::vector<std::__1::unique_ptr<int, std::__1::default_delete<int> >, eastl::allocator>::DoAssign<const
      std::__1::unique_ptr<int, std::__1::default_delete<int> > *, false>' requested here
                        DoAssign<const_iterator, false>(x.begin(), x.end(), eastl::false_type());
                        ^
/usr/local/include/EASTL/vector.h:1393:10: note: in instantiation of member function 'eastl::vector<std::__1::unique_ptr<int,
      std::__1::default_delete<int> >, eastl::allocator>::operator=' requested here
                        *this = x;                   // itself call this member swap function.
                              ^
/usr/local/include/EASTL/vector.h:686:5: note: in instantiation of member function 'eastl::vector<std::__1::unique_ptr<int,
      std::__1::default_delete<int> >, eastl::allocator>::swap' requested here
                                swap(x);           // member swap handles the case that x has a different allocator than ou...
                                ^
eastl-vector-move.cpp:8:6: note: in instantiation of member function 'eastl::vector<std::__1::unique_ptr<int,
      std::__1::default_delete<int> >, eastl::allocator>::operator=' requested here
  v2 = std::move(v1);
     ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:2600:31: note: copy constructor is implicitly deleted because
      'unique_ptr<int, std::__1::default_delete<int> >' has a user-declared move constructor
    _LIBCPP_INLINE_VISIBILITY unique_ptr(unique_ptr&& __u) _NOEXCEPT
                              ^
3 errors generated.

I found it that function and bind are not like std stl yet

For example, declare but do not define it in the basic_string template, then define it outside:
template <typename T, typename Allocator>
const typename basic_string<T, Allocator>::size_type basic_string<T, Allocator>::npos = (basic_string<T, Allocator>::size_type)(-1);

After generating a Visual Studio solution using the following:

cmake.exe -G "Visual Studio 14 2015 Win64"

Visual studio fails in compilation with the following:

1>------ Build started: Project: EASTL, Configuration: Debug x64 ------
1>  allocator_eastl.cpp
1>C:\Code\Research\EASTL\include\EASTL/internal/config.h(61): fatal error C1083: Cannot open include file: 'EABase/eabase.h': No such file or directory
1>  assert.cpp
1>C:\Code\Research\EASTL\include\EASTL/internal/config.h(61): fatal error C1083: Cannot open include file: 'EABase/eabase.h': No such file or directory
1>  fixed_pool.cpp
1>C:\Code\Research\EASTL\include\EASTL/internal/fixed_pool.h(22): fatal error C1083: Cannot open include file: 'EABase/eabase.h': No such file or directory
1>  hashtable.cpp
1>C:\Code\Research\EASTL\include\EASTL/internal/hashtable.h(30): fatal error C1083: Cannot open include file: 'EABase/eabase.h': No such file or directory
1>  intrusive_list.cpp
1>C:\Code\Research\EASTL\include\EASTL/internal/config.h(61): fatal error C1083: Cannot open include file: 'EABase/eabase.h': No such file or directory
1>  numeric_limits.cpp
1>C:\Code\Research\EASTL\include\EASTL/internal/config.h(61): fatal error C1083: Cannot open include file: 'EABase/eabase.h': No such file or directory
1>  red_black_tree.cpp
1>C:\Code\Research\EASTL\include\EASTL/internal/config.h(61): fatal error C1083: Cannot open include file: 'EABase/eabase.h': No such file or directory
1>  string.cpp
1>C:\Code\Research\EASTL\include\EASTL/internal/config.h(61): fatal error C1083: Cannot open include file: 'EABase/eabase.h': No such file or directory
1>  thread_support.cpp
1>C:\Code\Research\EASTL\include\EASTL/internal/config.h(61): fatal error C1083: Cannot open include file: 'EABase/eabase.h': No such file or directory
1>  Generating Code...
2>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug x64 ------
2>Project not selected to build for this solution configuration 

Why is _CHAR16T defined in pretty much every CMakelist.txt?

The comment in eabase.h:629 suggests that this is only needed for VS2010 and if that is the case, it should be set in the CMake files only when building with VS2010.

On the other hand this macro is already defined in eabase.h:721 for VS2010+. I haven't tried to trace all the platform detection code that leads to this point, but it might suggest that the define in the CMake files is unnecessary?

Any clarifications on this?

Hi,
When using vector::insert() and vector::set_capacity(), the elements already inside the vector are copy and not move.

Here a code to reproduce the problem:

struct CheckCopy
{
	CheckCopy() : m_Value(0) {}
	CheckCopy(int value) : m_Value(value) {}
	CheckCopy(const CheckCopy& iOther) : m_Value(iOther.m_Value) { std::cout << "Copy" << std::endl; }
	CheckCopy(CheckCopy&& iOther) : m_Value(iOther.m_Value) {}
	void operator =(const CheckCopy& iOther) { m_Value = iOther.m_Value; std::cout << "Copy" << std::endl; }
	void operator =(CheckCopy&& iOther) { m_Value= iOther.m_Value; }

	int m_Value;
};

void TestInsert()
{
	eastl::vector<CheckCopy> myVector1;
	myVector1.reserve(20);
	for (int idx = 0; idx < 2; ++idx)
		myVector1.push_back().m_Value = idx;

	eastl::vector<CheckCopy> myVector2;
	for (int idx = 0; idx < 3; ++idx)
		myVector2.push_back().m_Value = 10 + idx;

	// Here we have 5 copy instead of 3
	std::cout << "Insert 3 elts with iterator" << std::endl;
	myVector1.insert(myVector1.begin(), myVector2.begin(), myVector2.end());

	eastl::vector<CheckCopy> myVector3;
	myVector3.push_back().m_Value = 20;
	// Here we have 6 copy instead of one
	std::cout << "Insert 1 elt with iterator" << std::endl;
	myVector1.insert(myVector1.begin(), myVector3.begin(), myVector3.end());

	// Here we have 8 copy instead of 2
	std::cout << "Insert 1 elt" << std::endl;
	myVector1.insert(myVector1.begin(), 1, CheckCopy(17));

	// Here we have 18 copy instead of 11
	std::cout << "Insert 10 elts" << std::endl;
	myVector1.insert(myVector1.begin(), 10, CheckCopy(17));

	// No copy should be done here.
	std::cout << "set_capacity(2)" << std::endl;
	myVector1.set_capacity(2);
}

I create a Pull Request which contain a bug fix for that: #66

Hope it will help.

Both Clang and GCC (MinGW) crash seemingly in the string benchmarks when optimizations are enabled and they link to the dynamic runtime. No crash happens with static runtime, but this could probably be a deeper problem in EASTL or libstdc++, needs investigating.

From my debugging it appears that the libstdc++ deleter calls into EASTL's global allocator deleter, which calls aligned_free, this causes it to crash. I personally have no idea how to fix it, help wanted.

The code below fails to compile with eastl but works fine with libc++

std::vector<std::unique_ptr<int>> vec;
eastl::sort(vec.begin(), vec.end());

They are using an old API: EA::StdC::Stopwatch::Restart
and main.cpp is trying to include PPMalloc/EAGeneralAllocatorDebug.h, which doesn't exist.

On lines 105 and 128 in this file, the template does not specify "typename T", only "typename Allocator". Hence, it does not compile on all platforms.

This was said in the talk at cppcon 2015 from Scott Wardle, where he mentioned EASTL and why it's faster in debug mode.
After which he mentions that you basically hope for the best and that you didn't introduce that many bugs.
I'm not sure how much of this is still true today, but if it is, I was thinking about a way that could get us best of both worlds.
We could set up a preprocessor that scans for a custom set of macros that would do the inlining for us.
So I was thinking that we then would end up with something comparable to this in the generated source code:

// Pre-Inlined eastl::vector<T>::push_back
// At EASTL/vector.h:123
/* insert code here*/
// End of Pre-Inlined eastl::vector<T>::push_back

So whenever you would run into a bug at one place, you can be sure you fixed it everywhere.
The obvious downside of this is that you have to generate the source code, but I think it could be worth it in the long run looking at it from a stability standpoint.

Hi,

This tweet https://twitter.com/jdryg/status/698042963604144128 and this one https://twitter.com/jdryg/status/698043020046921730 from Jim Drygiannakis seem to suggest it might be a good idea / preferable to use std::recursive_mutex instead of std::mutex as a fallback for eastl::mutex, since the implementations (both Windows & pthreads) of eastl::mutex seems to use recusive locking.

I can't recall off the top of my head if eastl::mutex was always recursive, but I think it is / was on other platforms. What do you guys think?

Any reason to specify CMake version 3.1 or greater but have your Travis file using 3.4.3? I get that it should work well as expected. Would there be any value in bumping the CMakeLists.txt to version 3.4.3?

Hi, I'm getting the compile error below.

I added the following include paths:
D:\programming\EASTL-master\test\packages\EABase\include\Common
D:\programming\EASTL-master\include

and this line:

include < EASTL/sort.h >

and got:

1>D:\programming\EASTL-master\test\packages\EABase\include\Common\EABase/eabase.h(724): error C2371: 'char16_t' : redefinition; different basic types
1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\yvals.h(528) : see declaration of 'char16_t'

Visual studio 2012, x64 build.

Hey Rob,

I was just playing around with a ubuntu virtualbox to test out some gcc work I was doing. Looks like EASTL does not build on it. Internally it must as we use it for servers and things so it should mostly just work.

Anyway I will try and fix and submit a patch.

[ 17%] Building CXX object packages/EAStdC/CMakeFiles/EAStdC.dir/source/EASprintf.cpp.o
In file included from /home/swardle/cpp/EASTL/test/packages/EAStdC/source/EASprintf.cpp:8:0:
/home/swardle/cpp/EASTL/test/packages/EAStdC/include/EAStdC/EASprintf.h: In function ‘int EA::StdC::Sprintf(T*, const T*, ...)’:
/home/swardle/cpp/EASTL/test/packages/EAStdC/include/EAStdC/EASprintf.h:30:7: error: ‘result’ does not name a type
  auto result = std::vsprintf(pDestination, pFormat, arguments);
       ^
/home/swardle/cpp/EASTL/test/packages/EAStdC/include/EAStdC/EASprintf.h:32:18: error: there are no arguments to ‘va_end’ that depend on a template parameter, so a declaration of ‘va_end’ must be available [-fpermissive]
  va_end(arguments);
                  ^
/home/swardle/cpp/EASTL/test/packages/EAStdC/include/EAStdC/EASprintf.h:32:18: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/home/swardle/cpp/EASTL/test/packages/EAStdC/include/EAStdC/EASprintf.h:34:9: error: ‘result’ was not declared in this scope
  return result;
         ^
/home/swardle/cpp/EASTL/test/packages/EAStdC/source/EASprintf.cpp: In function ‘int EA::StdC::Vsnprintf(wchar_t*, size_t, const wchar_t*, __va_list_tag*)’:
/home/swardle/cpp/EASTL/test/packages/EAStdC/source/EASprintf.cpp:23:16: error: redefinition of ‘int EA::StdC::Vsnprintf(wchar_t*, size_t, const wchar_t*, __va_list_tag*)’
 EASTDC_API int Vsnprintf(wchar_t* EA_RESTRICT pDestination, size_t n, const wchar_t* EA_RESTRICT pFormat, va_list arguments)
                ^
/home/swardle/cpp/EASTL/test/packages/EAStdC/source/EASprintf.cpp:20:16: error: ‘int EA::StdC::Vsnprintf(char32_t*, size_t, const char32_t*, __va_list_tag*)’ previously defined here
 EASTDC_API int Vsnprintf(char32_t* EA_RESTRICT pDestination, size_t n, const char32_t* EA_RESTRICT pFormat, va_list arguments)
                ^
/home/swardle/cpp/EASTL/test/packages/EAStdC/source/EASprintf.cpp:24:56: error: ‘vswprintf’ was not declared in this scope
  { return vswprintf(pDestination, n, pFormat, arguments); }
                                                        ^
make[2]: *** [packages/EAStdC/CMakeFiles/EAStdC.dir/source/EASprintf.cpp.o] Error 1
make[1]: *** [packages/EAStdC/CMakeFiles/EAStdC.dir/all] Error 2
make: *** [all] Error 2
[ 16%] Built target EASTL

Following SampleNewAndDelete.cpp, void* operator new[] accepts argument const char* name, so it is possible to total track memory allocation grouped by named containers. However, void operator delete only as one argument (void* p), so I am confused about how memory deallocation is intended be tracked?

EASTL adds contiguous_iterator_tag, but then code does not compile with

define EASTL_STD_ITERATOR_CATEGORY_ENABLED 1

since this iterator tag is not in C++ before 2017.

Could the docs be hosted on github pages or somewhere accessible? https://github.com/electronicarts/EASTL/tree/master/doc

I'm not one to be pedantic about this kinda thing, but the readme has the correct spelling right by the incorrect spelling and it stands out :) Thanks for open sourcing this!

I have a class which has a eastl::vector_multimap which is backed by a vector.

In my default move assignment operator for my class, I'm getting an error because my value types are move-only and eastl::vector is trying to copy them.

When I dig into the code, I get:

#if EASTL_MOVE_SEMANTICS_ENABLED
        template <typename K, typename T, typename C, typename A, typename RAC>
        inline typename vector_multimap<K, T, C, A, RAC>::this_type&
        vector_multimap<K, T, C, A, RAC>::operator=(this_type&& x)
        {
            base_type::operator=(eastl::move(x));
            eastl::swap(mValueCompare, x.mValueCompare);
            return *this;
        }
    #endif

then

    #if EASTL_MOVE_SEMANTICS_ENABLED
        template <typename T, typename Allocator>
        typename vector<T, Allocator>::this_type&
        vector<T, Allocator>::operator=(this_type&& x)
        {
            if(this != &x)
            {
                DoClearCapacity(); // To consider: Are we really required to clear here? x is going away soon and will clear itself in its dtor.
                swap(x);           // member swap handles the case that x has a different allocator than our allocator by doing a copy.   **** <===== THIS LINE
            }
            return *this; 
        }
    #endif

and eventually the stack trace gets to the point where it tries to make a copy of a unique_ptr and fails.

Why is it doing a copy instead of a move? Does this mean I cannot put move-only types in a vector?

The following code fails:
eastl::fixed_vector<int,5> myVector;
if (myVector.full())
{
FAILURE
}

This seems incorrect. Am I expected to also check that !myVector.empty(). The problem is that

((void*)mpBegin != (void*)mBuffer.buffer)

because mpBegin == nullptr

Thoughts?

https://github.com/electronicarts/EASTL/blob/master/include/EASTL/iterator.h#L468
It should be ++/--mIterator instead of the ++/--tempMoveIterator

Hi,

It looks like C++ 11 now supports an at() function in map I guess this should probably be added to the eastl map API?

Thanks,
Benbuck

Hi!

Thanks for taking the time to free this library. While I was idly browsing the sourcecode I noticed that the license headers on the files still say "// Copyright (c) Electronic Arts Inc. All rights reserved."

To be unambiguously useful it would help a lot of you could update the license headers to reflect the new distribution terms.

Thanks again,

As you mentioned to me on Gitter, the iteration times are a bit of a problem due to the build times on the CI platforms.
Unity builds combine all source files into a single file by including all other cpp files and compiling it in one go. It requires some changes to the source, like no anonymous namespaces and no using namespace in a global context.
But once you got rid of all of that, you can see a great increase in build time.
Do you think this is something we could implement?