6

This one i feel is hard to justify one over another. I see so many here at stackoverflow do both the variants. Some just call cURL console commmands externally from their programs(example: curl "content=hello world" -X POST https://example.com -H "charset=UTF-8"). And others import the library and call it programmatically inside the program.

So my question is for upcoming projects in the future, is it worth the work to include the library and setup all of it. Or is it simply a smarter option to call cURL from command line and read it's responses?

And out of curiosity why doesn't everyone do one of the variants? Why do some people use console commands and other include the libraries, are there maybe some pitfalls later down the line?

CoffeDev
  • 258
  • 2
  • 12
  • 1
    Short answer is yes. Why? When you use the command line variant (through `system` or `fork` and `execv`) you are spawning multiple processes. If efficiency is a consideration, the additional overhead is a bad thing. Otherwise it is a wash, but note the output of `curl` will contain DOS line-ending which can cause surprises if on Linux. – David C. Rankin Oct 31 '20 at 08:23
  • What would you do on a machine that did not have the curl application installed? Seems very opinion based too. – Retired Ninja Oct 31 '20 at 08:48
  • @RetiredNinja they usually place the curl.exe command line app together where you program is installed, incase they choose to not include it into the program – CoffeDev Oct 31 '20 at 08:53
  • @CoffeDev Sure, but not on a mobile device or console. – Retired Ninja Nov 01 '20 at 02:00

3 Answers3

3

Whenever possible use the library. Not just for cURL, but in general.

You should definitely avoid system() calls or creating separate processes launching the external command line application. This adds overhead and can cause issues when porting your code between different platforms.

Also libcurl has a ton of features. The command line is extensive, but the C API is even more powerful.

Using libcurl will require more lines of code than calling the curl command line application, but it's the right thing to do.

Calling the curl command line application from C is usually done out of lazyness or as a shortcut to save some time.

Brecht Sanders
  • 6,215
  • 1
  • 16
  • 40
0

libcurl has extensive features that can't easily be expressed as a command line. You would prefer it if you're building something that needs to efficiently handle many transfers at once, or if you need advanced features like receiving HTTP2 pushed resources.

curl is easier to use. You would prefer it if you just need to download or upload a few things.

FYI You can pass the --libcurl argument to curl to see how a curl command line would be implemented in libcurl.

Andrew Lambert
  • 1,869
  • 1
  • 17
  • 31
0

I used to have the same concern about whether to use libcurl or simply to invoke command-line.

Command-line tool curl is relatively simple to use. But a child process is spawned and then you need IPC if data exchanging is required between parent and child process.

While, using libcurl is harder since you are entailed to reading API references and picking up functions you need then arranging them to work. But the payoff is that libcurl is more flexible, more powerful.

My experience is that I used system(curl) to send JSON data in a C++ program. That program was a single-way communication. By using curl command line, I quickly finished what I expected. But if I chose to use libcurl, I believe I would read the docs for a few days before writing a single line of code.

There is another story of mine. It is same to ask whether to use ffmpeg tool or its library. My project is to extract frames from videos and then to feed them into other subroutines. So I used libavcodec/libavformat or so to do my job. This did cost a few more effort but good thing was reading tutorials on the internet sufficed.

HQW.ang
  • 119
  • 8
  • You should avoid `system()` calls, see: https://stackoverflow.com/questions/19913446/why-should-the-system-function-be-avoided-in-c-and-c – Brecht Sanders Nov 01 '20 at 14:42