Your standard library for metaprogramming

Overview

Boost.Hana Version Travis status Appveyor status Try it online Gitter Chat

Your standard library for metaprogramming

Overview

#include <boost/hana.hpp>
#include <cassert>
#include <string>
namespace hana = boost::hana;
using namespace hana::literals;

struct Fish { std::string name; };
struct Cat  { std::string name; };
struct Dog  { std::string name; };

int main() {
  // Sequences capable of holding heterogeneous objects, and algorithms
  // to manipulate them.
  auto animals = hana::make_tuple(Fish{"Nemo"}, Cat{"Garfield"}, Dog{"Snoopy"});
  auto names = hana::transform(animals, [](auto a) {
    return a.name;
  });
  assert(hana::reverse(names) == hana::make_tuple("Snoopy", "Garfield", "Nemo"));

  // No compile-time information is lost: even if `animals` can't be a
  // constant expression because it contains strings, its length is constexpr.
  static_assert(hana::length(animals) == 3u, "");

  // Computations on types can be performed with the same syntax as that of
  // normal C++. Believe it or not, everything is done at compile-time.
  auto animal_types = hana::make_tuple(hana::type_c<Fish*>, hana::type_c<Cat&>, hana::type_c<Dog*>);
  auto animal_ptrs = hana::filter(animal_types, [](auto a) {
    return hana::traits::is_pointer(a);
  });
  static_assert(animal_ptrs == hana::make_tuple(hana::type_c<Fish*>, hana::type_c<Dog*>), "");

  // And many other goodies to make your life easier, including:
  // 1. Access to elements in a tuple with a sane syntax.
  static_assert(animal_ptrs[0_c] == hana::type_c<Fish*>, "");
  static_assert(animal_ptrs[1_c] == hana::type_c<Dog*>, "");

  // 2. Unroll loops at compile-time without hassle.
  std::string s;
  hana::int_c<10>.times([&]{ s += "x"; });
  // equivalent to s += "x"; s += "x"; ... s += "x";

  // 3. Easily check whether an expression is valid.
  //    This is usually achieved with complex SFINAE-based tricks.
  auto has_name = hana::is_valid([](auto&& x) -> decltype((void)x.name) { });
  static_assert(has_name(animals[0_c]), "");
  static_assert(!has_name(1), "");
}

Documentation

You can browse the documentation online at http://boostorg.github.io/hana. The documentation covers everything you should need including installing the library, a tutorial explaining what Hana is and how to use it, and an extensive reference section with examples. The remainder of this README is mostly for people that wish to work on the library itself, not for its users.

An offline copy of the documentation can be obtained by checking out the gh-pages branch. To avoid overwriting the current directory, you can clone the gh-pages branch into a subdirectory like doc/html:

git clone http://github.com/boostorg/hana --branch=gh-pages --depth=1 doc/html

After issuing this, doc/html will contain exactly the same static website that is available online. Note that doc/html is automatically ignored by Git so updating the documentation won't pollute your index.

Hacking on Hana

Setting yourself up to work on Hana is easy. First, you will need an installation of CMake. Once this is done, you can cd to the root of the project and setup the build directory:

mkdir build
cd build
cmake ..

Usually, you'll want to specify a custom compiler because the system's compiler is too old:

cmake .. -DCMAKE_CXX_COMPILER=/path/to/compiler

Usually, this will work just fine. However, on some systems, the standard library and/or compiler provided by default does not support C++14. If this is your case, the wiki has more information about setting you up on different systems.

Normally, Hana tries to find Boost headers if you have them on your system. It's also fine if you don't have them; a few tests requiring the Boost headers will be disabled in that case. However, if you'd like Hana to use a custom installation of Boost, you can specify the path to this custom installation:

cmake .. -DCMAKE_CXX_COMPILER=/path/to/compiler -DBOOST_ROOT=/path/to/boost

You can now build and run the unit tests and the examples:

cmake --build . --target check

You should be aware that compiling the unit tests is pretty time and RAM consuming, especially the tests for external adapters. This is due to the fact that Hana's unit tests are very thorough, and also that heterogeneous sequences in other libraries tend to have horrible compile-time performance.

