Type traits on Digital Mars
Hi, The attached patch improves the type traits library on Digital Mars. Mostly it just selects the correct code to be used, the only new code is a new version of boost::is_convertible. Using '...' to overload the conversion check works really badly, so I experimented with different ways of trying to get it to select the right overload, and found one that mostly works. You can see it in the patch. Also, when using static cosnt values it can sometimes cause '_m_from' to get instantiated - causing a link error. To work round this, it uses enums. With this patch applied there are still the following problems: The compiler has trouble with const and volatile modifiers on voids and arrays in template variables. So it gets a lot of the tests involving these types wrong. The compiler allows some conversions that it shouldn't. For example, it only warns about binding temporaries to non-const references, instead of causing an error. So, in these cases is_convertible is true. Would it be worth adding checks for these cases? is_abstract doesn't work. is_base_and_derived uses the 'broken' implementation, based on is_convertible. The test tricky_is_enum_test fails to compile. Daniel
"Daniel James" <daniel@calamity.org.uk> wrote in message news:41277537.4010707@calamity.org.uk...
Hi,
The attached patch improves the type traits library on Digital Mars. Mostly it just selects the correct code to be used, the only new code is a new version of boost::is_convertible.
Nice work. I tried briefly some time back to get is_convertible to work on DMC, since I suspected it would be the source of a lot of trouble, but I quickly gave up because I couldn't get the regression tests to work because of preprocessor problems. Jonathan
Daniel James <daniel@calamity.org.uk> writes:
Hi,
The attached patch improves the type traits library on Digital Mars. Mostly it just selects the correct code to be used, the only new code is a new version of boost::is_convertible. Using '...' to overload the conversion check works really badly, so I experimented with different ways of trying to get it to select the right overload, and found one that mostly works. You can see it in the patch. Also, when using static cosnt values it can sometimes cause '_m_from' to get instantiated - causing a link error. To work round this, it uses enums.
With this patch applied there are still the following problems:
The compiler has trouble with const and volatile modifiers on voids and arrays in template variables. So it gets a lot of the tests involving these types wrong.
The compiler allows some conversions that it shouldn't. For example, it only warns about binding temporaries to non-const references, instead of causing an error. So, in these cases is_convertible is true. Would it be worth adding checks for these cases?
is_abstract doesn't work.
is_base_and_derived uses the 'broken' implementation, based on is_convertible.
The test tricky_is_enum_test fails to compile.
Doesn't Walter update DMC++ quite often? Would it be better to just report bugs to him and wait for the fixes? I have no major objection to the patches; I'm just slightly concerned about crufting up the codebase to add support for a previously unsupported compiler if it will happen without changes in a few weeks anyway. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upt5k867g.fsf@boost-consulting.com...
Doesn't Walter update DMC++ quite often?
Yes, but there are lots of bugs on his list ;-)
Would it be better to just report bugs to him and wait for the fixes?
Walter seems to be very conscientious about bug reports, but I don't think you can assume that if you report a bug it will be fixed in a matter of weeks.
I have no major objection to the patches; I'm just slightly concerned about crufting up the codebase to add support for a previously unsupported compiler if it will happen without changes in a few weeks anyway.
I'd like to see boost support DMC soon. IMO, the best way to motivate Walter to fix the bugs which most affect boost is to run and publish the regression tests for DMC. (I have a feeling I'm about to be asked to volunteer :-) ) I tend to think he'll be more motivated if DMC passes, say, 42% of the tests than if it passes 0-5%. In the latter case, judging by his reaction when preprocessor problems were reported to him earlier this year, I think he might conclude that the problems must be with boost. (After all, DMC can't be *that* bad.) So I'd like to see patches committed if they give substantial parts of boost some hope of compiling with DMC. But this is idle speculation. Jonathan
"Jonathan Turkanis" <technews@kangaroologic.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upt5k867g.fsf@boost-consulting.com...
Doesn't Walter update DMC++ quite often?
Yes, but there are lots of bugs on his list ;-)
Would it be better to just report bugs to him and wait for the fixes?
Walter seems to be very conscientious about bug reports, but I don't think you can assume that if you report a bug it will be fixed in a matter of weeks.
I have no major objection to the patches; I'm just slightly concerned about crufting up the codebase to add support for a previously unsupported compiler if it will happen without changes in a few weeks anyway.
I'd like to see boost support DMC soon. IMO, the best way to motivate Walter to fix the bugs which most affect boost is to run and publish the regression tests for DMC.
But if we cover all the bugs up with workarounds he'll never see any problems.
(I have a feeling I'm about to be asked to volunteer :-) ) I tend to think he'll be more motivated if DMC passes, say, 42% of the tests than if it passes 0-5%. In the latter case, judging by his reaction when preprocessor problems were reported to him earlier this year, I think he might conclude that the problems must be with boost. (After all, DMC can't be *that* bad.)
Wow, that's pretty arrogant. If he has that attitude, Boost test failure reports aren't going to make any difference.
So I'd like to see patches committed if they give substantial parts of boost some hope of compiling with DMC.
But this is idle speculation.
Hum. Maybe you should ask Walter what he's going to be responsive to. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"Jonathan Turkanis" <technews@kangaroologic.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upt5k867g.fsf@boost-consulting.com...
Doesn't Walter update DMC++ quite often?
Yes, but there are lots of bugs on his list ;-)
Would it be better to just report bugs to him and wait for the fixes?
Walter seems to be very conscientious about bug reports, but I don't think you can assume that if you report a bug it will be fixed in a matter of weeks.
I have no major objection to the patches; I'm just slightly concerned about crufting up the codebase to add support for a previously unsupported compiler if it will happen without changes in a few weeks anyway.
I'd like to see boost support DMC soon. IMO, the best way to motivate Walter to fix the bugs which most affect boost is to run and
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uwtzr18kc.fsf@boost-consulting.com... publish
the regression tests for DMC.
But if we cover all the bugs up with workarounds he'll never see any problems.
(I have a feeling I'm about to be asked to volunteer :-) ) I tend to think he'll be more motivated if DMC passes, say, 42% of the tests than if it passes 0-5%. In the latter case, judging by his reaction when preprocessor problems were reported to him earlier this year, I think he might conclude that the
Daniel said his fixes don't make DMC pass all the tests. So presumably there'll still be faiulres to point out. problems
must be with boost. (After all, DMC can't be *that* bad.)
Wow, that's pretty arrogant.
I didn't mean to imply he was arrogant. I said he 'very conscientious about bug reports'. But his *initial* reaction, when Dan Watkins reported proprocessor trouble to him either late last year, was that boost must have been expecting too much of the preprocessor. Later I (with limited knowledge of the preprocessor) gave him some short examples of code which the DMC preprocessor handled incorrectly, and he eventually fixed it. I believe Paul Mensonides did the same. But it turned out the problems with the DMC preprocessor ran very deep.
If he has that attitude, Boost test failure reports aren't going to make any difference.
So I'd like to see patches committed if they give substantial
I've carried on some brief email correspondence with him, and I've followed the DMC lists. I think he understandably likes to focus his attention on bugs that directly affect his existing users. So I can understand why he wouldn't be very motivated to start fixing a huge list of bugs if only 5% of the boost regressions pass. He'd be spending energy on fixes which wouldn't necessarily help any users in the immediate future. parts
of boost some hope of compiling with DMC.
But this is idle speculation.
Hum. Maybe you should ask Walter what he's going to be responsive to.
Like I said, I've discussed this with him a bit. Of course, more discussion would be a good idea. But my impression is that if we just report bugs and wait for Walter to fix them it will be a long time before substantial parts of boost work. Jonathan
"David Abrahams" <dave@boost-consulting.com> wrote:
But if we cover all the bugs up with workarounds he'll never see any problems.
Jonathan Turkanis wrote:
Daniel said his fixes don't make DMC pass all the tests. So presumably there'll still be faiulres to point out.
Yes, I've already reported some bugs. As far as type traits were concerened, I only reported bugs that couldn't be worked around, or were likely to cause problems elsewhere. After all, overloading on a (...) parameter is pretty rare. Making a lot of bug reports for something I had got for free seemed a bit cheeky, especially for doing weird things like using const void template parameters, and preprocessor metaprogramming. But, this was probably a mistake. It's up to Walter how important a bug is. I'll write some more test cases and send them to the Digital Mars newsgroup. He can let us know if he's likely to fix them. So far, he hasn't given any indication either way. I do feel that if I am asking him to make changes to support Boost, I should put some effort into getting Boost working on Digital Mars. I can understand why this might not matter to other people, especially since more standard compliant compilers are available for free. Daniel
David Abrahams wrote:
Doesn't Walter update DMC++ quite often? Would it be better to just report bugs to him and wait for the fixes? I have no major objection to the patches; I'm just slightly concerned about crufting up the codebase to add support for a previously unsupported compiler if it will happen without changes in a few weeks anyway.
I've made a few bug reports concerning type traits - although mainly concerning the bugs that I haven't worked around. You can see them here: http://www.digitalmars.com/drn-bin/wwwnews?c%2B%2B/4156 I'm a little hesitant when it comes to overload resolution because I don't fully understand the rules, especially the subtleties required for the type traits library. Having said that, the main problem is the way it overloads variable argument lists, and I can probably get my head around that. Would anyone be willing to help me out by writing an explanation of what's required? I can put together examples showing exactly what fails. In this case, I didn't think the patch was that bad, it only really adds code to is_convertible, which already seems to have an implementation per compiler. I could simplify it a bit by adding BOOST_NO_INCLASS_MEMBER_INITIALIZATION to Digital Mars' config file, so that enums are used for all member static constants, but that seemed a little extreme. For the preprocessor library, I think that if all the bugs I reported were fixed then my changes could be totally removed. But I don't expect that will happen soon. Daniel
Daniel James <daniel@calamity.org.uk> writes:
David Abrahams wrote:
Doesn't Walter update DMC++ quite often? Would it be better to just report bugs to him and wait for the fixes? I have no major objection to the patches; I'm just slightly concerned about crufting up the codebase to add support for a previously unsupported compiler if it will happen without changes in a few weeks anyway.
I've made a few bug reports concerning type traits - although mainly concerning the bugs that I haven't worked around. You can see them here:
http://www.digitalmars.com/drn-bin/wwwnews?c%2B%2B/4156
I'm a little hesitant when it comes to overload resolution because I don't fully understand the rules, especially the subtleties required for the type traits library. Having said that, the main problem is the way it overloads variable argument lists, and I can probably get my head around that. Would anyone be willing to help me out by writing an explanation of what's required? I can put together examples showing exactly what fails.
It's pretty simple. a (...) parameter is always a worse match than anything else that matches, including template parameter types. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
The attached patch improves the type traits library on Digital Mars. Mostly it just selects the correct code to be used, the only new code is a new version of boost::is_convertible. Using '...' to overload the conversion check works really badly, so I experimented with different ways of trying to get it to select the right overload, and found one that mostly works. You can see it in the patch. Also, when using static cosnt values it can sometimes cause '_m_from' to get instantiated - causing a link error. To work round this, it uses enums.
With this patch applied there are still the following problems:
Those all look fine and I'll apply them, however I've never been able to get dmc working with bjam, for example I see: ...found 42 targets... ...updating 4 targets... dmc-C++-action ..\..\..\bin\boost\libs\config\test\config_info.test\dmc\debug\th reading-multi\config_info.obj '-cpp' is not recognized as an internal or external command, operable program or batch file. -cpp -c -g -S -o+none -Ae -Ar -ND -I"..\..\..\bin\boost\libs\config\t est" -I"c:\data\boost\develop\boost" -o"..\..\..\bin\boost\libs\config\test\co nfig _info.test\dmc\debug\threading-multi\config_info.obj" "..\..\..\libs\config\tes t\config_info.cpp" ...failed dmc-C++-action ..\..\..\bin\boost\libs\config\test\config_info.test\dm c\debug\threading-multi\config_info.obj... ...skipped <@boost!libs!config!test\config_info.test\dmc\debug\threading-multi>c onfig_info.exe for lack of <@boost!libs!config!test\config_info.test\dmc\debug\t hreading-multi>config_info.obj... ...skipped <@boost!libs!config!test\config_info.test\dmc\debug\threading-multi>c onfig_info.run for lack of <@boost!libs!config!test\config_info.test\dmc\debug\t hreading-multi>config_info.exe... ...failed updating 1 target... ...skipped 3 targets... Any ideas? Thanks, John.
John Maddock wrote:
Those all look fine and I'll apply them, however I've never been able to get dmc working with bjam, for example I see:
...found 42 targets... ...updating 4 targets... dmc-C++-action ..\..\..\bin\boost\libs\config\test\config_info.test\dmc\debug\th reading-multi\config_info.obj '-cpp' is not recognized as an internal or external command, operable program or batch file.
Try bjam -sTOOLS=dmc -sDMC_ROOT=C:\dm Regards, Janusz
John Maddock wrote:
Those all look fine and I'll apply them.
Thanks. It looks like you haven't changed 'is_base_and_derived.c'. Is that just a mistake, or is there a reason? Janusz Piwowarski wrote:
Try bjam -sTOOLS=dmc -sDMC_ROOT=C:\dm
That still doesn't work for me, I'm afraid. The Digital Mars standard library is very dated, so you have to use stlport, but the header directories seem to get listed in the wrong order. I'll look into more and take it up on the boost build list sometime. Daniel
Thanks. It looks like you haven't changed 'is_base_and_derived.c'. Is that just a mistake, or is there a reason?
It's because I missed it :-( Fixed now.
Try bjam -sTOOLS=dmc -sDMC_ROOT=C:\dm
That still doesn't work for me, I'm afraid. The Digital Mars standard library is very dated, so you have to use stlport, but the header directories seem to get listed in the wrong order. I'll look into more and take it up on the boost build list sometime.
Same for me, I see (correct error messages this time!): ...found 46 targets... ...updating 13 targets... MkDir1 ..\..\..\bin MkDir1 ..\..\..\bin\boost MkDir1 ..\..\..\bin\boost\libs MkDir1 ..\..\..\bin\boost\libs\config MkDir1 ..\..\..\bin\boost\libs\config\test MkDir1 ..\..\..\bin\boost\libs\config\test\config_info.test MkDir1 ..\..\..\bin\boost\libs\config\test\config_info.test\dmc MkDir1 ..\..\..\bin\boost\libs\config\test\config_info.test\dmc\debug MkDir1 ..\..\..\bin\boost\libs\config\test\config_info.test\dmc\debug\threading- multi dmc-C++-action ..\..\..\bin\boost\libs\config\test\config_info.test\dmc\debug\th reading-multi\config_info.obj c:\cpp\dm\bin\..\stlport\stlport\stl/_alloc.h(134) : Error: undefined identifier '__stl_new' c:\cpp\dm\bin\..\stlport\stlport\stl/_alloc.h(135) : Error: undefined identifier '__stl_delete' class _STLP_CLASS_DECLSPEC __Named_exception : public _STLP_EXCEPTION_BASE { ^ c:\cpp\dm\bin\..\stlport\stlport\stdexcept(56) : Error: identifier expected --- errorlevel 1 "c:\cpp\dm\bin\dmc" -cpp -c -g -S -o+none -Ae -Ar -ND -I"..\..\..\bin\boo st\libs\config\test" -I"c:\data\boost\develop\boost" -I"c:\cpp\dm\include" -o" ..\..\..\bin\boost\libs\config\test\config_info.test\dmc\debug\threading-mul ti\c onfig_info.obj" "..\..\..\libs\config\test\config_info.cpp" ...failed dmc-C++-action ..\..\..\bin\boost\libs\config\test\config_info.test\dm c\debug\threading-multi\config_info.obj... ...skipped <@boost!libs!config!test\config_info.test\dmc\debug\threading-multi>c onfig_info.exe for lack of <@boost!libs!config!test\config_info.test\dmc\debug\t hreading-multi>config_info.obj... ...skipped <@boost!libs!config!test\config_info.test\dmc\debug\threading-multi>c onfig_info.run for lack of <@boost!libs!config!test\config_info.test\dmc\debug\t hreading-multi>config_info.exe... ...failed updating 1 target... ...skipped 3 targets... ...updated 9 targets... John.
participants (5)
-
Daniel James -
David Abrahams -
Janusz Piwowarski -
John Maddock -
Jonathan Turkanis