Ronald Garcia wrote:

Listed under showstoppers is ticket 4874 for multi_array. To address this tag I need a language lawyer, and I am not one.

The issue is that VC 2010 under debug mode fails to compile multi_array because it's copy() function checks iterator tags. multi_array iterators have had input_iterator_tag but not output_iterator tag.

I'm not a language lawyer either (far from it) and I have never used multi_array. I did however read all of the SGI STL manual, so perhaps I can still help.

The outstanding question I have is whether it is necessary or even legal for an iterator to have an iterator_category that is somehow both input_iterator_tag AND output_iterator tag simultaneously.

First I say *legal* because in my copy of a standard draft, (24.3.3) says: For every iterator of type Iterator, iterator_traits<Iterator>::iterator_category shall be defined to be the most specific category tag that describes the iterator’s behavior.

Your iterator models Input Iterator. Since it's used to iterate over a container, I assume that the same iterator can be used to pass over its range multiple times. That would mean it's also a Forward Iterator. According to the manual, Forward Iterator is a refinement of both Input Iterator and Output Iterator: http://www.sgi.com/tech/stl/ForwardIterator.html So it looks like the most specific tag for your iterator class is at least forward_iterator_tag.

I'm unclear on whether that can be any tag other than the specific ones listed. In particular, can I inherit two tags to merge them.

You probably could, but I don't think it would be a good idea in this case. For one, there already appears to be a unique most specific iterator tag for your iterator class which sort-of incorporates output_iterator. More importantly, if you explicitly use output_iterator as a category, you'll remove the possibility for your iterator class to be a const iterator...

Second, I say *necessary* because while input_iterator_tag, forward_iterator_tag, bidirectional_iterator_tag, and random_access_iterator_tag form an inheritance chain, none of them inherit from output_iterator_tag. Furthermore, const_iterators like "const int *" are not OutputIterators but seem to still be RandomAccessIterators. So in this case I'm not sure when (if ever) it is necessary to have an iterator category that is convertible to output_iterator_tag. In fact, the Boost.Concept library doesn't ever even look at the iterator_category when checking OutputIterator concept. All uses of output_iterator_tag I can find in the standard are things like back_inserter and front_inserter,

... as you explained here! A mutable Forward Iterator is also an Output Iterator, but a const Forward Iterator is not. So the only correct application for output_iterator_tag is in iterator classes whose primary purpose is to store values, such as back_insert_iterator and ostream_iterator. For those classes it simply wouldn't make sense to be a const iterator.

things that are not "really" iterators, so to speak.

By a "real" iterator you probably mean an iterator which can pass over its range multiple times. This again reveals that you're probably at least talking about a Forward Iterator. Rule of thumb: Sequence containers are always at least Forward Iterable. Rule of thumb: if you feel tempted to use both input_iterator_tag and output_iterator_tag, you should probably use forward_iterator_tag instead. My advice: use forward_iterator_tag and see whether that works better with MSVC. HTH, Julian

On 1/17/2012 7:07 AM, Vicente Botet wrote:

Marshall Clow-2 wrote

...

There are a couple of useful reports on svn.boost.org:

Active Showstoppers: https://svn.boost.org/trac/boost/report/43 Active Regressions: https://svn.boost.org/trac/boost/report/30

IMHO, these bugs should be at least looked at before each release.

Hi,

Concerning the Boost.Thread showstoppers,

#4521 Error using boost::move on packaged_task (MSVC 10) #4885 Access violation in set_tss_data at process exit due to invalid assumption about TlsAlloc #6174 packaged_task doesn't correctly handle moving results #6194 Adapt to Boost.Move #6222 Compile error with SunStudio: unique_future move

Yesterday I made a commit in trunk that should take care of all of them (I don't think #6222 will behave as expected after the Boost.Move adaptation, as SunStudio doesn't support well Boost.Move) except #4885.

