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"
"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:)
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.
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.
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:
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.
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.
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 ?
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.
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).
