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