I've found only two FastCGI libraries for C++. There's the "official" one, and fastcgi++. How is either one better than the other? Do any others exist?
What you probably want is hidden in the contrib directory of Cgicc package.
fcgi-test.cpp is an example of how to use cgicc with FastCGI.
Path to the installed fcgi-test.cpp should be
/usr/share/doc/libcgicc-doc/examples/contrib/fcgi-test.cpp
As fastcgi++ is still listed as "Development Status: 4- Beta" so I would suggest going for the official one. It has been around for ages and has bindings for a whole host of languages. Licences between the 2 don't seem to make much difference. Put some measurements in your code and if performance is an issue then spend some time playing around with alternatives.
The official library is rather low-level, and as such, is only useful as an intermediate for a high-level CGI library such as cgicc.
Fastcgi++, on the other hand, allows for use of C++ idioms when dealing with FastCGI. Incompleteness in v1 motivated me to fork it into mosh-fcgi.
Pros:
My fork complies with every point of the standard (especially ROLE_FILTER)
everything's extensively templated, so it's easier to use arbitrary T for std::basic_strings.
Cons:
My modifications are in alpha mode.
In any case, download the latest zip from https://github.com/moshbear/mosh-fcgi.
See also the Cgicc library:
http://www.gnu.org/software/cgicc/
The library appears to be mature (currently at version 3.x). According to the documentation it can be used with FastCGI by passing a custom reader (reader_function_t) to the constructor of the Cgicc class.
There is a pretty library for creating FastCGI daemons: https://github.com/golubtsov/Fastcgi-Daemon
The C-version of FastCGI does very little, and developing in C++ isn't such a big problem as it hardly interferes with your own code. It's most likely just a loop and an environment variable.
So my advice would be just to stick with the official version.
Just be aware of one thing: it works by redefining printf! So if you use cout it won't work.
Related
Referring to the following library and my previous thread, I have two questions:
Question #1: I have decided not to mess up with Java Libraries and hence could anyone tell me if there is another way to figure out how to use the libphonenumber library in coldfusion?
Question #2: As discussed in my previous thread, that many people are porting it to different programming languages like JavaScript, Ruby, PHP as they are not written in Java. The google library libphonenumber is written in PHP and I am wondering why someone would port it to PHP language.
(This is more of a comment, but is a little too long)
Seems like this was already answered in the comments of your other thread, but to reiterate:
Is there another way to use a java library from CF?
No. There is basically only one way to use java libraries from CF. Add the jar(s) to the class path and use createObject. You could also use a dynamic class loader like Mark Mandel's JavaLoader.cfc (or the rip of that project baked into CF10+). However, ultimately they all do the same thing.
Since using java libraries is pretty simple in CF, I am curious why you do not want to use it. While I suppose you could rewrite it in pure CFML, I would ask why? The whole point of libraries is reuse, which saves development time. Since there already is a compatible library available to you, there is not much point in rewriting it. Not unless you are doing it as a learning exercise.
The google library libphonenumber is written in PHP
No. There is port that is written in PHP. The "official" project is "a Java, C++ and Javascript library.". So it sounds like your options are the java version (server side) or javascript version (client side use). That is it.
I am wondering why someone would port it to PHP language.
Because the java library is not compatible with every platform out there, PHP being one of them. If a developer on an unsupported platform wanted to use it, they have two choices: port it or write their own from scratch. Since the google project already did most of the heavy lifting, porting is simpler.
What is the most basic way to go to a webpage and download its contents? the webpage i wish to get only has text, most of which is in tables.
is there a std library that does it (like urllib in python)?
There's no official C++ network library, no. There are many different APIs available, though. Which is best for you would depend on what platform(s) you were targeting and what framework(s) you might already be using.
That said, cpp-netlib is a platform-neutral API that follows C++ idioms nicely. I've used it and it works.
A large number of tasks that are not covered by the C++ standard library can be done using boost, the collection of peer-reviewed portable libraries, which are used by pretty much every C++ project today. For networking, we use boost.asio.
Their tutorials include HTTP clients: http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/example/http/client/sync_client.cpp and http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/example/http/client/async_client.cpp
However, although this is highly portable and may end up becoming part of the C++ standard library in future, it is a bit too low-level for your task. libCURL is the today's default library for HTTP downloads.
Is there a good, simple library which allows C++ to load a webpage? I just want to grab the source as text. I'm not using any IDE or significant library, just straight command line.
Tangentially, is there something fundamental I'm missing about programming in C++? I would think any language in common use today would have droves of web-based functionality, being so central to computer usage, but I can find next to no discussion on how to accomplish it. I realise C++ significantly predates the modern internet, so it lacking any core ability in the regard is reasonable, but the fact that relevant libraries seem so sparse is baffling.
Thanks for your help.
Sure, for example libcurl is powerful and popular.
Internet-related libraries for C++ are extremely abundant -- they're just not part of the C++ standard, partly because the current version of that standard is so old, though I'm sure that's not the only reason. But turn to the world of open sources and you'll find more than you can shake a stick at.
libcurl is a popular C library for fetching HTTP and other URLs. There's also cURLpp a C++ binding .
On Windows you have the WinINet and WinHTTP APIs.
I think HTTP is a bit too complex to be part of the C++ Standard Library. The specification would have to take a lot of details into account such as proxy servers and MIME types.
I need to develop a Windows/Linux command line utility. The utility will talk to middleware that has a standard API on both platforms. I have done some cross-platform development before, on FreeBSD/Linux, which was considerably easier - and I had people in the group with experience that I could talk to.
At this point there is no one in my group who has tackled a Windows/Linux development project. I am looking for advice on how to best set it up. I'm kind of a newbie to C++ too, I have mostly developed C#/.Net GUI applications and Linux device driver level "stuff". Kind of a weird mix.
I was thinking that it would be best to define my own data types and not use either the Linux or the Windows defined types - keep the OS specific code in separate folders and include conditionally. That's kind of what we did for the Linux/BSD work. So it seemed like a good start.
One of the developers here is a big fan of Boost... another thought the TCLAP command line parser library was easier to use... Obviously everything has to be compatible with the licensing.
The code will be open sourced, but it is production code - so I don't want to be sloppy. What else should I be doing or looking for? Are there any best practices out there?
Boost is good, as is ACE. Between the 2 of those they cover pretty much anything you would want to do in a cross-platform manner. I have also gone the route of getting posix libraries for windows and using gcc on cygwin, but I don't recommend it.
Use a portable runtime that is supported on both platforms. I have had good luck with the Apache Portable Runtime.
Use standard C or C++ for most of the project. Only use platform specific functions when necessary. If possible, put those in a wrapper in isolated files so that the build (makefile) can substitute in the correct version for the appropriate platform.
Refrain from using #ifdef LINUX or #ifdef WINDOWS or similar conditional compilation. Those get really hard to debug and there are error prone when the keyword is not supplied to the compiler.
Use Boost. Among other things, you'll get a portable implementation of a subset of TR1, which is worth it if only for <cstdint> and the types within - int32_t etc. As well, shared_ptr is essential for many moderately complicated data structures.
Boost also has a slew of helper types which are extremely convenient in day-to-day C++ tasks. Two specific ones that come to mind right away are optional, and ptr_... polymorphic container types come to mind right away. String algorithm library is also very handy, considering the lack of very commonly needed string functions, such as case conversion or trimming, in the standard library.
Speaking of more heavyweight components, Boost.Filesystem is a very decent cross-platform abstraction for filesystem navigation, also a relatively common task in command-line tools. Then there's Boost.MultiIndex is a swiss army knife of containers - rarely truly needed, but when it is, it's indispensable.
I did a gig this summer in .NET and just ported to Mono. Worked great.
Although there are some good cross platform libraries out there (like Boost), remember that they are probably not there by default. This is especially problematic if you are shipping binaries only. The target platform is unlikely to have the library (or correct version of the library) that you need.
First prize is to stick with standard C++ (even if you need to implement simple stuff yourself). This avoid library dependence altogether.
If you must use a library, try statically linking against it (although this may create big binaries). This will allow you to avoid runtime failure due to lack of binaries.
If you must ship DLLs (or .so on some unixes) make sure that the correct version is shipped with your product and some way to avoid conflicts with the wrong version.
If you are shipping code, include the library with the code and build the library as well as your utility.
Also beware of GPL and possibly LGPL code. If you release a library with a GPL dependency (or modify an LGPL library) you will need to supply the code and allow redistribution as per the GPL.
TCLAP is the only header-only CLI parsing option that I'm aware of. As such, it strikes me as the most portable and is probably your best bet (it's currently what I use and recommend for exactly those reasons). It also helps that the API for TCLAP is very developer friendly and automatically generates decently formatted help messages for you.
Boost program_options has a shard library component to it, which is irritating to maintain ABI with. It also gets around nuisance parsing incompatibilities and behaviors from the getopt family of arguments.
I have used libparamset, that is cross platform (Windows, OS X, Linux) CLI parser. It provides flexible and powerful CLI parser and various UI building features (input error handling, wildcards, typo detection, task resolving, help formatting ...) to build a good command-line tool. It is suitable for both C and C++ projects.
I'm looking to add full text indexing to a Linux desktop application written in C++. I am thinking that the easiest way to do this would be to call an existing library or utility. This article reviews various open source utilities available for the Gnome and KDE desktops; metatracker, recoll and stigi are all written in C++ so they each seem reasonable. But I cannot find any notable documentation on how to use them as libraries or through an API. I could, instead, use something like Clucene or Xapian, which are generic full text indexing libraries. They seem more straightforward but if I used them, I'd have to implement my own indexing daemon, an unappealing prospect.
Also, Xesam seems to be the latest thing, does anyone have any evidence that it works?
So, does anyone have experience using any of the applications or libraries? How did you use it and what documentation was useful?
I used CLucene, which you mentioned (and also Lucene.NET), and found it to be pretty good.
There's also Strigi which AFAIK works with Xesam and is the default used in KDE.
After further looking around, I found and worked with Recol. It believe that it has the best C++ interface to a full text search engine, in this case Xapian.
It is important to realize that clucene and Xapian are both highly complex libraries designed primarily for multi-user server applications. Cutting them down to a level appropriate for a client-system is not easy. If I remember correctly, Strigi has a complex, pure C interface which isn't adapted.
Clucene also doesn't seem to be that actively maintained currently and Xapian seems to be maintained. But the thing is the existence of recol, which allows you to index particular files without the massive, massive setup that raw Xapian or clucene requires - creating your own "stemming" set is not normally desirable, etc.