There are also optional targets which are enabled only when the required software is available on your computer. For example, generating the documentation requires Doxygen to be installed. An informative message will be printed during the CMake generation step whenever an optional target is disabled. You can install any missing software and then re-run the CMake generation to update the list of available targets.

Tip

You can use the help target to get a list of all the available targets.

If you want to add unit tests or examples, just add a source file in test/ or example/ and then re-run the CMake generation step so the new source file is known to the build system. Let's suppose the relative path from the root of the project to the new source file is path/to/file.cpp. When you re-run the CMake generation step, a new target named path.to.file will be created, and a test of the same name will also be created. Hence,

cd build # Go back to the build directory
cmake --build . --target path.to.file # Builds the program associated to path/to/file.cpp
ctest -R path.to.file # Runs the program as a test

Tip for Sublime Text users

If you use the provided hana.sublime-project file, you can select the "[Hana] Build current file" build system. When viewing a file to which a target is associated (like a test or an example), you can then compile it by pressing ⌘B, or compile and then run it using ⇧⌘B.

Project organization

The project is organized in a couple of subdirectories.

  • The benchmark directory contains compile-time and runtime benchmarks to make sure the library is as fast as advertised. The benchmark code is written mostly in the form of eRuby templates. The templates are used to generate C++ files which are then compiled while gathering compilation and execution statistics.
  • The cmake directory contains various CMake modules and other scripts needed by the build system.
  • The doc directory contains configuration files needed to generate the documentation. The doc/html subdirectory is automatically ignored by Git; you can conveniently store a local copy of the documentation by cloning the gh-pages branch into that directory, as explained above.
  • The example directory contains the source code for all the examples of both the tutorial and the reference documentation.
  • The include directory contains the library itself, which is header only.
  • The test directory contains the source code for all the unit tests.

Contributing

Please see CONTRIBUTING.md.

License

Please see LICENSE.md.

Releasing

To release a new version of Hana, use the util/release.sh script. The script will merge develop to master, create a tag on master and then bump the version on develop. The tag on master will be annotated with the contents of the RELEASE_NOTES.md file. Once the release.sh script has been run, the master and develop branches should be pushed manually, as well as the tag that was created on master. Finally, create a GitHub release pointing to the new tag on master.

