Re: [Boost-users] [filesystem] Apparent non-compliant code in current operations.hpp, ...

From: Marty Fried (public.forums_at_[hidden])
Date: 2007-10-19 12:47:39

Back on Fri, 19 Oct 2007 11:37:11 +0200, in gmane.comp.lib.boost.user,Markus
Schöpflin <markus.schoepflin_at_[hidden]> wrote:

>Note for boost.devel readers: The original problem report can be found at 
>http://permalink.gmane.org/gmane.comp.lib.boost.user/31028.
>
>Currently I think the reported error is really a problem in boost code, if 
>the reproducer below is indeed correct. But I'm still puzzled why cxx in 
>strict ansi mode isn't complaining.
>
>Did anyone encounter this problem already?
>
>Note to original poster: See below for answers.
>
>Marty Fried wrote:
>> Back on Thu, 18 Oct 2007 09:53:36 +0200, in gmane.comp.lib.boost.user,Markus
>> Schöpflin <markus.schoepflin_at_[hidden]> wrote:
>> 
>>> Marty Fried wrote:
>>>
>>> [snip compilation problem with filesystem]
>>>
>>> 1) Could you try if it works with the trunk version? There have been a few 
>>> fixes in this area, but I don't know if those will help you.
>>>
>>> 2) Filesystem has passed the tests for 1.34.1 with cxx on Tru64 in strict 
>>> ansi mode, which is usually good at finding this kind of errors. So could 
>>> you please post the minimal test case you found, this allows me to check if 
>>> cxx should have found the problem, and if yes, why I didn't find it.
>>>
>> 
>> Thanks Markus,
>> 
>> 1.  I had looked over the trunk version, and compared it with the existing
>> 1.34.1 version.  I didn't see anything that looked like it was remotely 
>> related to this problem.  

>No worry, I just remembered that we have regression test runs for xlC on 
>the trunk. See 
>http://beta.boost.org/development/tests/trunk/developer/summary.html for 
>details on the state of xlC. Looks like xlC has its problems with boost code.

I seems to me that something strange is going on; I'm not able to even
compile the filesystem library without errors. It seems like the regression
tests succeeded with the compile and link, if I'm reading it correctly.
Could it be that the test is done with an older version of xlC, that may not
have checked for this condidtion?  We are using version 8; version 9
recently came out.

I want to go back to aix and try the exact command line listed for the vacpp
test output, to see what result I get.  I'll report back.

>Hmm, cxx has this to say:
>
>cxx: Error: foo.cxx, line 6: Cannot create variable "f" of incomplete type
>           "foo<int>".
>           detected during instantiation of
>                     "void templatefunc<T>() [with T=int]" at line 11
>    foo<int> f;
>------------^
>
>Now I'm left wondering why the tests on Tru64 don't show this error. Just 
>to be sure, do you get the error while compiling the filesystem lib itself 
>or while using the compiled filesystem lib?
>
>If you get the error during compilation of the library, are you sure that 
>above code is a valid reproducer for the original problem? (I'm not 
>implying that it isn't, I just want to make sure it is.)

I believe the test case is valid, but there is one difference that may
matter here...  the test case has one less level of indirection than the
actual code.  We didn't think it made a difference, and we wanted to
simplify as much as possible; the test showed that the error is caught by
xlC and Comeau, but not by gcc or msvc.  However, it could be that one more
level of indirection is needed to hide the error from Tru64, too.  In other
words, maybe Tru64 is better than gcc and MSVC at finding this test case
error, but not as good as xlC/Comeau with one more level of indirection to
mask it.  Would you like me to modify the test case?

I appreciate your looking into this - I was worried you might dismiss it as
a problem with an unsupported compiler - not that I think it really is that
simple. Assuming it's really an error, it will probably eventually become a
problem with a supported compiler.

Please let me know what I can do next to help out.
-- 
Marty Fried  
Senior software engineer 
Aldon  http://www.aldon.com