Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-10-19 15:00:55
On 10/19/2013 1:58 PM, Jeremiah Willcock wrote:
> On Sat, 19 Oct 2013, Edward Diener wrote:
>> On 10/19/2013 3:31 AM, Stephen Kelly wrote:
>>> On 10/19/2013 02:51 AM, Edward Diener wrote:
>>>> I realize this is more than just moving a file, but rather involves
>>>> moving the specializations of property map templates for the
>>>> distributed property map out of their places in property_map to some
>>>> place under graph. I also realize that this may be beyond what you
>>>> have tasked yourself to do,
>>> It could be better and doesn't seem like unreasonable effort. If we ever
>>> get that far, I'd look into that, yes.
>> I am working on this and will post a message about the results when I
>> am finished locally and have tested it.
> Please keep me posted on that as well (and it would have been nice to
> have a subject line specifically on Graph and PropertyMap issues). I
> suspect that the underlying communication layer used by the parallel
> graph and property map libraries can be pulled out; it is in the graph
> library right now, leading to the dependency. There also seem to be
> more general utilities (untracked_pair and unsafe_serialize, for
> example) that might belong in Boost.Serialization instead of the graph
> or property map libraries. Looking through the other graph headers used
> in distributed_property_map.hpp (which is the one with the most
> dependencies), they can either be moved to boost/property_map/parallel
> since they have no other dependencies themselves, or (in the case of
> hash<edge_desc_impl>) moved into the graph library. I am also willing
> to make those changes if you want.
I did notice that you were the person who created the
distributed_property_map.hpp, but I did not know what your e-mail
address was so I did not try to contact you about it.
My work has been to move distributed_property_map.hpp and .ipp into the
graph/parallel directory and add into that directory a
distributed_iterator_property_map.hpp and a
distributed_vector_property_map.hpp taken from the property map
specializations in property_map's property_map.hpp and
vector_property_map.hpp, while removing the specilizations code from the
latter two. Also the paths in graph tests would change to pickup these
new locations. All this would effectively remove any dependency on graph
from the property_map implementation.
I am not changing any code whatsoever, just moving things around, and
then I am going to run the property_map tests and graph tests to make
sure I have not broken anything.
I did not think to move any of the other files you mentioned into
property_map itself from the graph library, as I was only considering
the minimum way of achieving the separation.
I do think that if one is specializing some class template in library A
whose dependencies in the specialization code are in library B that the
way to do this is to put the specializations in library B since an
end-user of that particular specialization must "use" library B anyway
to have the specialization work properly. Likewise I don't think that
graph serialization code belongs in serialization but rather in graph.
Any help you can give or advice is clearly welcomed, but I think I can
get this done on my own without really having to understand, which of
course you do since you wrote it, the distributed_property_map code and
specializations based on it.
My goal is purely to have property_map be not dependent on graph since
it is its own concept. I have a use for property_map totally outside of
any use for graph in a library I am still developing, thus my own
willingness to do this work.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk