{"id":48454547,"url":"https://github.com/modm-io/avr-libstdcpp","last_synced_at":"2026-04-06T22:03:46.381Z","repository":{"id":40428086,"uuid":"148344932","full_name":"modm-io/avr-libstdcpp","owner":"modm-io","description":"Subset of the C++ standard library for AVR targets","archived":false,"fork":false,"pushed_at":"2025-05-24T06:46:30.000Z","size":2130,"stargazers_count":75,"open_issues_count":5,"forks_count":28,"subscribers_count":17,"default_branch":"master","last_synced_at":"2025-05-24T07:36:26.388Z","etag":null,"topics":["avr","cpp","stdlib"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/modm-io.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"COPYING.MPLv2","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-09-11T16:13:25.000Z","updated_at":"2025-05-24T06:46:35.000Z","dependencies_parsed_at":"2024-04-20T11:33:03.012Z","dependency_job_id":"00840ff1-3b6f-4cca-8669-e1ef44bc4cbc","html_url":"https://github.com/modm-io/avr-libstdcpp","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/modm-io/avr-libstdcpp","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/modm-io%2Favr-libstdcpp","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/modm-io%2Favr-libstdcpp/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/modm-io%2Favr-libstdcpp/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/modm-io%2Favr-libstdcpp/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/modm-io","download_url":"https://codeload.github.com/modm-io/avr-libstdcpp/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/modm-io%2Favr-libstdcpp/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31491098,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-06T17:22:55.647Z","status":"ssl_error","status_checked_at":"2026-04-06T17:22:54.741Z","response_time":112,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["avr","cpp","stdlib"],"created_at":"2026-04-06T22:03:45.831Z","updated_at":"2026-04-06T22:03:46.374Z","avatar_url":"https://github.com/modm-io.png","language":"C++","readme":"# avr-libstdcpp: libstdc++ port for avr-gcc\n[![Build Status](https://github.com/modm-io/avr-libstdcpp/actions/workflows/compile_examples.yml/badge.svg)](https://github.com/modm-io/avr-libstdcpp/actions)\n==================\n\n`avr-libstdcpp` is a partial, non-fully-tested\nimplementation of the C++ standard library and its STL.\nIt is intended to be used with `avr-gcc`.\n\nMany features of modern C++11,14,17 and 20 are supported.\n\n`avr-gcc` does not have a complete C++ standard library nor does it include an STL implementation.\nThe `avr-libstdcpp` port (even though not-fully-tested\nand only partially full/complete) will, nonetheless,\nbe useful for those interested in making more comprehensive utilization\nof C++, including its standard library, with a modern `avr-gcc` compiler.\n\n## Historical origins\n\nThe `avr-libstdcpp` library traces its own origins to existing\nGNU/GCC C++ standard library implementation(s), themselves targeting\nembedded systems. This work is essentially an even-more\n_embedded_-_friendly_ adaptation of the aforementioned work.\n\nThe `avr-libstdcpp` port began in 2018 with an initial import\nof a GNU/GCC-based C++ standard library from GCC 8.\nA second import of a GNU/GCC-based C++ standard library from GCC 10\nin 2020 modernized the port to include many contemporary C++20 features.\n\n## Using the library\n\n- Add the `avr-libstdcpp/include` path to the standard `-isystem` (or `-I`) include path(s) of the compiler on the command line.\n- Upon doing this, include standard library headers in the usual way (i.e., `#include \u003calgorithm\u003e`,  `#include \u003carray\u003e`,  `#include \u003ccstdint\u003e`, etc.).\n- There are also several source files located in the [src directory](./src). Some of these may potentially be needed.\n- For instance, when doing floating-point mathematical calculations with the `\u003ccmath\u003e` library, the file [`math.cc`](./src/math.cc) located [here](./src) needs to be added as a normal source file to your project.\n\n\nFor straightforward header-only use, for example,\nsimply add the `-isystem` (or alternatively the `-I`) include path\nto your particular location of `avr-libstdcpp/include` on the command line...\n\n```sh\navr-g++ -O2 -x c++ -isystem /my_path/avr-libstdcpp/include -mmcu=atmega328p test.cpp -o test.elf\n```\n\n... and seamlessly use standard library headers in your code.\n\n```cpp\n#include \u003carray\u003e\n#include \u003cnumeric\u003e\n\nstd::array\u003cint, 3U\u003e a { 1, 2, 3 };\n\nint main()\n{\n  // 6\n  auto sum = std::accumulate(a.cbegin(), a.cend(), 0);\n\n  static_cast\u003cvoid\u003e(sum);\n}\n```\n\nAdditional straightforward code samples exercising standard library usage\ncan be found in the [examples](./examples) folder.\n\n## Using the library with MICROCHIP's ATMEL Studio\n\n`avr-libstdcpp` can be successfully used with MICROCHIP's ATMEL Studio.\nThe include path of the headers needs to be added to the project settings in the normal way.\nAdd also any of the necessary source files, as described in the section above.\n\nThis is an advanced use of `avr-libstdcpp` in combination with MICROCHIP's ATMEL Studio\nbecause the underlying GCC compiler used with ATMEL Studio also needs to be\nupgraded to a much more modern one than the `avr-gcc` 5\ndelivered in the standard installation of this studio.\n\nAn [informative thread](https://github.com/modm-io/avr-libstdcpp/issues/17#issuecomment-1098241768)\nprovides a few more details on how to use `avr-libstdcpp` with MICROCHIP's ATMEL Studio.\n\n## Guidance for tiny bare-metal systems\n\n### Very helpful go-to libraries\n\nIn general the C++ standard library is intended\nto be written and implemented in a resource-sensitive\nfashion. This includes efforts to save on both\nmemory as well as run-time.\nIn fact, C++ standard library functions and algorithms\nhave, in general, been specifically written and tuned by\nthe library authors with efficiency aspects in mind.\nIn particular, library components compile reliably and quickly\nand also lend themselves well to compiler optimization.\n\nSome library components, however, are particularly well-suited\nfor bare-metal microcontroller programming.\nThese can be exceptionally helpful when used properly and sensibly\nin tiny bare-metal microcontroller environments.\n\nA subjective list of these the libraries/headers\nand their main uses includes, but is not limited to,:\n\n- `\u003carray\u003e` for containers having known, fixed size.\n- `\u003calgorithm\u003e` for standard algorithms such as sorting, minimax, sequential operations, etc.\n- `\u003ccmath\u003e` for projects requiring floating-point mathematical functions such as `std::sin()`, `std::exp()`, `std::frexp()` and many more. For some mathematical uses, it might be necessary to include [`math.cc`](./src/math.cc) in your project. This source file is located [here](./src).\n- `\u003ccstdint\u003e` which defines integral types having specified widths residing within `namespace std` like `std::uint8_t`.\n- `\u003climits\u003e` offering compile-time query of numeric limits of built-in types.\n- `\u003cnumeric\u003e` featuring a collection of useful numeric algorithms such as `std::accumulate()`, etc.\n- `\u003ctype_traits\u003e` for compile-time decisions based on types.\n\nWith these libraries alone, the entire project can benefit\nfrom a great deal of the standard library's power without compromising\nin any way on performance or sleek memory footprint.\nThis is because these libaries are typically lean, fast and require no additional storage.\n\nThe following non-trivial, real-world example, for instance,\nwraps instances of an overly-simplified LED class abstraction\nas object-references in an `std::array`.\nOnce stored, the application exercises the LED's toggle\nfunction in an algorithmic loop with `toggle()`-method call\nexpressed via lambda function.\n\n```cpp\n#include \u003calgorithm\u003e\n#include \u003carray\u003e\n#include \u003ctype_traits\u003e\n\nclass led\n{\npublic:\n  led() = default;\n\n  auto toggle() -\u003e void { }\n};\n\nled led0;\nled led1;\nled led2;\n\nusing led_ref_type = std::reference_wrapper\u003cled\u003e;\n\nstd::array\u003cled_ref_type, 3U\u003e led_refs =\n{\n  led0,\n  led1,\n  led2\n};\n\nint main()\n{\n  for(;;)\n  {\n    std::for_each(led_refs.begin(),\n                  led_refs.end(),\n                  [](led\u0026 lr) { lr.toggle(); });\n  }\n}\n```\n\nThis nifty little example is terse, expressive and powerful.\nIt makes use of parts of `\u003calgorithm\u003e`, `\u003carray\u003e`  and `\u003ctype_traits\u003e`\nto greatly simplify the programming within a non-trivial\nmicrocontroller situation.\n\nThis example is key because it combines the domains\nof object-oriented programming with the templated\nalgorithms and wrappers of the STL to assist\nin our microcontroller world.\n\n### Libraries requiring more design considerations\n\nSome C++ library and STL artifacts, however,\nrequire more careful design considerations\nregarding memory allocation and management.\n\nConsider, for instance, `std::vector` from the `\u003cvector\u003e` library.\nVector creates a flexibly-sized array-like collection\nof items of any kind, depending on the template parameter.\n\nFor instance:\n\n```cpp\n#include \u003cvector\u003e\n\n// A vector of 3 integers.\nstd::vector\u003cint\u003e v { 1, 2, 3 };\n```\n\nSee also the [main.cpp](./examples/vector/main.cpp) file\nin the [./examples/vector](./examples/vector) directory.\n\nThis vector requires storage for three integers which,\non the `avr-gcc` platform is 6 bytes. The storage is managed\nthrough vector's _second_, less well-known template parameter.\nIn other words,\n\n```cpp\nnamespace std {\n\n// Forward declaration of the vector template class.\ntemplate\u003ctypename T,\n         typename AllocatorType = std::allocator\u003cT\u003e\u003e\nclass vector;\n\n}\n```\n\nUsing containers requires memory allocation with a so-called allocator.\nIf none is specified, as in our code snippet, the default allocator\nfrom namespace `std` for the templated type `T` of the vector is\nautomatically selected.\n\nGood embeddable self-written custom allocators are essential for\nusing such containers so that memory could be managed with\na self-written memory pool, an off-chip memory device, etc.\nA common selection is a pool of static memory creating a so-called\n_ring_ _allocator_. This is an intermetiate/advanced topic\nwhich will refine STL use _on_ _the_ _metal_ and\nalso allow for flexible template use in these resource-sensitive\nrealms.\n\n## Notable adaptions and limitations\n\nSome parts of the C++ standard library are not well suited for\ntiny bare-metal systems. These include some memory-intensive\nand/or hardware-intensive library artifacts.\n\n`avr-libstdcpp` has the following known adaptions and limitations.\n\n- **I/O streaming and RTTI:** I/O streaming and run-time type information (RTTI) are known\nto be resource-intensive and could be disruptive on tiny\nembedded platforms. An effort has been made to essentially\nremove both these library dependencies and their\nassociated codes.\n\n- **exceptions:** Exceptions are also difficult to efficiently\nimplement on tiny embedded platforms and this library port avoids using exceptions.\nThe headers `\u003cstdexcept\u003e` and `\u003cexception\u003e`, their dependencies,\nand their directly relevant code sequences have been removed.\nSimple mechanisms such as those found in `\u003ccassert\u003e`\nand `\u003ccerrno\u003e`, however, remain mostly available.\n\n- **`\u003catomic\u003e`:** The `\u003catomic\u003e` library is being handled\nspecifically in the draft of\n[avr-libstdcpp/pull/36](https://github.com/modm-io/avr-libstdcpp/pull/36).\n\n- **`\u003crandom\u003e`:** There is no source of entropy whatsoever on these platforms\nin their standard configuration. So `std::random_device`\nhas been removed.\n\n- **Hashing:** Hashing has been optimized for tiny architectures and uses a rudimentary 16-bit CRC algorithm.\n\n- **`\u003cchrono\u003e`:** Only certain judiciously selected clock functions from the `\u003cchrono\u003e` library are implemented.\nThese include `std::chrono::high_resolution_clock` and `std::chrono::steady_clock`. When using\nthese clocks, it is required to implement the clock's static method\n`now()` in a project-specific fashion. This is because\nthe library's authors can not in a generic way implement any\nmicrocontroller-specific clock(s) since this requires detailed knowledge\nof the underlying microcontroller peripherie.\n\n- **`int`, `size_t`, `ptrdiff_t` and the like:** Data types such as\n`int`, and `size_t` and `ptrdiff_t` (which are aliased to\n`unsigned`/`signed` versions of `int`)\nare generally limited to 16-bits in width\non tiny `avr-gcc` platforms. Although this is a compiler attribute,\nit has strong influence on the library (particularly the STL)\nimplementation because these data types are used copiously therein.\nThis compiler attribute limits ranges, indexes, etc. to 16-bits.\nWith the compiler switch `-mint8`, the built-in type `int`\nis only 8 bits wide and extreme range limitations\nare expected to make STL use tricky.\n\n- **`\u003ccmath\u003e`:** In `avr-gcc` 10 and higher, the built-in data types\n`double` and `long double` can be either 32 or 64 bits in width.\nThe widths depend on the compiler command line options `-mdouble=32`\n(alternatively `-mdouble=64`) and/or `-mlong-double=32`\n(alternatively `-mlong-double=64`). Standard floating-point\n`\u003ccmath\u003e` functions such as `std::sin()`, `std::cos()`,\n`std::exp()` and the like will, therefore, have input and output\nwidths according to these command line options.\n\n## C++20 `constexpr` support\n\nThe following is a rather advanced, highly useful topic.\nWhen using C++20, `constexpr` construction, assignment and evaluation\nof various algorithms can and often will be generally\ncompile-time constant (i.e, via consistent use of C++20 `constexpr`-ness).\n\nAs a result of this, STL algorithms that use compile-time constant inputs are, in fact,\nevaluated at compile time in C++20. This lets us perform a strong,\npurposeful shift of algorithmic complexity _to_-_the_-_left_.\nIn other words, we shift algorithmic complexity _into_ the compile-time\nstage of code development and _away from_ the precious RAM-ROM-space/cycles\nof the compiled running code.\n\nIn the following code, for instance, we revisit the `std::array`/`\u003cnumeric\u003e`\nexample from above. The variation below exhibits complete compile-time\nevaluation of the algorithmic result.\n\nTo take the deep dive in this topic, follow all the useful compile-time\npreprocessor symbols such as\n`__cpp_lib_constexpr_algorithms`, `__cpp_lib_constexpr_numeric`, and many more\nin [feature testing](https://en.cppreference.com/w/cpp/feature_test).\n\n```cpp\n#include \u003carray\u003e\n#include \u003cnumeric\u003e\n\n#if (defined(__cpp_lib_constexpr_numeric) \u0026\u0026 (__cpp_lib_constexpr_numeric\u003e=201911L))\n#define MODM_CONSTEXPR constexpr\n#define MODM_CONSTEXPR_NUMERIC_IS_CONSTEXPR 1\n#else\n#define MODM_CONSTEXPR\n#define MODM_CONSTEXPR_NUMERIC_IS_CONSTEXPR 0\n#endif\n\nMODM_CONSTEXPR std::array\u003cint, 3U\u003e a { 1, 2, 3 };\n\nint main()\n{\n  // 6\n  auto MODM_CONSTEXPR sum = std::accumulate(a.cbegin(), a.cend(), 0);\n\n  #if (MODM_CONSTEXPR_NUMERIC_IS_CONSTEXPR == 1)\n  static_assert(sum == 6, \"Error: Unexpected std::accumulate result!\");\n  #endif\n\n  return (sum == 6 ? 0 : -1);\n}\n```\n\nSee also the [numeric.cpp](./examples/numeric/numeric.cpp) file\nin the [/examples/numeric](./examples/numeric) directory.\n\n## Additional details\n\n`avr-libstdcpp` is intended for a modern `avr-gcc`\nsuch as the port available in the [modm-io project](https://github.com/modm-io/avr-gcc)\nrepository. Tests show usability for `avr-gcc` 7 through 15.\n\nThis library has been checked for compatibility on `avr-gcc`\nwith language standards C++11,14,17,20,23 and 2c.\n\nUsing the port way back to `avr-gcc` 5 does not work\nat the moment with today's form of the checked-in library,\nand `avr-gcc` 7 or higher is required.\nThis is because the very old compiler lexical parsers are not capable\nof properly handling some of the library's template code.\nSee also [avr-libstdcpp/issues/15](https://github.com/modm-io/avr-libstdcpp/issues/15)\nwhich is closed and includes justification for its closure.\n\n## Licensing\n\nThe library source files in [`src/`](./src/)\nand the library include files in [`include/` and its subfolders](./include/)\n(with two exceptions for the sources, as mentioned below)\nare licensed under [GNU General Public License Version 3](./COPYING3) or higher.\n\nAll of the [example codes](./examples/) and also two library source files\n(namely `functexcept.cc` and `math.cc` in [`src/`](./src/))\nare subject to the terms of the [Mozilla Public License Version 2.0](./COPYING.MPLv2).\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmodm-io%2Favr-libstdcpp","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmodm-io%2Favr-libstdcpp","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmodm-io%2Favr-libstdcpp/lists"}