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

Clang 14 and 15 build error #57

Closed
ivan-volnov opened this issue Dec 7, 2022 · 11 comments
Closed

Clang 14 and 15 build error #57

ivan-volnov opened this issue Dec 7, 2022 · 11 comments

Comments

@ivan-volnov
Copy link

Hello. Thanks for the library!

asio-grpc/src/agrpc/detail/memory_resource.hpp:26:10: fatal error: 'memory_resource' file not found
#include <memory_resource>
         ^~~~~~~~~~~~~~~~~
1 error generated.

I have this include in #include <experimental/memory_resource>

@Tradias
Copy link
Owner

Tradias commented Dec 7, 2022

When using clang+libc++ you can tell asio-grpc to utilize Boost.Container instead of <memory_resource>. See Usage in the README. For example, vcpkg with standalone asio would look like this:

{
    "$schema": "https://raw.githubusercontent.com/microsoft/vcpkg/master/scripts/vcpkg.schema.json",
    "name": "test",
    "version": "0.1.0",
    "dependencies": [
        {
            "name": "asio-grpc",
            "features": [
                "boost-container"
            ]
        },
        "asio"
    ]
}

@ivan-volnov
Copy link
Author

ivan-volnov commented Dec 7, 2022

Thanks, I have seen it. But I hoped to use it without Boost. Purely with standalone asio. May be add another option for experimental prefix?

@Tradias
Copy link
Owner

Tradias commented Dec 7, 2022

Sure, I can look into it. experimental/memory_resource won't work however, because it does not contain unsynchronized_pool_resource. I could use something like recycling_allocator instead.

@ivan-volnov
Copy link
Author

ivan-volnov commented Dec 7, 2022

Yes, you are right, experimental/memory_resource doesn't contain unsynchronized_pool_resource.

Unfortunately recycling_allocator is not a big deal either because of Boost dependency.

Will look for another workaround.

Tried to update clang to 15. No luck.

The work on memory_resource has been abandoned in clang:
https://quuxplusone.github.io/blog/2018/06/05/libcpp-memory-resource/

@ivan-volnov ivan-volnov changed the title Clang 14 build error Clang 14 and 15 build error Dec 7, 2022
@Tradias
Copy link
Owner

Tradias commented Dec 7, 2022

Oh the recycling_allocator is part of Asio, which means it is also available in standalone asio: https://think-async.com/Asio/asio-1.24.0/doc/asio/reference/recycling_allocator/recycling_allocator.html

@ivan-volnov
Copy link
Author

Well, it would be great! Looking forward for the commit =)

@Tradias
Copy link
Owner

Tradias commented Dec 17, 2022

Master branch now contains an option to enable the use of recycling_allocator:

set(ASIO_GRPC_USE_RECYCLING_ALLOCATOR on)
set(ASIO_GRPC_USE_BOOST_CONTAINER off)

add_subdirectory(/path/to/repository/root)

@Tradias
Copy link
Owner

Tradias commented Jan 4, 2023

Version 2.4.0 has been released containing this feature. I also simplified it such that

set(ASIO_GRPC_USE_RECYCLING_ALLOCATOR on)
add_subdirectory(/path/to/repository/root)

should do the trick. Let me know if everything works as you expect.

@Tradias
Copy link
Owner

Tradias commented Jan 11, 2023

Hi @ivan-volnov,

have you found some time to test the new feature, does it work as you expect? If so, could you close the issue please?

@ivan-volnov
Copy link
Author

Hi @Tradias,

Thank you very much for fixing the issue.

I ended up with writing my own small one-file implementation of the library using your old blog post. Thanks a lot for this!

So, I can't test it anymore...
I don't use the code I don't understand or that has a lot of redundant stuff.

My recommendations are: refactor the library, make it small and easy as possible.

@Tradias
Copy link
Owner

Tradias commented Jan 12, 2023

Glad to hear that my blog post was helpful.

In the immediate future I plan on adding a Tutorial section to the documentation, but aimed at users more than maintainers. Nonetheless, it might shed some light on the complexity in some parts of the library. For v3 I also plan on removing some parts of the public API and simplify things like repeatedly_request.
With libraries it is always a tricky dance between genericity and focus.

@Tradias Tradias closed this as completed Jan 12, 2023
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