A few years ago, I dabbled with the idea of building a "shared clipboard" application across platforms and decided to use Redis - esply the pub/sub mechanism - for this. I ended up discovering and using hiredis[0] (which I can see now was co-authored by antirez as well). I'm curious to know if hiredis can be used from C++ 11 as well.
As arjo129 says, there is nothing preventing you from using hiredis, provided they don't make use of the few cases where C language features and C++ are no longer compatible, e.g. VLAs or structure initializers.
However, given it is a C API you will get the usual C unsafe code, instead of C++'s improvements regarding type safety.
My experience over the last five years pertaining to software requirements have been:
Does it require low latency? Yes -> use Clang environment. In this case, redis usually doesn't fit the bill within the stack. I'm surprised for most other use cases, people are using C++, where Ruby/Java can provide a solid programming abstraction (and fast development time). tl;dr I would be curious of the use case of C++ and redis.
Nice. Would you consider a mechanism for injecting the client with extra commands for redis modules? As far as I can tell it's possible to run generic commands with the client, but it would be a nice touch to add more commands to it.
Silly question, but if redis is written in c , couldn't c++ call redis' interface directly. I'm aware it wouldn't be best practice and there would be problems if redis' c code base was non-compliant with c++ standards? But is this effectively a c++ wrapper ?
A wrapper is not entirely useless. It can use features of C++ like shared / unique pointers, lambdas, w/e to make working with redis in a C++ code base more C++ like. This takes advantage of all the features from C++ while hiding the low level C interface (which I assume uses manual memory management for instance).
This is not a silly question. Yes, using the C library from C++ is certainly possible. There would be nothing non-compliant about that, although you would need to write code that is somewhat frowned upon when writing C++ (i.e. using raw pointers all over the place). No, this is not a wrapper. It doesn't use the C library to pass queries to redis.
Neat, but horrid naming for everything. Why does namespace need explicit "cpp_" prefix? Why do classes inside "cpp_redis" namespace still have "redis_" prefix? I would prefer simple "redis::client" so much nicer than "cpp_redis::redis_client"
A quick fix, but having many of these can make code much harder to read since you will need to trace through the various aliases to find the actual implementation.
So it doesn't conflict with any of the stuff you might've written yourself already to deal with redis (which, presumably, you named the stuff you've written `redis`). Besides, you can just namespace the thing at the top.
"Why does namespace need explicit "cpp_" prefix?"
I get used to namespace by the library name for each library I build. I believe it does make sense, I think here the issue is maybe more about the library name itself.
As other people suggested, it is still possible to create an alias for this namespace
"Why do classes inside "cpp_redis" namespace still have "redis_" prefix?"
I 100% agree and I think I will change that!
It is also inconsistent as I got a `redis_client` class but at the same time a `future_client` without redis_prefix.
I definitely makes more sense to name it only redis and I'll make that change later on:)
Looks like a learning project for someone relatively new to C++.
I suggest using git tags instead of putting a version number in every commit message.
Have you looked into epoll or kqueue or even poll? Or for your windows backend, WSAEventSelect/WaitForMultipleObjects or IOCP... Trying to get all these disparate ways of doing async sockets to use a consistent wrapper interface is an interesting challenge.
I do use git tags but I also include version numbers in my commit messages so that I can easily determine in which version a given commit was published.
I find it pretty useful. I know some people prefer to create a dev branch, then squash merge, but sometimes you got multiple features and I feel it is more convenient to separate them into multiple commits that will belongs to the same release.
Do you have some other suggestions, I would be interested :)
Concerning epoll/poll, the networking part was first based on it.
However, the poll implementation on windows is buggy and thus it is more advised to use select on windows apparently... So to keep consistency between unix and windows versions, I decided to switch back to select for both platform for now.
I'm planning to switch back to poll for unix and look at WSAEventSelect.
I also looked at IOCP and it is really interesting.
However, it is pretty hard to implement a portable library that uses select/poll under unix but IOCP on windows as the implementation is pretty different. There are some ways, but the way I designed the networking part does not make it possible without changing completely the design on one platform
> I do use git tags but I also include version numbers in my commit messages so that I can easily determine in which version a given commit was published.
If we look at a commit on github, I'll see all tags that contain that commit:
34 comments
[ 3.0 ms ] story [ 75.3 ms ] thread[0] https://github.com/redis/hiredis
However, given it is a C API you will get the usual C unsafe code, instead of C++'s improvements regarding type safety.
Wouldn't one compile hiredis in C, their app in C++, and link the two together?
In general compiling C code with a C++ compiler isn't the path of least resistance.
And even if some things leak into the headers they might be accepted by compiler extensions.
But yes, in general if a c library's headers are hostile to cross-language usage then using it from c++ won't be trivial.
Does it require low latency? Yes -> use Clang environment. In this case, redis usually doesn't fit the bill within the stack. I'm surprised for most other use cases, people are using C++, where Ruby/Java can provide a solid programming abstraction (and fast development time). tl;dr I would be curious of the use case of C++ and redis.
"Why does namespace need explicit "cpp_" prefix?" I get used to namespace by the library name for each library I build. I believe it does make sense, I think here the issue is maybe more about the library name itself. As other people suggested, it is still possible to create an alias for this namespace
"Why do classes inside "cpp_redis" namespace still have "redis_" prefix?" I 100% agree and I think I will change that! It is also inconsistent as I got a `redis_client` class but at the same time a `future_client` without redis_prefix. I definitely makes more sense to name it only redis and I'll make that change later on:)
Thanks foryour feedback though :)
I suggest using git tags instead of putting a version number in every commit message.
Have you looked into epoll or kqueue or even poll? Or for your windows backend, WSAEventSelect/WaitForMultipleObjects or IOCP... Trying to get all these disparate ways of doing async sockets to use a consistent wrapper interface is an interesting challenge.
I do use git tags but I also include version numbers in my commit messages so that I can easily determine in which version a given commit was published. I find it pretty useful. I know some people prefer to create a dev branch, then squash merge, but sometimes you got multiple features and I feel it is more convenient to separate them into multiple commits that will belongs to the same release. Do you have some other suggestions, I would be interested :)
Concerning epoll/poll, the networking part was first based on it. However, the poll implementation on windows is buggy and thus it is more advised to use select on windows apparently... So to keep consistency between unix and windows versions, I decided to switch back to select for both platform for now. I'm planning to switch back to poll for unix and look at WSAEventSelect.
I also looked at IOCP and it is really interesting. However, it is pretty hard to implement a portable library that uses select/poll under unix but IOCP on windows as the implementation is pretty different. There are some ways, but the way I designed the networking part does not make it possible without changing completely the design on one platform
If we look at a commit on github, I'll see all tags that contain that commit:
https://i.imgur.com/KTkz2K1.png
So I know this commit was created before the 3.3.0 tag (and all later tags).
You can do the same thing at the command line with:
which would display the same information.(it also shows tags similar to branch heads)