This commit contains much more that the fix for these Showstoppers. My idea was to merge the whole to release for 1.50. Should I merge the trunk once the tester results are good enough or should I merge only the code related to these Showstoppers?

I don't think that I could have time to take care of #4885 or #6222. Anthony?

You do realize the deadline for merging changes to release was yesterday? Rene. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On Tue, Jan 17, 2012 at 8:30 AM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:

Rene Rivera-2 wrote

...

On 1/17/2012 7:07 AM, Vicente Botet wrote:

...

Marshall Clow-2 wrote

...

There are a couple of useful reports on svn.boost.org:

Active Showstoppers: https://svn.boost.org/trac/boost/report/43 Active Regressions: https://svn.boost.org/trac/boost/report/30

IMHO, these bugs should be at least looked at before each release.

Hi,

Concerning the Boost.Thread showstoppers,

#4521 Error using boost::move on packaged_task (MSVC 10) #4885 Access violation in set_tss_data at process exit due to

invalid

...

...

assumption about TlsAlloc #6174 packaged_task doesn't correctly handle moving results #6194 Adapt to Boost.Move #6222 Compile error with SunStudio: unique_future move

Yesterday I made a commit in trunk that should take care of all of them (I don't think #6222 will behave as expected after the Boost.Move adaptation, as SunStudio doesn't support well Boost.Move) except #4885.

This commit contains much more that the fix for these Showstoppers. My idea was to merge the whole to release for 1.50. Should I merge the trunk once the tester results are good enough or should I merge only the code related to these Showstoppers?

I don't think that I could have time to take care of #4885 or #6222. Anthony?

You do realize the deadline for merging changes to release was yesterday?

Yes, this is why I've planned to merge them on 1.50:)

D'oh. I didn't read you email carefully enough :-\

If we consider that them are Showstoppers we should do something else. Note that these Showstoppers were already for 1.48, ...

Well, they could be relabeled to not showstoppers. Especially if it's a problem for a "not release tested" platform. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Dear Gennadiy, thanks for your response. This is the first response at all that I get on ticket #6331. On Tue, 17 Jan 2012 22:00:37 +0000, Gennadiy Rozental wrote:

Torsten Maehne <Torsten.Maehne <at> gmx.de> writes:

...

Hello,

concerning regressions in Boost.Test, ticket #6331 "g++ compilation error due to ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if

1. I am yet to see why this is boost.test fault and not compiler bug.

Even though, I stumpled on this bug while preparing the test case for ticket #6126, it was Jeroen Habraken <vexocide@gmail.com>, who tracked it down to recent changes in Boost.Test. Did you look at the test case. --------------------------------------------------------------- #define BOOST_TEST_MODULE test_boost_test_decorator_enable_if #include <boost/test/included/unit_test.hpp> #include <boost/typeof/native.hpp> BOOST_AUTO_TEST_CASE(test_dummy) { // do nothing } --------------------------------------------------------------- It just includes two Boost headers and then fails to compile. This enough to make g++ 4.2.1, 4.5.3, and 4.6.2 fail to compile the test case. (clang+ + 3.0 compiles just fine the test case). I'm not familiar enough with all the magic going on behind the scenes in Boost.Test to judge if it not changes the visibility of certain symbols in certain namespaces, e.g., by "using" statements. At least, just including into a test case: --------------------------------------------------------------- #include <boost/test/tree/decorator.hpp> #include <boost/typeof/native.hpp> int main(int argc, char* argv[]) { return 0; } --------------------------------------------------------------- won't cause a compiler error. I don't know what triggers the compiler to look-up enable_if<Cond, T> in the other test case. I don't know either why the compiler sees the definition of boost::unit_test::decorator::enable_if in namespace boost::type_of. I don't know how to further analyse the issue. It's a bit frustrating to see that new tickets in the Boost Trac system seem to receive so few attention compared to other open-source project I have contributed, too. It's good to see that the Boost mailing lists are so much more responsive. :-) It might well be a compiler bug, but seeing how long it takes that new compiler versions are widely deployed even on common platforms such as Windows, Linux, or Mac OS X -- especially in production environments, such issues should be fixed also in the Boost library.

