[fusion] Getting rid of the incomplete type error for vector
Hello, a number of platforms fail when fusion vectors are used with an error message like this: cxx: Error: ../boost/fusion/sequence/conversion/detail/as_vector.hpp, line 41: incomplete type is not allowed (incompletetyp) return vector<>(); -------------------^ Removing the inclusion of boost/.../detail/as_vector.hpp in the header file boost/.../vector/vector.hpp (line 12) solves the issue for me. Could the fusion author please indicate if this is the right fix, and if yes, could this fix please be committed ASAP? TIA, Markus
Markus Schöpflin wrote:
Hello,
a number of platforms fail when fusion vectors are used with an error message like this:
cxx: Error: ../boost/fusion/sequence/conversion/detail/as_vector.hpp, line 41: incomplete type is not allowed (incompletetyp) return vector<>(); -------------------^
Removing the inclusion of boost/.../detail/as_vector.hpp in the header file boost/.../vector/vector.hpp (line 12) solves the issue for me. Could the fusion author please indicate if this is the right fix, and if yes, could this fix please be committed ASAP?
Confirmed and committed. Jeez! Me smack in the head!!! I did lots of dependency analysis only to learn (from you) that that file is not needed there. IIRC, it was needed at one point in the development, but not anymore. Anyway, I uncovered lots of cyclic dependencies along the way and got rid of them, so I'd say my effort was not in vain. :P Thanks for pointing it out! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote: [...]
Confirmed and committed. Jeez! Me smack in the head!!! I did lots of dependency analysis only to learn (from you) that that file is not needed there. IIRC, it was needed at one point in the development, but not anymore.
Well, I used a more pragmatic approach: cxx -E ... as_vector.cpp | grep -w vector | less
Anyway, I uncovered lots of cyclic dependencies along the way and got rid of them, so I'd say my effort was not in vain. :P
Which is a good thing.
Thanks for pointing it out!
You're welcome. This will hopefully clear a great many errors seen on Tru64/CXX, whenever the tests have cycled. Markus
Markus Schöpflin wrote:
Joel de Guzman wrote:
[...]
Confirmed and committed. Jeez! Me smack in the head!!! I did lots of dependency analysis only to learn (from you) that that file is not needed there. IIRC, it was needed at one point in the development, but not anymore.
Well, I used a more pragmatic approach: cxx -E ... as_vector.cpp | grep -w vector | less
Well, that's my problem. I do not have access to the compiler. Otherwise, I would've found it already. So, I based my hunt on pure intuition. The compilers that I use regularly does not exhibit the problem.
Anyway, I uncovered lots of cyclic dependencies along the way and got rid of them, so I'd say my effort was not in vain. :P
Which is a good thing.
Thanks for pointing it out!
You're welcome. This will hopefully clear a great many errors seen on Tru64/CXX, whenever the tests have cycled.
Yeah. many thanks! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman schrieb:
Markus Schöpflin wrote:
Joel de Guzman wrote:
[...]
Confirmed and committed. Jeez! Me smack in the head!!! I did lots of dependency analysis only to learn (from you) that that file is not needed there. IIRC, it was needed at one point in the development, but not anymore. Well, I used a more pragmatic approach: cxx -E ... as_vector.cpp | grep -w vector | less
Well, that's my problem. I do not have access to the compiler. Otherwise, I would've found it already. So, I based my hunt on pure intuition. The compilers that I use regularly does not exhibit the problem.
Uh, I didn't mean to imply any criticism with that. Sorry if I did. I'm wondering if g++ cannot be configured to check for this kind of errors? Anyone knows? Markus
Markus Schoepflin wrote:
I'm wondering if g++ cannot be configured to check for this kind of errors? Anyone knows?
If the Standard requires diagnostics for this error (which is something I'm not sure about), then compiling '-pedantic -ansi' should cause g++ to emit a diagnostics. From g++ man page: Some users try to use -pedantic to check programs for strict ISO C conformance. They soon find that it does not do quite what they want: it finds some non-ISO practices, but not all---only those for which ISO C requires a diagnostic, and some others for which diagnostics have been added. A feature to report any failure to conform to ISO C might be useful in some instances, but would require considerable additional work and would be quite different from -pedantic. We don't have plans to support such a feature in the near future. For the program below, in strict ansi mode, EDG Front End issues an error: "incomplete type is not allowed" (and, accordingly, cxx and aC++ issue this error also). g++ 4.2.1 does not issue any diagnostics, even when compiling '-pedantic -ansi'. Again, I'm not sure if a diagnostics is required in this case. template <typename T> struct apply { typedef T type; }; template <typename T = void> struct vector; template <typename Iterator> static typename apply<Iterator>::type call(Iterator) { return vector<>(); } Boris ----- Original Message ----- From: "Markus Schöpflin" <markus.schoepflin@web.de> To: <boost@lists.boost.org> Sent: Tuesday, October 23, 2007 12:49 PM Subject: Re: [boost] [fusion] Getting rid of the incomplete type error forvector Joel de Guzman schrieb:
Markus Schöpflin wrote:
Joel de Guzman wrote:
[...]
Confirmed and committed. Jeez! Me smack in the head!!! I did lots of dependency analysis only to learn (from you) that that file is not needed there. IIRC, it was needed at one point in the development, but not anymore. Well, I used a more pragmatic approach: cxx -E ... as_vector.cpp | grep -w vector | less
Well, that's my problem. I do not have access to the compiler. Otherwise, I would've found it already. So, I based my hunt on pure intuition. The compilers that I use regularly does not exhibit the problem.
Uh, I didn't mean to imply any criticism with that. Sorry if I did. I'm wondering if g++ cannot be configured to check for this kind of errors? Anyone knows? Markus _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
For the program below, in strict ansi mode, EDG Front End issues an error: "incomplete type is not allowed" (and, accordingly, cxx and aC++ issue this error also). g++ 4.2.1 does not issue any diagnostics, even when compiling '-pedantic -ansi'. Again, I'm not sure if a diagnostics is required in this case.
template <typename T> struct apply { typedef T type; };
template <typename T = void> struct vector;
template <typename Iterator> static typename apply<Iterator>::type call(Iterator) { return vector<>(); }
See 14.6/5:
No diagnostic shall be issued for a tem- plate definition for which a valid specialization can be generated. If no valid specialization can be generated for a template definition, and that template is not instantiated, it is unspecified whether or not an implementation is required to issue a diagnostic. The implementation is allowed to defer issuing a diagnostic until the function is instantiated.
Sebastian Redl
Sebastian Redl wrote:
Boris Gubenko wrote:
Again, I'm not sure if a diagnostics is required in this case. See 14.6/5: [...] The implementation is allowed to defer issuing a diagnostic until the function is instantiated.
This is what I suspected, but did not check. Thanks for the reference! Boris ----- Original Message ----- From: "Sebastian Redl" <sebastian.redl@getdesigned.at> To: <boost@lists.boost.org> Sent: Tuesday, October 23, 2007 4:16 PM Subject: Re: [boost] [fusion] Getting rid of the incomplete typeerror forvector
Boris Gubenko wrote:
For the program below, in strict ansi mode, EDG Front End issues an error: "incomplete type is not allowed" (and, accordingly, cxx and aC++ issue this error also). g++ 4.2.1 does not issue any diagnostics, even when compiling '-pedantic -ansi'. Again, I'm not sure if a diagnostics is required in this case.
template <typename T> struct apply { typedef T type; };
template <typename T = void> struct vector;
template <typename Iterator> static typename apply<Iterator>::type call(Iterator) { return vector<>(); }
See 14.6/5:
No diagnostic shall be issued for a tem- plate definition for which a valid specialization can be generated. If no valid specialization can be generated for a template definition, and that template is not instantiated, it is unspecified whether or not an implementation is required to issue a diagnostic. The implementation is allowed to defer issuing a diagnostic until the function is instantiated.
Sebastian Redl _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Markus Schöpflin wrote:
Joel de Guzman schrieb:
Joel de Guzman wrote:
[...]
Confirmed and committed. Jeez! Me smack in the head!!! I did lots of dependency analysis only to learn (from you) that that file is not needed there. IIRC, it was needed at one point in the development, but not anymore. Well, I used a more pragmatic approach: cxx -E ... as_vector.cpp | grep -w vector | less Well, that's my problem. I do not have access to the compiler. Otherwise, I would've found it already. So, I based my hunt on
Markus Schöpflin wrote: pure intuition. The compilers that I use regularly does not exhibit the problem.
Uh, I didn't mean to imply any criticism with that. Sorry if I did.
Hey, no need to apologize, not at all :-) Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (5)
-
Boris Gubenko -
Joel de Guzman -
Markus Schöpflin -
Markus Schöpflin -
Sebastian Redl