EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.

EA Standard Template Library

Build Status

EASTL stands for Electronic Arts Standard Template Library. It is a C++ template library of containers, algorithms, and iterators useful for runtime and tool development across multiple platforms. It is a fairly extensive and robust implementation of such a library and has an emphasis on high performance above all other considerations.

Usage

If you are familiar with the C++ STL or have worked with other templated container/algorithm libraries, you probably don't need to read this. If you have no familiarity with C++ templates at all, then you probably will need more than this document to get you up to speed. In this case, you need to understand that templates, when used properly, are powerful vehicles for the ease of creation of optimized C++ code. A description of C++ templates is outside the scope of this documentation, but there is plenty of such documentation on the Internet.

EASTL is suitable for any tools and shipping applications where the functionality of EASTL is useful. Modern compilers are capable of producing good code with templates and many people are using them in both current generation and future generation applications on multiple platforms from embedded systems to servers and mainframes.

Package Managers

You can download and install EASTL using the Conan package manager:

conan install eastl/[email protected]

The EASTL package in conan is kept up to date by Conan team members and community contributors. If the version is out-of-date, please create an issue or pull request on the Conan Center Index repository.

You can download and install EASTL using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
vcpkg install eastl

The EASTL port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Documentation

Please see EASTL Introduction.

Compiling sources

Please see CONTRIBUTING.md for details on compiling and testing the source.

Credits And Maintainers

EASTL was created by Paul Pedriana and he maintained the project for roughly 10 years.

EASTL was subsequently maintained by Roberto Parolin for more than 8 years. He was the driver and proponent for getting EASTL opensourced. Rob was a mentor to all members of the team and taught us everything we ever wanted to know about C++ spookyness.

Max Winkler is the current EASTL owner and primary maintainer within EA and is responsible for the open source repository.

Significant EASTL contributions were made by (in alphabetical order):

  • Avery Lee
  • Colin Andrews
  • JP Flouret
  • Liam Mitchell
  • Matt Newport
  • Max Winkler
  • Paul Pedriana
  • Roberto Parolin
  • Simon Everett

Contributors

Projects And Products Using EASTL

License

Modified BSD License (3-Clause BSD license) see the file LICENSE in the project root.

