Overview
Features
Download
Documentation
Community
Add-Ons & Services
The POCO C++ Libraries Blog

Archive: February, 2007

Does C++ Suck?

Filed under: Uncategorized by alex at 18:57

Here’s a blog on how C++ sucks and committee members are an ignorant bunch having little or no clue what they talk about when it comes to threading. I find it interesting to see over and over how people sharply and firmly focus on a single aspect of [insert your favorite issue here, from Iraq war to garbage-collection] and elaborate it to a great extent to prove a point without even bothering to look at the big picture, historical context and value of optimal solution morphed by all the forces acting upon and constraining the issue at hand. Often they have a point in the narrow sense, but they also blatantly disregard any other concern. I guess the world should reboot now, deleting all the code written so far and starting it over in a language so pure and perfect that we’d think we’re in heaven. Before we embark on that journey, someone points us to No Silver Bullet, please. Mixing that kind of “analysis” with arrogance is also often a case. For the intrigued, comp.lang.c++.moderated has discussed the issue, too. I haven’t learned much from that discusion thread.
But wait, here’s the solution to the problem, blogs another expert. It’s called “the Erlang way”. Without pretending to be an expert on the issue, let me take a minute here to share what I have (prompted by the mentioned blogs) recently learned about the Erlang way of concurrency. It’s based on the Actor model. Erlang processes (not to be confused with OS processes) are single threads (not to be confused with OS threads) of execution that share nothing, which makes them safe in a concurrent scenario. They are not operating system processes and are very lightweight, hence cheap to spawn, making Erlang applications readily concurrent in an agile way and very scalable. The Erlang poster-boy, Yaws web server beats Apache hands down in both performance and scalability. However, the important point is that the problem is not in Apache or C. The culprit is actually the operating system and the way it implements concurrency. C (or C++) simply uses the OS API to achieve concurrency. And I’m not sure whether there’s any room for Lin-Win fight in that arena – they seem to be about equally bad, give or take. But hey, worry you not, prudent software professional, that too is about to be resolved by the upcoming world reboot alongside with the operating system rewrite in The Perfect One-and-Only Language. I could actually make a good use of a sabatical decade, and this seems like a perfect opportunity.

Joking aside, who wouldn’t like to see a good solution for concurrency – it’s like an 18-wheeler coming down the road at us. However, there are fundamental reasons preventing true Erlang-like functionality in C++. A significant aspect of Erlang processes is their lightweighted-ness, which comes from the fact that they are spawned with minimal stack size which can later be resized if needed, which, as it turns out, is impossible to achieve without keeping track of the pointers to allocated memory. In plain words – you need garbage collection. For the curious reader, it is explained well in this post. Clearly, nothing comes free, so Erlang pays for this in performance currency – it is slower than C++ when it comes to computing efficiency. So, unless someone can convince the C++ standards committee to sacrifice performance and turn C++ into garbage-collected language running on a VM and have its own (OS independent) threading implementation, the whole discussion is a waste of time. I’ve been thinking long and hard of a “microkernel-like” design for my servlet container – I’d love to load a shared library (or some sort of a lightweight “process”) really quickly and not share my memory with it (i.e. not be vulnerable to anything bad going inside the library). Any way one looks at it – you can’t have it all. There are always trade-offs and that’s the bottom line.

So, back to the original question – does C++ suck? If one looks at some aspects of the language in isolation, a compelling “C++ sucks” case can easily be built. However, when one reads through Design and Evolution of C++, many a reason for language features becomes clear and obvious. Mistakes have been (vector<bool> :-\ anyone?) and likely will be made. However, on average, I’d say that C++ crowd comes across as a pretty sharp bunch. I’ve personally heard Stroustrup say that running multiple threads in shared memory space is simply not a good thing to do. Imagine that, bloggers – even he is aware of it. Unfortunately, we live in an imperfect world and write our imperfect applications in imperfect languages to run them on imperfect machines being controlled by imperfect operating systems. Theo de Raadt puts it well in one of his interviews: “everything we build is turds, we just move them around or shine them or have a different view on which way they should be rolled”.

Concurrency shall be addressed in the upcoming standard. There are some interesting proposals emerging that could make concurrency easier to digest in C++, such as lock-free techniques as presented by A. Alexandrescu and B. Stroustrup. It is important to stay alert, think before you code and expect no miracles. Short of some lunatic pressing the nuke button, the world is not rebooting any time soon. So, looking at it from a broad perspective, C++ does not suck. It is the most succesful general-purpose computer programing language in history. And, for better or worse, warts and all, it still rocks.

POCO 1.2.9 Released

Filed under: News by guenter at 11:02

Time for another POCO bugfix release. 1.2.9 fixes various bugs and brings some performance improvements, most notable in the HTTP classes. Sergey N. Yatskevich contributed various patches for this release – thank you! Please see the CHANGELOG for the details.

How To Tell The Open Source Winners From The Losers

Filed under: News by alex at 15:45

In the last Information Week issue, there is an article by Charles Babcock on the topic of open source and its feasibility for companies.

Here’s Babcock’s classification of a succesful OS project:

  • A thriving community
  • A handful of lead developers, a large body of contributors, and a substantial–or at least motivated–user group offering ideas.

  • Disruptive goals
  • Does something notably better than commercial code. Free isn’t enough.

  • A benevolent dictator
  • Leader who can inspire and guide developers, asking the right questions and letting only the right code in.

  • Transparency
  • Decisions are made openly, with threads of discussion, active mailing list, and negative and positive comments aired.

  • Civility
  • Strong forums police against personal attacks or niggling issues, focus on big goals.

  • Documentation
  • What good’s a project that can’t be implemented by those outside its development?

  • Employed developers
  • The key developers need to work on it full time.

  • A clear license
  • Some are very business friendly, others clear as mud.

  • Commercial support
  • Companies need more than e-mail support from volunteers. Is there a solid company employing people you can call?

Model View Controller

Filed under: Uncategorized by alex at 17:11

Prompted by Kai Londenberg’s post, I’ve decided to actually sit down and read Terence Parr’s papers.

As we all know, the MVC pattern is a classic, right? According to Parr’s articles, a vast majority of the modern incarnations claiming to be designed after it are actually blatantly violating it. In his paper, he fails to mention Google’s CTemplate, which is attempting something along his lines (I’m not quite clear whether CTemplate is actually used anywhere – the code is quite messy, but the idea behind it is sound). According to author, the StringTemplate is [quote] “a general purpose text generation engine with a functional language that strikes a balance between power and enforcement of model-view separation” [/quote].

From the theoretical standpoint, Parr appears to be right. I do not have any experience with StringTemplate or CTemplate to be able to make a valid judgment about practical use, but Parr has some good testimonials and few real world projects (jGuru and other web sites, ANTLR3) to back up his theory.
In any case, I have found the mentioned material very educational and definitely worth reading.