"dan" <dan_member@pathlink.com> wrote in message news:bunlv5$apq$1@digitaldaemon.com...
> 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.
>
>

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

"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
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!

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.