Comments
  • Cannot move assign a eastl::vector<unique_ptr<int>>

    Cannot move assign a eastl::vector>

    #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.
    
    
  • Visual Studio project generation not including appropriate headers

    Visual Studio project generation not including appropriate headers

    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 
    
  • Submodule hell - not the way they're meant to work

    Submodule hell - not the way they're meant to work

    Hi,

    I'm not sure who's idea it was to switch to submodules. That in itself is not a huge problem, a little annoying maybe, but ok, fair enough, its your project. But to make them interdependent so that --recursive is effectively broken? Its now very difficult (read: impractical) to keep up-to-date with the latest versions without hacking around, creating an independent folder and committing that to a local repository without the submodules. It just takes someone who already has other submodules in their project, such as protobuf for example, that has its own submodules so that they require the use of --recursive for a successful clone.

    Please reconsider this layout. I'm a long time user of EASTL and I'm glad its still being maintained and is as great as ever, but this change is going to be an ongoing issue to keep up-to-date.

  • Add MinGW-w64 (MSYS2) CI scripts

    Add MinGW-w64 (MSYS2) CI scripts

    This PR adds scripts for appveyor to automatically check mingw-w64 (MSYS2) compatibility. Some things I did:

    • Switch GCC to C++14, since it needs to run in C++14 mode for variadic template support.
    • Add C++14 deleters to the test allocators.
    • Turn off strict aliasing on GCC, without this the intrusive list test won't pass. (Probably needs some investigating to make sure this also works on compilers that do not have such an option.)
    • Clean up the CMakeLists a bit.

    The mingw-w64 appveyor build script is separate from the standard one, I've done this in an attempt to shorten the amount of time before you can see if integration failed. Another thing I did, I stopped clang from building in release mode in x86 configurations, since it ICEs on about 90% of the source code.

  • Build issue | Xcode 7.2 Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin14.5.0

    Build issue | Xcode 7.2 Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin14.5.0

    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>
    
  • eabase.h: error C2371: 'char16_t' : redefinition; different basic types

    eabase.h: error C2371: 'char16_t' : redefinition; different basic types

    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.

  • macro defining char8_t to char breaks valid code

    macro defining char8_t to char breaks valid code

    The macro in eabase.h breaks valid code: https://github.com/electronicarts/EASTL/blob/master/test/packages/EABase/include/Common/EABase/eabase.h#L715

    // this code is fine without the #define
    #define char8_t char
    
    enum char8_t : unsigned char {};
    

    produces the error:

    
    <source>:4:6: error: expected identifier or '{'
    
    enum char8_t : unsigned char {};
    
         ^
    

    https://godbolt.org/z/GjgPra

    This example code comes from the popular c++ library {fmt}:

    https://github.com/fmtlib/fmt/blob/master/include/fmt/format.h#L404

  • When copying a vector_map to another vector_map, sends entire pair to key's constructor if it can accept it

    When copying a vector_map to another vector_map, sends entire pair to key's constructor if it can accept it

    https://github.com/electronicarts/EASTL/blob/master/include/EASTL/utility.h#L407

    If your key type has a templated constructor that can take a pair, this constructor is selected. For example a constructor like:

    template<class T>
    MyKeyType(T&&t);
    
    

    I don't see why (off the top of my head) you'd ever want this constructor to be called.

    
    /Users/xaxxon/apb/include/field_string.h:15:9: note: in instantiation of function template specialization 'AlignedString<16>::AlignedString<eastl::pair<FieldString, std::__1::function<bool (Thing &)> > >' requested here
            SUPER(std::forward<Strings>(strings)...)
            ^
    /usr/local/include/EASTL/utility.h:407:7: note: in instantiation of function template specialization 'FieldString::FieldString<eastl::pair<FieldString, std::__1::function<bool (Thing &)> > >' requested here
                                    : first(eastl::move(x)),
                                      ^
    /usr/local/include/EASTL/memory.h:605:34: note: in instantiation of function template specialization 'eastl::pair<FieldString, std::__1::function<bool (Thing &)> >::pair<eastl::pair<FieldString, std::__1::function<bool (Thing &)> > &, void>' requested here
                                            ::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<eastl::pair<FieldString, std::__1::function<bool (Thing &)> > *, void>, eastl::generic_iterator<eastl::pair<FieldString, std::__1::function<bool (Thing &)> > *, void> >' requested here
                    const generic_iterator<Result, void> i(Internal::uninitialized_copy_impl(eastl::generic_iterator<First, void>(first), // generic_iterator makes a pointer act like an iterator.
                                                                     ^
    /usr/local/include/EASTL/vector.h:578:18: note: in instantiation of function template specialization 'eastl::uninitialized_copy_ptr<eastl::pair<FieldString, std::__1::function<bool (Thing &)> > *, eastl::pair<FieldString, std::__1::function<bool (Thing &)> > *, eastl::pair<FieldString, std::__1::function<bool (Thing &)> > *>' requested here
                    mpEnd = eastl::uninitialized_copy_ptr(x.mpBegin, x.mpEnd, mpBegin);
                                   ^
    /usr/local/include/EASTL/vector_map.h:326:5: note: in instantiation of member function 'eastl::vector<eastl::pair<FieldString, std::__1::function<bool (Thing &)> >, eastl::allocator>::vector' requested here
                    : base_type(x), mValueCompare(x.mValueCompare)
                      ^
    /Users/xaxxon/apb/src/game_data.cpp:30:9: note: in instantiation of member function 'eastl::vector_map<FieldString, std::__1::function<bool (Thing &)>, eastl::less<FieldString>, eastl::allocator, eastl::vector<eastl::pair<FieldString, std::__1::function<bool (Thing &)> >, eastl::allocator> >::vector_map' requested here
            insertion_filters(other.insertion_filters) {
    
    
  • Compile failures with char8_t

    Compile failures with char8_t

    (Disclaimer: I'm a Microsoft employee on the Visual C++ team.)

    We've stumbled across some build failures in EASTL after implementing support for char8_t under /std:c++latest in the development version of Visual C++. Specifically:

    1. Line 927 of include/EASTL/string.h calls eastl::CharStrlen with a const value_type*. When char8_t is the C++20 fundamental type and value_type is char, there is no overload of eastl::CharStrlen that accepts const char*. (There are four overloads defined in include/EASTL/internal/char_traits.h accepting pointer-to-const char8_t, char16_t, char32_t, and wchar_t, but no char.)

    2. Line 16 of test/packages/EAStdC/source/EASprintf.cpp wants to call vsnprintf with a char8_t*, but there's no such overload of vsnprintf.

  • Inconsistency between std::is_function and eastl::is_function

    Inconsistency between std::is_function and eastl::is_function

    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.

  • EASTL doesn't detect non-apple clang on MacOS properly - thinks modern clang versions are pre-C++11

    EASTL doesn't detect non-apple clang on MacOS properly - thinks modern clang versions are pre-C++11

    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.

  • [MSVC][std:c++latest] EASTL failed to build with msvc due to error C2338 on Windows

    [MSVC][std:c++latest] EASTL failed to build with msvc due to error C2338 on Windows

    Hi all, EASTL failed to build with msvc due to error C2338 on Windows. Could you please help look at this issue?

    Environment: Windows: windows server 2019 VS: 2019

    Repro steps: 1.open VS2019 x64 tools command 2.git clone https://github.com/electronicarts/EASTL F:\gitP\electronicarts\EASTL 3.cd F:\gitP\electronicarts\EASTL 4.mkdir build_amd64 & cd build_amd64 5.set VSCMD_SKIP_SENDTELEMETRY=1 & "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\VsDevCmd.bat" -host_arch=amd64 -arch=amd64 & set CL= /std:c++latest 6.cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_SYSTEM_VERSION=10.0.18362.0 -DEASTL_BUILD_TESTS:BOOL=ON -DEASTL_BUILD_BENCHMARK:BOOL=OFF .. 2>&1 7.set CL=%CL% /Zc:static_assert- 8.set CL=%CL% /Zc:char8_t- 9.msbuild /m /p:Platform=x64 /p:Configuration=Release EASTL.sln /t:Rebuild 2>&1

    Error info: F:\gitP\electronicarts\EASTL\test\source\TestStringView.cpp(12,15): error C2338: Building with char8_t tests e nabled, but EA_CHAR8_UNIQUE evaluates to false. [F:\gitP\electronicarts\EASTL\build_amd64\test\EASTLTest.vcxproj] F:\gitP\electronicarts\EASTL\test\source\TestString.cpp(17,15): error C2338: Building with char8_t tests enabl ed, but EA_CHAR8_UNIQUE evaluates to false. [F:\gitP\electronicarts\EASTL\build_amd64\test\EASTLTest.vcxproj]

    log build.log

  • bitvector: remove explicit copy constructor and copy assignment

    bitvector: remove explicit copy constructor and copy assignment

    not only it is same as default implementation, but also disallows move assignment (violates rule-of-5)

    since, there is no sense in declaring copy/assignment, we just remove it (use rule of zero) https://en.cppreference.com/w/cpp/language/rule_of_three

  • remake vector_set from inheritance from underlying container to aggre…

    remake vector_set from inheritance from underlying container to aggre…

    …gation

    this makes it safer, as it disallows some of changes that could violate sorted contract it also saves at least sizeof(void*) on most common comparators (due to empty struct optimization in compressed_pair)

    con: it explicitly requires container class to follow vector API (almost all functions are exposed in vector_set)

    to consider: remove non const front(), back(), at(), [] access. Those are not safe either, left them only for compatibility

  • Add EASTL.natvis to EASTL when using MSVC and install to doc directory

    Add EASTL.natvis to EASTL when using MSVC and install to doc directory

    This adds EASTL.natvis to the EASTL target when using MSVC and installs the file to the doc directory, enabling users to use the file without needing to reference the Git repository or manually copy the file.

C++14 evented IO libraries for high performance networking and media based applications

LibSourcey C++ Networking Evolved LibSourcey is a collection of cross platform C++14 modules and classes that provide developers with an arsenal for r

Nov 22, 2022
Embedded Template Library

Embedded Template Library (ETL) Motivation C++ is a great language to use for embedded applications and templates are a powerful aspect. The standard

Nov 26, 2022
Nov 27, 2022
An open-source C++ library developed and used at Facebook.

Folly: Facebook Open-source Library What is folly? Folly (acronymed loosely after Facebook Open Source Library) is a library of C++14 components desig

Nov 23, 2022
Functional Programming Library for C++. Write concise and readable C++ code.
Functional Programming Library for C++. Write concise and readable C++ code.

FunctionalPlus helps you write concise and readable C++ code. Table of contents Introduction Usage examples Type deduction and useful error messages T

Nov 28, 2022
? A glib-like multi-platform c library
? A glib-like multi-platform c library

A glib-like cross-platform C library Supporting the project Support this project by becoming a sponsor. Your logo will show up here with a link to you

Nov 27, 2022
NIH Utility Library

libnih is a light-weight "standard library" of C functions to ease the development of other libraries and applications. Its goals are: * despite it

Sep 15, 2022
An open source library for C

Homo Deus - C Library Introduction The Homo Deus C Library (hdelibc) is an open source collection of tools for the C programming language. The project

Nov 28, 2022
JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, RTAS and AAX audio plug-ins.
JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, RTAS and AAX audio plug-ins.

JUCE is an open-source cross-platform C++ application framework used for rapidly developing high quality desktop and mobile applications, including VS

Dec 1, 2022
A toolkit for making real world machine learning and data analysis applications in C++

dlib C++ library Dlib is a modern C++ toolkit containing machine learning algorithms and tools for creating complex software in C++ to solve real worl

Nov 24, 2022
Easy to use, header only, macro generated, generic and type-safe Data Structures in C
Easy to use, header only, macro generated, generic and type-safe Data Structures in C

C Macro Collections Easy to use, header only, macro generated, generic and type-safe Data Structures in C. Table of Contents Installation Contributing

Nov 23, 2022
A collection of single-file C libraries. (generic containers, random number generation, argument parsing and other functionalities)

cauldron A collection of single-file C libraries and tools with the goal to be portable and modifiable. Libraries library description arena-allocator.

Oct 26, 2022
C++ Parallel Computing and Asynchronous Networking Engine

As Sogou`s C++ server engine, Sogou C++ Workflow supports almost all back-end C++ online services of Sogou, including all search services, cloud input method,online advertisements, etc., handling more than 10 billion requests every day. This is an enterprise-level programming engine in light and elegant design which can satisfy most C++ back-end development requirements.

Nov 25, 2022
Idle is an asynchronous and hot-reloadable C++ dynamic component framework
Idle is an asynchronous and hot-reloadable C++ dynamic component framework

Idle is an asynchronous, hot-reloadable, and highly reactive dynamic component framework similar to OSGI that is: ?? Modular: Your program logic is en

Nov 29, 2022
EASTL stands for Electronic Arts Standard C++ Template Library

EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.

Nov 23, 2022
High Performance 3D Game Engine, with a high emphasis on Rendering
High Performance 3D Game Engine, with a high emphasis on Rendering

Electro High Performance 3D Game Engine, with a high emphasis on Rendering MainFeatures Rendering PBR Renderer (Cook–Torrance GGX) IBL (Image Based Li

Sep 27, 2022
GWork is a skinnable, embeddable GUI library with an extensive control set

GWork is a skinnable, embeddable GUI library with an extensive control set. Control rendering is abstracted, and can be implemented by any application wishing to use the library. Gwork (pronounced "gw-orc") is a fork of the GUI library GWEN. It was forked to fix issues with GWEN and add new features.

Nov 24, 2022
RRxIO - Robust Radar Visual/Thermal Inertial Odometry: Robust and accurate state estimation even in challenging visual conditions.
RRxIO - Robust Radar Visual/Thermal Inertial Odometry: Robust and accurate state estimation even in challenging visual conditions.

RRxIO - Robust Radar Visual/Thermal Inertial Odometry RRxIO offers robust and accurate state estimation even in challenging visual conditions. RRxIO c

Nov 11, 2022
HDRView is a simple research-oriented image viewer with an emphasis on examining and comparing high-dynamic range (HDR) images
HDRView is a simple research-oriented image viewer with an emphasis on examining and comparing high-dynamic range (HDR) images

HDRView is a simple research-oriented high-dynamic range image viewer with an emphasis on examining and comparing images, and including minimalistic tonemapping capabilities. HDRView currently supports reading EXR, PNG, TGA, BMP, HDR, JPG, GIF, PNM, PFM, and PSD images and writing EXR, HDR, PNG, TGA, PPM, PFM, and BMP images.

Nov 23, 2022