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.
Related
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.
I'm considering building a closed-source application that dynamically links against the Qt libraries. The target platforms would be Linux and Windows. In order to fulfill the obligations of the LGPL:
"The user of your application has to be able to re-link your application against a different or modified version of the Qt library" (Qt faq).
I'm struggling to understand what is technically necessary to make this possible. Especially without releasing the source code.
Under which conditions would a user be able to just replace the .so/.dll files that ship with the application with her own, modified versions?
Is this possible at all? Because on the same matter the libstdc++ faq states:
The LGPL requires that users be able to replace the LGPL code with a modified version; this is trivial if the library in question is a C shared library. But there's no way to make that work with C++, where much of the library consists of inline functions and templates, which are expanded inside the code that uses the library. So to allow people to replace the library code, someone using the library would have to distribute their own source, rendering the LGPL equivalent to the GPL.
Thank you!
Edit: The second issue is clarified by LGPL version 3, section 3. Useful reference: an old version of the Eigen FAQ discussing this issue and their correspondence with the FSF about it.
In practice, people usually are linking to a shared library Qt; so slightly upgrading Qt -as long as some common API remains, is possible. An advanced user could in principle adapt the Qt library (starting from the source code of the version you are using) to fit his needs (e.g. correct a naughty bug, in particular without touching any Qt header file). Of course give all the details to help him (at least, mention exactly the version of Qt you are linking against).
In principle, as you noticed, this might perhaps not be enough. Only a trial and a judge could really decide, so ask your lawyer.
Of course I am not a lawyer.
BTW, did you consider asking your manager or client (or the legally responsible person) to release your code as free software and publish it (e.g. under GPLv3+ on github)? In my biased opinion, this would be the best solution!
I am a frustrated newbie of C++ who would like to do the simple task of extracting a pixel matrix from an image file, do some transformation, and then output the modified matrix to an image format of my choosing.
I've given libpng a try and it's API is a mess and hardly readable. Interestingly, some people said it's the best available for C++. I gave my software developer cousin a call and he told me to use OpenGL. So, I did some Googling and I still haven't found a straight answer.
It appears getting a simple "int* readPNG(char* path)" is too much to ask for when the likes of Java, Matlab, and python have these things included in their standard libraries. This is just ridiculous! How do you pros come by and what libraries do you use?
Also a few trivial C++ questions:
- Is there any way to organize classes in a hierarchy like how packages are used in Java? I tried filters in Visual C++ but they don't seem to be the same thing.
- Is there any way to get easily comprehensible stack traces for runtime failures?
Try OpenCV. It is an image processing library with very simple features for editing and saving the images. It will serve your purpose. It also comes with very elegant documentation.
I've found ImageMagick's Magick++ library to be the most useful tool for handling image formatted data programmatically.
C++ has namespaces like Java but they are much more difficult to use and may only make things less readable. As for stack traces, I recommend combing the existing stackoverflow answers for that. In short, it's not simple.
I suggest you improve your Google-fu. There are lots of image processing libraries for C++, including the Boost Generic Image Library, which is as close to standard as you'll get. If you don't have Boost installed and minimal fuss installing libraries, you can always try The CImg Library.
As for your other questions (e.g. stack traces), you'll need to ask separate questions.
I'd suggest Magick++, the C++ API to ImageMagick.
As for packages: you can use namespaces, but that's not nearly comparable to Java's packages (no package-level access etc). They're mostly what they're called: a means to organize names.
Stack traces are not trivial in C++. And there's no platform-independent way of implementing them that I'm aware of.
If you need these features, I just wonder why you don't stick with Java or Python or the likes ? ...
1) Try freeImage - very easy to use and the documentation is readable.
freeimage site
2) for stack traces: which environment are you working with? In Visual Studio there is Stack window (Debug/Windows/Call Stack - Alt 7),
You can also use DebugView and OutputDebugString - not really traces the stack, but can be very usable in debugging. .
I recommend DevIL (formerly known as OpenIL). It has read and write support for 17 formats, and supports many more for just reading.
This is my answer to my very own question here:
Some of the suggested libraries up there have issues with installation with Visual Studio 2010, offer practically no instructions for installation with Visual Studio (i.e. FreeImage), or simply have ridiculously messy API's (i.e. libpng).
If you are new to C/C++, please be careful about what library to choose. Even if there are technical forums roaming with gurus who knows all the answers, you are most likely on your own spending days experimenting and piecing up clues that experienced volunteers could've easily answered in 2 sentences (if they bothered).
Now, what works for me is the OpenCV image library (http://opencv.willowgarage.com/), which is introduced by Mister daerty0153 up there. When you go on the website, don't download the superpack from sourceforge. Instead, read the installation instructions (http://opencv.willowgarage.com/wiki/InstallGuide) and choose what platform you are using.
In my case, I use Visual Studio 2010 as my IDE and so this is the actual subpage that is relevant: http://opencv.willowgarage.com/wiki/VisualC%2B%2B
One problem I encountered is letting VS2010 recognize the .dll files and is not remedied by following those instructions. My solution was to copy all of them to my project folder and that solves all the problem. Some suggested it is a VS 2010 bug.
Hope it helps others suffering from the same situation.
Possible duplicates
Is there a reason to not use Boost?
What are the advantages of using the C++ BOOST libraries?
OK, the high-level question is "Please provide me with what you consider to be the most effective arguments of why entire Boost, or some specific parts of it, should be compiled on our company's system and endorsed in software engineering standards".
Details of what I need:
Would gladly accept both positive arguments (why install), as well as proposed rebuttals of likely counter-arguments I might hear (see question context below).
Arguments should be made aimed at both technical Software Engineering team members and/or very technical senior managers - in other words, for the latter, the details of the argument may/should be technical, but the thrust of the argument should be "how would this make/save the company X money vs losing the company Y money as a cost of adding it to our toolset".
Context of the question:
I'm a developer in a company with several hundred developers, many dosens of whom do C++.
I had the (mis)fortune of being reassigned from my beloved Perl development spot to a team where I am also doing C++ development. So far I found numerous things that I could easily have done in Perl that are very hard/cumbersome to do in C++ (foreach loop as an example), and anytime I hit one of these, the answer 50% likely ends up being "You can't do this in standard C++ but you can do it with Boost"
Our toolkit includes some legacy RogeWave libraries, and VERY limited number of Boost libraries (e.g. no regex, no foreach), of very old vintage.
Any development must use libraries compiled and vetted by Software Engineering team. That is a hard and fast rule.
SE team is somewhat resistant to adding new libraries, for a variety of reasons (e.g. effort to do this; functionality conflicts with RogeWave, for example for RegEx; the risk of installing and using any new software; cost of educating developers, etc...). They will add the libraries if presented with sufficient business need or majorly convincing cost/benefit ratio argument, but they have pretty tough threshold.
So, I'm looking for examples of which parts of Boost are so wonderful (with exact cost/benefit estimates) that installing them would be an Obviously Worth It Effort for Software Engineering.
Thanks in advance for any ideas/suggestions/examples.
Please don't mark this question as subjective as I am looking for measurable answers, not merely wonderful feelings :)
Wherever I worked in the last decade, when they had their own smart pointer class, I found bugs in that - usually within a few weeks. And, no, I never went and looked at it hoping to find errors.
I got into the habit of posting the following quote from the TR1 smart pointer proposal:
The Boost developers found a shared-ownership smart pointer exceedingly difficult to implement correctly. Others have made the same observation. For example, Scott Meyers [Meyers01] says:
"The STL itself contains no reference-counting smart pointer, and writing a good one - one that works correctly all the time - is tricky enough that you don't want to do it unless you have to. I published the code for a reference-counting smart pointer in More Effective C++ in 1996, and despite basing it on established smart pointer implementations and submitting it to extensive pre- publication reviewing by experienced developers, a small parade of valid bug reports has trickled in for years. The number of subtle ways in which reference-counting smart pointers can fail is remarkable."
This plus a detailed analysis of the bug(s) I found usually got me the job of incorporating the boost libs into the code base. :)
It seems to me you're doing this the wrong way around. Since proposals to add new libraries are going to be met with a lot of resistance, don't even bother trying to argue for boost as a whole. Choose your battles instead.
Find the specific Boost libraries which you know (with your knowledge of the application it's to be used in) will be useful and save time and money. And then propose adding those.
I could easily list the Boost libs I've found useful, and why I think they're great, but I don't know if they'll be of any use in your application.
Push for individual boost libraries to be included, and then perhaps, over time, so many of them will be included that it'll be simpler for everyone to just include all of Boost.
It's an open standard not controlled by a specific company ( no licensing costs )
It's cross platform
It's expertly designed / written and very fast / efficient extensively tested
There are open source implementations which your team can compile themselves.
Boost will soon become part of the standard C++ STL
Here is a slightly oldish 2005 article on Dr. Dobbs discussing the upcoming C++0x standard.
http://www.ddj.com/cpp/184401958
I had to maintain a component using that old vintage Tools.h++ from Roguewave, on a Solaris system.
On Solaris, if we want to use boost, we need to use either gcc, or SunStudio with STLport implementation of the standard (instead of Roguewave one). And as Tools.h++ requires the old Roguewave pre-standard implementation of the standard -- on Solaris --, I had to give up on boost.
In the end I rewrote a simplified version of a few boost-like features I needed.
If you are in that same situation (*) , you would not be able to move from Roguewave library to boost that easily. There is a non negligible cost in this operation, as for instance pointer containers from both libraries have quite different interfaces.
(*) Where we can't slowly change bits by bits of the old code to progressively use boost. In that situation, the migration has to be radical and to change simultaneously every occurrence of Tools.h++ by something more trendy, or even better.
NB: Most people are able to progressively use boost in old projects, and may miss a very important, and yes technical, point. Hence my negative answer.
Boost is a great tool and an invaluable part of our product development (we'd be lost without smart_ptr)... but because it is changing so fast the stability of releases can be effected.
For example, we were happily introducing new versions of Boost as soon as they came out without thinking twice. That is until we were stung with a bug in the 1.35 threading library that produced occassional (ie difficult to debug) but critical errors. Fortunately we identified the issue before anything was released to the public and could move back to 1.34.
Ever since then we've taken a specific version, extensively tested it, and not updated without a compelling reason to do so.
Here are two suggestions for advocating boost:
Who's Using Boost? (http://www.boost.org/users/uses.html)
lots of major projects use boost: (e.g., adobe photoshop, CERN)
Boost Project Cost (http://www.boost.org/development/index.html)
How much it would cost to hire a team to write boost from scratch? There's a nifty (somewhat gimmicky) calculator there that helps to put it in perspective.
I've used Boost graph library a fair amount but not much of the rest of it. I frequently see recommendations here to use parts of Boost (say, Boost's various smart pointers). Obviously Boost is good and good to use. It is also large or diverse. Does anyone know of a FAQ or decent best practices doc to help a knowledgeable C++ programmer make better use of Boost?
You might find https://stackoverflow.com/questions/379290/how-to-learn-boost useful.
But in general, keep in mind that Boost is not a library, but a collection of libraries. Which means that you can and should use parts of it, but probably not all of it.
Just read over the list of libraries within Boost, and check the documentation for the specific libraries that sound useful. The Boost website is really the authoritative source, both on what Boost has to offer, and on how it should be used.
Pick out individual libraries that seem useful, and see what the Boost website has to say about them.
I learned the libraries I use by other developers suggesting certain libraries and me reading all the documentation I could find/needed to use the library.
However recently I bought this book, Beyond the C++ Standard, that introduces the most common parts of Boost. Even with reasonable boost experience I found this book really useful. It explains what the the libraries do, why they do it, how to use it and some of the techniques they use to implement it.
When some problem looks like a wheel which was invented already, firstly I look at boost's list of libraries and I trying to use that which will be appropriate for certain task. That's is my way to learn boost.