Dear Gennadiy Rozental, I've converted my local copy of the serialization library tests to use test/minimal.hpp in the hope that I can use it in the future as the "lowest common denominator" to permit testing against a wider array of platforms. Boost Test for support of msvc is scheduled to be remove in the near future. I've had problems testing the serialization library with comeau compilers because both the seriailzation library and boost test include instantiated code for string output and the comeau "pre-linker" fails here. I've felt the need for a "lighter weight" version of boost test. Recently on a contract job of mine I used some headers from boost. I didn't need to compile any boost libraries in this case. The existence of test/minimal.hpp permitted me to use boost test without going building the libraries which turned out to be very convenient for a number of reasons. So - I'm happy with test/minimal.hpp - But - in order to make it work with the serialization library I had to make a couple of tweaks which I would like to submit in the hope that they can be incorporated into the official boost test version. Change # 1 A small change to permit commeau to be tested with the serialization library. This is obviously a crude hack but perhaps it can be fine tuned to make it acceptable. RCS file: /cvsroot/boost/boost/boost/test/impl/unit_test_parameters.ipp,v retrieving revision 1.10 diff -r1.10 unit_test_parameters.ipp 204,205c204,205 < const_string rs_str = retrieve_framework_parameter( RANDOM_SEED, argc, argv ); < s_random_seed = rs_str.is_empty() ? 0 : lexical_cast<unsigned int>(rs_str ); ---
// const_string rs_str = retrieve_framework_parameter( RANDOM_SEED, argc, argv ); // s_random_seed = rs_str.is_empty() ? 0 : lexical_cast<unsigned int>( rs_str );
Change #2 I added some test tool macros for test/minimal.hpp . I would like to see these incorporated but of course could life without them if I have to. Index: minimal.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/test/minimal.hpp,v retrieving revision 1.19 diff -r1.19 minimal.hpp 17a18,19
#define BOOST_TEST_INCLUDED
22a25,29
#define BOOST_WARN(exp) \ ( (exp) \ ? static_cast<void>(0) \ : boost::minimal_test::report_message(#exp,__FILE__,__LINE__, BOOST_CURRENT_FUNCTION, true) )
27a35,62
#define BOOST_CHECK_MESSAGE(exp, msg_) \ ( (exp) \ ? static_cast<void>(0) \ : boost::minimal_test::report_error(msg_,__FILE__,__LINE__, BOOST_CURRENT_FUNCTION) )
#define BOOST_WARN_MESSAGE(exp, msg_) \ ( (exp) \ ? static_cast<void>(0) \ : boost::minimal_test::report_message(msg_,__FILE__,__LINE__, BOOST_CURRENT_FUNCTION) )
#define BOOST_REQUIRE_MESSAGE(exp, msg_) \ ( (exp) \ ? static_cast<void>(0) \ : boost::minimal_test::report_critical_error(msg_,__FILE__,__LINE__,BOOST_CURRENT_FUNCTION))
#define BOOST_WARN_EQUAL( left, right ) \ BOOST_WARN((left) == (right)) #define BOOST_CHECK_EQUAL( left, right ) \ BOOST_CHECK((left) == (right)) #define BOOST_REQUIRE_EQUAL( left, right ) \ BOOST_require((left) == (right))
#define BOOST_TEST_CHECKPOINT(msg_) \ boost::minimal_test::report_message( (msg_),__FILE__,__LINE__, BOOST_CURRENT_FUNCTION, true )
#define BOOST_TEST_MESSAGE(msg_) \ boost::minimal_test::report_message( (msg_),__FILE__,__LINE__, BOOST_CURRENT_FUNCTION, true )
29a65
32a69,70
#define BOOST_TEST_DONT_PRINT_LOG_VALUE( ArgumentType )
36c74,75 < #include <boost/test/detail/global_typedef.hpp> ---
#define BOOST_DISABLE_WIN32 //#include <boost/test/detail/global_typedef.hpp> 38c77 < #include <boost/test/utils/class_properties.hpp>
//#include <boost/test/utils/class_properties.hpp> 42c81 < #include <boost/cstdlib.hpp> // for exit codes#include <boost/cstdlib.hpp> // for exit codes
//#include <boost/cstdlib.hpp> // for exit codes#include <boost/cstdlib.hpp> // for exit codes 47c86 < #include <string> // std::string
//#include <string> // std::string 63c102 < report_error( const char* msg, const char* file, int line, const_string func_name, bool is_msg = false )
report_message( const char* msg, const char* file, int line, const_string func_name, bool is_msg = false ) 65d103 < ++errors_counter(); 79a118,124 report_error( const char* msg, const char* file, int line, const_string func_name, bool is_msg = false ) { ++errors_counter(); report_message(msg, file, line, func_name, is_msg); }
inline void
Thank you very much - I should say that one of your boost articles - maybe its still in there about how testing can change your life had a great effect on me. It has been very helpful to me personally. The "testing philosophy" expounded there - along with the instant availability of test/minimal.hpp - has made a night / day difference in the quality of code produced at one of my customers. Though off topic, I never really thanked you for your in depth review of the my original serialization library submission. Except for one tiny slip ("... contains this gem"), it was an exhaustive point by point critique of every aspect of it. Not that I enjoyed being on the receiving end of such criticism, it was clear to me that it was basically correct and well thought out.. After I recovered from the rejection I went back and re-did it using your critique as a checklist and was eventually successful in getting the library accepted. So, for better or worse, this library is part of boost only because of your six hour investment. Robert Ramey
"Robert Ramey" <ramey@rrsd.com> writes:
No - it never occured to me to look there. Is this documented anywhere?
No, being in boost/detail, it doesn't have to be. It's not for "public consumption;" just a convenience for Boost developers. See how that works?
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
I've felt the need for a "lighter weight" version of boost test.
Did you try boost/detail/lightweight_test.hpp ?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
"Robert Ramey" <ramey@rrsd.com> wrote in message news:e6etq0$7he$1@sea.gmane.org...
Dear Gennadiy Rozental,
Hmm, no "sir" - well for the fellow booster plain Gennadiy should work ;o)
I've converted my local copy of the serialization library tests to use test/minimal.hpp in the hope that I can use it in the future as the "lowest common denominator" to permit testing against a wider array of platforms.
Hi, Robert If you care for my opinion, it would not be a wise move, unless you don't case about the quality of your tests of course. Current state of the Unit Test Framework (UTF) allows me to state that it's a preferred solution in all possible use scenarios (simplest one-liner, simple single function test with several assertions or complex multilevel test case structure) from all possible angles: * usability * functionality * compilation time There was a thread some time ago where I gave detailed comparison. As for the "wider array of platforms" - Boost.Test doesn't delve in most part any gray areas of the language and so both components covers the same set of platforms: at least among those that we test on. I personally never use it. The only scenario I could even imagine it make sense to use is write a "quickie" - simple test I plan to throw immediately in some unfamiliar environment, where I do not have time/permission to build a library on. Even in this scenario I would rather use included version of UTF.
Boost Test for support of msvc is scheduled to be remove in the near future.
We discussed this couple time and I thought I was clear. Ok. Lets imagine two years from now boost decides to drop msvc 6.5 from regression testing. Would you still insist on maintaining this configuration? Even though none of the boost components you depend on are going to be tested on it and accordingly will start to fail sooner or later? My hope is that your answer is no. In this case I could most solemnly swear that Boost.Test will work on all platforms boost perform regression testing on and you have nothing to worry about.
I've had problems testing the serialization library with comeau compilers because both the serialization library and boost test include instantiated code for string output and the comeau "pre-linker" fails here.
I do remember some issues with this compiler. But I don't think that we couldn't find some workaround.
I've felt the need for a "lighter weight" version of boost test. Recently on a contract job of mine I used some headers from boost. I didn't need to compile any boost libraries in this case. The existence of test/minimal.hpp permitted me to use boost test without going building the libraries which turned out to be very convenient for a number of reasons.
So - I'm happy with test/minimal.hpp -
But - in order to make it work with the serialization library I had to make a couple of tweaks which I would like to submit in the hope that they can be incorporated into the official boost test version.
Change # 1
A small change to permit commeau to be tested with the serialization library. This is obviously a crude hack but perhaps it can be fine tuned to make it acceptable.
RCS file: /cvsroot/boost/boost/boost/test/impl/unit_test_parameters.ipp,v
I don't believe minimal_test.hpp depends on unit_test_parameters.ipp. So I do not see why you brig it up here. But post release we could revaluate the best fix for commeau issue.
Change #2
I added some test tool macros for test/minimal.hpp . I would like to see these incorporated but of course could life without them if I have to.
Index: minimal.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/test/minimal.hpp,v retrieving revision 1.19 diff -r1.19 minimal.hpp 17a18,19
#define BOOST_TEST_INCLUDED
22a25,29
#define BOOST_WARN(exp) \ ( (exp) \ ? static_cast<void>(0) \ : boost::minimal_test::report_message(#exp,__FILE__,__LINE__, BOOST_CURRENT_FUNCTION, true) )
27a35,62
#define BOOST_CHECK_MESSAGE(exp, msg_) \ ( (exp) \ ? static_cast<void>(0) \ : boost::minimal_test::report_error(msg_,__FILE__,__LINE__, BOOST_CURRENT_FUNCTION) )
#define BOOST_WARN_MESSAGE(exp, msg_) \ ( (exp) \ ? static_cast<void>(0) \ : boost::minimal_test::report_message(msg_,__FILE__,__LINE__, BOOST_CURRENT_FUNCTION) )
#define BOOST_REQUIRE_MESSAGE(exp, msg_) \ ( (exp) \ ? static_cast<void>(0) \ : boost::minimal_test::report_critical_error(msg_,__FILE__,__LINE__,BOOST_CURRENT_FUNCTION))
#define BOOST_WARN_EQUAL( left, right ) \ BOOST_WARN((left) == (right)) #define BOOST_CHECK_EQUAL( left, right ) \ BOOST_CHECK((left) == (right)) #define BOOST_REQUIRE_EQUAL( left, right ) \ BOOST_require((left) == (right))
These do not bring any value. Why would you want something like this?
#define BOOST_TEST_CHECKPOINT(msg_) \ boost::minimal_test::report_message( (msg_),__FILE__,__LINE__, BOOST_CURRENT_FUNCTION, true )
#define BOOST_TEST_MESSAGE(msg_) \ boost::minimal_test::report_message( (msg_),__FILE__,__LINE__, BOOST_CURRENT_FUNCTION, true )
29a65
32a69,70
#define BOOST_TEST_DONT_PRINT_LOG_VALUE( ArgumentType )
36c74,75 < #include <boost/test/detail/global_typedef.hpp> ---
#define BOOST_DISABLE_WIN32 //#include <boost/test/detail/global_typedef.hpp> 38c77 < #include <boost/test/utils/class_properties.hpp>
//#include <boost/test/utils/class_properties.hpp> 42c81 < #include <boost/cstdlib.hpp> // for exit codes#include <boost/cstdlib.hpp> // for exit codes
//#include <boost/cstdlib.hpp> // for exit codes#include <boost/cstdlib.hpp> // for exit codes 47c86 < #include <string> // std::string
//#include <string> // std::string 63c102 < report_error( const char* msg, const char* file, int line, const_string func_name, bool is_msg = false )
report_message( const char* msg, const char* file, int line, const_string func_name, bool is_msg = false ) 65d103 < ++errors_counter(); 79a118,124 report_error( const char* msg, const char* file, int line, const_string func_name, bool is_msg = false ) { ++errors_counter(); report_message(msg, file, line, func_name, is_msg); }
inline void
All in all it's just repetition of some of the staff UTF provides. Soon you need some other missing feature and next thing you know we copy/paste the whole UTF implementation into single header file. I would really want to avoid this repetition. minimal.hpp exist for particular purpose and I don't see a need to extends it's boundaries. It's just not a message I would like to send to Boost.Test users.
Thank you very much - I should say that one of your boost articles - maybe its still in there about how testing can change your life had a great effect on me. It has been very helpful to me personally. The "testing philosophy" expounded there - along with the instant availability of test/minimal.hpp - has made a night / day difference in the quality of code produced at one of my customers.
I don't want to repeat myself, but I would recommend to revaluate some other components presented by Boost.Test. UTF would be give you and your customer much more whatever your testing needs are.
Though off topic, I never really thanked you for your in depth review of the my original serialization library submission. Except for one tiny slip ("... contains this gem"), it was an exhaustive point by point critique of every aspect of it. Not that I enjoyed being on the receiving end of such criticism, it was clear to me that it was basically correct and well thought out.. After I recovered from the rejection I went back and re-did it using your critique as a checklist and was eventually successful in getting the library accepted. So, for better or worse, this library is part of boost only because of your six hour investment.
It was (and still is) a pleasure collaborate with you either. Let's hope you will find my response to your critique respectively successful. Regards, Gennadiy
On Mon, 12 Jun 2006 01:44:25 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
environment, where I do not have time/permission to build a library on. Even in this scenario I would rather use included version of UTF.
I love Boost.Test, and use it religiously. However, I've always used the lib, and never had need for the "included" feature util this past weekend. However, I could not get it to work immediately as it seemed to not have the same feature set. I was probably doing something wrong, but I could not find any good docs or examples of using it (other than to say include stuff from included directory, which seems to be a bit scant). So, I scp-d everything to another machine which had the libs and did my work there. However, it did remind me that you've said the "included" variant is available, but I could not use it readily. Could you please help me locate more detailed instructions on how to use the "included" variant? Also, I assume compile times are longer, but other than that, what do you lose, if anything, by using the included version? Thanks!
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20060613115639.4a490dcc.jody-boost-011304@atdesk.com...
On Mon, 12 Jun 2006 01:44:25 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
environment, where I do not have time/permission to build a library on. Even in this scenario I would rather use included version of UTF.
[...]
Could you please help me locate more detailed instructions on how to use the "included" variant? Also, I assume compile times are longer, but other than that, what do you lose, if anything, by using the included version?
Well. It supposed to be equivalent. And you get "included" version with a simple change from: #define BOOST_TEST_MODULE my_test #include <boost/test/unit_test.hpp> to: #define BOOST_TEST_MODULE my_test #include <boost/test/included/unit_test.hpp> And everithing should still work as before. Whatever extra headers you had to include in case of offline library (like floating_point_comparison.hpp), they still need to be included separately. Gennadiy
Gennadiy Rozental wrote:
"Robert Ramey" <ramey@rrsd.com> wrote in message news:e6etq0$7he$1@sea.gmane.org...
Dear Gennadiy Rozental,
Hmm, no "sir" - well for the fellow booster plain Gennadiy should work ;o)
aaaa - unfortunately I can't figure out how to pronounce this so I can't remember how it's spelled. I didn't want to say "Mr. Rosenthal" given that we're on such intimate terms, so I just copied your full name. OTOH I spent many years outside the U.S. after being living in Califonia until my twenties. When I came back to the U.S (now twenty years ago) is was struck by the "instant familiarity" of american language and customs. It stll seems odd to me to hear - "My name is Brittany - I'll be your waiter this evening. The first time time this happened, I stood up shook her hand, introduced my wife (she's from germany) and said "Hello, My name is Robert and this is my wife Annegret and we'll be your customers". Unfortunately, this provoked consturnation among the staff rather the the hilarity I had anticipated. It wasn't totally lost - my wife thought it was hysterically funny. No real point here - I'm still hoping to find someone who can laugh at my humor.
Hi, Robert
If you care for my opinion, it would not be a wise move, unless you don't case about the quality of your tests of course. Current state of the Unit Test Framework (UTF) allows me to state that it's a preferred solution in all possible use scenarios (simplest one-liner, simple single function test with several assertions or complex multilevel test case structure) from all possible angles:
* usability * functionality * compilation time
Hmmm - and universality?
We discussed this couple time and I thought I was clear. Ok. Lets imagine two years from now boost decides to drop msvc 6.5 from regression testing.
From my personal perspective, it could be dropped right now as I happen to test that on my own machine whenever I make a change. Same goes for BCB 5.51 and 5.64
Would you still insist on maintaining this configuration? Even though none of the boost components you depend on are going to be tested on it and accordingly will start to fail sooner or later?
My hope is that your answer is no. In this case I could most solemnly swear that Boost.Test will work on all platforms boost perform regression testing on and you have nothing to worry about.
*** Hmmm maybe this is the crux of the difference. I don't see Boost Test as primarily a means running boost regression testing. Of course its that, but I see it as much more. I see it as the "Tool of choice" for users making C++ unit tests. which is not quite the same thing. The boost regression testing environment is sort of special - it presupposes installation of bjam and building boost libraries etc. This is more of a "marketing" view point. Some boost libraries benefit by being almost universal - others not. Boost Test is one of the former. *** So, I have a different take on this. Suppose I make library A. As library author I can decide which platforms (in addition to the mythical totally conforming compiler and standard library) it will run on. This isn't a decision made by boost or boost policy. And of course its going to vary by library. BOOST_STATIC_ASSERT can and should be made almost universal. Boost Lambda cannot be without crippling its usefulness. So library B is implemented and running nicely on the platforms the author has decided its appropropriate to support. Library B depends upon Library A. Library C comes along and doesn't support all the platforms that Library B does - but that's no problem as Library A doesn't depend on B. The author of Library A adds some new functionality. Still no problem since he left in the old code. Now Library A makes some changes which break the original API for some platforms. Of course that is where the problem arises. But why is it necessary for the author of Library A to do this? What does it cost him to just leave to original code in? The code is already written and tested. As an example, the serialization library still works with BCB 5.51 and VC 6.x. Its not that I invest any effort to do this - Its just that it costs me nothing to leave this facility available. A good example is spirit. Spirit has moved on but left sprite 1.6x around - this solution has worked well for me.
I've had problems testing the serialization library with comeau compilers because both the serialization library and boost test include instantiated code for string output and the comeau "pre-linker" fails here.
Change # 1
A small change to permit commeau to be tested with the serialization library. This is obviously a crude hack but perhaps it can be fine tuned to make it acceptable.
This addresses the comeau pre-linker issue. Perhaps the fact that this "solves" the issue for the serialization library might give you a hint as to a permanent fix. Maybe its not a big deal as it seems only to inhibit testing of the serialization library.
I don't want to repeat myself, but I would recommend to revaluate some other components presented by Boost.Test. UTF would be give you and your customer much more whatever your testing needs are.
I don't dispute that UTF is better. Its just that sometimes I want to make a test and I can't build the boost libraries without taking a big detour into bjam country. Robert Ramey
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey | Sent: 13 June 2006 18:13 | To: boost@lists.boost.org | Subject: Re: [boost] Boost.Test - misc observations | | OTOH I spent | many years outside the U.S. after being living in Califonia until my | twenties. When I came back to the U.S (now twenty years | ago) is was struck | by the "instant familiarity" of american language and | customs. It stll | seems odd to me to hear - "My name is Brittany - I'll be | your waiter this | evening. The first time time this happened, I stood up | shook her hand, | introduced my wife (she's from germany) and said "Hello, My | name is Robert | and this is my wife Annegret and we'll be your customers". | Unfortunately, | this provoked consturnation among the staff rather the the | hilarity I had | anticipated. It wasn't totally lost - my wife thought it was | hysterically | funny. No real point here - I'm still hoping to find | someone who can laugh at my humor. Well you found one here - LOL! | | > I don't want to repeat myself, but I would recommend to revaluate | > some other components presented by Boost.Test. UTF would | be give you | > and your customer much more whatever your testing needs are. | | I don't dispute that UTF is better. Its just that sometimes | I want to make | a test and I can't build the boost libraries without taking | a big detour into bjam country. Surely this isn't true now that Dave's Merry Men have produced a Idiot-proof (well I did it OK) way of downloading pre-built libraries, including Boost.Test. We have yet to see the new improved Boost.Test documentation promised for 1.34 though, and I think they should solve many persistent problems. (Incidentally we did find almost insuperable problems ***jointly*** building html documentation using Dreamweaver. It may be that Boost.Book (with CVS?) will make this easier - but I have yet to open that can to see what worms it may contain. Even the feedback/correction of spilliing misfakse is timesome.) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 13 June 2006 18:13
[snip]
I don't dispute that UTF is better. Its just that sometimes I want to make a test and I can't build the boost libraries without taking a big detour into bjam country.
Surely this isn't true now that Dave's Merry Men have produced a Idiot-proof (well I did it OK) way of downloading pre-built libraries, including Boost.Test.
Actually, it's not included - at least not the last time I tried (which is only a few minutes ago). I've only tried the Dublin and Ishikawa mirrors though, could there be a difference? // Johan
"Robert Ramey" <ramey@rrsd.com> wrote in message news:e6mrml$ick$1@sea.gmane.org...
Gennadiy Rozental wrote:
"Robert Ramey" <ramey@rrsd.com> wrote in message news:e6etq0$7he$1@sea.gmane.org...
Dear Gennadiy Rozental,
Hmm, no "sir" - well for the fellow booster plain Gennadiy should work ;o)
aaaa - unfortunately I can't figure out how to pronounce this so I can't remember how it's spelled. I didn't want to say "Mr. Rosenthal" given that we're on such intimate terms, so I just copied your full name. OTOH I spent many years outside the U.S. after being living in Califonia until my twenties. When I came back to the U.S (now twenty years ago) is was struck by the "instant familiarity" of american language and customs. It stll seems odd to me to hear - "My name is Brittany - I'll be your waiter this evening. The first time time this happened, I stood up shook her hand, introduced my wife (she's from germany) and said "Hello, My name is Robert and this is my wife Annegret and we'll be your customers". Unfortunately,
LOL
this provoked consturnation among the staff rather the the hilarity I had anticipated. It wasn't totally lost - my wife thought it was hysterically funny. No real point here - I'm still hoping to find someone who can laugh at my humor.
Hi, Robert
If you care for my opinion, it would not be a wise move, unless you don't case about the quality of your tests of course. Current state of the Unit Test Framework (UTF) allows me to state that it's a preferred solution in all possible use scenarios (simplest one-liner, simple single function test with several assertions or complex multilevel test case structure) from all possible angles:
* usability * functionality * compilation time
Hmmm - and universality?
I am not sure what you mean by term universality. Do you mean portability?
We discussed this couple time and I thought I was clear. Ok. Lets imagine two years from now boost decides to drop msvc 6.5 from regression testing.
From my personal perspective, it could be dropped right now as I happen to test that on my own machine whenever I make a change. Same goes for BCB 5.51 and 5.64
IMO you underestimate crucial importance of testing. More on this below.
Would you still insist on maintaining this configuration? Even though none of the boost components you depend on are going to be tested on it and accordingly will start to fail sooner or later?
My hope is that your answer is no. In this case I could most solemnly swear that Boost.Test will work on all platforms boost perform regression testing on and you have nothing to worry about.
*** Hmmm maybe this is the crux of the difference. I don't see Boost Test as primarily a means running boost regression testing.
No do I.
Of course its that, but I see it as much more. I see it as the "Tool of choice" for users making C++ unit tests. which is not quite the same thing.
Right
The boost regression testing environment is sort of special - it presupposes installation of bjam and building boost libraries etc. This is more of a "marketing" view point. Some boost libraries benefit by being almost universal - others not. Boost Test is one of the former.
I am not sure I understand: how any library may not benefit from being universal/portable?
*** So, I have a different take on this.
Suppose I make library A. As library author I can decide which platforms (in addition to the mythical totally conforming compiler and standard library) it will run on. This isn't a decision made by boost or boost policy. And of course its going to vary by library.
And from that it follows that your decision with platforms your library works on depend on which platforms all the your library's dependencies works on. Formally: the set of platforms supported by your library could not exceed intersection of all respective sets for your dependencies. In more simple terms: if the library you depend on doesn't work on platform P regardless of you willingness to support this platform it couldn't be done. But how do we define formally: "Library A works on platform P". My understanding could be expressed in a following definition: Library A works on platform P iff: 1. All libraries A depend on works on platform P 2. Library A could be build on platform P (if offline library is necessary) 3. All required unit tests for library A pass on platform P. Item 3 in above definition is crucial IMO. From above definition it follows that if dependency D of library A is not tested on platform P - library A does *not* work on platform P.
BOOST_STATIC_ASSERT can and should be made almost universal.
You may think so. I may think so. Even 10000 happy users may think so. But if we don't test BOOST_STATIC_ASSERT on platform P, no library that depend on it could claim it works on that platform. Another important point is: nothing is universal. Do you mean to suggest that BOOST_STATIC_ASSERT should be written in a such a way that it will work on any C++ compilers currently used by at least single person as a development tool?
Boost Lambda cannot be without crippling its usefulness.
So library B is implemented and running nicely on the platforms the author has decided its appropropriate to support. Library B depends upon Library A. Library C comes along and doesn't support all the platforms that Library B does - but that's no problem as Library A doesn't depend on B. The author of Library A adds some new functionality. Still no problem since he left in the old code. Now Library A makes some changes which break the original API for some platforms.
I am not sure how all above is relevant. While Library A is tested on platform P library author is not allowed to make any changes that break existing API. End of story (some exceptions possible, but that is out of scope for this discussion). But! As soon as library A stops testing on platform P it (according to definition above) doesn't work on platform P anymore and author is free to make any changes affecting API specific for that platform, including completely removing it from source code.
Of course that is where the problem arises. But why is it necessary for the author of Library A to do this? What does it cost him to just leave to original code in? The code is already written and tested.
These points are incorrect on many levels IMO. Here just couple of them: 1. The code that is not being tested will stop working sooner or later a. All global changes you apply to your code will affect platform P specific areas either (unless you want to give up global substitution and make routine case by case modification) b. You make changes in areas around that does not work with code in platform P specific sections 2. Source code clarity decreasing exponentially depending number of workarounds applied. I may not be that bad with one. But try to decipher code with 10 different workarounds for different platforms applied within close vicinity. 3. Workaround potentially complicate both your design and implementation, when without particular workaround your solution could be much neater/clearer For example vc 6.5 does not support PS and PO. Now your code has whole extra level of indirection to workaround this. 4. You couldn't introduce in your code any dependencies that does not work on platform P - which would make workaround completely useless.
As an example, the serialization library still works with BCB 5.51 and VC 6.x. Its not that I invest any effort to do this - Its just that it costs me nothing to leave this facility available. A good example is spirit. Spirit has moved on but left sprite 1.6x around - this solution has worked well for me.
Yes, indeed, spirit is a good example. Instead of keeping tons of workarounds in current code they dropped obsolete platforms and moved on. Old version that support these platforms is still available. Funny thing is that the same is true for *all* boost libraries. Whether it's Boost.Test, Boost.Serialization or any other. Boost 1.33 contains version that works on all platforms that we are trying to obsolete. So now, once we stop testing on these platforms I do not see any reason to keep workarounds for them in latest codebase.
I don't dispute that UTF is better. Its just that sometimes I want to make a test and I can't build the boost libraries without taking a big detour into bjam country.
You could always employ included version of UTF, that does not require bjam involvement. Regards, Gennadiy
participants (6)
-
David Abrahams -
Gennadiy Rozental -
Jody Hagins -
Johan Nilsson -
Paul A Bristow -
Robert Ramey