Ian wrote: >>> This way we could support different output stream libraries and keep > boost maybe as an optional dependency. What do the others think? Does > this all make sense? > > Dom & Craig, > > From a package integration point of view, I really prefer to have > further dependencies kept to a minimum, especially with multiple > platform and multiple compiler ports looming. If you do bring in boost, > I would prefer it optional so we could build without it for > core functionality.
That eliminates the utility of using the Boost streams framework in the manner I was hoping for. In PoDoFo's case I don't care very much, since we have existing code that works just fine. I was hoping to use the Boost streams framework to see if I could make things easier for people new to the code, make it easier for users of the library to operate in a stream-oriented and memory efficient manner, and see if I could get some speed boosts along the way. In the end, though, it's not a big deal - I'm not sure it would work out, and I'm not sure if I'll have time to do it. Consider the matter dropped. At this point, though, I must confess to considerable frustration with regards to Boost. It's the library everybody wants to use, but nobody uses because it's an "additional dependency". So we all write more code not directly related to what we're trying to do, then spend more time debugging and optimising it. I'm not convinced this is a particularly wise choice, especially since Boost is portable across a large variety of platforms and compilers (look at their automatic test suites) and has pre-packaged versions for most platforms. Additionally, many of the Boost libraries don't even have to be compiled separately, and can just be used as headers. I increasingly suspect, however, that C & C++ developers' tendency to avoid dependencies wastes a great deal of time and helps produce lower quality code than we could if we just used what we needed to get on with the job at hand, if nothing else because it takes testing and debugging time away from the core functionality of the app. The Java folks clearly benefit from the lower cost of introducing dependencies and the better in-language libraries. How many reference counting templated shared pointer implementations do you think there are out there? How long do you think it can be before we can actually *use* things like std::tr1::shared_ptr or <tr1/tuple> without people screaming about it? 10 years? As it happens it looks like Boost is working to help there by including a set of tr1 headers for older compilers ... but of course, if you try to use Boost you get complaints about dependencies. [BTW, I'm not actually all that in love with templated refcounting shraed pointers - they often serve to hide the real problem, rather than help to fix it. It's still a good example.] I'm really beginning to understand why people use Java (you can just tell the user to upgrade their Java runtime, and they'll *DO IT* - not least because they can do so without breaking the install of any older ones they might also have) or C# (when a language feature is released, you can bundle the runtime to use it with your app. So long as you only care about Windows, anyway). By contrast, C++ developers are being constantly dragged back as if they're programming for systems 10 years older than they really are. -- Craig Ringer ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
