Juan Antonio Farré Basurte wrote:

...

Hello, I'm using boost libraries in my research work and I need to

...

libraries. I've been working with version 1.37.0 without any problem.

Now I updated to 1.38.0. I built the libraries in the same way and the same directories as 1.37.0

...

(on /usr/local). The compilation and dynamic linkage phase work, but when I run the program it complains with "file not found" on the shared

I've added /usr/local/lib to /etc/ld.so.conf and now it works. What I don't understand is why the linker didn't complain (the problem was when executing), and why it worked before with 1.37.0. Thanks a lot anyway, Juan link to graph and program options library files.

You need to always provide the exact error message. Also, what does ldd say? Did you recompile your

program?

- Volodya

_______________________________________________ Boost-users

mailing list

Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

...

I've added /usr/local/lib to /etc/ld.so.conf and now it works. What I don't understand is why the linker didn't complain (the problem was when executing),

That's actually the way dynamic linking works under UNIX: You tell the linker which libraries to link with, but aren't tied to this library location when you deploy the program (e.g. on a different computer). Hence you use

-L directive to tell gcc/ld where to look for libraries (shared or static), and have to edit ld.so.conf to tell

which looks through all referenced dynamic libraries for symbols when you start your executable) where to look for libraries when running executables.

Note, that you don't have to edit ld.so.conf: you could instead set the variable LD_LIBRARY_PATH to the library location (works like the PATH environment variable, so you can

Thanks a lot for all this detailed and useful information :) Regards, Juan the the dynamic linker (the program provide multiple paths

separated by colons). This way you can accomplish your task without super user privileges. Note, that the variable is called DYLD_LIBRARY_PATH on Mac OSX systems. _______________________________________________

Boost-users mailing list

Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

I'm working in a graph algorithm that works on graphs that implement BidirectionalGraphConcept and VertexAndEdgeListGraphConcept. The only additional requirement is that they must have some concrete bundled properties (I don't want to deal with the, I understand old, method of defining properties). For example, if g is a graph and v is a valid vertex descriptor of that graph,

This is a really good question because it deals with application-specific graph concepts. These aren't really addressed anywhere in the library. Since your algorithm is generic, you should be thinking about how to "generically" get the properties of the graph. You can do this by abstracting the property reference as a function call. Instead of, g[v].min, you should be writing: vertex_min(g). Or whatever 'min' actually means in this case. What you're doing is effectively defining application-specific semantics for a graph (that vertices have a min property). In order for a graph to model that property, you just have to provide an overload specific to your graph type. Andrew Sutton andrew.n.sutton@gmail.com

it should always be possible to use the expression g[v].min, but if I use the expression g[v] I don't know the type of the object it returns. If there isn't any way to find out that, I'll have no other option than choosing between your totally-generic solution or to be still more restrictive and impose using my default implementation of the bundled properties the graph must have.

I don't believe that there's a reliable way to access bundled property types. You can probably use the vertex_property_type and one metafunction or another to extract the bundled types, but I don't know the exact process for this. This only applies to graphs that actually define that type, though. Expecting a function isn't really "totally generic". It just hides the differences that are causing your problem. andrew.n.sutton@gmail.com

I need to use the topological_sort BGL algorithm. This algorithm needs either that the graph has an internal vertex index property or that you provide a property map for it. I'd like to perform conditional compilation, so that I only build and provide the vertex index property map when it's needed, and the internal index property of the graph when it has it. For example, for an adjacency_list with vecS for VertexList, the property already exists in the graph and I wouldn't like to provide a property map for it. But if I choose listS for VertexList, there isn't such internal property and I need to provide the property map. As I don't know what Graph implementation my template will be provided, I need to find a way to know at compile time if that graph has the internal index property or not. Is there any (documented?) way to do it? This is the concrete information I need right now, but, if possible, I'd like to know how to find out if the graph has any concrete internal property, and not only the index one.

I don't think that this is really documented anywhere... You might look at pending/property.hpp - there are number of metafunctions there that might be useful. Specifically, I think you'd be looking at property_value, which appears to extract a property from a property list. This may "return" no_property if the requested kind is not supported. Andrew Sutton andrew.n.sutton@gmail.com

...

I need to use the topological_sort BGL algorithm. This algorithm needs either that the graph has an internal

vertex index

...

property or that you provide a property map for it. I'd like to perform conditional compilation, so that I only build and provide the vertex index property map when it's needed, and the internal index property of the graph when it has it. For example, for an adjacency_list with vecS for VertexList, the property already exists in the graph and I wouldn't like to provide a property map for it. But if I choose listS for VertexList, there isn't such internal

...

and I need to provide the property map. As I don't know what Graph implementation my template will be

property provided,

...

I need to find a way to know at compile time if that graph has the internal index property or not. Is there any (documented?) way to do it? This is the concrete information I need right now, but, if possible,

I'd like to know how to find out if the graph has any concrete internal

...

property, and not only the index one.

I don't think that this is really documented anywhere... You might look at pending/property.hpp - there are number of

useful. Specifically, I think you'd be looking at property_value, which appears to extract a

metafunctions there that might be property from a property list. This may "return"

no_property if the requested kind is not supported.

What about runtime detection? Would get(property_tag,graph) compile correctly for an unexistant property? What would it return, then, at runtime if the property does not exist? a 0 pointer? Thanks, Juan

On Thu, 19 Mar 2009, Andrew Sutton wrote: (snip)

Unfortunately, I don't think such a function actually exists. However, if you can detect these at compile time, you can easily reflect that as a runtime query:

template bool has_property(Graph const& g) { return has_property_metafunc::value; }

It appears that the value_type of an undefined non-bundled property map is always boost::detail::error_property_not_found, so you can use the following metafunction to detect them: #include #include #include #include template struct graph_has_property: public boost::mpl::not_< boost::is_same< typename boost::property_traits< typename boost::property_map::type >::value_type, boost::detail::error_property_not_found > > {}; This always returns true when given a bundled property, however (it does work for testing for non-bundled properties in graphs that have bundled properties). I have not figured out how to test for bundled properties; there is a compile error when trying to get a particular value from a nonexistent member of a bundled property map. Is that a case that is important to you? There are several Boost graph algorithms that make a decision based on whether a property exists; look for the handling of the color map at the bottom of boost/graph/breadth_first_search.hpp for an example (look at the definition of boost::detail::bfs_dispatch). The code there is a more complicated version of the metafunction above, but can also handle an optionally user-specified color map. -- Jeremiah Willcock