Hi Roland, [I'm sending this message both to the list and to you personally in case you don't read the list regularly]. I'm wondering what's the status of your "views" library, which is now in Boost sandbox? I'm rather interested to use it and see in in Boost, and I have some questions: 1. Do you plan to work on it anytime soon and push it to review? 2. It (specifically filter_iterator) does not work for me (see the attached compile log). Is there any change you'll fix the problems? Will it be OK if I fix the problems? 3. I would have expected that there is some common 'view' class which provides definitions for typedefs and functions like 'empty' and that individual views only define methods which really differ, like begin/end. Was this design ever considered. 4. Together with filter_view, I'd like to have 'filter' function, so that I can do something like: for_each( filter(vertices(g), boost::lambda::bind(out_degree_f, _1, g) == 0), .....); Is it possible add such functions? - Volodya
Vladimir Prus wrote:
I'm wondering what's the status of your "views" library, which is now in Boost sandbox?
I'm rather interested to use it and see in in Boost, and I have some questions:
1. Do you plan to work on it anytime soon and push it to review?
Given the current backlog of libraries to be reviewed, and my inexperience with Boost's review mechanism, I don't have such plans right now. On the other hand, every now and then I receive an email saying "I'd really like to see the views library in Boost". Well. What are you missing when using the current Sandbox code? Bug fixes? (see below) Documentation? (ahem) Some other view types? (sitting on my HD) Or ...?
2. It (specifically filter_iterator) does not work for me (see the attached compile log). Is there any change you'll fix the problems? Will it be OK if I fix the problems?
Should be fixed.
3. I would have expected that there is some common 'view' class which provides definitions for typedefs and functions like 'empty' and that individual views only define methods which really differ, like begin/end. Was this design ever considered.
Yes, I considered that solution. Take empty(), for instance: some views are empty if (and only if) their underlying container is. Others, such as filter_view, might be empty even if the underlying container is not empty. What should I do then, make empty() virtual (gasp)? After all, there is not much which views have in common, so I thought it was not worth the effort to extract a common base class.
4. Together with filter_view, I'd like to have 'filter' function, so that I can do something like:
for_each( filter(vertices(g), boost::lambda::bind(out_degree_f, _1, g) == 0), .....);
Is it possible add such functions?
I guess you're using for_each from sequence_algo? I tried to call for_each with a filter_view as first argument. MSVC 7.0, as helpful as ever, told me that Compiling... filter_for_each_example.cpp d:\boost-sandbox\boost\sequence_algo\container_traits.hpp(507) : fatal error C1507: previous user errors and subsequent error recovery halt further compilation Build Time 0:03 Wow. I'm afraid I don't have the time to fix that. - Roland
Hi Roland,
I'm wondering what's the status of your "views" library, which is now in Boost sandbox?
I'm rather interested to use it and see in in Boost, and I have some questions:
1. Do you plan to work on it anytime soon and push it to review?
Given the current backlog of libraries to be reviewed, and my inexperience with Boost's review mechanism, I don't have such plans right now. On the other hand, every now and then I receive an email saying "I'd really like to see the views library in Boost". Well.
Hopefully you'll find some time ;-)
What are you missing when using the current Sandbox code?
Mostly, library is sandbox which is not yet submitted is perceived as "unfinished", so I was wondering what's exactly is unfinished. Of course, there are other issues: like using the library from another Boost libraries and after all, Boost is more easily available than sandbox, so using a library in Boost is more convenient.
2. It (specifically filter_iterator) does not work for me (see the attached compile log). Is there any change you'll fix the problems? Will it be OK if I fix the problems?
Should be fixed.
After your second commit I can compile the test just fine. Thanks!
3. I would have expected that there is some common 'view' class which provides definitions for typedefs and functions like 'empty' and that individual views only define methods which really differ, like begin/end. Was this design ever considered.
Yes, I considered that solution.
Take empty(), for instance: some views are empty if (and only if) their underlying container is. Others, such as filter_view, might be empty even if the underlying container is not empty. What should I do then, make empty() virtual (gasp)?
After all, there is not much which views have in common, so I thought it was not worth the effort to extract a common base class.
Ok, agrument understood.
4. Together with filter_view, I'd like to have 'filter' function, so that I can do something like:
for_each( filter(vertices(g), boost::lambda::bind(out_degree_f, _1, g) == 0), .....);
Is it possible add such functions?
I guess you're using for_each from sequence_algo?
Right.
d:\boost-sandbox\boost\sequence_algo\container_traits.hpp(507) : fatal error C1507: previous user errors and subsequent error recovery halt further compilation
Wow. I'm afraid I don't have the time to fix that.
I guess gcc won't crash in this way ;-) What do you think about such functions in general. I might have the time to play with the idea. BTW, please find a trivial patch to add some missing typenames. Could it be applied? - Volodya
4. Together with filter_view, I'd like to have 'filter' function, so that I can do something like:
for_each( filter(vertices(g), boost::lambda::bind(out_degree_f, _1, g) == 0), .....);
Is it possible add such functions?
I guess you're using for_each from sequence_algo?
Right.
d:\boost-sandbox\boost\sequence_algo\container_traits.hpp(507) : fatal error C1507: previous user errors and subsequent error recovery halt further compilation
Wow. I'm afraid I don't have the time to fix that.
I guess gcc won't crash in this way ;-) What do you think about such functions in general. I might have the time to play with the idea.
It sure would be worthwhile to play with this idea. In your example above, filter() means something like make_filter_view() (I'd prefer the later, longer name), and such make_... functions should be provided for each view type.
BTW, please find a trivial patch to add some missing typenames. Could it be applied?
Applied. Please feel free to commit similar trivial patches whenever needed. - Roland
Vladimir Prus wrote:
4. Together with filter_view, I'd like to have 'filter' function, so that I can do something like:
for_each( filter(vertices(g), boost::lambda::bind(out_degree_f, _1, g) == 0), .....);
Just out of curiosity: Why don't you use a transform_view instead of for_each()? Of course I don't know the details here (i.e. which function is meant by "....."), but wouldn't it be possible here to say filter_view<Vertices, ...> filtered( vertices(g), bind(...) == 0 ); transform_view< filter_view<.,.>, ... > result( filtered, some_function() ); - Roland
Roland Richter wrote:
4. Together with filter_view, I'd like to have 'filter' function, so that I can do something like:
for_each( filter(vertices(g), boost::lambda::bind(out_degree_f, _1, g) == 0), .....);
Just out of curiosity:
Why don't you use a transform_view instead of for_each()?
Well, I need to invoke a function on each element of filtered sequence, not transform it further.
Of course I don't know the details here (i.e. which function is meant by "....."),
It's going to be boost::lambda::bind(add_edge_f, _1, sink, g)
but wouldn't it be possible here to say
filter_view<Vertices, ...> filtered( vertices(g), bind(...) == 0 ); transform_view< filter_view<.,.>, ... > result( filtered, some_function() );
Do I have to iterate over 'result' to really invoke the function? - Volodya
Vladimir Prus wrote:
filter_view<Vertices, ...> filtered( vertices(g), bind(...) == 0 ); transform_view< filter_view<.,.>, ... > result( filtered, some_function() );
Yes, you are right. At some point you have to call a for_each()-like function, so it's a matter of taste (and performance, probably) when to do it. - Roland
participants (2)
-
Roland Richter -
Vladimir Prus