Stefan Strasser wrote:

Zitat von Ryan Gallagher <ryan.gallagher@gmail.com>:

...

alfC <alfredo.correa <at> gmail.com> writes:

...

I stumbled upon the concept of true typedef, or strong typedef in opposition to usual typedef which are weak. [snip] I was wondering if this is already implemented in some corner of Boost, or as a detail implementation.

There's a detail impl in serialization, I believe. Search for BOOST_STRONG_TYPEDEF

there is more interesting stuff in Boost.Seriailzation that could be part of boost in general. - especially seriailzation::singleton, because it requires linking to the serialization library even though you don't serialize anything.

Hmmm - the whole purpose of boost::serialization::singleton was to be header only and require no linking against any other library. Did I get this wrong?

- ptr_serialization_support in http://www.boost.org/doc/libs/1_41_0/boost/serialization/export.hpp which forces instantiation of a function.

this apparently cannot be implemented platform independently, so Boost.Config might be the right library for it?

These are related to boost::serialization::extended_type_info which extends the standard type_info facility in accordance with the needs of boost serialization. This results (sort of as a side effect) support for runtime plugin - sort of like a poor man's C++ COM.

- smart_cast

yep and my personal favorite - dataflow iterators. But I suspect this functionality has probably been covered by Ranges - I'm don't know this, I'm just deducing that from the name. Oh - codecvt_utf8. The whole codecvt thing is ripe for a library. I realise that some proposals have been made in this area. I haven't studied them in detail so I don't want to be critical. But, my experience with using the codecvt facility in the serialization library leads me to suspect that it is better than is generally appreciated. In fact, the whole C++ streams is better than it first appears. The problems is it's sort of obtuse. Some libraries to help support it would help explain and promote this. I'm thinking of things like composable codecvt facets and alternative filebuf implementations. I've always felt the boost streams library got a little off track by not leverage enough on the standard library - a missed opportunity in my opinion. Robert Ramey

Stefan Strasser wrote:

Zitat von Robert Ramey <ramey@rrsd.com>:

template <class Archive, class Serializable> struct ptr_serialization_support { # if defined(BOOST_MSVC) || defined(__SUNPRO_CC) virtual BOOST_DLLEXPORT void instantiate() BOOST_USED; # elif defined(__BORLANDC__) static BOOST_DLLEXPORT void instantiate() BOOST_USED; enum { x = sizeof(instantiate(),3) }; # else static BOOST_DLLEXPORT void instantiate() BOOST_USED; typedef instantiate_function< &ptr_serialization_support::instantiate > x; # endif };

which forces instantiations in order to register serializers as part of static initialization. AFAIK there is no way in C++ or boost to initialize data on startup that is not specifically referred to (like in a static variable), but only modifies static data. like you do in Boost.Serialization to create the serializer maps.

Dave Abrahams gets credit for the implemenation of this. It replaces some even more hacky code which was depended upon header order. I don't see a wider application - but then I've never thought about it. Actually my point is really totally different. Here is a scenario: a) Some writes a library - e.g. serialization. b) In the course of doing so, it becomes necessary implement some new concept which isn't arleady in boost. One then has two choices: i) just make it ii) step back and make it "better" by organising it as a small library. In both cases the new facility becomes an implentation detail. Personally I prefer ii) above. because it helps clarify my thinking and results in something I test independently and orthogonally. The result looks like a boost library, and it's good enough for government work - but it hasn't been subjected to the rigorous criticism that other libraries are. The previous examples describe these modules in the serialization library. I"m absolutely sure that most of the larger libraries have similar "sub-libraries". I also know that some of the "sub-libraries" have evolved in separatly reviewed and maintained boost libraries. Our current review, testing, deployment, etc system doesn't support this reality very well - which is a large part of my proposal as presented at BoostCon 2010. I believe we are starting to make progress on this but it will take time. My concrete suggestion here are for those who want to enter the "Boost Pantheon" of authors of officially reviewed libraries. This includes GSOC candidates. Most of the library proposals are way to ambitious to complete in the alotted time. But there are lot's of "sub-libraries" which could be promoted. This would require building up the library infrastucture - adding missing features, documentation, comprehensive testing, etc. and defending the "new" library at a formal review - and of course being the maintainer. I realize this doesn't have the sex appeal of make a new library from scratch - but in the longer term it's real fundamental value which makes a difference and makes for a successful library. (Hmmm - I'm restraining myself from carrying this analogy over to marriage). Only and idea which is truely finished and polished has value as a boost library. The "sub-libraries" have demonstrated their utility - but they need owners. Robert Ramey

