October 2010 - Boost-users - lists.boost.org

[BGL] visualizing large graphs
by Cedric Laczny 01 Oct '10

01 Oct '10

Hi, although this might seem a bit off-topic, I think it is an important topic and might be very well interesting for some of us. The boost graph library provides methods to export graphs e.g. for the use with graphviz. However, this is a rather "one-way" solution. Besides that, it is difficult to handle large graphs with graphviz. Therefore, I was wondering if there have been some recent developments here? I would especially be interested in a solution that allows the direct visualisation of a graph (even previously serialized), possibly integrating ways to filter out some of the data in order to be able to visualize the graph in some way. It is clear to me that visualizing arbitrarily large graphs will be limited by physical limitations mostly (RAM etc.). But I would find it very convenient to at least load the graph, set some filters, so that I don't need to do this seperatly via a C++-program. Actually, I am writing my graph to a format that can be visualized by Cytoscape. Unfortunately, this suffers from large limitations on the size of the graph (number of edges and nodes). I am looking forward to hear your ideas about this and possible suggestions about libraries or programs that might achieve this goal. Thank you. Best regards, Cedric

6 12

[python] base::get_override() exception set
by Trigve Siver 01 Oct '10

01 Oct '10

Hi, when calling get_override() method while trying to find python overload and overload is not found exception in python is set. This is because PyObject_GetAttrString() is used for retrieving the attribute. If attribute is not found, PyObject_GetAttrString() set the exception. This is using python 3.1. I've created ticket https://svn.boost.org/trac/boost/ticket/4701 with patch. Could anyone look at this? Thanks Trigve

1 0

[format] print float number with fixed number of decimals *and* integer digits
by alfC 30 Sep '10

30 Sep '10

I always found the rules for printf formatting, which Boost.Format uses, cryptic. I usually find the right combination by trial and error. In this case I want to print decimal numbers with both fixed number of integer digits and decimal digits. How can I do this with Boost.Format. #include<boost/format.hpp> #include<iostream> int main(){ int i = 2; std::cout << boost::format("%04i") % i << std::endl; //prints 0002, ok! double d = 3.1415; std::cout<< boost::format("%04.8f") % d << std::endl; // ^ prints 3.14150000, // want 0003.14150000 //(or even ' 3.14150000') //(or even ' 3.1415 ') return 0; } Thank you, Alfredo

3 3

Re: [Boost-users] [serialization] boost::serialization adds huge amounts of exports to resultant Windows PE file (Robert Ramey)
by Chris Yuen 30 Sep '10

30 Sep '10

Robert Ramey wrote: > Are you sure you're building in release mode? Yes of course. Is that expected to make a difference? Reading from `force_include.hpp`, even Release mode wouldn't escape from this (see below) I dug into the problem a little bit more. I replaced `force_include.hpp` with the following two lines and then actually recompiled boost::serialization #define BOOST_DLLEXPORT #define BOOST_USED The code bloat is gone (as shown by `dumpbin /exports`, yes, actually by 8MB), *and* the resulting program actually compiles and runs fine (sample program at: http://boost.codepad.org/f9LodmfD **). I tested again at MSVC2010 at both Release|x64 and Release|Win32. This seems to be a rather intrusive hack that seems to have become outdated with MSVC2010 (haven't tested with MSVC2005 and MSVC2008 yet. It's installed on another machine). Right now, `force_include.hpp` reads this: #if defined(BOOST_HAS_DECLSPEC) && !defined(__COMO__) // ... # define BOOST_DLLEXPORT __declspec(dllexport) This means we are unconditionally doing this explosive exports for all MS platforms. Even Release mode cannot optimize away these explicitly marked DLL exports. Should we at least have an option to turn off this very intrusive workaround? Right now my only option is to patch `force_include.hpp` manually. There might be some people that actually need the hack, but for some of us who's dug into it and actually confirmed it's not needed, it would be nice to be able to turn that off since the bloat introduced is definitely non-trivial. ** Of course I don't mean this particular sample program generates 8MB of export symbols. This is only to show what I mean by "it compiles and runs." The actual program that resulted from boost::serialization's 8MB bloat contained 100+ "exported" classes serialized through base pointers. The specs is quite close to what I showed in the sample program. ** That doesn't seem to play well with CodePad's boost. Oh well. Best regards, Chris Yuen

2 1