Comments
  • [Build] Boost::Hana on Windows with Clang 3.7.0 using MinGW64 and Visual Studio 2015

    [Build] Boost::Hana on Windows with Clang 3.7.0 using MinGW64 and Visual Studio 2015

    More a success story than issue: I've been building Hana with Clang 3.7.0 (libstdc++ of gcc 5.2.0), both provided by MinGW64, and it compiled and ran all tests and examples successfully (917 of 917), with and without exceptions enabled, respectively.

    Secondly, I've tried LLVM/Clang on Windows with the prebuilt windows binaries from http://llvm.org/releases/download.html . After generating the solution with cmake, changing manually the platform toolset to LLVM-vs2014, I chose manually some of the tests and examples, and compiled and ran them successfully. This includes the known difficult tests with type traits and the 9 parts of tuple tests. The build is a bit verbose due to some warnings about unrequired compiler flags, and features being GNU extensions, such like string literals. To my surprise, even the VS debugger works with the Clang-generated binaries... Unfortunately I'm not too familiar with the Visual Studio toolchain, so I can't provide a patch for the cmake scripts or to automate the testing framework. At least not in the near future.

    Anyway, I'd say there are now at least two possible ways to use Boost::Hana on Windows. And Cygwin should also work fine once GCC is upgraded from 4.9.3 to 5.2.0 or higher.

    opened by m-j-w 41
  • Function objects should have a unique address

    Function objects should have a unique address

    When used from different translation units, function objects should resolve to the same address. In other words, we want boost::hana::drop to have the same address in all translation units. This is related to #75.

    bug 
    opened by ldionne 28
  • Support of c++20

    Support of c++20

    If i turning on support of c++20 on my compiler(msvc) i've got errors:

    1> d:\libraries\boost_1_72_0\boost\hana\traits.hpp(71,62): error C2039: 'is_literal_type': is not a member of 'std'

    1> d:\libraries\boost_1_72_0\boost\hana\traits.hpp(197,50): error C2039: 'result_of': is not a member of 'std'

    because above traits removed in c++20...and std::is_pod is deprecated!

    opened by fsmoke 24
  • tag discriminated types?

    tag discriminated types?

    Is there an easy way to use tags to discriminate types but still retain the original functionality with functions that don't support the tags?

    Consider the overview example which I've modified with pseudocode demonstrating what I wish to do. Is there a way to do something like:

    #include <boost/hana.hpp>
    #include <boost/hana/ext/std/type_traits.hpp>
    #include <cassert>
    #include <string>
    using namespace boost::hana;
    using namespace boost::hana::literals;
    
    struct Fish{};
    struct Cat{};
    struct Dog{};
    
    tag<std::string,Fish> FishStr;
    tag<std::string,Cat> CatStr;
    tag<std::string,Dog> DogStr;
    
    int main() {
      // Sequences capable of holding heterogeneous objects, and algorithms
      // to manipulate them.
      auto animals = make_tuple(FishStr{"Nemo"}, CatStr{"Garfield"}, DogStr{"Snoopy"});
      auto names = transform(animals, [](auto a) {
        return a;
      });
      assert(reverse(names) == make_tuple("Snoopy", "Garfield", "Nemo"));
      auto fish = filter(animal_types, [](auto a) {
        return traits::is_tagged(a,Fish());
      });
      static_assert(fish == make_tuple(type<FishStr>), "");
    }
    

    I don't think this would compile, but is there something to that effect available in the repository?

    question 
    opened by ahundt 21
  • gcc-6 can now build most of the testsuite successfully

    gcc-6 can now build most of the testsuite successfully

    gcc-6 can now build most of the Hana testsuite successfully, see: http://www.boost.org/development/tests/develop/developer/hana.html (trippels-powerpc64le-gcc-6.0 column)

    Maybe it is time to remove the gcc warning:

    warning "You appear to be using GCC, which is not supported by Hana yet."?

    opened by octoploid 20
  • Poll: Let's find a name for foldl and foldr

    Poll: Let's find a name for foldl and foldr

    It was suggested on the Boost mailing list that foldl and foldr were ugly. Let's settle this with a poll. Leave a comment to vote for an option or to propose a new option.

    Since there are also foldl1 and foldr1, which are equivalent to foldl and foldr but do not take an initial state, it seems legitimate to ask that a valid naming convention also accounts for them. Here are the current propositions:

    1. foldl/foldr/foldl1/foldr1 (as is)
    2. fold/reverse_fold/??/??
    3. fold_left/fold_right/??/??
    4. fold.left/fold.right/??/?? (optionally, we could have fold == fold.left)
    help wanted poll 
    opened by ldionne 16
  • Policy for returning references and copies

    Policy for returning references and copies

    Currently, Hana does not make any guarantee about what is returned from methods like at or at_key. Indeed, the documentation for at_key just says

    Returns the value associated to the given key in a structure, or fail.

    This makes no guarantee that a reference to the value in the map should be returned. Indeed, the following code currently fails because at_key returns a copy of the value, which is a temporary int:

    #include <boost/hana.hpp>
    using namespace boost::hana;
    
    int main() {
        auto map = make_map(
            make_pair(int_<0>, 0)
        );
        map[int_<0>] = 3;
    }
    

    The error is:

    error: expression is not assignable
        map[int_<0>] = 3;
        ~~~~~~~~~~~~ ^
    

    This causes serious usability problems. On the other hands, if we had a special Iterable generating values on the fly (for example an infinite Iterable generating the fibonacci sequence), we wouldn't be able to return a reference. Hence, the resolution is not exactly clear.

    Another related problem is to determine a policy for when to return a container of references. For example, consider the following code, which was submitted to me in a private email:

    #include <boost/hana.hpp>
    #include <iostream>
    using namespace boost::hana;
    using namespace boost::hana::literals;
    
    struct Person {
        BOOST_HANA_DEFINE_STRUCT(Person,
            (int, age)
        );
    };
    
    int main() {
     Person john{30};
     members(john)[0_c] = 0;
     // fails because the expression is not assignable
    }
    

    This is because members returns a container holding copies of the members of the struct, not references to it. While it seems that it would be more useful to return a sequence of references, it would also create lifetime issues when the Person is a temporary.

    bug 
    opened by ldionne 15
  • [functional] [test] hana::partial re-forwarding (what were originally) rvalue references can bind to non-const lvalue reference overloads

    [functional] [test] hana::partial re-forwarding (what were originally) rvalue references can bind to non-const lvalue reference overloads

    Is this intended behavior? I was expecting it to bind to the const lvalue reference overload instead of the && overload, since I assume you want a partial object to remain idempotent - but I was not expecting the non-const lvalue reference overload.

    Repro - the side effects probably don't matter here, but I always like to have them when testing just to be sure, and so I can print the call counts whenever:

    #include <iostream>
    #include <boost/hana.hpp>
    
    struct bar {
    
        static int move_count;
        static int copy_count;
    
        bar() = default;
    
        bar(const bar&) {
            copy_count++;
        }
    
        bar(bar&&) {
            move_count++;
        }
    };
    
    int bar::move_count = 0;
    int bar::copy_count = 0;
    
    struct print_overload_t {
    
        void operator()(bar& f) {
            std::cout << "bar&" << std::endl;
        }
    
        void operator()(const bar& f) {
            std::cout << "const bar&" << std::endl;
    
        }
        void operator()(bar&& f) {
            std::cout << "bar&&" << std::endl;
        }
    
    };
    
    int main() {
        auto print_overload = print_overload_t{};
        auto p = boost::hana::partial(print_overload, bar{});
    
        print_overload(bar{});
        p();
    
        std::cin.get();
        return 0;
    }
    

    By the way, I studied your implementation of partial for a bit, and it's the coolest few lines of C++ I think I've ever read. The way you forward from the templated "secret" constructor back into the class template types so you can store the forwarded values is staggeringly creative. I've been trying to think of a way to do exactly that, and I never would've thought of that trick. It took me a few double takes to realize what you were doing.

    wontfix 
    opened by badair 14
  • Provide to_xxx equivalent for to<xxx_tag>

    Provide to_xxx equivalent for to

    As you suggested via email, this is a WIP pull request.

    • adding to_map
    • adding to_set
    • adding to_tuple

    WIP - need to add documentation in fwd headers... Suggestions? I've never used Doxygen before.

    WIP - remove doc comments in this commit?

    WIP - to_type mentioned in issue #164 - is this necessary? Why not just use to? Do we want to add STL extensions (to_vector, etc) instead?

    feature 
    opened by badair 14
  • Naive questions about hana::map

    Naive questions about hana::map

    Hi, I'm considering using hana::map to implement a container that zips together a list of objects of different types and allows the user to access the objects by the "tag" of these types in an expressive way. Here's what I've come up so far:

    #include<iostream>
    #include <typeinfo>
    #include <boost/hana.hpp>
    #include <string>
    #include <utility>
    namespace hana = boost::hana;
    
    using namespace std;
    
    struct Name {
      using value_type = std::string;
    };
    
    auto name = hana::type_c<Name>;
    
    struct Age {
      using value_type = int;
    };
    
    auto age = hana::type_c<Age>;
    
    template < class ... Args >
    auto create_person(Args&&...args) {
      return hana::make_map(
          hana::make_pair(
            std::forward<Args>(args), 
            typename std::decay_t<Args>::type::value_type())
          ...
      );
    }
    
    int main(int argc, char* argv[]) {
      auto person = create_person(name,age);
      person[name] = "John"; 
      person[age] = 30; 
      cout << person[name] << ", " << person[age] << endl; 
    }
    

    My questions are:

    1. Is there any runtime overhead in looking the value by key in the map object in general? i.e., person[name] = "John"; should be equivalent to simply mutating a std::string object in terms of runtime performance. I assume the answer is no but I want to make sure that's true in general even if Name::value_type or Age::value_type is more complicated object.
    2. Should perfect forwarding be avoided when passing the type constant to hana's metafunctions as in the above create_person example?
    3. Is this the best way of doing it? I'm totally new to this library and suggestions are welcome.
    opened by Char-Aznable 13
  • Accessing map with result of `decltype_` does not compile

    Accessing map with result of `decltype_` does not compile

    I am trying to index into a hana::map using the result of hana::decltype_ and iterating over the contents of a tuple.

    My understanding was that hana::decltype_ produces a hana::type_c, which seemed to be suitable for indexing into my map. I have also tried constructing a key using language decltype and wrapping that in type_c, but I got the same error.

    Is this incorrect usage?

    #include <iostream>
    #include <boost/hana.hpp>
    
    namespace hana = boost::hana;
    
    enum Id : uint8_t {
      a, b, c
    };
    
    constexpr auto id_map = hana::make_map(
        hana::make_pair(hana::type_c<std::string>, Id::a),
        hana::make_pair(hana::type_c<int>, Id::b),
        hana::make_pair(hana::type_c<bool>, Id::c)
      );
    
    int main() {
      hana::tuple<std::string, int, bool> types_tuple;
    
      hana::for_each(types_tuple, [](const auto & x) {
        std::cout << "ID is: " << id_map[hana::decltype_(x)] << std::endl;
      });
    }
    

    Gives this error in clang 3.8 (truncated significantly), on current master:

    /home/jackie/code/cmbml/external/hana/include/boost/hana/optional.hpp:108:9: error: static_assert
          failed "hana::optional::operator* requires a non-empty optional"
            static_assert(detail::wrong<dummy...>{},
            ^             ~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/jackie/code/cmbml/external/hana/include/boost/hana/map.hpp:358:52: note: in instantiation of
          function template specialization 'boost::hana::optional<>::operator*<>' requested here
                constexpr std::size_t index = decltype(*MaybeIndex{}){}();
                                                       ^
    /home/jackie/code/cmbml/external/hana/include/boost/hana/at_key.hpp:49:23: note: in instantiation
          of function template specialization 'boost::hana::at_key_impl<boost::hana::map_tag,
          void>::apply<const
          boost::hana::map<boost::hana::detail::hash_table<boost::hana::detail::bucket<std::__cxx11::basic_string<char>,
          0>, boost::hana::detail::bucket<int, 1>, boost::hana::detail::bucket<bool, 2> >,
          boost::hana::basic_tuple<boost::hana::pair<boost::hana::type_impl<std::__cxx11::basic_string<char>
          >::_, Id>, boost::hana::pair<boost::hana::type_impl<int>::_, Id>,
          boost::hana::pair<boost::hana::type_impl<bool>::_, Id> > > &, boost::hana::type_impl<const
          std::__cxx11::basic_string<char> >::_>' requested here
            return AtKey::apply(static_cast<Xs&&>(xs), key);
                          ^
    

    And a bit further down:

    In file included from /home/jackie/code/cmbml/external/hana/include/boost/hana.hpp:133:
    /home/jackie/code/cmbml/external/hana/include/boost/hana/map.hpp:358:66: error: illegal initializer
          type 'decltype(* MaybeIndex{})' (aka 'void')
                constexpr std::size_t index = decltype(*MaybeIndex{}){}();
                                                                     ^
    /home/jackie/code/cmbml/external/hana/include/boost/hana/at_key.hpp:49:23: note: in instantiation
          of function template specialization 'boost::hana::at_key_impl<boost::hana::map_tag,
          void>::apply<const
          boost::hana::map<boost::hana::detail::hash_table<boost::hana::detail::bucket<std::__cxx11::basic_string<char>,
          0>, boost::hana::detail::bucket<int, 1>, boost::hana::detail::bucket<bool, 2> >,
          boost::hana::basic_tuple<boost::hana::pair<boost::hana::type_impl<std::__cxx11::basic_string<char>
          >::_, Id>, boost::hana::pair<boost::hana::type_impl<int>::_, Id>,
          boost::hana::pair<boost::hana::type_impl<bool>::_, Id> > > &, boost::hana::type_impl<const
          std::__cxx11::basic_string<char> >::_>' requested here
            return AtKey::apply(static_cast<Xs&&>(xs), key);
    
    opened by jacquelinekay 13
  • Add vcpkg installation instructions

    Add vcpkg installation instructions

    hana is available as a port in vcpkg, a C++ library manager that simplifies installation for hana and other project dependencies. Documenting the install process here will help users get started by providing a single set of commands to build hana, ready to be included in their projects.

    We also test whether our library ports build in various configurations (dynamic, static) on various platforms (OSX, Linux, Windows: x86, x64) to keep a wide coverage for users.

    I'm a maintainer for vcpkg, and here is what the port script looks like. We try to keep the library maintained as close as possible to the original library.😊

    opened by FrankXie05 0
  • boost::hana::drop_front doesn't respect refness

    boost::hana::drop_front doesn't respect refness

    #include <boost/hana/ext/std/tuple.hpp>
    #include <boost/hana/fold_left.hpp>
    #include <boost/hana/find_if.hpp>
    #include <boost/hana/for_each.hpp>
    #include <boost/hana/transform.hpp>
    #include <boost/hana/tuple.hpp>
    #include <boost/hana/type.hpp>
    
    #include <iostream>
    #include <tuple>
    #include <vector>
    
    namespace hana = boost::hana;
    
    int main()
    {
        int x = 1;
        int y = 2;
        int z = 3;
    
        std::tuple<int&, int&, int&> refs {x, y, z};
        auto ref_drop = boost::hana::drop_front(refs);
    
        x = 10;
        y = 20;
        z = 30;
    
        std::cout << x << " " << y << " " << z << std::endl;
        std::cout << std::get<0>(refs) << " " << std::get<1>(refs) << " " << std::get<2>(refs) << std::endl;
        std::cout << std::get<0>(ref_drop) << " " << std::get<1>(ref_drop) << std::endl;
    }
    

    The output of the above code is:

    10 20 30
    10 20 30
    2 3
    

    Expected output is:

    10 20 30
    10 20 30
    20 30
    

    I would expect if I pass boost::hana::drop_front a std::tuple<T&, U&, V&> to get back a std::tuple<U&, V&> but instead I get a std::tuple<U, V>. This is unexpected. Is this intended behavior?

    opened by KierenP 1
  • Circular dependency of boost/hana/concept/struct.hpp and boost/hana/accessors.hpp breaks tooling

    Circular dependency of boost/hana/concept/struct.hpp and boost/hana/accessors.hpp breaks tooling

    Title says it all

    <boost/hana/concept/struct.hpp> includes <boost/hana/accessors.hpp>... which includes <boost/hana/concept/struct.hpp>.

    Is this intentional? It doesn't cause build errors (at least on linux, GCC/Clang), but it breaks tooling like clangd and clang-tidy

    opened by braxtons12 0
  • Get warnings with clang14

    Get warnings with clang14

    I now get this warning a lot

    fast_and

     /scratch/prudhomm/feelpp/feelpp/contrib/boost/hana/include/boost/hana/detail/fast_and.hpp:21:50: warning: left operand of comma operator has no effect [-Wunused-value]
    [build]         : std::is_same<fast_and<b...>, fast_and<(b, true)...>>
    

    make

    [build] /scratch/prudhomm/feelpp/feelpp/contrib/boost/hana/include/boost/hana/core/make.hpp:35:28: warning: left operand of comma operator has no effect [-Wunused-value]
    [build]             static_assert((sizeof...(X), false),
    [build]                            ^~~~~~~~~~~~
    

    any idea how to remove this ?

    opened by prudhomm 1
  • Cast to void on discarded LHS of comma operator

    Cast to void on discarded LHS of comma operator

    to avoid warnings in clang 14:

    In file included from test/headers/boost/hana/any.cpp:1:
    In file included from include/boost/hana/any.hpp:15:
    In file included from include/boost/hana/any_of.hpp:16:
    In file included from include/boost/hana/at.hpp:16:
    In file included from include/boost/hana/concept/iterable.hpp:20:
    In file included from include/boost/hana/drop_front.hpp:20:
    In file included from include/boost/hana/integral_constant.hpp:13:
    In file included from include/boost/hana/bool.hpp:17:
    In file included from include/boost/hana/core/to.hpp:21:
    include/boost/hana/core/make.hpp:35:28: error: left operand of comma operator has no effect [-Werror,-Wunused-value]
                static_assert((sizeof...(X), false),
                               ^~~~~~~~~~~~
    
    opened by ecatmur 1
Releases(v1.7.0)
  • v1.7.0(Sep 3, 2020)

  • v1.6.1(Aug 26, 2020)

    • Official support for Xcode 6, 7 and 8, 9, 10 and LLVM Clang 3.5, 3.6, 3.7, and 3.8 has has been dropped. The library should still work with these compilers, however they are not being tested regularly anymore, so they are not officially supported.

    • The hana::traits::result_of trait has been removed. Since std::result_of has been removed from the Standard in C++20, users should move away from it.

    Source code(tar.gz)
    Source code(zip)
  • v1.5.0(Jul 6, 2018)

    Hana v1.5.0, synced with Boost 1.68.0

    This release contains:

    • Make metafunction & friends SFINAE friendly
    • Add experimental::Printable support for Visual C++
    • Some containers were made final, which may cause code that made valid assumptions about the representation of those containers to break. This is not a breaking change per se because this was never guaranteed by the library, but it may nonetheless affect some users.
    Source code(tar.gz)
    Source code(zip)
  • v1.4.0(Feb 27, 2018)

    • Added the 'take_back_c' function (#372)
    • Remove the limitation on the number of members for struct macros (#376)
    • Add a way to create a hana::string from a constexpr char const* (#347)
    • Fix ambiguous conversion to the underlying type of integral_constants (#354)
    • Bumped minimum CMake version to 3.9
    • Various improvements to the CI
    Source code(tar.gz)
    Source code(zip)
  • v1.3.0(Nov 12, 2017)

  • v1.2.0(Jun 29, 2017)

    This release contains

    • Added support for set-theoretic operations on hana::map (see PR #350)
    • Added the index_if function; like find_if but returns an optional index instead of an optional value
    • various bug fixes
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Feb 26, 2017)

    This release contains various bug fixes. The main improvement is better support for empty base optimization in hana::pair, which should make it easier for the compiler to optimize Hana away, at the cost of worst compile-times.

    Source code(tar.gz)
    Source code(zip)
  • v1.0.2(Jan 7, 2017)

  • v1.0.1(Aug 24, 2016)

  • v1.0.0(May 13, 2016)

    First stable release of Hana

    This tag marks the first stable release of Hana, and the release of Hana inside Boost 1.61.0. From this moment on, interface stability is assured inside major version numbers, as required by Semantic Versioning.

    Source code(tar.gz)
    Source code(zip)
  • v0.7.0(Feb 17, 2016)

    This pre-release implements many improvements, the most notable being compile-time hash tables for implementing hana::map. This should provide a significant compile-time improvement to users of hana::map.

    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Nov 19, 2015)

    While Hana will not be released with Boost 1.60.0, this release represents the state of Hana as of the release of Boost 1.60.0. Of course, we're still in 0.xx.yy, so don't expect any of this to be stable :-).

    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Oct 29, 2015)

  • v0.4.0(Jun 9, 2015)

    This release is for the Boost formal review that will be taking place from June 10 to June 24. During this time (and starting now), the master branch will be frozen to let the reviewers do their work.

    Source code(tar.gz)
    Source code(zip)
  • v0.3.0(Jun 3, 2015)

    We're one week away from the formal review! Major changes have been done to the documentation, and the code is even more stable than before.

    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Apr 22, 2015)

    This release is the first of a couple that should converge towards v1.0.0 right after the formal review in next June.

    [Edit: In the end, v1.0 will wait for Hana's first release alongside with Boost]

    Source code(tar.gz)
    Source code(zip)
Owner
Boost.org
Boost provides free peer-reviewed portable C++ source libraries.
Boost.org
libcu++: The C++ Standard Library for Your Entire System

libcu++, the NVIDIA C++ Standard Library, is the C++ Standard Library for your entire system. It provides a heterogeneous implementation of the C++ Standard Library that can be used in and between CPU and GPU code.

NVIDIA Corporation 2k Sep 29, 2022
Libft is an individual project at 42 that requires us to re-create some standard C library functions including some additional ones that can be used later to build a library of useful functions for the rest of the program.

?? Index What is Libft? List of Functions Technologies ✨ What is Libft? Libft is an individual project at 42 that requires us to re-create some standa

Paulo Rafael Ramalho 7 Jan 17, 2022
Thrust is a C++ parallel programming library which resembles the C++ Standard Library.

Thrust: Code at the speed of light Thrust is a C++ parallel programming library which resembles the C++ Standard Library. Thrust's high-level interfac

NVIDIA Corporation 4.2k Sep 27, 2022
jkds is a modern header-only C++20 library that complements the standard library.

jkds is a modern header-only C++20 library that complements the standard library. It provides generic atypical data structures, ergonomic functional programming abstractions, and then some.

Alberto Schiabel 5 May 24, 2022
Bionic BSD-3-ClauseBionic - Google's standard library, developed for Android. BSD-3-Clause

bionic bionic is Android's C library, math library, and dynamic linker. Using bionic as an app developer See the user documentation. Working on bionic

Android Open Source Project 552 Sep 28, 2022
CloudABI's standard C library

NOTE: This project is unmaintained CloudABI is no longer being maintained. It was an awesome experiment, but it never got enough traction to be sustai

Nuxi 272 Sep 15, 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.

Electronic Arts 6.7k Oct 2, 2022
An open source standard C library that includes useful functions && (Reimplementation of libc functions + own functions).

?? LIBFT-42 : Artistic view of LIBC: ?? HOW DOES IT FEEL HAVING YOUR OWN LIB: SUBJECT : ENGLISH PDF ℹ️ What is LIBFT : This project aims to code a C l

Abdessamad Laamimi 11 Sep 21, 2022
Reimplementation of some of the Standard C Library functions.

42-libft Reimplementation of some of the Standard C Library functions. This repository contains some of the standard library C functions. List of avai

Lavrenova Maria 6 Sep 29, 2022
STXXL: Standard Template Library for Extra Large Data Sets

STXXL is an implementation of the C++ standard template library STL for external memory (out-of-core) computations

STXXL 431 Sep 24, 2022
MSVC's implementation of the C++ Standard Library.

Microsoft's C++ Standard Library This is the official repository for Microsoft's implementation of the C++ Standard Library (also known as the STL), w

Microsoft 8.2k Oct 3, 2022
mlibc is a C standard library

mlibc is a C standard library Official Discord server: https://discord.gg/7WB6Ur3 Design of the library Directory Purpose options/ (More or less) OS-i

The Managarm Project 524 Sep 29, 2022
A standard conforming C++20 implementation of std::optional.

A standard conforming C++20 implementation of std::optional.

null 31 Aug 24, 2022
This project is pretty straightforward, you have to recode printf. You will learn what is and how to implement variadic functions. Once you validate it, you will reuse this function in your future projects.

100/100 Introduction to ft_printf This is the third project in the 1337 Curriculum #42network . This project is pretty straight forward, recode the pr

Zakaria Yacoubi 4 May 27, 2022
A thread-safe, easy-to-use, utility for sending and receiving notifications. It allows you to decouple different modules of your application.

NotificationManager NotificationManager is a thread-safe, easy-to-use utility for sending and receiving notifications. It allows you to decouple diffe

Carlos Aragonés 6 Dec 27, 2021
Library that simplify to find header for class from STL library.

Library that simplify to find header for class from STL library. Instead of searching header for some class you can just include header with the class name.

null 6 Jun 7, 2022
D++ Extremely Lightweight C++ Discord Library

D++ An incredibly lightweight C++ Discord library This project is in alpha stages of development. Completed so far: Websocket connection with heartbea

brainbox.cc 501 Oct 1, 2022
Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags.

Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags. Quick start #include <bitflags/bitf

Marin Peko 72 Aug 24, 2022
expected lite - Expected objects in C++11 and later in a single-file header-only library

expected lite: expected objects for C++11 and later expected lite is a single-file header-only library for objects that either represent a valid value

Martin Moene 232 Sep 28, 2022