The POCO C++ Libraries Blog

Archive: August, 2006

POCO 1.2 Released

Filed under: News by guenter at 09:00

POCO 1.2 has been released today.
This release contains major improvements and new features.
Summary of changes (please see CHANGELOG for details):

  • namespaces and header locations have changed
  • improvements to command line options handling
  • improvements to HTTP server and client classes
  • support for raw sockets and ICMP
  • improvements to DateTime, bugfixes in Timezone
  • improvements to Logging (including a new LogStream class)
  • HashTable classes in Foundation
  • ThreadPool now supports thread priorities
  • ActiveMethod now supports start policies; improved exception support
  • typesafe sprintf-like formatting
  • Process::launch() now supports I/O redirection to pipes
  • improvements to the build system (configure; make; make install is now supported)
  • various other bugfixes and enchancements

Paradigm Shift

Filed under: Uncategorized by alex at 17:20

Jim Coplien is blogging on the next paradigm shift and first signs of recognition of his 8-year old book. Very interesting read.

The Sandbox is Now Open

Filed under: News by guenter at 15:08

I have created a sandbox directory in the SVN repository for POCO.

Currently, two libraries live it in, both contributions by Alex: Web and IO.

Those who know how to do …

Filed under: Uncategorized by alex at 00:01

… do, those who don’t – teach.

Believe it or not Scott Meyers is a poster boy for the second half of the above statement. He is also the first person that made me think about it in a serious, positive and equal-to-the-first-half sense. Whether he knows how to do, I don’t know. But I don’t think anyone would dare to deny Scott due credit for his work – it is safe to say that the guy is top-notch, world class, one of the few, in what he does. Yet, he confessed recently it’s been decades since he has written a line of production code. And no, it was not in C++. I know you are surprised. I was, too. At first. Then I was relieved because I have realized why I read Scott’s books and attend his seminars, not the other way around. I am from the first half of the sentence. Since my employer keeps on handing me magic green pieces of paper which I am skillfully converting into useful stuff like bread, butter and air-conditioning, it must be that I am from the first half. And since “In God we trust, everyone else pays cash”, I’m really happy for it ;-).

But, I do not want to talk about Scott or myself. I want to talk about Poco – a top-notch creation in the first-half sense (although second-half application should not be excluded – I heartily recommend it to universities if they really want to teach students how to make software properly). There is a lot of pragmatic sense in Poco for things that, well, make sense. And that matters, especially in C++ and real world (AKA “production”) domains. From my personal experience in the last year and a half, Poco is made by folks who know how to do. My contributions are really small compared to the overal size of the framework, but I am nevertheless proud to be a part of it. Anyway, how does the Fair and Balanced Poco Dictator keep our Favorite Framework Kingdom a great place to live and what exactly is it that makes us love it more than other frameworks out there? For one thing, there are no re-invented wheels in Poco. At least not non-round ones. std::string is thy string and thou shalt have no other strings. STL does a pretty darn good job at containing things and iterating over them, so use it, rather than trying to parallel it. Regular expressions, compression, xml parsing, … have been conquered by some folks long time ago. Stand on their shoulders rather than your users’ toes. Also, it’s nice that all parts have the same “look and feel” to them.

To be completely fair and balanced, there are missing parts (see project ideas) and not all things Poco are as shiny as they could be, but once rare rough surfaces are spotted and pointed out, they are quickly and efficiently taken care of. Util::Application options are the most recent example.

So, let me conclude with a provoking thought based on article from the second-half poster boy. Not exactly the most recent stuff, but actual nevertheless and it made me think – there may be some classes in Poco with too much interface and I myself am guilty for some of them. Would it make sense to think of pulling out some existing non-member functions (DateTime and Timestamp numerous operators come in mind) and also considering NMF in future where it makes sense? It may seem like a heresy at first, but it would make objects lighter and enhance encapsulation which may make it a worthwhile endeavor.

Comments welcome.

New 1.2 Snapshot Available

Filed under: News by guenter at 16:08

