Digital Mars - c++ - DMC++ & Boost

↑ ↓ ← → "Jonathan Turkanis" <technews kangaroologic.com> writes:

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bu2bdl$21ea$1 digitaldaemon.com...
 Anyone got a working set of Boost files for DMC++?

 I want to include DMC++ in a perf test.


I've been working a little with Dan Watkins (aka Dan W.) on the
project begun by Christof Meerwald of getting a version of boost to
work on DMC. The current boost CVS contains a config file for DMC, and
some DMC-specific changes made to MPL (and possibly type traits). Dan
can give you a diff for boost-1.30.2 which contains essentially the
same stuff, plus a little more.

My impression is that many of the core libraries should work;
unfortunately, all my non-trivial boost code relies heavily on MPL,
which still does not compile fully, so I can't say for sure.

So far all I have done personally is run the regression tests in the
boost config library to determine the defect macros that need to be
defined. When I get a chance I'm going to start running the regular
boost regression tests to see how much compiles.

Jonathan

Jan 13 2004

↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:

I've missed my deadline for using it, but am still interested in whether the
DMC++ support will be rolled into the main Boost distribution at its next
release. Do you know whether it will or not, or is it yet to be decided?

"Jonathan Turkanis" <technews kangaroologic.com> wrote in message
news:bu2fb1$284l$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bu2bdl$21ea$1 digitaldaemon.com...
 Anyone got a working set of Boost files for DMC++?

 I want to include DMC++ in a perf test.


 I've been working a little with Dan Watkins (aka Dan W.) on the
 project begun by Christof Meerwald of getting a version of boost to
 work on DMC. The current boost CVS contains a config file for DMC, and
 some DMC-specific changes made to MPL (and possibly type traits). Dan
 can give you a diff for boost-1.30.2 which contains essentially the
 same stuff, plus a little more.

 My impression is that many of the core libraries should work;
 unfortunately, all my non-trivial boost code relies heavily on MPL,
 which still does not compile fully, so I can't say for sure.

 So far all I have done personally is run the regression tests in the
 boost config library to determine the defect macros that need to be
 defined. When I get a chance I'm going to start running the regular
 boost regression tests to see how much compiles.

 Jonathan

Jan 21 2004

↑ ↓ ← → dan <dan_member pathlink.com> writes:

In article <bulh04$310g$2 digitaldaemon.com>, Matthew says...
I've missed my deadline for using it, but am still interested in whether the
DMC++ support will be rolled into the main Boost distribution at its next
release. Do you know whether it will or not, or is it yet to be decided?


The current diff has been incorporated into the upcoming release version of
boost, 1.31, as well as the main trunk, by Aleksey Gurtovoy, two nights ago.
This does not imply, however, official compatibility, since there are many
unresolved issues;  but it's a first official attempt.  Currently, most of the
regression tests fail with DMC due mostly to preprocessing problems, I believe.

MPL's Finite State Machine compiles and works, which is what part of boost I
needed most urgently, personally.  But not all MPL features pass, and I have no
idea what the status is for other libraries.  Jonathan is still working on it.

Jan 21 2004

↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:

"dan" <dan_member pathlink.com> wrote in message
news:bumaf3$16p8$1 digitaldaemon.com...
 In article <bulh04$310g$2 digitaldaemon.com>, Matthew says...
I've missed my deadline for using it, but am still interested in whether




DMC++ support will be rolled into the main Boost distribution at its next
release. Do you know whether it will or not, or is it yet to be decided?


 The current diff has been incorporated into the upcoming release version


 boost, 1.31, as well as the main trunk, by Aleksey Gurtovoy, two nights


 This does not imply, however, official compatibility, since there are many
 unresolved issues;  but it's a first official attempt.  Currently, most of


 regression tests fail with DMC due mostly to preprocessing problems, I


 MPL's Finite State Machine compiles and works, which is what part of boost


 needed most urgently, personally.  But not all MPL features pass, and I


 idea what the status is for other libraries.  Jonathan is still working on



Thanks for the update.

May I ask whether you know when 1.31 is likely to be released? I'm hoping to
include it on the CD for my book, which must be readied in by mid-March.

Cheers

Matthew

Jan 21 2004

↑ ↓ ← → "Jonathan Turkanis" <technews kangaroologic.com> writes:

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bun3nj$2ffm$1 digitaldaemon.com...


 Thanks for the update.

 May I ask whether you know when 1.31 is likely to be released? I'm


 include it on the CD for my book, which must be readied in by




Sorry to take so long to reply. I just looked at the CVS for the
updcoming 1.31 release. The MPL changes which Dan mailed to Aleksy
Gurtovoy have been committed, but Christof Meerwald's fixes have not.
This is as I suspected.

I wish to post an announcement soon to the boost developers list that
I will be willing to coordinate the effort to add support for Digital
Mars. This will probably involve discussions with library authors on a
library-by-library basis. I know that some library author's are
reluctant to make even the most trivial changes.

Unfortunately this means that some of the boost libraries which work
with Dan's diff for 1.30.2 may not work with 1.31.

Jonathan

Jan 21 2004

↑ ↓ ← → dan <dan_member pathlink.com> writes:

In article <bun857$2mfs$1 digitaldaemon.com>, Jonathan Turkanis says...
Sorry to take so long to reply. I just looked at the CVS for the
updcoming 1.31 release. The MPL changes which Dan mailed to Aleksy
Gurtovoy have been committed, but Christof Meerwald's fixes have not.
This is as I suspected.

