I am coding in C++ for a while, and I already get used to platform compatibility issue. But now, I realized that backward compatibility is another substantial issue:
How can the Boost libraries be used successfully for important projects?
Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible.
(Source: http://www.boost.org/users/faq.html)
Does Java have the same issue? I know that the situation is different from package to package, but how about Java packages that are as much famous as boost is in C++ world?
You have conveniently snipped the rest of the answer on the Boost FAQ, which tells you how to deal with this problem:
Deal with this by freezing the version of the Boost libraries used by
your project. Only upgrade at points in your project's life cycle
where a bit of change will not cause problems. Individual bug fixes
can always be obtained from the boost repository.
As for the rest of your question...
Does Java have the same issue?
Of course. This is not an issue with a specific programming language. It's an issue with 3rd-party libraries or frameworks in general.
I know that the situation is different from package to package, but how about Java packages that are as much famous as boost is in C++ world?
There is nothing like Boost for Java, because many things offered by Boost are already part of the Java framework itself, for better or worse. Think of string algorithms or filesystem operations.
That being said, perhaps Apache Commons comes close. As it turns out, it has its own share of backward compatibility issues -- which, as I said above, is completely normal. For example, the release notes for v4.0 clearly state the following:
This version uses the generics features of Java 5 and is not compatible with earlier JDK versions.
(...), we have chosen to break the API in various ways. (...) We have also removed all deprecated classes and fixed oddities in the previous API that we couldn't fix due to backwards compatibility restrictions.
Keep in mind that both Boost and Apache Commons deal with this fundamental software-engineering problem in a very professional and well-documented way. Unfortunately, the same cannot be said about most other libraries and frameworks you will encounter in the wild, regardless of the programming language used.
Related
For our current project, we are thinking to use Boost framework.
However, the project should be truly cross-platform and might be shipped to some exotic platforms. Therefore, we would like to use only Boost packages (libraries) that does not contain any platform specific code: pure C++ and that's all.
Boost has the idea of header-only packages (libraries).
Can one assume that these packages (libraries) are free from platform specific code?
In case if not, is there a way to identify these kind of packages of Boost?
All C++ code is platform-specific to some extent. On the one side, there is this ideal concept of "pure standard C++ code", and on the other side, there is reality. Most of the Boost libraries are designed to maintain the ideal situation on the user-side, meaning that you, as the user of Boost, can write platform-agnostic standard C++ code, while all the underlying platform-specific code is hidden away in the guts of those Boost libraries (for those that need them).
But at the core of this issue is the problem of how to define platform-specific code versus standard C++ code in the real world. You can, of course, look at the standard document and say that anything outside of it is platform-specific, but that's nothing more than an academic discussion.
If we start from this scenario: assume we have a platform that only has a C++ compiler and a C++ standard library implementation, and no other OS or OS-specific API to rely on for other things that aren't covered by the standard library. Well, at that point, you still have to ask yourself:
What compiler is this? What version?
Is the standard library implementation correct? Bug-free?
Are those two entirely standard-compliant?
As far as I know, there is essentially no universal answer to this and there are no realistic guarantees. Most exotic platforms rely on exotic (or old) compilers with partial or non-compliant standard library implementations, and sometimes have self-imposed restrictions (e.g., no exceptions, no RTTI, etc.). An enormous amount of "pure standard C++ code" would never compile on these platforms.
Then, there is also the reality that most platforms today, even really small embedded systems have an operating system. The vast majority of them are POSIX compliant to some level (except for Windows, but Windows doesn't support any exotic platform anyways). So, in effect, platform-specific code that relies on POSIX functions is not really that bad since it is likely that most exotic platforms have them, for the most part.
I guess what I'm really getting at here is that this pure dividing line that you have in your mind about "pure C++" versus platform-specific code is really just an imaginary one. Every platform (compiler + std-lib + OS + ext-libs) lies somewhere along a continuum of level of support for standard language features, standard library features, OS API functions, and so on. And by that measure, all C++ code is platform-specific.
The only real question is how wide of a net it casts. For example, most Boost libraries (except for recent "flimsy" ones) generally support compilers down to a reasonable level of C++98 support, and many even try to support as far back as early 90s compilers and std-libs.
To know if a library, part of Boost or not, has wide enough support for your intended applications or platforms, you have the define the boundaries of that support. Just saying "pure C++" is not enough, it means nothing in the real world. You cannot say that you will be using C++11 compilers just after you've taken Boost.Thread as an example of a library with platform-specific code. Many C++11 implementations have very flimsy support for std::thread, but others do better, and that issue is as much of a "platform-specific" issue as using Boost.Thread will ever be.
The only real way to ever be sure about your platform support envelope is to actual set up machines (e.g., virtual machines, emulators, or real hardware) that will provide representative worst-cases. You have to select those worst-case machines based on a realistic assessment of what your clients may be using, and you have to keep that assessment up to date. You can create a regression test suite for your particular project, that uses the particular (Boost) libraries, and test that suite on all your worst-case test environments. Whatever doesn't pass the test, doesn't pass the test, it's that simple. And yes, you might find out in the future that some Boost library won't work under some new exotic platform, and if that happens you need to either get the Boost dev-team to add code to support it, or you have to re-write your code to get around it, but that's what software maintenance is all about, and it's a cost you have to anticipate, and such problems will come not only from Boost, but from the OS and from the compiler vendors too! At least, with Boost, you can fix the code yourself and contribute it to Boost, which you can't always do with OS or compiler vendors.
We had "Boost or not" discussion too. We decided not to use it.
We had some untypical hardware platforms to serve with one source code. Especially running boost on AVR was simply impossible because RTTI and exceptions, which Boost requires for a lot of things, aren't available.
There are parts of boost which use compiler specific "hacks" to e.g. get information about class structure.
We tried splitting the packages, but the inter dependency is quite high (at least 3 or 4 years ago).
In the meantime, C++11 was underway and GCC started supporting more and more. With that many reasons to use from boost faded (Which Boost features overlap with C++11?). We implemented the rest of our needs from scratch (with relative low effort thanks to variadic templates and other TMP features in C++11).
After a steep learning curve we have all we need without external libraries.
At the same time we have pondered the future of Boost. We expected the newly standardized C++11 features would be removed from boost. I don't know the current roadmap for Boost, but at the time our uncertainty made us vote against Boost.
This is not a real answer to your question, but it may help you decide whether to use Boost. (And sorry, it was to large for a comment)
I actually like the clean approach of Boost.GIL, standardized libraries are cool and Adobe certainly put some thought in it but when comparing to libs such as OpenCV its feature set is marginal. Do you use GIL and for what purposes?
Boost.GIL is not dead. There is a few maintainers interested in keeping the project up to date, fixing bugs, helping contributors to bring new features, etc.
Boost.GIL is preparing for refreshing release as part of the upcoming Boost 1.68, including new I/O implementation accepted to Boost.GIL during the official Boost review a longer while ago.
Stay tuned and if you have any specific questions, feel free to post to the official boost-gil mailing list
Boost is a widely accepted set of libraries, but it's not in the C++ standard. So don't feel that you've violated the ANSI/ISO code of conduct by using something that better suits your needs.
Do not use boost gil, recently I tried to use it to do a "complex" task of reading a png file, but for that it requires installing a bunch of libraries that have no install documentation for Windows, and to make matters worse gil documentation suggest the following regarding libpng and libjpeg(in year 2020):
The user has to make sure this library is properly installed. I
strongly recommend the user to build the library yourself. It could
potentially save you a lot of trouble.
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'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.
(mingw32, windows xp)
Hello, I am attempting to migrate from Java to c++. I am confused and frustrated about finding, installing, and compiling non-standard c++ libraries. in Java it's so convenient they stuffed every functionality and documentation ever needed in java's standard api. Is there a list of essential c++ library such as Threading, gui, networking, image\ audio processing, xml, etc.etc. in one place? or possibly, offered as a single package?
I tried installing QT library for weeks and it wont even compile. in Java i used to learn by trial-and-error to learn new aspect of functionality, but that would be impossible if i can't fetch and run new api in the first place.
please, i need your suggestion, originally i wanted to break free of Java's abstraction, but now i just want to be able to use c++ before I decided shooting myself in the head.
The C++ standard library is extremely light. It contains nowhere near the functionality offered by the Java runtimes or by the .NET CLR.
The Boost libraries add a whole bunch of functionality to C++, but not much (if any) in the area of user interface.
For UI, there's the question of which platform you're targetting. If it's Win32, then you can use the straight Win32 API (mostly designed for C, but there are some C++ wrappers for parts of it). If you want cross-platform, then you're looking at QT or GTK (although there are others).
But, as Andrew already said: "why do you want to learn C++ anyway?". Don't get me wrong: I program in C++ for a living, and actually enjoy it (although I'm beginning to suspect a case of Stockholm Syndrome). If I had to start again, I'd go with a more modern language and environment (Java or C#; or Ruby or Python).
My advice would be: take it one step at a time.
First, figure out how to include a pre-built library in your code. I'd recommend starting with ZLib (it's got a very easy design to work with and it's also a useful tool to have available). Once you've got the pre-built library working, remove it and try compiling ZLib from the source code. Ask on Stack Overflow if you need help at any point, we'll get you through it.
By the time you get that working, you should have all the knowledge you need to get Qt compiled and installed too.
Threading, XML, Networking, some image generation, encoding and processing - boost provides those. As for XML, there's for example Arabica - it abstracts away platform-specific libraries by wrapping them with a nice standard C++ scent.
The GUI part is a different problem.
There's Qt, wxWidgets, gtk with c++ bindings (gtkmm), native libraries for each platform and their C++ wrappers (WTL is an excellent library for Win32), but as the C++ standard evolved and boost is becoming part of the standard (C++0x coming soon), there are no GUI frameworks that leverage those standard facilities and introduce their own instead. They do their job very well though.