A new snapshot release of 1.2 (poco-1.2-20060816) is available from SourceForge.
This release is now feature complete and contains the proposed changes to namespaces and header file locations. If no severe issues will show up, the official 1.2 release will be available next week.
The changelog is here. And the updated reference documentation is here.
Not all platforms have been tested yet.

I have released another snapshot today: poco-1.2-20060817
This release should work on all supported platforms, and it also contains improvements to command line argument handling in Util::Application. See the changelog for details.
The documentation has been updated.

Update 2:
Another snapshot: poco-1.2-20060818 (Changelog)

Namespaces, Again

Filed under: Uncategorized by guenter at 17:27

Today I made a change to the way namespaces in POCO are handled. First, I got rid of the unpopular namespace macros. Second, I introduced an outer Poco namespace.
The change was quite painless and with the help of Visual Studio’s Replace in Files function I was able do the complete change in about two hours (including building and running the testsuites).

For the namespace syntax, I chose same style as in Boost. This means that namespace blocks are not indented, and the way the braces are placed is different than the way the Coding Styleguide suggests. Instead of Foundation_BEGIN and Foundation_END we now have

namespace Poco {
namespace XML {

class ...

} } // namespace Poco::XML

This seems like a good compromise between readability and style.
Unless there are major objections, I plan to put the changes into 1.2. I will probably also add some kind of backwards compatibility switch in the form of a using namespace Poco; in Foundation/Foundation.h if a certain preprocessor macro (POCO_USE_POCO_NAMESPACE) is defined.

I am thinking about getting rid of the Foundation namespace alltogether. So, everything in the Foundation library will be directly in the Poco namespace, while the other library will use two namespaces (Poco::XML, Poco::Util, Poco::Net). I think this makes sense, because Foundation is the “heart” of Poco, and all other libraries depend on it. Boost does it similar. Also, shorter namespaces make the code more readable (Poco::Foundation::BufferedBidirectionalStreamBuf really is quite long).
Also, I am thinking about changing the directory hierarchy for header files, by introducing a Poco top-level directory. This will again sync namespaces to include file hierarchies, so we have
#include “Poco/BinaryWriter.h” for Poco::BinaryWriter
#include “Poco/Net/HTTPClientSession.h” for Poco::Net::HTTPClientSession.

The only downside is that this will break existing code and require a global search/replace session. However, my own experience with our quite expensive codebase shows that this can be done quite easily. I really want to put this into 1.2, because the longer we wait with breaking changes, the more damage will result.

Preview of Release 1.2 Available

Filed under: News by guenter at 20:30

I have posted a preview of the upcoming 1.2 release to SourceForge (poco-1.2-20060810). Get it from here. The changelog is here. And the updated reference documentation for 1.2 is here.
This release has not yet been tested on all platforms, so you might experience some rough edges. It should work fine on Windows, Linux and Mac OS X.

In Medio Stat Virtus

Filed under: Uncategorized by alex at 00:18

No, I will not write about virtual function call runtime overhead ;-). I want to comment on some blogs instead and point out that the virtue is not in extremes.

Is functional programming back to mainstream? Writes Joel Spolsky about merits of functions: “programming languages with first-class functions let you find more opportunities for abstraction, which means your code is smaller, tighter, more reusable, and more scalable”. Well put, Joel. To conclude his point, Joel refers to Steve Yegge’s blog. Steve is a bit too harsh on OO, but has a point nevertheless. At one point, he even gives a credit to C++ for supporting functions. He immediately straightens the record, though, explicitly stating that he does not claim “C++ is good”. It appears that Steve feels like no respectable contemporary programming expert could utter a such a heresy. Perfect things exist in fairy tales, Steve. We, however, live in an imperfect world. And, as a consequence, C++ is indeed not good. But it’s the best we’ve been able to come up with so far. It is hard (yet worth the effort) to find the right balance between embracing new technologies with moderation while keeping the good old practices and backward compatibility. What we are (finally) witnessing is the thick OO (Objects Only) early morning fog evaporating in the mid-day sunlight. In that sense, Java has already failed with “everything as Object” (except for those few things that are not) and it’s version of “generics”. Moreover, the former is failing on two fronts simultaneously: C++ crowd sees it for what it is – a trendy marketing name for a fancy cast syntax, while Java crowd thinks Sun (pun intended 😉 ) has rudely spoiled their foggy OO party.

