
Once upon a time I did a bunch of work towards a Boost Predef library. The goal was to have a consistent set of version and feature definitions as could be determined from the predefined macros of toolsets <https://svn.boost.org/svn/boost/sandbox/predef/>. But the work stalled for one basic reason.. How do I write tests for such a library? The only other library that approaches the domain of this one is Boost Config and, AFAICT, it doesn't test the macros themselves. As I'm looking to finish of this lib for eventual submission I'm looking for ideas on this. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On Sat, May 22, 2010 at 8:07 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
Once upon a time I did a bunch of work towards a Boost Predef library. The goal was to have a consistent set of version and feature definitions as could be determined from the predefined macros of toolsets <https://svn.boost.org/svn/boost/sandbox/predef/>. But the work stalled for one basic reason.. How do I write tests for such a library? The only other library that approaches the domain of this one is Boost Config and, AFAICT, it doesn't test the macros themselves.
As I'm looking to finish of this lib for eventual submission I'm looking for ideas on this.
You could perhaps use Boost.Wave to preprocess the files in various ways so you can test the configurations? Or use Clang if you feel particularity adventurous.

Rene Rivera wrote:
Once upon a time I did a bunch of work towards a Boost Predef library. The goal was to have a consistent set of version and feature definitions as could be determined from the predefined macros of toolsets <https://svn.boost.org/svn/boost/sandbox/predef/>. But the work stalled for one basic reason.. How do I write tests for such a library? The only other library that approaches the domain of this one is Boost Config and, AFAICT, it doesn't test the macros themselves.
First, this looks very nice. Second, BOOST_VERSION_NUMBER(0,0,1) is an awfully verbose way to write 1, don't you think? Third, the only way to test this I can think of is to write tests that, effectively, repeat the preprocessor work done in the configuration files, but written in a less factored way and with static assertions to verify expected values. The special cases don't seem to allow for anything automatic. For example, #ifdef _MSC_VER BOOST_STATIC_ASSERT(BOOST_CXX_MSVC); BOOST_STATIC_ASSERT(BOOST_CXX_MSVC_BUILD); # if _MSC_VER == 1400 BOOST_STATIC_ASSERT(BOOST_CXX_MSVC/100000 == 800); # elif _MSC_VER == 1510 BOOST_STATIC_ASSERT(BOOST_CXX_MSVC/100000 == 910); # elif ... ... # endif #endif (I glossed over the BOOST_CXX_MSVC_BUILD values just for simplicity.) A test file for each compiler would avoid introducing too much noise in any given file, I should think. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (3)
-
OvermindDL1
-
Rene Rivera
-
Stewart, Robert