Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for unordered_map #7

Closed
rosshadden opened this issue Apr 20, 2017 · 2 comments
Closed

Support for unordered_map #7

rosshadden opened this issue Apr 20, 2017 · 2 comments

Comments

@rosshadden
Copy link

rosshadden commented Apr 20, 2017

I noticed not all of the STL types are present, like unordered_map for example. Are these planned for the future?

@mike-matera
Copy link
Owner

Hi!

Thanks for the comment. Most of the STL comes from the upstream project:

https://git.uclibc.org/uClibc++

That's the right place to ask for STL features. I've sent them patches to them but I never heard back. According to their git they're still developing so I don't want to make too many changes that might conflict with upstream. Sorry!

@rosshadden
Copy link
Author

Okay, thanks for the explanation.

mike-matera pushed a commit that referenced this issue Jan 3, 2022
The `carlosperate/download-file-action` action is used in the GitHub Actions workflows as a convenient way to download
external resources.

A major version ref has been added to that repository. It will always point to the latest release of the "1" major
version series. This means it is no longer necessary to do a full pin of the action version in use as before.

Use of the major version ref will cause the workflow to use a stable version of the action, while also benefiting from
ongoing development to the action up until such time as a new major release of an action is made. At that time we would
need to evaluate whether any changes to the workflow are required by the breaking change that triggered the major
release before manually updating the major ref (e.g., uses: `carlosperate/download-file-action@v2`). I think this
approach strikes the right balance between stability and maintainability for these workflows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants