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

From: Marty Fried (public.forums_at_[hidden])
Date: 2007-10-18 14:06:14

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.
>
>3) If you have a fix and are confident that it works, open a ticket on the 
>boost trac system, attaching a patch, preferably against the trunk version. 
>If you don't have a fix but are confident that it is an error, open a 
>ticket anyway. ;-)
>
>4) Which front-end does xlC use? EDG?

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.  If you insist, I can try to pull down the files; I
don't know offhand how to do this correctly, but I imagine I can figure out
a way to do it.

2.  My coworker came up with this minimal test case.  It has one level of
indirection rather than 2 like filesystem, because that's all that's
required to exhibit the problem.  Without the one level of indirection, MSVC
and GCC both also display the error.  As I mentioned in my original post,
this sample was fed into a web form on the Comeau site, which will check 
the code for compliancy with the standard.  It's the best we have available
for testing.  As I understand it, the mechanism is that the real function
remove_all() (not the template function) forces instantiation of the
template function remove_all(), which in turn forces the instantiation of
the template function remove_all_aux(), which in turn forces the
instantiation of basic_directory_iterator, before its definition later in
the file.

I think the test case is small enough to post in this message, so here it
is:
/********  Test case  ********/

template <typename T> class foo;

template <typename T>
inline void templatefunc()
{
   foo<int> f;
}

inline void func()
{
   templatefunc<int>();
}
 
template <typename T>
class foo
{
};

/********  Results from Comeau compiler  *********/

Comeau C/C++ 4.3.9 (Mar 27 2007 17:24:47) for ONLINE_EVALUATION_BETA1
Copyright 1988-2007 Comeau Computing.  All rights reserved.
MODE:strict errors C++ C++0x_extensions
 
"ComeauTest.c", line 6: error: incomplete type is not allowed
     foo<int> f;
              ^

"ComeauTest.c", line 6: warning: variable "f" was declared but never
referenced
     foo<int> f;
              ^

1 error detected in the compilation of "ComeauTest.c".

/********  End test case  ********/

3.  Our fix would most likely be to compile the filesystem library with less
strict compatibility checking.  I'm not envolved at all with the standards
process, so I can't really know for sure how confident I should be that this
is an error.  I've heard that Comeau C++ was used to find error in other
compilers, like gcpp, so that is the main reason I think it's an error.

4.  We use xlC_r, the reentrant version of xlC (xlc++).  I don't really know
what EDG is, but I'm pretty sure we don't use it.  FWIW, we currently have
version 8, but will try to get version 9, which was recently released.  But
I suspect that would only be more strict rather than less so.

Please let me know if you need more information.
-- 
Marty Fried  
Senior software engineer 
Aldon  http://www.aldon.com