This web site is an effort to support the creation of more quality C++ libraries by
Specifying the minimal requirements that a C++ library must fulfill to be useful to the C++ community.
Suggesting the tools and methods to meet those requirements with minimal effort.
That is, while specifying the library requirements and suggesting tools to be used, we wanted to permit libraries to use their own tools if the author desired. This means that we can add per-existing conforming libraries to the site without disruption. Also, in practice, there is a wide variety of size of libraries. Some are very small maybe one header file, while others might be very large. So its very likely that different solutions for things like issue tracking, documentation preparation etc. might vary. Finally, tools evolve. In the last ten years, preference in source control systems has evolved from CVS to SVN to GIT. We want to permit library tools to evolve as well. It is for this reason we don't implement facilities such as issue tracking in this website but rather expect the a library submission provide links to where these facilities are actually implemented.
There are pieces of this all over the place.
These were interesting in that they focused on providing a unitified system for library development. I was never sold on the idea that one could be successful by telling C++ programmers what to do. (I can get barely get anyone to listen to my suggestions). And besides - it's a huge amount of work do something of this scale.
So my approach was to make a "facade" which would
permit an author to use what he already has for repository, issues, testing dashboard, etc. This would make it easier to make a submission. So far this has worked out well. There are already multiple kinds of repositories and test dashboards being used by different authors. Apparently they had no problem making a submission. The main obstacle for a submission is that I require browsable html documentation. Even this low bar keeps out much useless code.
present a unified interface to a variety of underlying tool implementations. The user interface is a "facade". This is to make it easy to browse documentation, code and issues, etc. in a more or less unified way. I want a user to be able to evaluate 10 libraries in an hour so he can accept one for his own application. Currently this takes a couple of days to do.
Not have to do any of the facilities myself since it's pointless to replicate other's work - and let them maintain it. If they do a bad job - then authors will switch and just update their links. You can see the whole point is for me to avoid doing any actual work - which of course is why I'm a software developer in the first place.
provide mentoring for library authors to maximize the success of their efforts.
build on and support the Boost review system.
I wanted a website that had all the features that modern websites should have:
Aesthetically pleasing with good typography, flowing text, etc.
Ease of maintenance, update, etc.
Accept commentary and library submissions.
Appropriate user control and spam suppression
Exploit modern social media features such as RSS feeds, Facebook Favorites, per library and per page nested comment threads to facilitate library development. Perhaps these will become a permanent historical record which gathers all the "extra" information required. Also this will permit users to leave hints for those users which follow. It's about organizing information which is now all over the place.
Achieving the above turns out to be much more effort than one would think. The whole web development universe turns out to be a very unpleasant place for a C++ programmer. I won't spend time with the details, but here are some of the options I considered.
Previously, many years ago, I made some websites. To implement forms I used PERL. It was easy to use, but ended up very much a hack. Good enough for the simple things I wanted to do then, but I knew immediately that I needed more help than PERL could offer.
This is a website builder which generates all the site pages by answering questions. Actually not bad as far as it goes - it can only go so far. Fortunately I didn't have to invest a huge amount of time to understand that it wasn't going to do the job.
I looked at PHP and was quite impressed.
Excellent documentation of the language and libraries. This really impressed me. Also all the documentation pages permit additional explanation, examples, etc. To be added by the community. This turns out to be very, very helpful. I resolved to include such a facility on this web site as well. I also considered the possibility of permitting users to annotate documentation of submitted library documentation. I set that idea aside as it would take me further off course, but I remain intrigued with it.
The PHP language is sort of "irregular" in comparison with C++. It's sort of a poor man's C++ interpreter. But in reality this isn't a huge problem as the task for which PHP is used - creating dynamic web pages - isn't all that demanding.
Web pages generated with PHP tend to be HTML interspersed with PHP (or vice versa). Since a lot of it isn't carefully written, it turns out to be indecipherable to the human brain.
I'm not sure if there is a way to debug it interactively. At the vary least it would require a server on one's local system. I didn't think I should have to go to all that trouble just for a relatively simple application.
I'm not sure how much overhead dynamically interpreting PHP adds to the serving of web pages. I just assumed that it would not be an issue on this low traffic web site.
I actually made a prototype web site using just PHP. It was not unsatisfactory, but by this time I became enamored with the ability to comment on submissions and pages and added this facility as a requirement. Also, maintenance would be an issue. So I resolved to find a more complete solution.
Having seen the PHP documentation and being a being a huge fan of WikiPedia, I investigated MediaWiki and other Wiki systems. There are many of these. Most are written in PHP. After spending too much time, I concluded that making this do what I want would entail too much work and resolved to look elsewhere.
Next I tried Wordpress. This is a very impressive setup.
A complete system for administering the site including users, pages, PHP code etc.
An architecture which supports "plugins" and "themes". These permit one to decouple - to some extent, the look and feel of the sight from the content. There are thousands of plugins and themes available. They are easy to try out. Turns out that most of these are deficient in some way so one has to try quite a few of them to get things just right. It's no perfect, but it's great when it works.
Documentation is not too bad. In addition, there are books available.
Support for commenting on library submissions and web pages. This includes spam filtering, user logins, email notification, etc.
So it was a good start. However, getting things "just right" finally meant learning quite about the whole system which consumed a lot of time. Like most things, it has to be "made to work". Still, all in all I got it to make most of the things in this site work the way I wanted.
The result you see here is a customization of a standard Wordpress theme. This required approximately 1000 lines of PHP code and 13 (at last count) free and paid Wordpress plug-ins. Trying to count all the Wordpress and plug-in code included would be hard to do - but I doubt it would be less than 20,000 lines. I don't know if another tool (that I didn't look at) would have made the job easier, faster or better. I just stopped looking when I found something that could do the job.