Show HN: Cpp_Redis – C++11 Lightweight Redis client | Hacker News Reader

Show HN: Cpp_Redis – C++11 Lightweight Redis client

github.com

66 pointscylix34 comments

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"

    namespace redis = cpp_redis;

there you go.

now you have

    redis::redis_client

a bit better, but not

    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.

Thanks for your feedback!

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

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.

[0] https://github.com/redis/hiredis

There's nothing stopping you from using hiredis in c++

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.

> 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

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.

Depends how C++ compatible are the headers, as they can't make use of C99 or C11 features that aren't part of ANSI C++17.

True, although most C libraries ought to use those features in the implementation files and not the headers if they want to be used widely.

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.

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.

Hi,

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:

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:

    git tag --contains 009bdeedbc

which would display the same information.

Running `git describe` will give you the nearest tag. gitk will also show you the tag in a manner similar to how it displays a branch head.

Btw: gitg is a slightly more modern looking gitk alternative :)

(it also shows tags similar to branch heads)

On the other hand, gitk is light, simple, cross-platform, and works.

You're right, gitg doesn't work on macOS. But since I'm only using Windows and Linux it works for me :)

awesome, thanks for the tips!

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.

Redis is commonly used to share data/communicate between different subsystems, potentially written in different languages.

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.

Makes sense, thanks for clarifying clishem

made this couple years ago: https://gist.github.com/keymone/b89c23e3e43beb97eb94 (tiny ruby redis client)

https://github.com/Cylix/tacopie an interesting network library.

which is used in this project (Cpp_Redis)

Does this correctly handle Redis clustering? E.g. the "get it from this other node" message? I don't see a handler for that in redis_client.cpp.

Looks like it doesn't, although it supports the cluster control API.

exactly, it only supports cluster control API for now

Why not go full cluster?

Reply on news.ycombinator.com