More Mac Compiler Woes - Boost 1.30.0 - Thread and type_traits
Hey guys, I am having some more problems getting Boost 1.30 to compile on the Mac. I am using CW Pro 8.3, compiling a TARGET_CARBON project. I am having trouble getting the MP implementation of threads to compile. It seems to be having trouble with function pointers where the syntax function<type> is used. I remember at one point it was mentioned that: function<type, type...> was deprecated and we were to use either the more universally supported: functionN<type,type...> or the cleaner: function<void myfuncSig()> instead if our compiler supported it. (Mine doesn't support that last one yet I don't think.) I am guessing that the oldest syntax was removed and no one has bothered to update the Mac carbon thread implementaton to compile again since then? That one seems pretty easy to fix - just update to a supported syntax? (I could do this, update to the functionN<type,type...> syntax since that is what my compiler supports. If someone wants me to make and submit the changes to them for inclusion I'd be happy to, if I knew who to send them to...) Or is there a better/easier workaround? Secondly, the Signals library is not compiling. It's actually not a Signals problem, I think it is a type_traits problem. I am getting a bunch of strange compile errors, in a boost::type_traits file called: is_base_and_derived.hpp It looks like there is a template near the top that is the first thing that fails. There is a define that goes into an alternate implementation for certain broken compilers. Perhaps CodeWarrior needs to be added to the list of compilers that compiles the "broken compiler" version of the stuff in this header? Thanks in advance for your help! -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------
Hey guys, [...] Secondly, the Signals library is not compiling. It's actually not a Signals problem, I think it is a type_traits problem.
I am getting a bunch of strange compile errors, in a boost::type_traits file called: is_base_and_derived.hpp
It looks like there is a template near the top that is the first thing
fails. There is a define that goes into an alternate implementation for certain broken compilers. Perhaps CodeWarrior needs to be added to the
"Bobby Thomale" <bobby-thomale@mail.inoveon.org> wrote in message news:BABC8F05.19621%bobby-thomale@mail.inoveon.org... that list
of compilers that compiles the "broken compiler" version of the stuff in this header?
We are seeing the same problem trying to use tokenizer.hpp with CodeWarrior on the Mac. Again, errors in is_base_and_derived.hpp on lines that use type_traits. Here's an example: ******** Error : ')' expected (included from: object_traits.hpp:25 compressed_pair.hpp:23 compressed_pair.hpp:20 iterator_adaptors.hpp:124 token_iterator.hpp:15 tokenizer.hpp:21 Book.h:5 Archive.h:4 Archive.cpp:1) is_base_and_derived.hpp line 113 static type_traits::yes_type check(D const volatile *, T); ******** People do seem to be using boost with CodeWarrior on the Mac so surely we just need to tweak the correct setting, right? Somebody? -- Stephen W. Carson DirXion Software St. Louis, MO
Somewhere you need to undefine the "check" macro from the Metrowerks/mac header file debugging.h. - Mat --On Monday, May 05, 2003 10:44 AM -0500 "Stephen W. Carson" <yg-boost-users@gmane.org> wrote:
Hey guys, [...] Secondly, the Signals library is not compiling. It's actually not a Signals problem, I think it is a type_traits problem.
I am getting a bunch of strange compile errors, in a boost::type_traits file called: is_base_and_derived.hpp
It looks like there is a template near the top that is the first thing
fails. There is a define that goes into an alternate implementation for certain broken compilers. Perhaps CodeWarrior needs to be added to the
"Bobby Thomale" <bobby-thomale@mail.inoveon.org> wrote in message news:BABC8F05.19621%bobby-thomale@mail.inoveon.org... that list
of compilers that compiles the "broken compiler" version of the stuff in this header?
We are seeing the same problem trying to use tokenizer.hpp with CodeWarrior on the Mac. Again, errors in is_base_and_derived.hpp on lines that use type_traits. Here's an example: ******** Error : ')' expected (included from: object_traits.hpp:25 compressed_pair.hpp:23 compressed_pair.hpp:20 iterator_adaptors.hpp:124 token_iterator.hpp:15 tokenizer.hpp:21 Book.h:5 Archive.h:4 Archive.cpp:1) is_base_and_derived.hpp line 113 static type_traits::yes_type check(D const volatile *, T); ********
People do seem to be using boost with CodeWarrior on the Mac so surely we just need to tweak the correct setting, right? Somebody? -- Stephen W. Carson DirXion Software St. Louis, MO
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
"Bobby Thomale" <bobby-thomale@mail.inoveon.org> wrote in message news:BABC8F05.19621%bobby-thomale@mail.inoveon.org...
Hey guys, [...] Secondly, the Signals library is not compiling. It's actually not a Signals problem, I think it is a type_traits problem.
I am getting a bunch of strange compile errors, in a boost::type_traits file called: is_base_and_derived.hpp
It looks like there is a template near the top that is the first
This problem stems from the fact that the Metrowerks/mac header debugging.h defines a macro named "check" which conflicts with the function named check defined in the boost headers. Somewhere (in a header wrapping debugging.h?) you need to undefine the "check" macro. - Mat --On Monday, May 05, 2003 10:44 AM -0500 "Stephen W. Carson" <yg- boost-users@gmane.org> wrote: thing
fails. There is a define that goes into an alternate implementation for certain broken compilers. Perhaps CodeWarrior needs to be added to the
that list
of compilers that compiles the "broken compiler" version of the stuff in this header?
We are seeing the same problem trying to use tokenizer.hpp with CodeWarrior on the Mac. Again, errors in is_base_and_derived.hpp on lines that use type_traits. Here's an example: ******** Error : ')' expected (included from: object_traits.hpp:25 compressed_pair.hpp:23 compressed_pair.hpp:20 iterator_adaptors.hpp:124 token_iterator.hpp:15 tokenizer.hpp:21 Book.h:5 Archive.h:4 Archive.cpp:1) is_base_and_derived.hpp line 113 static type_traits::yes_type check (D const volatile *, T); ********
People do seem to be using boost with CodeWarrior on the Mac so surely we just need to tweak the correct setting, right? Somebody? -- Stephen W. Carson DirXion Software St. Louis, MO
------------------------ Yahoo! Groups Sponsor -------------------- -~--> Get A Free Psychic Reading! Your Online Answer To Life's Important Questions. http://us.click.yahoo.com/cjB9SD/od7FAA/uetFAA/EbFolB/TM ------------------------------------------------------------------- --~->
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi- bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Friday 11 April 2003 04:25 pm, Bobby Thomale wrote:
I remember at one point it was mentioned that:
function<type, type...>
was deprecated and we were to use either the more universally supported:
functionN<type,type...>
or the cleaner:
function<void myfuncSig()>
instead if our compiler supported it.
(Mine doesn't support that last one yet I don't think.)
I am guessing that the oldest syntax was removed and no one has bothered to update the Mac carbon thread implementaton to compile again since then?
That one seems pretty easy to fix - just update to a supported syntax? (I could do this, update to the functionN<type,type...> syntax since that is what my compiler supports. If someone wants me to make and submit the changes to them for inclusion I'd be happy to, if I knew who to send them to...)
Or is there a better/easier workaround?
Sorry, I completely missed this message this first time around. For CodeWarrior you'll need to use the functionN<type, type...> syntax with Boost.Function. William Kempf is the author/maintainer of Boost.Threads and Mac Murrett contributed the Mac carbon implementation. If you would put together a patch using the appropriate functionN classes it would be appreciated, and I'm sure Bill Kempf would accept it.
Secondly, the Signals library is not compiling. It's actually not a Signals problem, I think it is a type_traits problem.
Odd. It sounds like a compiler problem, but our Win32 regression tests show Signals working properly with CodeWarrior 8.3. We don't have any regular regression testing for CodeWarrior on the Mac, unfortunately :( Doug
I remember at one point it was mentioned that:
function<type, type...>
was deprecated and we were to use either the more universally supported:
functionN<type,type...>
or the cleaner:
function<void myfuncSig()>
instead if our compiler supported it.
(Mine doesn't support that last one yet I don't think.)
I am guessing that the oldest syntax was removed and no one has bothered to update the Mac carbon thread implementaton to compile again since then?
That one seems pretty easy to fix - just update to a supported syntax? (I could do this, update to the functionN<type,type...> syntax since that is what my compiler supports. If someone wants me to make and submit the changes to them for inclusion I'd be happy to, if I knew who to send them to...)
Or is there a better/easier workaround?
Sorry, I completely missed this message this first time around. For CodeWarrior you'll need to use the functionN<type, type...> syntax with Boost.Function.
William Kempf is the author/maintainer of Boost.Threads and Mac Murrett contributed the Mac carbon implementation. If you would put together a patch using the appropriate functionN classes it would be appreciated, and I'm sure Bill Kempf would accept it.
Ok. I have already made the changes locally. Do you want me to just send them to Bill then?
Secondly, the Signals library is not compiling. It's actually not a Signals problem, I think it is a type_traits problem.
Odd. It sounds like a compiler problem, but our Win32 regression tests show Signals working properly with CodeWarrior 8.3. We don't have any regular regression testing for CodeWarrior on the Mac, unfortunately :(
Huh. It is definitely broken - someone else posted about it earlier today, too. Well, I wasn't sure what to do about it. My thought was that CodeWarrior should be using the same "broken compiler workaround" that the other compilers were using. I will send you the change I made. It makes it compile all right but I have no idea if it is the right thing or not... (I don't exactly understand the type-traits source. :-) Are you the right person to take a look at it and (possibly) add it to the Boost sources? -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------
On Monday 05 May 2003 02:08 pm, Bobby Thomale wrote:
William Kempf is the author/maintainer of Boost.Threads and Mac Murrett contributed the Mac carbon implementation. If you would put together a patch using the appropriate functionN classes it would be appreciated, and I'm sure Bill Kempf would accept it.
Ok. I have already made the changes locally. Do you want me to just send them to Bill then?
If you post it to the Boost developers list, (make sure "thread" is in the subject!), he'll see it.
Secondly, the Signals library is not compiling. It's actually not a Signals problem, I think it is a type_traits problem.
Odd. It sounds like a compiler problem, but our Win32 regression tests show Signals working properly with CodeWarrior 8.3. We don't have any regular regression testing for CodeWarrior on the Mac, unfortunately :(
Huh. It is definitely broken - someone else posted about it earlier today, too.
Well, I wasn't sure what to do about it. My thought was that CodeWarrior should be using the same "broken compiler workaround" that the other compilers were using.
Recent versions of CodeWarrior can handle it. I suggest trying the solution Mat Marcus proposed.
I will send you the change I made. It makes it compile all right but I have no idea if it is the right thing or not... (I don't exactly understand the type-traits source. :-)
Are you the right person to take a look at it and (possibly) add it to the Boost sources?
I can, but I'm not the best person for it. Doug
participants (2)
-
Bobby Thomale -
Douglas Gregor -
Mat Marcus -
mmarcus7
-
Stephen W. Carson