And what about our favorite language? It’s been happily promoting multi-paradigm programming for decades now. The C++ future is exactly where it’s been so far – compatibility with the past, promotion of good practices, smart introduction of new concepts and libraries and keeping up with technologies as they become mainstream (which is not exactly at the moment of an idea introduction as Herb Sutter points out). As long as it regards the past, keeps up with times and technology while steering clear of extremes, C++ will do just fine. Respice, adspice, prospice.

Namespaces in POCO

Filed under: Uncategorized by guenter at 17:00

There has been a lot of discussion lately regarding namespaces in POCO. Both the way how namespaces are defined, which is currently done with macros (shudder 😉 ), and the way, namespaces are, well, named.

I am seriously thinking about getting rid of the namespaces macros. After reflecting about it for some time, the main reason why I used them in the first place was just because I was so used to them.

There is one open question, and this is whether we should put everything into a top level Poco namespace, or not.

Personally, I think, one level of namespaces is enough in C++. C++ is not Java, where the runtime requires that everything is in a unique namespace. This is because in Java there is no linker involved, only a class loader. In C++, the developer has direct control over what’s getting linked to his application, so this alone greatly reduces the possibility of naming conflicts.

Nevertheless, with just one level of namespaces, there is a small chance for collissions, especially since we’re using four namespaces (Foundation, XML, Util, Net), and even more in the future.

So, the big question: Should we put everthing into a top-level Poco namespace? Tell me your thoughts!


Filed under: Uncategorized by alex at 22:42

Thank God It’s Friday – a perfect time to relax and put out few thoughts about programming languages. Not surprisingly, I often come across as a language bigot, which I really am not. It’s not my fault that there’s so many lousy languages, and only one True One ;-). Just kidding – I actually wrote few Python lines of code a couple of years ago and – liked it.

Seriously, when I think a bit more about what is it exactly that ties me to C++, I concluded that the most important things are independence from any proprietary lock-in and low performance price paid for abstraction. Don’t get me wrong about lock-in – it’s not the money I’m against – I have no problem with people charging for software or related development/suport services, after all I am doing it myself. But I want my freedom to get out of it if I choose. When I see an attempt to cleverly lure, lock me in and then engage in extortion scheme knowing I have no choice but pay, I am out of there. I have recently attended a presentation about a major car manufacturing facility information system that is 100% MS VB. Presenter said the choice was smart because “things are really smooth and easy with VB”. My language bias aside, I could not help but wonder whether his opinion had anything to do with the fact that he is working for the contracting company supplying software development and maintenance services to the mentioned manufacturer – all viewed in the light of the fact that most of their recent income is generated because MS has desupported VB, so everything must be ported to VB.NET. I am truly grateful to the C++ standard body for paying so much attention to backward (and C) compatibility. Especially since they are not paid for it. And then, to be quite honest, I am also thankful (believe it or not) to – Microsoft. I think their support for C++ has helped a lot to keep C++ alive. Needless to say, they’ll have to look elsewhere for their proprietary extensions victim, though.
As I have mentioned already somewhere, I have been using Poco for about year and a half at work, in school and more (sometimes I really I think I need a life 😉 ). The more I use poco, the more I like it. I had no problem with it when it was not “free” and I personally did not see the big issue with eventually being required to pay for it if I’d want to venture into making money with it and deny the rest of the world to peek into my code. During this year and a half, I wrote 3 relatively small apps at work to see how does poco do in real world (steel manufacturing material tracking and process control) and they run as a charm – “set it and forget it” in its best – we are currently considering a major port of a significant portion of legacy code to Poco platform. I have also started two projects on my own time. These projects will be open sourced, well … soon (gotta go get a life first) – I’m currently waiting for 1.2 release to polish and actually launch the first project – dubbed Molto – a 2.4 Sun servlet specification compatible Poco-based container. Stay tuned …