Le 20/07/2010 22:16, John Dlugosz a écrit :

There may be a single feature (like the utf-8 facet) that is duplicated in several places and needs a home. But that home could be some existing library, or a new misc library, rather than a very small library of its own? I think it would be helpful to have a list, to encourage people to "adopt a feature", and to see if anything ought to be grouped together. And people working on other code will have a central place to report these when they are noticed or introduced.

There are two candidates for a unicode library that should enter the review queue soon, and they'd probably be a better home for this.

Mathias Gaunard wrote:

Le 17/07/2010 17:26, Robert Ramey wrote:

...

and my personal favorite - dataflow iterators. But I suspect this functionality has probably been covered by Ranges - I'm don't know this, I'm just deducing that from the name.

I don't really understand what dataflow iterators are. Isn't it just a syntactic shortcut in the constructor of an iterator adaptor that calls the base constructor recursively?

That's my name for it. All it is is an iterator adaptor with a templated constructor. This permits me to make new iterators by composiing existing ones. All the work happens at compile time. I've suggested that the interator adaptor have a templated constructor Although I think there was some merit in the idea there wasn't enough interest to do this. In any case, I'm suspecting that ranges might have implemented similar functionality.

...

Oh - codecvt_utf8. The whole codecvt thing is ripe for a library.

Since wchar_t is potentially 16-bit, utf8_codecvt_facet should do transcoding between UTF-8 and UTF-16, not between UTF-8 and UCS-2 as it does now.

However it doesn't appear that it is possible to do N to M conversion well with a codecvt facet according to what someone said in another thread

I'm just describing what I would like to see. That's all.

...

I realise that some proposals have been made in this area. I haven't studied them in detail so I don't want to be critical. But, my experience with using the codecvt facility in the serialization library leads me to suspect that it is better than is generally appreciated. In fact, the whole C++ streams iis better than it first appears. The problems is it's sort of obtuse. Some libraries to help support it would help explain and promote this. I'm thinking of things like composable codecvt facets and alternative filebuf implementations. I've always felt the boost streams library got a little off track by not leverage enough on the standard library - a missed opportunity in my opinion.

What I've got as part as my Unicode library is a straight-forward Converter concept and convert iterators/ranges. You define a Converter that describes how to do one step of an arbitrary variable-width N to M conversion with input and output iterators, then you can turn it into an iterator adaptor to convert as you traverse or just apply it in a loop to do the conversion on the whole range eagerly. You can of course apply different Converters one after the other or even compose Converters, albeit the latter has limits since the steps need to play nicely together (i.e. either the Converter needs to be stable by concatenation, or the one applied first needs to have fixed-width output).

That sounds like what I called "dataflow iterators". I did use it for implementing base64 output and lot's of other conversions. The only thing I needed to do this was to add a templated constructor. The other thing I would like to see is a codecvt facet which takes an iterator adaptor a template argument.

I have made a facility to make a codecvt facet out of any Converter, but I suspect it doesn't really work at all since I don't think I deal with "partial" cases correctly, and I haven't come up with a practical way of dealing with Converters that are not stable by concatenation.

This seems to me to be the right idea. But no doubt it's a lot harder than it looks - if it's doable at all.

The fact that you can't have anything other than char/char or wchar_t/char is also a bit limiting.

Note that I used the "dataflow iterator" to implement things that were not 1 to 1. (like base64 output of binary data). Robert Ramey