2. I think qualifying symbols from boost namespace is right thing to do in any case

Well, I agree, but what is a user of the Boost libraries able to do about it? Using enable_if and co. without a qualifying namespace is widespread in the Boost sources: A grep on the Boost headers and some filtering shows that enable_if without a qualifying namespace identifier is used approx. 1000 times all over the Boost library. Qualifying all occurences of enable_if and co. will need a quite huge and well coordinated effort to be fixed by the different library authors. I am aware that also other Boost libraries have their own enable_if variants. However, all seem to be templates except for the boost::unit_test::decorator::enable_if. Maybe therefore no problems were yet observed in combination with typename statements. At least that is how far I understand the issue.

3. This code is not part of the release.

This is good to hear. Boost.Test is very useful for me and I use it in conjunction with other Boost libraries regularly. Having it broken in a an official Boost release would cause me quite some headache as suddenly my unit tests for my own code would stop compiling for reasons I cannot influence.

Gennadiy

Best regards, Torsten Maehne

Dear Gennadiy, On Wed, 18 Jan 2012 17:07:19 +0000, Gennadiy Rozental wrote:

Torsten Maehne <Torsten.Maehne <at> gmx.de> writes:

...

Dear Gennadiy,

thanks for your response. This is the first response at all that I get on ticket #6331.

I've been closely tracking the progress on this ticket and related conversations.

...

I don't know either why the compiler sees the definition of boost::unit_test::decorator::enable_if in namespace boost::type_of.

I've been somewhat destructed around new year. Let me see if I can figure this out. Frankly I am at loss why would we see this conflict. Symbols are in completely different namespaces.

Thank you, it is good to know that you followed the development around the ticket even though there wasn't any feedback in the trac indicating it. It's true that I submitted the issue at a time of year, where people often have more personal priorities. I can fully understand it. After all, most of us contribute to open source projects in their free time. :-) It would be great if you could figure out what goes wrong there. After all, g++ is a very common compiler and even its latest versions seem to be affected. While digging into the issue, I came across the CHANGES document for g++ 4.7.0 currently under development. It states "G++ now correctly implements the two-phase lookup rules such that an unqualified name used in a template must have an appropriate declaration found either in scope at the point of definition of the template or by argument-dependent lookup at the point of instantiation. As a result, code that relies on a second unqualified lookup at the point of instantiation to find functions declared after the template or in dependent bases will be rejected. The compiler will suggest ways to fix affected code, and using the -fpermissive compiler flag will allow the code to compile with a warning." <http://gcc.gnu.org/gcc-4.7/changes.html> Could our problem be related? I also found a meta-bug in gcc's bug tracker grouping currently known problems around the name-lookup: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18805> I did not yet found the time to read in detail the referred bugs to see whether there's a known issue resembling the problem at hand.

Gennadiy

Best regards, Torsten

Dear Gennadiy, On Sat, 21 Jan 2012 04:54:34 +0000, Gennadiy Rozental wrote:

Torsten Maehne <Torsten.Maehne <at> gmx.de> writes:

...

It would be great if you could figure out what goes wrong there. After all, g++ is a very common compiler and even its latest versions seem to be affected.

I figured it out I think. I checked in a fix. The problem was in some other completely unrelated place.

Thanks for localising the problem, unfortunately, your fix was incomplete to make the test case compile on my platform. However, after looking at your patch, I knew for what I had to watch out and I found a second ipp file (boost/test/impl/logged_expectations.ipp), which contained a misplaced using namespace. Please, confer to the reopened ticket #6331 for details: https://svn.boost.org/trac/boost/ticket/6331

Gennadiy

Thanks for your help! Regards, Torsten