[test] trunk breakage
I went to check the current state of Boost.UUID test results on trunk, and found many tests failing. Here's a typical issue: http://tinyurl.com/y8c9w39 This looks like Boost.Test problem. The testrun is for revision 58533, while last change in boost/test is: r58526 | rogeeff | 2009-12-25 12:20:28 +0300 (Fri, 25 Dec 2009) | 1 line in preparation of production use of test tools So, it seems the test run corresponds to the current state of Boost.Test, and that state is a bit broken. In fact, it looks like a *lot* of tests are failing on trunk, and every test that uses Boost.Test is affected. Boost.Test itself appears to fail to build in may configurations: http://tinyurl.com/ybfkeb2 Gennadiy, I realize this might be a Christmas/New Year break, but at the same time we have a "major code changes" deadline on Jan 4th, and such interruption of test reporting make things hard. Is there any chance you could investigate? If this issue cannot be sorted out quickly, we might have to revert the commit for now. Thanks, Volodya
Vladimir Prus <vladimir <at> codesourcery.com> writes:
I went to check the current state of Boost.UUID test results on trunk, and found many tests failing. Here's a typical issue:
We really should get some kind of email notification about this.
Hmm. Forked fine for me for gcc 3 something and msvc. What is the proper (portable) way to copy va_list? Or at least what is the workaround for this compiler? Gennadiy
Gennadiy Rozental wrote:
Vladimir Prus <vladimir <at> codesourcery.com> writes:
I went to check the current state of Boost.UUID test results on trunk, and found many tests failing. Here's a typical issue:
We really should get some kind of email notification about this.
We used to have *some* nagging script, but it was discontinued. I don't know why.
Hmm. Forked fine for me for gcc 3 something and msvc.
Well, gcc 3 is ancient history.
What is the proper (portable) way to copy va_list?
va_copy, I think. - Volodya
On 12/28/2009 7:03 AM, Gennadiy Rozental wrote:
What is the proper (portable) way to copy va_list? Or at least what is the workaround for this compiler?
There isn't a portable way to copy a va_list. va_copy is not standard. On some systems it's __va_copy, and other systems (e.g. msvc) don't have it at all. Can the code in question be rewritten to not need it? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler <eric <at> boostpro.com> writes:
On 12/28/2009 7:03 AM, Gennadiy Rozental wrote:
What is the proper (portable) way to copy va_list? Or at least what is the workaround for this compiler?
There isn't a portable way to copy a va_list. va_copy is not standard. On some systems it's __va_copy, and other systems (e.g. msvc) don't have it at all. Can the code in question be rewritten to not need it?
I essentially need to do double pas through va_list. I can't reinitialize it cause I am doing this in a function which takes va_list as argument. Can I use va_copy with gcc 4? Gennadiy
On Monday 28 December 2009 03:45:02 pm Gennadiy Rozental wrote:
Eric Niebler <eric <at> boostpro.com> writes:
On 12/28/2009 7:03 AM, Gennadiy Rozental wrote:
What is the proper (portable) way to copy va_list? Or at least what is the workaround for this compiler?
There isn't a portable way to copy a va_list. va_copy is not standard.
It is a C99 macro
On some systems it's __va_copy, and other systems (e.g. msvc) don't have it at all. Can the code in question be rewritten to not need it?
I essentially need to do double pas through va_list. I can't reinitialize it cause I am doing this in a function which takes va_list as argument.
Can I use va_copy with gcc 4?
I think so. I am no expert on this but just had a quick look. va_copy exist on my Ubuntu system. The GCC compiler seems to have had it ac part of C99 support since 4.0. http://gcc.gnu.org/gcc-4.0/c99status.html I just updated my boost trunk working directory and hit a va_list problem in test_tools.ipp . Seems related to this thread, so I replaced the problem assignment expression with a most likely and very naive call to va_copy, and the build at least continued. @@ -198,8 +198,8 @@ format_report( OutStream& os, predicate_result const& pr, unit_test::lazy_ostrea } case CHECK_PRED_WITH_ARGS: { - va_list args_copy = args; - + va_list args_copy; + va_copy(args_copy, args); os << prefix << assertion_descr; // print predicate call description In addition, from the man page: http://man-wiki.net/index.php/3:va_arg It looks like you need to match each va_copy with a va_end to clean up the copy. The implementation code in apache c++ standard library have some attempt to prevent portability issues related to need for va_copy on some platforms. Some useful comments as well: http://svn.apache.org/repos/asf/stdcxx/branches/4.1.3/src/exception.cpp maybe we need macro support for this, could it possibly help with something like: BOOST_VA_COPY(dest, src); // assignment or va_copy use_va_copy(dest); BOOST_VA_COPY_END(dest); // va_end on platforms with va_copy -- Bjørn
Bjørn Roald wrote:
On Monday 28 December 2009 03:45:02 pm Gennadiy Rozental wrote:
Eric Niebler <eric <at> boostpro.com> writes:
On 12/28/2009 7:03 AM, Gennadiy Rozental wrote:
What is the proper (portable) way to copy va_list? Or at least what is the workaround for this compiler?
There isn't a portable way to copy a va_list. va_copy is not standard.
It's in C99, and while not in C++ 2003, it's in C++0x. So it is standard.
It is a C99 macro
and a C++0x macro listed in the standard in section 18.9 Other Runtime Support in the <cstdarg> synopsis.
On some systems it's __va_copy, and other systems (e.g. msvc) don't have it at all. Can the code in question be rewritten to not need it?
I essentially need to do double pas through va_list. I can't reinitialize it cause I am doing this in a function which takes va_list as argument.
Can I use va_copy with gcc 4?
Yes, as long as you have the right version! Originally c++0x didn't have it, but gcc recognized it as a bug and fixed it for 4.3.0. Patrick
On 12/29/2009 1:45 AM, Gennadiy Rozental wrote:
Eric Niebler<eric<at> boostpro.com> writes:
On 12/28/2009 7:03 AM, Gennadiy Rozental wrote:
What is the proper (portable) way to copy va_list? Or at least what is the workaround for this compiler?
There isn't a portable way to copy a va_list. va_copy is not standard. On some systems it's __va_copy, and other systems (e.g. msvc) don't have it at all. Can the code in question be rewritten to not need it?
I essentially need to do double pas through va_list. I can't reinitialize it cause I am doing this in a function which takes va_list as argument.
As others here have pointed out, va_copy is not standard in C++03, which is the language that most (all?) of Boost's users care about. Boost's guidelines are pretty explicit about non-standard code:
Aim for ISO Standard C++. Than means making effective use of the standard features of the language, and avoiding non-standard compiler extensions. It also means using the C++ Standard Library where applicable.
Of course, it's not always possible to avoid non-standard code. But if there's a way to make just a single pass over the va_list and save the results for later re-use, I think that would be preferable. It would certainly address the portability problems this change has caused. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
As others here have pointed out, va_copy is not standard in C++03, which is the language that most (all?) of Boost's users care about. Boost's guidelines are pretty explicit about non-standard code:
I care about c++0x, and it's in that standard.
Aim for ISO Standard C++. Than means making effective use of the standard features of the language, and avoiding non-standard compiler extensions. It also means using the C++ Standard Library where applicable.
It's in there. Basically it's C99 and C++0x, C++03 is based on C89, so doesn't have it. Patrick
Vladimir Prus wrote:
I went to check the current state of Boost.UUID test results on trunk, and found many tests failing. Here's a typical issue:
This looks like Boost.Test problem. The testrun is for revision 58533, while last change in boost/test is:
r58526 | rogeeff | 2009-12-25 12:20:28 +0300 (Fri, 25 Dec 2009) | 1 line in preparation of production use of test tools
So, it seems the test run corresponds to the current state of Boost.Test, and that state is a bit broken. In fact, it looks like a *lot* of tests are failing on trunk, and every test that uses Boost.Test is affected. Boost.Test itself appears to fail to build in may configurations:
Gennadiy, I realize this might be a Christmas/New Year break, but at the same time we have a "major code changes" deadline on Jan 4th, and such interruption of test reporting make things hard. Is there any chance you could investigate? If this issue cannot be sorted out quickly, we might have to revert the commit for now.
This appears to be fixed now. Thanks! - Volodya
Vladimir Prus wrote:
Gennadiy, I realize this might be a Christmas/New Year break, but at the same time we have a "major code changes" deadline on Jan 4th, and such interruption of test reporting make things hard. Is there any chance you could investigate? If this issue cannot be sorted out quickly, we might have to revert the commit for now.
This appears to be fixed now. Thanks!
Unfortunately, not everywhere. MSVC 10 appears to be unhappy: http://tinyurl.com/y9wnv8z What can be done here? Thanks, Volodya
I realise that I've brought this up before, but it seems that there is an opportunity to get another hearing on it. I would like to see trunk testing altered so that for each library it is tested against the release branch of all the other libraries rather than the trunk versions of all the other libraries as happens now. Boost.Test is a perfect example. The author of boost test tests his stuff and checks it into the trunk. This is what he has to do in order to see his stuff tested on all the other platforms he doesn't have.
From time to time this is going to reveal a bug that he didn't know about. So far so good. Except, since all the other libraries are using this component, they show up with bugs also. Now the author of Boost Test is on the hot seat and can't work on his own schedule. The whole boost release is now waiting on him. It's unfair to the author and breaks/suspends trunk testing for all the other libraries which might depend upon Boost Test.
Of course this can occur not only with boost test but any library which is depended upon by others. Also, the fact that a library passes test against the trunk is no guarentee that it will pass when merged into the release. A library might be dependent upon a change which has yet to be merged into release branch. This situation wouldn't occur if each library in the trunk was tested against release. Robert Ramey Vladimir Prus wrote:
Vladimir Prus wrote:
Gennadiy, I realize this might be a Christmas/New Year break, but at the same time we have a "major code changes" deadline on Jan 4th, and such interruption of test reporting make things hard. Is there any chance you could investigate? If this issue cannot be sorted out quickly, we might have to revert the commit for now.
This appears to be fixed now. Thanks!
Unfortunately, not everywhere. MSVC 10 appears to be unhappy:
What can be done here?
Thanks, Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Cross-posting to boost-testing and boost-devel...) On 1/6/2010 7:32 AM, Robert Ramey wrote:
I realise that I've brought this up before, but it seems that there is an opportunity to get another hearing on it.
Thanks for (re-)raising this issue.
I would like to see trunk testing altered so that for each library it is tested against the release branch of all the other libraries rather than the trunk versions of all the other libraries as happens now.
Boost.Test is a perfect example. The author of boost test tests his stuff and checks it into the trunk. This is what he has to do in order to see his stuff tested on all the other platforms he doesn't have. From time to time this is going to reveal a bug that he didn't know about. So far so good. Except, since all the other libraries are using this component, they show up with bugs also. Now the author of Boost Test is on the hot seat and can't work on his own schedule. The whole boost release is now waiting on him. It's unfair to the author and breaks/suspends trunk testing for all the other libraries which might depend upon Boost Test.
Of course this can occur not only with boost test but any library which is depended upon by others.
Right. Boost.Test and Boost.Build are particularly critical.
Also, the fact that a library passes test against the trunk is no guarentee that it will pass when merged into the release. A library might be dependent upon a change which has yet to be merged into release branch.
I've been bitten by this before.
This situation wouldn't occur if each library in the trunk was tested against release.
I agree that the current situation, where we have several single points of failure -- a bug introduced by one component on trunk gumming up the whole works for everyone -- is unsatisfying. Your suggestion sounds reasonable, but I don't know enough about our test infrastructure to see the possible implications for our test runners and for our developers. One concern I have is that most developers will not be running their own tests in this configuration before committing to trunk. I suppose that's not so bad because at worst, their component ends up broken on trunk, but the rest of the world is unaffected because presumably they haven't merged their broken change to release yet (and everybody else is using the last-known-good version of that component from release). Can someone who knows more about our test infrastructure say a bit more about Robert's suggestion? As a half-measure, we could treat Boost.Build and Boost.Test as special and have the test runners use the versions on the release branch. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
(Cross-posting to boost-testing and boost-devel...)
On 1/6/2010 7:32 AM, Robert Ramey wrote:
This situation wouldn't occur if each library in the trunk was tested against release.
I agree that the current situation, where we have several single points of failure -- a bug introduced by one component on trunk gumming up the whole works for everyone -- is unsatisfying. Your suggestion sounds reasonable, but I don't know enough about our test infrastructure to see the possible implications for our test runners and for our developers.
One concern I have is that most developers will not be running their own tests in this configuration before committing to trunk.
It could be arranged that developers would also need to do their local testing in the same library+release configuration.
I suppose that's not so bad because at worst, their component ends up broken on trunk, but the rest of the world is unaffected because presumably they haven't merged their broken change to release yet (and everybody else is using the last-known-good version of that component from release).
Can someone who knows more about our test infrastructure say a bit more about Robert's suggestion? As a half-measure, we could treat Boost.Build and Boost.Test as special and have the test runners use the versions on the release branch.
It's not a half measure, it's actually the ideal testing situation and the current test scripts are somewhat arranged to handle this because it was the ultimate goal of testing when I started rewriting them. And at this time Boost.Build and some of the other infrastructure tools already use specific release only versions for testing. Specifically only the released Boost.Jam is used for testing, and Boost.Build and the release tools could be changed to use specific versions.. As long as they are tagged in SVN. That was the good news. The bad news is that there would need to be additional work to make the test scripts do the same for libraries. Which would not be a big amount of work. The really bad news, is that in order to make such testing possible at the library level would require that the Boost sources are modularized into the library parts so that the scripts can manufacture a complete Boost from the modules. -- -- 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
One concern I have is that most developers will not be running their own tests in this configuration before committing to trunk.
Actually, I've been doing this myself for the past year. And it's made my life much, much easier. Here is what I do: a) I checked out an entire boost release branch to my local machine b) I switch three directories to the trunk. In my case these directories are root/boost/archive, root/boost/serialization, and root/libs/serialization. c) I run tests by invoking ../../../tools/regression/src/library_test.sh from the directory root/libs/serialization/test. d) This generates test result tables in that that directory which I can view with my browser. Note that this script uses the standard bjam testing infrasture which means that thinks like my bjam script changes are also tested. e) after doing d) above maybe 50 times, with msvc 7.1, and msvc 9.0 and gcc 4.3.2 ,I'm thinking it might work so I just check in my changes. Since the three directories are from the trunk, that's where the changes go. f) then I watch the trunk tests until it looks like I didn't break anything. g) Now the tricky part, I have to merge my changes to release branch. There's probably a better way to do this, but here is how I do it. I switch the three directories to the release branch, and merge in in the changes from the trunk and check in the changes. Then I switch the three magic directories back to the trunk. On one occasion I forgot this last step which resulted in an embarassing hickup in accidently checking in changes directly to release and a very inopportune time. This system has worked very well for me
It could be arranged that developers would also need to do their local testing in the same library+release configuration.
I believe that I am currently doing this by using the above procedure.
I suppose that's not so bad because at worst, their component ends up broken on trunk, but the rest of the world is unaffected because presumably they haven't merged their broken change to release yet (and everybody else is using the last-known-good version of that component from release).
Can someone who knows more about our test infrastructure say a bit more about Robert's suggestion? As a half-measure, we could treat Boost.Build and Boost.Test as special and have the test runners use the versions on the release branch.
It's not a half measure, it's actually the ideal testing situation and the current test scripts are somewhat arranged to handle this because it was the ultimate goal of testing when I started rewriting them. And at this time Boost.Build and some of the other infrastructure tools already use specific release only versions for testing. Specifically only the released Boost.Jam is used for testing, and Boost.Build and the release tools could be changed to use specific versions.. As long as they are tagged in SVN. That was the good news.
The bad news is that there would need to be additional work to make the test scripts do the same for libraries. Which would not be a big amount of work.
Note that my procedure above can be used without ANY changes in the test/build infrastructure. Any changes would only effect the "independent" testers.
The really bad news, is that in order to make such testing possible at the library level would require that the Boost sources are modularized into the library parts so that the scripts can manufacture a complete Boost from the modules.
Conceptually, this is what I see happening. a) Tester has trunk and release directories b) Tester updates local copies of both directories from SVN system c) for each library: i) Tester updates local copies of the 2 or three directories ON T ii) switch the relevant directories to the trunk. SVN is very slow with this so probably a trickier method like linking /moving directories would be used. iii) Tests are run on that librarie ii) undo changes in ii above. I realize this would alter the python script, but everything else would stay the same - like the test matrix generation etc. Also the current tools like boost build and all the bjam tools and scripts would be unchanged. Besides the improvements in testing - basically testing one thing at time the tests would run a lot faster. Currently, if library A depends upon library B and library B changes, then library A is tested again. Since library A is based on the assumption that library B is working, This results in either wasted time ( and a lot of it) or spurious test failures for library A - another time waster. The new system would only re-run the testing of library A when changes to library B have been merged to release. Robert Ramey
Gennadiy Rozental wrote:
Robert Ramey <ramey <at> rrsd.com> writes:
The new system would only re-run the testing of library A when changes to library B have been merged to release.
Do you mean we should test against release brunch?
yes
I thought you previously refer to the last release.
If I did - that was a mistake. I mean we should test against the "next release". But..... Actually, from my perspective I view boost as a collection of 'releases" - one for each library. So for a given library - say boost/config.h which the the serialization library depends upon, In my brain the version on the release branch is the "latest release" In fact, when I make projects which use boost - generally small one-off projects - I just use my local boost release branch. So what boost calls the "next release" really is the "latest release" for me. Is everyone following that? So from time to time I update my local copy of the release branch and re-run my tests. If I had nothing else to do, I should probably just re-run all the "out of date" tests on my local environment. Conceptually, it's all relative. What I really need is to be able to build it locally from the release branch. It should be doable (and easy to do), and I think I remember that I have done it, it's just that, like all good programmers, I'm just lazy so for documentation I just use the latest one I can find. Robert Ramey
What I really need is to be able to build it (the documentation) locally from the release branch. It should be doable (and easy to do), and I think I remember that I have done it, it's just that, like all good programmers, I'm just lazy so for documentation I just use the latest one I can find.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
2010/1/7 Robert Ramey <ramey@rrsd.com>:
What I really need is to be able to build it (the documentation) locally from the release branch.
I build the documentation about once a week, more often when releasing. The html files in subversion redirect to the trunk documentation on the web, which is normally pretty good. If you want the release branch documentation you can get it from: http://boost.cowic.de/rc/boost-docs.7z It only contains the doc/html directory so it needs to extracted in place in order to use the images and stylesheets. Something like this should do the trick: 7za -o$BOOST_ROOT/doc -y x boost-docs.7z You need to install 7-zip. The command line version is usually called something like p7zip. Daniel
Actually what I would like to do is the following: a) do an SVN update of my BoostRelease directory. This is what I do now. Works great. So I have on my machine the whole "next release" b) Then I want to be able to invoke something like bjam " build documentation" from the BoostRelease directory. I think I can do this and in fact I think I have done this - I just forgot the procedure. This would give me the following: a) The documentation on my local system for the "next release" b) the build process should much simpler and more up to date then downloading a whole new zip. The build would only have to build those components which have changed. c) I could choose which kind of documentation I wanted html or pdf or (maybe someday) windows help file Robert Ramey Daniel James wrote:
2010/1/7 Robert Ramey <ramey@rrsd.com>:
What I really need is to be able to build it (the documentation) locally from the release branch.
I build the documentation about once a week, more often when releasing. The html files in subversion redirect to the trunk documentation on the web, which is normally pretty good. If you want the release branch documentation you can get it from:
http://boost.cowic.de/rc/boost-docs.7z
It only contains the doc/html directory so it needs to extracted in place in order to use the images and stylesheets. Something like this should do the trick:
7za -o$BOOST_ROOT/doc -y x boost-docs.7z
You need to install 7-zip. The command line version is usually called something like p7zip.
Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Actually what I would like to do is the following:
a) do an SVN update of my BoostRelease directory. This is what I do now. Works great. So I have on my machine the whole "next release"
b) Then I want to be able to invoke something like bjam " build documentation" from the BoostRelease directory. I think I can do this and in fact I think I have done this - I just forgot the procedure.
You are supposed to only need to: cd <boost-root>/doc bjam But this is assuming you have set up all the dependent tools you need to build DocBook docs.
This would give me the following:
a) The documentation on my local system for the "next release"
b) the build process should much simpler and more up to date then downloading a whole new zip. The build would only have to build those components which have changed.
c) I could choose which kind of documentation I wanted html or pdf or (maybe someday) windows help file
Building PDF docs is complicated by needing to have a specific PDF generator software which is commercial, IIRC. I heven't tried building PDF so someone else will have to answer as to how to do it. -- -- 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
Rene Rivera wrote:
c) I could choose which kind of documentation I wanted html or pdf or (maybe someday) windows help file
Building PDF docs is complicated by needing to have a specific PDF generator software which is commercial, IIRC. I heven't tried building PDF so someone else will have to answer as to how to do it.
Technically, you can use Apache FOP. In practice, you might need to use specific version, as all other versions are badly broken. What version exactly is sacred knowledge. I believe John is using XEP Personal for generating release docs on PDF. - Volodya
c) I could choose which kind of documentation I wanted html or pdf or (maybe someday) windows help file
Building PDF docs is complicated by needing to have a specific PDF generator software which is commercial, IIRC. I heven't tried building PDF so someone else will have to answer as to how to do it.
Technically, you can use Apache FOP. In practice, you might need to use specific version, as all other versions are badly broken. What version exactly is sacred knowledge. I believe John is using XEP Personal for generating release docs on PDF.
Nod. XEP Personal edition is highly recommended - modulo the fact that it basically doesn't have any useful error handling :-( Apache FOP will build some of the docs OK, but often completely mangles the pagination in more complex cases, so I've stayed away from it. If you're building docs for a specific library that isn't too large, and you're prepared to manually check the docs to make sure they're OK, then FOP may work for you. Otherwise XEP personal edition is free and a drop in replacement for FOP. Just my 2c.... John.
Vladimir Prus <vladimir <at> codesourcery.com> writes:
Unfortunately, not everywhere. MSVC 10 appears to be unhappy:
What can be done here?
I've checked in another change last night based on "ifdef va_copy". Does it still fail? Gennadiy
On 1/6/2010 8:52 AM, Gennadiy Rozental wrote:
Vladimir Prus<vladimir<at> codesourcery.com> writes:
Unfortunately, not everywhere. MSVC 10 appears to be unhappy:
What can be done here?
I've checked in another change last night based on "ifdef va_copy". Does it still fail?
The attached patch eliminates the need for va_copy. I've verified the patch with msvc-9.0 and gcc-3.4. OK to commit? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler <eric <at> boostpro.com> writes:
The attached patch eliminates the need for va_copy. I've verified the patch with msvc-9.0 and gcc-3.4. OK to commit?
Any reason to prefer this implementation to the one currently in trunk? Do we have any configurations which are failing? Gennadiy
On 1/6/2010 2:38 PM, Gennadiy Rozental wrote:
Any reason to prefer this implementation to the one currently in trunk?
You mean, aside from the fact that it is standard C++03, conforms to Boost's coding guidelines, requires no compiler-specific workarounds, and is unlikely to be broken on platforms that are not being actively tested; whereas the one currently on trunk is none of those things? Not really, no. :-P -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler <eric <at> boostpro.com> writes:
On 1/6/2010 2:38 PM, Gennadiy Rozental wrote:
Any reason to prefer this implementation to the one currently in trunk?
You mean, aside from the fact that it is standard C++03, conforms to Boost's coding guidelines, requires no compiler-specific workarounds, and is unlikely to be broken on platforms that are not being actively tested; whereas the one currently on trunk is none of those things? Not really, no. :-P
Current one does not require compiler specific workarounds, is unlikely to be broken on platforms that are not being actively tested, is cleaner, uses correct tools for the job and conforms to the commonly supported (included next C++) C standard (not sure about what specific coding standard you refer to). Boost.Test does use several interfaces in various places which are not 100% portable according to C++03. Not sure if this innocent macro worth the trouble of maintaining the version which needs to be eventually changed (to use va_copy once it is commonly available). That said, if you feel strongly about this - go ahead and check this in. Gennadiy
On 1/6/2010 6:29 PM, Gennadiy Rozental wrote:
That said, if you feel strongly about this - go ahead and check this in.
Thank you. Committed. -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (9)
-
Bjørn Roald -
Daniel James -
Eric Niebler -
Gennadiy Rozental -
John Maddock -
Patrick Horgan -
Rene Rivera -
Robert Ramey -
Vladimir Prus