curlpp

C++ wrapper around libcURL

View the Project on GitHub

Beerpay Beerpay License: MIT Travis CI

Description

cURLpp is a C++ wrapper for libcURL. libcURL is described as:

a free and easy-to-use client-side URL transfer library, supporting FTP, FTPS, HTTP, HTTPS, GOPHER, TELNET, DICT, FILE and LDAP. libcurl supports HTTPS certificates, HTTP POST, HTTP PUT, FTP uploading, kerberos, HTTP form based upload, proxies, cookies, user+password authentication, file transfer resume, http proxy tunneling and more!

libcurl is highly portable, it builds and works identically on numerous platforms, including Solaris, NetBSD, FreeBSD, OpenBSD, Darwin, HPUX, IRIX, AIX, Tru64, Linux, Windows, Amiga, OS/2, BeOs, Mac OS X, Ultrix, QNX, OpenVMS, RISC OS, Novell NetWare, DOS and more…

libcurl is free, thread-safe, IPv6 compatible, feature rich, well supported and fast.

First, I need to quote Daniel Stenberg, the maintener of libcURL: You can use libcURL instantly from within your C++ programs. You don’t need cURLpp for that, cURLpp just adds an OO’ified layer that libcURL doesn’t normally provide. It means that you need to be sure that you need, or want, cURLpp features. If not, I suggest to use directly the libcURL library. So, what are thoses features that cURLpp offers?

Documentation

The programming guide for the 0.5.x and newer versions is here. This guide is greatly inspired by the libcURL guide, that I strongly suggest to read. There’s also some examples in the “examples/” source directory of cURLpp.

Development history

The original code (versions up to 0.3x)

This project was branched over the project began by Eric Lavigne. It’s no longer active.

The refactor over the original code (0.5.x and newer)

This version is a complete re-factorization of cURLpp against 0.3.x and older versions. This re-factorization was made for the following reasons:

Those two points are in fact related. cURLpp was difficult to maintain because each libcURL’s option change needed a change in cURLpp; the design didn’t allow those changes to be automatically taken in charge. Because I don’t monitor libcURL project carefully, those changes were only applied 2-3 months after the release. It wasn’t flexible because it didn’t allowed the user to change cURLpp’s behavior without risking to break previously made applications.

But in fact, the real problem is that I DO read feature requests, but do not necessarily program them (You can send your complains to my university/job/girlfriend). So, this design is, in fact, “Ze” one that is compatible with my laziness.

Seriously, here’s the advantages of this new design:

Development Plans

So, what’s next? I have some ideas for future releases. If you want to suggest some feature, don’t be shy and send me an email.

Version 0.6.0 (Out)

Exception safe feature. What’s exactly the matter? Isn’t supposed to be already exception safe? Well, the problem is when you work with C++ callbacks that are called within C code. What will happen if the callback throw an exception? The exception will go through the C code. This will completely break the C code. So, you need to be sure that it’s impossible that an exception is thrown, without being handled in your callback. So, I want to add some code that will handle any exception thrown and rethrow it in the C++ code, meaning in the cURLpp::Easy::perform function. Then, you’ll be able to throw exceptions, without being scared to break libcURL’s execution.

Functors. At this time we use plain functions as callbacks. However, if you want to use a member function, you need to create a function that will cast your data (that you previously set on the handle), and then call your member function. I want to use functors instead. If you don’t know what are functors, check this.

Version 0.7.0 (Out)

Multi interface. We need to add the Multi interface. Here’s the description from libcURL’s documentation: The multi interface is the asynchronous brother in the family and it also offers multiple transfers using a single thread and more. The multi interface introduces several new abilities that the easy interface refuses to offer. They are mainly:

Version 0.8.0

Share interface. Right now, we don’t provide any wrapping for the Share interface. Mostly, this wrapping will depend on the functor feature. This is the description from the libcURL documentation: The share interface was added to enable sharing of data between curl “handles”. You can have multiple easy handles share data between them. Have them update and use the same cookie database or DNS cache! This way, each single transfer will take advantage from data updates made by the other transfer(s).

Compilers

cURLpp is meant to be portable, but I can’t maintain, all by myself, a project file for every platform that exists. Here’s the environnements that I maintain, or will maintain personally: