- Boost - lists.boost.org

Re: [boost] [lexical_cast] A suggestion
by Vladimir.Batov＠wrsa.com.au 10 Feb '09

10 Feb '09

> That's not my concern. My concern is that I don't think lexical_cast is > a particularly good interface for its main uses, which could be thought > of as "to-string" and "from-string." Dave, I am not sure what you see wrong with lexical_cast interface. Could you elaborate? I am not using lexical_cast (due to throw, no default value and the def.ctor requirement). So, I still keep using the analog I wrote a while back and well before I ever heard of lexical_cast. Even though I wrote it independently, the interface happened to be very close: namespace aux { namespace string { template<class Type> std::string from (Type const&); template<class Type, class String> bool is (String const&) throw(); template<class Type, class String> Type to (String const&); template<class Type, class String> Type to (String const&, Type const&); } } That is, string str = aux::string::from(-1); int i1 = aux::string::to<int>(str); // throw int i2 = aux::string::to<int>(str, -1); // no throw As you can see it is pretty close to lexical_cast. > ... > I just don't think lexical_cast is the interface we need for most > convenient string conversions. It might be the case. However, I do not see any other practical suggestions that we could act on. Therefore, in the end we end up with nothing at all... again. That's been dragging for far too long. > ... > Maybe so, but I don't think lexical_cast is all that well-designed for > convenience to begin with, and tacking on little convenience features > isn't likely to yield a very clean interface. I am not that concerned about the internal design as it can be worked on and improved without rush behind the interface. If it is the interface that is the issue, then let's look at it. Any suggestions? So far, I do not see people arguing against that proposed "extension" offering anything practical in return. That is not constructive as people end up with nothing at all. I am not counting the <optional> suggestion as it seems as an overkill and it still has the default-constructability requirement. Thanks, Vladimir.

4 9

call_traits<SomeEnum>::param_type
by Leo Landa 10 Feb '09

10 Feb '09

Good day to everyone! Is there some reason why call_traits<SomeEnum>::param_type evaluates to be the const_reference (const SomeEnum&) instead of value_type (SomeEnum)? I can't figure out if its an easily fixable mistake in the library or a result of some consideration that's not quite obvious. Any advice is greatly appreciated. Leo.

1 0

[1.38] Beta release of PDF documentation (and some help needed).
by John Maddock 10 Feb '09

10 Feb '09

Folks, SVN commit 51104 to trunk provides the basic support for building all the Boost libraries that can be as PDF's: * improved fo.xsl stylesheet, * tweaked individual Jamfiles so they find their images etc when being built as a PDF, * adds doc/pdf/Jamfile.v2 to build all boost libraries that can be as individual PDF's. Beta builds of the PDF's are available for download from http://boost.cowic.de/rc/pdf/ includes the libraries and tools: Accumulators Algorithm/String Asio Bimap Bind ConceptCheck Config DateTime ForEach Function Functional/Hash Interprocess Intrusive Iterator Lambda Logic Math/Complex Math/Octonion Math/Quaternion Math/GCD Math/Special functions and Distributions Numeric/Conversion (currently has a build problem, not on ftp site) Optional (currently has a build problem, not on ftp site) Proto PtrContainer Pythod/Tutorial Range Regex ScopeExit Signals Spirit/Phoenix StaticAssert Thread (currently has a build problem, not on ftp site) TR1 TypeTraits Typeof Units Unordered Variant Xpressive BoostBook (currently has a build problem, not on ftp site) Boost.Jam Boost.Build Quickbook. I'd be grateful if all the Boost library authors that are using QuickBook/BoostBook/DocBook could take a look at their PDF's and check that they're OK, users too if you're willing! Also if anyone would rather that their library wasn't included in this build please speak up now - eventually the plan is make these available as a sourceforge download. The following default build options have now been added to the fo.xsl stylesheet customization layer, let me know if anyone is violently opposed to these: * No indent on body text (we need all the horizontal space we can get for code blocks). * Left and right page margins 0.5in - a little small, but as above we need all the space we can get. * Paper type is A4 - it's an ISO standard, and just a little smaller than US letter, so should print OK on both. * Draft mode is turned off so we don't try and download draft.png just in case. * SVG graphics are used for admonishments. * Default path to search for images (if not overridden in a library's Jamfile) is the SVN repository: allows most (but not all) libraries to be built as PDF's without having to change their Jamfiles. Known TODO's ~~~~~~~~~~~ * Some of the PDF's are badly named: for example the python tutorial is simply "tutorial.pdf", Phoenix is "users_manual.pdf" and Boost.Build is "standalone.pdf". Anyone know how to get Boost.Build to rename a file or else change the name of Boostbook target? * The libraries Conversion, Optional and Thread do not currently build as PDF's - their XML is invalid, looks like an easy fix though - just tweak their usage of hyperlinks at global (i.e. not in a section) scope. I think I can make the changes for this one if their authors agree. * The BoostBook documentation doesn't build as a PDF - Lots of invalid XML - this one looks much harder to fix. I need some help with this one. * Currently only RenderX's XEP FO processor will build all the docs correctly, Apache FOP is *still* not mature enough :-( * There is currently no way to detect overflow of content on the right margin (usually caused by over-long code blocks), ideally this would be made a build error. I've no idea how to achieve this - the things I've tried so far don't seem to work :-( Anyway thanks for your attention, and I'll look forward to your feedback, as well as this list, there is a Wiki site here https://svn.boost.org/trac/boost/wiki/BoostDocs/PDF to track progress, Regards, John Maddock.

11 30

nested BOOST_FOREACH and -Wshadow
by Dustin Spicuzza 10 Feb '09

10 Feb '09

Hey, I really enjoy using BOOST_FOREACH on containers, saves a ton of typing. However, one semi-annoying problem that I've ran into is that nesting instances of BOOST_FOREACH causes the gcc argument -Wshadow to complain quite a bit. A useless example of this behavior is as follows: #include <vector> #include <iostream> using namespace std; #include <boost/foreach.hpp> int main() { vector < vector <int> > array; BOOST_FOREACH( vector<int>& i1, array) BOOST_FOREACH( int i2, i1) cout << i2; } And you get the following warnings: g++ -Wshadow shadowtest.cpp -o shadowtest shadowtest.cpp: In function ‘int main()’: shadowtest.cpp:13: warning: declaration of ‘_foreach_col’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here shadowtest.cpp:13: warning: declaration of ‘_foreach_cur’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here shadowtest.cpp:13: warning: declaration of ‘_foreach_end’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here shadowtest.cpp:13: warning: declaration of ‘_foreach_continue’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here Now, I know that some people don't believe in getting rid of warnings just for warnings sake, but the fix for this would be extremely trivial and useful (given the amount of noise that it generates) -- just add a new macro, BOOST_FOREACH_NESTED, which has a third parameter denoting the level of nesting. That parameter would be token-pasted onto the end of the variable name, and get rid of the warnings. One could define up to N more macros of the form BOOST_FOREACH_NESTED_N that get rid of the third parameter, by calling that macro appropriately. This wouldn't break any existing code, and would allow those that choose to get rid of the warnings. There are a number of arguments against such a change: (a) -Wshadow is gcc specific and isn't enabled by default, (b) If you don't like the warning, don't nest BOOST_FOREACH statements, or don't use -Wshadow. However, my feeling (and this is probably just a matter of personal preference) is that given the triviality of the fix, theres no reason to not fix it. Granted, I could easily just make my own and stick it in a header file, but it seems like it would make more sense to be in boost itself. I could create a patch and post it if so desired. Thanks! Dustin -- Innovation is just a problem away -- Innovation is just a problem away

8 10

[MPI] Dynamic linking on Windows - mpi_datatype_cache() unresolved means BOOST_IS_MPI_DATATYPE unusable?
by Pete Bartlett 09 Feb '09

09 Feb '09

Dear all, It looks like boost::mpi::detail::mpi_data_type_cache() (in boost/mpi/detail/mpi_datatype_cache.hpp) is missing a declspec declaration, causing unresolved external symbols when trying to give a specialization of is_mpi_datatype. Is my use case (Windows, dynamic, "simple" types that qualify for is_mpi_datatype) unusual so that this hasn't been picked up before? Or am I missing something obvious? Thanks in advance for any help Pete

1 0

[lexical_cast] A suggestion
by Vladimir Batov 09 Feb '09

09 Feb '09

I use boost::lexical_cast quite a bit. Possibly due to specifics of my task I constantly stumble upon two things: 1. It throws if/when conversion fails; 2. It requires the 'Target' class to be default-constructible. I'd like to suggest extending the existing template<class Target, class Source> Target lexical_cast(Source const& arg) interface with template<class Target, class Source> Target lexical_cast(Source const& arg, Target const& failure_value) The behavior of the latter would be to return the 'failure_value' if/when the conversion fails. That communicates the fact of the conversion failure differently (without an exception thrown), i.e. its usage would be as following: int value = boost::lexical_cast(some-string, -1); if (value == -1) conversion failed. In fact, my usage pattern is such that I often do not even need to check the success of the conversion -- if the conversion fails, the supplied failure/default value is returned/used and proceeded with. Secondly, the proposed lexical_cast requirements would be looser -- no need for the default-constructibility of the Target, only the copy-constructibility (as already required anyway). For that the current lexical_cast implementation if(interpreter << arg) { Target result; if (interpreter >> result) return result; } throw_exception(bad_lexical_cast(typeid(Source), typeid(Target))); return Target(); // normally never reached (throw_exception) would change (for the proposed interface) to something like if(interpreter << arg) { Target result(failure_value); if (interpreter >> result) return result; } return failure_value; I am not sure how much value such an interface extension might have for others but for my usage pattern the benefit would be quite visible as the majority of our classes are with no default constructors and handling conversion-failure exceptions is quite a hassle... not to mention that for whatever guided/misguided reasons exceptions are virtually banned for our mission-critical development. Best, V.

14 40

An extension to boost::variant
by Chris Hamilton 09 Feb '09

09 Feb '09

While boost::variant is very capable at what it does, there is one thing it doesn't do (and maybe with very good reason, which I'm sure somebody on this list will be capable of pointing out to me if this is the case ;) Anyhow, boost::variant requires each of the enclosed types to be assignable, which is clearly not met of a reference type. My question is this: why can't boost::variant be clever about reference data types (detected using type_traits is_reference), and internally store them as pointers (type derived by using type_traits remove_reference). The outside API (assignment, output streaming, visitation, comparison, etc) could still treat the object as a reference. The reason I want this, is to have a nice String variant, that encapsulates the various forms a string can take in a current project: std::strings, char*'s, and std::string* and boost::shared_ptr<std::string>. I want functions to be able to handle all of these types transparently by using variants as the argument types. Allowing "const std::string&" as a variant type allows this to be done while not requiring a wasteful string copy. Are there any caveats to this that I should be aware of? (I have a small custom variant class implementing this, and it appears to work well. It's not as 'full fledged' as the boost::variant class, but the approach I've taken could surely be grafted on to boost::variant.) Cheers, Chris Hamilton

2 2

1.38.0 release done ?
by Stefan Seefeld 09 Feb '09

09 Feb '09

While I'm casually reading this ML, I notice some ongoing discussion concerning the 1.38.0 release. Looking at the boost.org website, I trip over the 1.38.0 release announcement, and I wonder whether I just missed the 1.38.0 announcement here on the list, or whether someone mistakenly announced a release-candidate for a final release. Could anybody clarify please ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 2

[graph]
by Andrew Sutton 09 Feb '09

09 Feb '09

Update on the BGL. I've just ported my SOC work en masse from 2007 to the BGL trunk. New features include: * [un]directed_graph classes - wrappers around adjacency lists. These serve as introductory classes to help with prototyping. They also try to hide all of the problems with vertex indices and property maps - as in every algorithm requires vertex maps, but only VerteSet == vecS provides them. * degree_centraility - algorithms for computing the degree centrality of vertices in a graph. Includes measures of influence and prestige. * closeness_centraltiy - algoritghms for computing the closeness centraility (based on SSPs) for vertices in a graph. * geodesic_distance - Computes the small-world and mean geodesic distances of graphs. * eccentricity - Algorithms for computing eccentricity, and the radius and diameter of the graph. * clustering_coefficient - Returns the clustering coefficient of a vertex or the average CC for the entire graph. * core_numbers - Partitioning of a graph into cores based on vertex degree (from David Gleich) * all_cycles - Find and visit all cycles in a graph (Tiernan) * all_cliques - Find and visit all cliques in a graph (Bron & Kerbosch) * exterior_properties - A new framework for helping define exterior properties (and property maps) for graphs. New graph concepts: * VertexIndexGraph - any graph for which get(vertex_index, g) is valid * EdgeIndexGraph - any graph for which get(edge_index, g) is valid Since nearly every algorithm requires a vertex index map in one way or another, these may as well be concepts. Also, its a convenient documentary artifact that lets you write, "If your graph is not a *IndexMap, then you must provide an index map as an exterior property." Documentation for these features is forthcoming. Its part of my project to (finally) migrate the BGL docs over to quickbook. There are tests for most of these features - some are in progress - others are woefully inadequate and under development. Since I'm generally pretty busy, these will probably materialize slowly. I'm aiming at 1.40. Questions? Comments? Andrew Sutton andrew.n.sutton(a)gmail.com

3 2

[thread|interprocess] Boost.Synchro: Towards a generic view of synchronization mechanisms
by vicente.botet 09 Feb '09

09 Feb '09

Hi, Currently there are two libraries defining mutex, condition variables and locks in Boost (Boost.Thread and Boost.Interprocess), which have similar interfaces but with some differences. This has as consequence that we can not interchange them. One of the reasons is that we are not working with concepts, and algorithms. Both boost::mutex and boost::interprocess_mutex are models of the same Lockable concept, but not because they share a common syntax but because they share a common semantics. Can we see a binary_semaphore as a Lockable? Well, usually a binary_semaphore will define operations such a post and wait, so binary_semaphore do no share the common syntax as boost::mutex and boost::interprocess_mutex. On the semantic side wait can be assimilated to lock and post to unlock. By the way, there are also other syntactical differences between the Boost.Thread and Boost.Interprocess classes. So how can we write gerenic code that can be used with every model of the concepts. The idea consist in switching from the OO paradigm to the functional paradigm. We found the same approach Boost.MPL and Boost.Fusion between others. So instead of requiring that a model of the concept Lockable defines the member functions lock and unlock, we require that the functional expressions lock(m) and unlock(m) are well founded. A generic Synchro library can define a default implementation that forwards to the member function. namespace synchro { template <typename Lockable> void lock(Lockable& lockable) { return lockable.lock(); } } Now we can overload the lock function on a binary_semaphore as namespace synchro { void lock(binary_semaphore& sem) { return sem.wait(); } } Just another example for a class template anotherLockableModel that models the Lockable concept but that with acquire/release functions. We need to overload again the lock function. namespace synchro { template< typename T> void lock( anotherLockableModel<T>& lockable ) { return lockable.acquire(); } } However, there are cases where overloads do not suffice (as described in N1295 - Partial specialization of function templates), and we need to use partial specialization of function templates. On compiler that do not support partial specialization of function templates we can use a workaround, that is, use partial specialization of class templates. The default implementation will now forward to a static function of a class which has forward to the member function namespace synchro { namespace partial_specialization_workaround { template< typename Lockable > struct lock { static void apply( Lockable& lockable ) { return lockable.lock(); } }; } template <typename Lockable> void lock(Lockable& lockable) { return partial_specialization_workaround::lock<Lockable>::apply(lockable); } } So now the user can partially specialize the class template partial_specialization_workaround::lock and define the apply function as needed: namespace synchro { namespace partial_specialization_workaround { template< typename T> struct lock <anotherLockableModel<T> >{ static void apply( anotherLockableModel<T>& lockable ) { return lockable.acquire(); } }; } } Once we have all the Lockable operations defined in this way, and do the same for ConditionVariable, we can define in a generic way unique_lock, shared_lock and upgrade_lock that works with boost::shared_mutex as boost::interprocess::interprocess_upgradable_mutex. This could leverage these libraries to define its own locks classes. Ion, Anthony, Boosters what do you think of applying this approach to get a generic Synchro library? Should the partial_specialization_workaround be applied systematicaly or it complicates things? Thanks, Vicente

2 3