Jonathan


I hope you're wrong, Jonathan. The two or three versions of the diffs that I
gave to Aleksey, all contained Christoff's original changes.  I just emailed you
and Aleksey to try and clarify this matter.

Jan 21 2004

↑ ↓ ← → dan <dan_member pathlink.com> writes:

False alarm!  Only some of Merewald's changes are not incorporated in boost
version 1.31, for various reasons. I re-post Aleksey Gurtovoy's reply to my
email in its entirety below...


******************************************************
Hi Dan,

Sorry, this is totally my fault -- I should have been more clear about 
which fixes got incorporated and why. There've been a number of diffs that 
I didn't check in because they fall into one of the three categories:

1) unneeded -- the code already compiles as is; for example, fixes in 
"boost/any.hpp" and "boost/detail/ob_compressed_pair.hpp" headers fall 
into this category;

2) obsolete -- fixes that became obsolete because of the changes in the 
corresponding code;

3) untestable -- fixes that seemed relevant but which I couldn't test 
because the code was still failing to compile due to other errors -- 
in most cases preprocessor-related; for instance, 'function' and 
'signal' libraries fall into this category.

IOW, all Merewald's (and some of mine) fixes that are still relevant and
would clearly make Boost more DM-friendly are there; other ones are not,
since they are not immediately helpful and cannot be tested. Again, 
sorry for any miscommunication on my part.

--
Aleksey Gurtovoy
MetaCommunications Engineering 
******************************************************


To Walter:  I forgot to mention one issue which I tried to deal with in boost
via a workaround, but which was not accepted, as it is really not in the purview
of boost, namely an assert() macro workaround...

#ifdef __DMC__
#  ifdef assert
#    undef assert
#  endif
#  ifdef _DEBUG
#    define assert(x) do{if(!((x)))asm int 3;}while(0)
#  else
#    define assert(x) do{(void)(0);}while(0)
#  endif
#endif

Specifically, when I use assert() from <cassert>, a failure of an assertion
causes the debugging session to terminate. I've been led to believe that the
correct behavior for assert() is to halt execution, and even allow running or
single-stpping past the failed assertion. The int 3 fix does not allow the
latter in the IDDE, but at least allows me to see the line of code where the
assertion failed.

Cheers!

Jan 22 2004

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"dan" <dan_member pathlink.com> wrote in message
news:buoh9e$1psr$1 digitaldaemon.com...
 False alarm!  Only some of Merewald's changes are not incorporated in


 version 1.31, for various reasons. I re-post Aleksey Gurtovoy's reply to


 email in its entirety below...


 ******************************************************
 Hi Dan,

 Sorry, this is totally my fault -- I should have been more clear about
 which fixes got incorporated and why. There've been a number of diffs that
 I didn't check in because they fall into one of the three categories:

 1) unneeded -- the code already compiles as is; for example, fixes in
 "boost/any.hpp" and "boost/detail/ob_compressed_pair.hpp" headers fall
 into this category;

 2) obsolete -- fixes that became obsolete because of the changes in the
 corresponding code;

 3) untestable -- fixes that seemed relevant but which I couldn't test
 because the code was still failing to compile due to other errors --
 in most cases preprocessor-related; for instance, 'function' and
 'signal' libraries fall into this category.

 IOW, all Merewald's (and some of mine) fixes that are still relevant and
 would clearly make Boost more DM-friendly are there; other ones are not,
 since they are not immediately helpful and cannot be tested. Again,
 sorry for any miscommunication on my part.

 --
 Aleksey Gurtovoy
 MetaCommunications Engineering
 ******************************************************


 To Walter:  I forgot to mention one issue which I tried to deal with in


 via a workaround, but which was not accepted, as it is really not in the


 of boost, namely an assert() macro workaround...

 #ifdef __DMC__
 #  ifdef assert
 #    undef assert
 #  endif
 #  ifdef _DEBUG
 #    define assert(x) do{if(!((x)))asm int 3;}while(0)
 #  else
 #    define assert(x) do{(void)(0);}while(0)
 #  endif
 #endif

 Specifically, when I use assert() from <cassert>, a failure of an


 causes the debugging session to terminate. I've been led to believe that


 correct behavior for assert() is to halt execution, and even allow running


 single-stpping past the failed assertion. The int 3 fix does not allow the
 latter in the IDDE, but at least allows me to see the line of code where


 assertion failed.

 Cheers!


Assert is supposed to exit the program via abort(). Of course, one can
modify the behavior for one's own purposes, but I have to ship to the
standard.

Jan 22 2004

↑ ↓ ← → "Jonathan Turkanis" <technews kangaroologic.com> writes:

"dan" <dan_member pathlink.com> wrote in message
news:bunlv5$apq$1 digitaldaemon.com...
 In article <bun857$2mfs$1 digitaldaemon.com>, Jonathan Turkanis


Sorry to take so long to reply. I just looked at the CVS for the
updcoming 1.31 release. The MPL changes which Dan mailed to Aleksy
Gurtovoy have been committed, but Christof Meerwald's fixes have




This is as I suspected.

Jonathan


 I hope you're wrong, Jonathan. The two or three versions of the


 gave to Aleksey, all contained Christoff's original changes.  I just


 and Aleksey to try and clarify this matter.


I didn't mean to cause a sense of alarm. I just looked through the
release candidate and didn't see the changes. The ones I checked were
the boost::and and boost::compressed pair.

I'm happy that the others are in.

My apologies.

Jonathan

Jan 22 2004