Re: [boost] Factoring out Test Library wrapstrstream
- Original Message - From: Rozental, Gennadiy [EMAIL PROTECTED] To: 'Boost mailing list' [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 7:13 PM Subject: RE: [boost] Factoring out Test Library wrapstrstream (3) fully included The problem with this is that I put the burden of doing so to the user. I do not get it. In this case you are the user (of Boost.Test library). To use fully included version you are using #include boost/test/included/test_exec_monitor.hpp All right... I totally missed this... I thought 'fully included' meant something else. Sorry. (btw: I couldn't find this on the Docs... perhaps it's just me) NOTE: I tried to use this method with the numeric library test. Using bcc55, I encountered the following error on test_tools.cpp: __strcmp__ is not a member of std I had to add the following to that source file, right before the opening namespace boost: # ifdef __BORLANDC__ #pragma intrinsic -strcmp # endif And that's it. No need for linking. I could use jamfiles, but jam builds doesn't work on every supported platform. For instance, it doesn't work on mine (borland), so I can't resort to jamfiles to attach the test framework to a simple test with a single file. Works for me. On windows I am testing using MSVC, GCC and BCC. Look on Boost.Test unit tests Jamfile. I know there are Jamfiles for bcc, but I can't get them to work. The problem is not with the compilers but with bjam on cygwin on Win98 On this platform, bjam produces command lines longer than the shell limit so the compiler gets its input trimmed off. Did you effectively used bjam on your computer to actually build the Test Framework with those windows compilers? What platform are you using for this? (2) fully linked Similarly, this requires me (and eventually the end user) to compile the test framwwork with every platform I want to test against. This is a burden in some cases. For example, since Borland doesn't work with bjam, I need to do it by hand for this compiler. Similarly, I need to go through all the trouble of building the test framework with every compiler I want to test my code against. This is too much for a single file test which would use just a small subset of the Test Framework AFAIK Boost.Test is compiled and works for all supported compilers/platforms. With and without Jamfile. I know that it *can be* compiled on all supported platforms. But I wouldn't say that it *is* compiled.. it isn't on my computer...:-) I need to compile it manually. Perhaps these could be solved if you upload to the files sections the binaries for the supported platforms. Great. If I'm not mistaken, most of the stuff from test_tools.hpp can be rearranged so that it becomes self-contained. That is, it would be possible to use some of it by simply including test_tools.hpp, with possibly a macro switch to indicate that its definitions shall be included right into the translation unit being compiled. No. Majority of the staff in test_tools.hpp depends on unit_test_log, unit_test_results and on test_tools.cpp of course. Those three modules constitute the 80 percent of unit test framework and separating them would not buy you to much. I see. Even if you rearrange test-tools so that it can be used standalone without external modules that needs to be linked or added to the project, I think that wrapstrstream() would be quite useful on its own. Using a text stream to quickly format text on the fly is a very common operation, and wrapstrstream() provides a nice solution for it. All right. I will try to prepare standalone file + doc for submission. Do we need the review for this? I don't think we should need a review for this. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Factoring out Test Library wrapstrstream
The problem is that BCC, by default, uses an 'intrinsic' version of strcmp which is not a real function thus it is not located in std. Declaring strcmp inside std doesn't help. The workaround is to either use unqualified calls to strcmp or to disable its intrinsic version. My patch does the latter. Why don't I have any problems compiling using borland command line tools? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Factoring out Test Library wrapstrstream
- Original Message - From: Rozental, Gennadiy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 25, 2002 4:17 AM Subject: RE: [boost] Factoring out Test Library wrapstrstream My tests are already arranged in a way that 'test/minimal.hpp' offers too little functionality while a whole test framework, such as test_execution_monitor or unit_test_framework requires me link or include too many translation units. Well currently Boost.Test propose three configuration: 1. Minimal 2. Full linked 3. Full included Does not any one of them fit for you? What are the issues? What set of features you are looking for? I'm considering the case of a single-file test which would use just a small subset of the Test Framework. (3) fully included The problem with this is that I put the burden of doing so to the user. I could use jamfiles, but jam builds doesn't work on every supported platform. For instance, it doesn't work on mine (borland), so I can't resort to jamfiles to attach the test framework to a simple test with a single file. (2) fully linked Similarly, this requires me (and eventually the end user) to compile the test framwwork with every platform I want to test against. This is a burden in some cases. For example, since Borland doesn't work with bjam, I need to do it by hand for this compiler. Similarly, I need to go through all the trouble of building the test framework with every compiler I want to test my code against. This is too much for a single file test which would use just a small subset of the Test Framework. (1) Minimal This is potentially the best option in this scenario. It fell short on my specific needs, but this can be easy to fix: Specifically, I wanted it to provide the *basic* stuff at 'test_tools.hpp' As a result, I don't want to use the Test Library (but we could discuss this, because I might be biased by its perceived complexity) I still hope to satisfy your requests for new features and explain everything that seems complex. Great. If I'm not mistaken, most of the stuff from test_tools.hpp can be rearranged so that it becomes self-contained. That is, it would be possible to use some of it by simply including test_tools.hpp, with possibly a macro switch to indicate that its definitions shall be included right into the translation unit being compiled. A quick search for BOOST_NO_STRINGSTREAM reveals that there is a sort of 'idiom' which is extensively used -by hand- among many unit tests (i.e, including the appropriate header and dealing later with either ostrstream or ostringstream). I also found that this idiom is very well captured by the Test Library under the form of the class 'wrapstrstream', which comes exactly as handy as most of the unit tests I've seen need it. You may nor remark it but this class change the interface a little right after 1.29 came out to implement different fix for the issue with copy constructor. Aha, I didn't notice it... Therefore, is it possible to factor out this class so it can be used standalone? Say, as /utility/wrapstrstream.hpp. Gennaidy, what do you think? TIA, Fernando Cacciola Well, if there is an interest in reuse of this class I do not see the reason why not. BTW at very end of 1.29 I added nullstream.hpp into details section of Boost.Test (borrowed and reworked a bit from Daryle Walker more_io). It also belongs somewhere in utility. Even if you rearrange test-tools so that it can be used standalone without external modules that needs to be linked or added to the project, I think that wrapstrstream() would be quite useful on its own. Using a text stream to quickly format text on the fly is a very common operation, and wrapstrstream() provides a nice solution for it. Best regards, Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Factoring out Test Library wrapstrstream
(3) fully included The problem with this is that I put the burden of doing so to the user. I do not get it. In this case you are the user (of Boost.Test library). To use fully included version you are using #include boost/test/included/test_exec_monitor.hpp And that's it. No need for linking. I could use jamfiles, but jam builds doesn't work on every supported platform. For instance, it doesn't work on mine (borland), so I can't resort to jamfiles to attach the test framework to a simple test with a single file. Works for me. On windows I am testing using MSVC, GCC and BCC. Look on Boost.Test unit tests Jamfile. (2) fully linked Similarly, this requires me (and eventually the end user) to compile the test framwwork with every platform I want to test against. This is a burden in some cases. For example, since Borland doesn't work with bjam, I need to do it by hand for this compiler. Similarly, I need to go through all the trouble of building the test framework with every compiler I want to test my code against. This is too much for a single file test which would use just a small subset of the Test Framework AFAIK Boost.Test is compiled and works for all supported compilers/platforms. With and without Jamfile. Great. If I'm not mistaken, most of the stuff from test_tools.hpp can be rearranged so that it becomes self-contained. That is, it would be possible to use some of it by simply including test_tools.hpp, with possibly a macro switch to indicate that its definitions shall be included right into the translation unit being compiled. No. Majority of the staff in test_tools.hpp depends on unit_test_log, unit_test_results and on test_tools.cpp of course. Those three modules constitute the 80 percent of unit test framework and separating them would not buy you to much. Even if you rearrange test-tools so that it can be used standalone without external modules that needs to be linked or added to the project, I think that wrapstrstream() would be quite useful on its own. Using a text stream to quickly format text on the fly is a very common operation, and wrapstrstream() provides a nice solution for it. All right. I will try to prepare standalone file + doc for submission. Do we need the review for this? Best regards, Fernando Cacciola Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Factoring out Test Library wrapstrstream
My tests are already arranged in a way that 'test/minimal.hpp' offers too little functionality while a whole test framework, such as test_execution_monitor or unit_test_framework requires me link or include too many translation units. Well currently Boost.Test propose three configuration: 1. Minimal 2. Full linked 3. Full included Does not any one of them fit for you? What are the issues? What set of features you are looking for? As a result, I don't want to use the Test Library (but we could discuss this, because I might be biased by its perceived complexity) I still hope to satisfy your requests for new features and explain everything that seems complex. A quick search for BOOST_NO_STRINGSTREAM reveals that there is a sort of 'idiom' which is extensively used -by hand- among many unit tests (i.e, including the appropriate header and dealing later with either ostrstream or ostringstream). I also found that this idiom is very well captured by the Test Library under the form of the class 'wrapstrstream', which comes exactly as handy as most of the unit tests I've seen need it. You may nor remark it but this class change the interface a little right after 1.29 came out to implement different fix for the issue with copy constructor. Therefore, is it possible to factor out this class so it can be used standalone? Say, as /utility/wrapstrstream.hpp. Gennaidy, what do you think? TIA, Fernando Cacciola Well, if there is an interest in reuse of this class I do not see the reason why not. BTW at very end of 1.29 I added nullstream.hpp into details section of Boost.Test (borrowed and reworked a bit from Daryle Walker more_io). It also belongs somewhere in utility. Gennadiy. P.S. Sorry it took me so long to answer. I just was overloaded at the work and with serialization review. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
