glib has a data structure called GAsyncQueue, which allows inter-thread communication with no semaphores/locks/etc., and even makes trivial the task of implementing a producer/consumer solution. If two different threads push data to a GAsyncQueue structure, the push function internally implements the mutually exclusive access to the queue; more awesomely, if a thread calls the pop function, and there is no data there, the calling thread blocks until some data is pushed into the queue by some other thread. All of this is done in a thread-safe manner, transparently to the developer.
glib有一个名为GAsyncQueue的数据结构，它允许线程间通信，而不是信号量/锁/等等。，甚至使实现生产者/消费者解决方案的任务变得微不足道。如果两个不同的线程将数据推到GAsyncQueue结构中，则push函数在内部实现对队列的互斥访问;更令人惊讶的是，如果一个线程调用了pop函数，并且那里没有数据，那么调用线程会阻塞，直到一些数据被其他线程推入队列。所有这些都是以线程安全的方式完成的，对开发人员是透明的。
As much as I like it, though, this library was built for C, and there might be better alternatives for higher level languages. I'm thinking about using glib anyway, but it feels odd to use a C library in a C++ code...
尽管我很喜欢它，但是这个库是为C构建的，而且对于高级语言来说可能有更好的选择。无论如何，我在考虑使用glib，但是在c++代码中使用C库是很奇怪的……
So, the question is: is there a C++ recommended equivalent for glib? More specifically, is there a more recommended C++ library that provides the same functionality as GAsyncQueue?
那么，问题是:是否有一个c++推荐的等价于glib?更具体地说，是否有一个更推荐的c++库提供与GAsyncQueue相同的功能?
1 个解决方案
#1
3
There is absolutely nothing wrong with using C in a C++ program (after all, C++ implementation is heavily based on C runtime, for example C++11 thread support cannot live without pthread library, at least on UNIX®-like platforms). I would definitely not choose the tool/library only and entirely basing on the language it is written in. But if you must use something else, then glib is not the only library in the world that provides provides asynchronous message passing (by the way, it doesn't really look like it supports IPC). Anyhow, here is a list of C++ frameworks that immediately come to my mind (in random order, as random as my thoughts):
是绝对没有错的c++程序中使用C(毕竟,c++实现在很大程度上基于C运行时,例如c++ 11线程不能没有pthread库的支持,至少在UNIX®式平台)。我绝对不会只选择工具/库，完全基于它所写的语言。但是如果您必须使用其他的东西，那么glib并不是世界上唯一一个提供异步消息传递的库(顺便说一下，它看起来并不像支持IPC)。无论如何，这里有一个c++框架的列表，它立即出现在我的脑海中(随机的顺序，像我的想法一样随机):
- Intel Threading Building Blocks
- 英特尔线程构建块
- Boost MPI
- Boost MPI
- Boost.ASIO
- Boost.ASIO
- Qt
- Qt
Each one has its own strengths and weaknesses, and which one to use really depends on what exactly your requirements are. I can only recommend you to pay attention to overall application architecture and how well the asynchronous message passing would fit into all of the components of your application. For example, in more or less complex applications that involve more than simple message passing, such asynchronous queues are oftentimes integrated with the event notification mechanisms in use (for example, OSX is built around kqueue/GCD).
每个人都有自己的长处和短处，使用哪一种取决于你的要求到底是什么。我只能建议您注意整个应用程序体系结构，以及异步消息传递将如何适合您的应用程序的所有组件。例如，在涉及多个简单消息传递的复杂应用程序中，这些异步队列通常与使用的事件通知机制集成(例如，OSX是围绕kqueue/GCD构建的)。
Hope it helps. Good Luck!
希望它可以帮助。好运！
#1
3
There is absolutely nothing wrong with using C in a C++ program (after all, C++ implementation is heavily based on C runtime, for example C++11 thread support cannot live without pthread library, at least on UNIX®-like platforms). I would definitely not choose the tool/library only and entirely basing on the language it is written in. But if you must use something else, then glib is not the only library in the world that provides provides asynchronous message passing (by the way, it doesn't really look like it supports IPC). Anyhow, here is a list of C++ frameworks that immediately come to my mind (in random order, as random as my thoughts):
是绝对没有错的c++程序中使用C(毕竟,c++实现在很大程度上基于C运行时,例如c++ 11线程不能没有pthread库的支持,至少在UNIX®式平台)。我绝对不会只选择工具/库，完全基于它所写的语言。但是如果您必须使用其他的东西，那么glib并不是世界上唯一一个提供异步消息传递的库(顺便说一下，它看起来并不像支持IPC)。无论如何，这里有一个c++框架的列表，它立即出现在我的脑海中(随机的顺序，像我的想法一样随机):
- Intel Threading Building Blocks
- 英特尔线程构建块
- Boost MPI
- Boost MPI
- Boost.ASIO
- Boost.ASIO
- Qt
- Qt
Each one has its own strengths and weaknesses, and which one to use really depends on what exactly your requirements are. I can only recommend you to pay attention to overall application architecture and how well the asynchronous message passing would fit into all of the components of your application. For example, in more or less complex applications that involve more than simple message passing, such asynchronous queues are oftentimes integrated with the event notification mechanisms in use (for example, OSX is built around kqueue/GCD).
每个人都有自己的长处和短处，使用哪一种取决于你的要求到底是什么。我只能建议您注意整个应用程序体系结构，以及异步消息传递将如何适合您的应用程序的所有组件。例如，在涉及多个简单消息传递的复杂应用程序中，这些异步队列通常与使用的事件通知机制集成(例如，OSX是围绕kqueue/GCD构建的)。
Hope it helps. Good Luck!
希望它可以帮助。好运！