[1.33.1] Goals, tasks, schedule
Certain issues that cropped up with the 1.33.0 release that necessitate a 1.33.1 release. 1.33.1 will be for safe bug fixes to 1.33.0 only, focusing on critical issues such as the already-addressed shared_ptr problem. There are two major issues we need to resolve before we can roll a release candidate of 1.33.1: - Include order dependencies in the Serialization library - GCC 4.0 type_info problems This is also a good opportunity to work in support for three compilers that are performing reasonably well now and should be supported by Boost: - Tru64 CXX - Apple GCC 4.0 on Tiger - Intel 9.0 on Linux We'll prepare the release candidate from the RC_1_33_0 branch, hopefully within a week or so, depending on the resolution of these issues. The release candidates will be available for much longer before the final release, up to a month or so, to root out any remaining issues. No new libraries or features may be added to the RC_1_33_0 branch; they should go onto the main branch, and we'll merge fixes from RC_1_33_0 back once we've released. Doug
This probably doesn't belong to boost mailing list, but since boost has a lot of support in preprocessor, there may be someone who can answer my question. I'm using general 'C' compiler in this project (hence I cannot use boost headers). I want to write a macro as follows; #define ERR(x, y) \ { \ # ifndef ERR##x \ # define ERR##x \ # else \ # error ERR##x already defined\ # endif y = x; \ } When I compile, I get the error saying, error C2162: expected macro formal parameter on all the preprocessor lines inside the #define ERR(...) body. The reason I want to do something like this is to have some unique numbers in the code (like locators. Don't want to use __FILE__ and __LINE__ for security reasons) and want to capture duplicates at compiletime. For example if I say in the code, int err = 10000 in one file, I don't want any other engineer to use 10000 in the anywhere else in the code. So I started writing something like int err = ERR(10000) but got into several compiler problems as I mentioned above. Any suggeations? Thanks, --Suman
The body of a macro cannot contain preprocessor directives. Any time the compiler sees a # as the first non whitespace character it says - this is a preprocessor directive and not part of the macro body. Even if the # got bound up in the macro body text, it would not have a newline preceding it as the backslashes just "join" all the text together without any newlines in between, i.e. the compiler does not look for preprocessor directives when rescanning substituted text. Maybe you could encode __LINE__ instead of reporting it directly and also define a unique constant for each source file as well - instead of using the filename. Your method wouldn't provide uniqueness across multiple translation units anyway. Graeme
As mentioned by Graeme, macros cannot expand to preprocessing directives. Or, more precisely, they cannot expand to anything that will be _interpreted_ as preprocessing directives. In the above, because it is a function-like macro, the # token acts as a stringizing operator. However, applying the stringizing operator to anything but a formal argument is ill-formed. Regards, Paul Mensonides
On Aug 30, 2005, at 6:04 AM, Neal Becker wrote:
See: http://aspn.activestate.com/ASPN/Mail/Message/boost/2786704 Doug
Neal Becker wrote:
Yes: http://zigzag.cs.msu.su/~ghost/rtti-4.0 Just run the "build.sh" script and then try running "main" binary. - Volodya
Those should be targets for the final 1.33.1 release, but I'm not sure if we really need them for the *first* Beta release. I'd like to add a few more issues to be resolved for the final 1.33.1 as well: Config: support for EVC++ (http://lists.boost.org/Archives/boost/2005/07/90101.php), I've applied this to the main HEAD branch apparently without ill effect, so I think it's safe for the release branch also. Ulrich first raised this months ago, so I feel we owe him this one! Regex: I'd like to try and fix lookbehind assertions (http://lists.boost.org/boost-users/2005/07/12655.php), it means adding at least one new API in order to fix this though, so it's borderline new feature. Threads: deadlocks in readwrite_mutex (http://lists.boost.org/Archives/boost/2005/08/92307.php), assuming there isn't a mistake in the test case then we could really use someone to look into this as a priority, a threading lib that deadlocks is not too good an advert! Threads: memory leak, this need documenting and explaining if it isn't already, and if we can't get rid of it (I suspect we can't). MPL: the has_xxx boilerplate is failing with vacpp (http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output/...) which causes all the regex tests to fail with that compiler. I'm pretty sure this *did* work at one point, and the error messages seem rather strange, so any ideas on this one would be welcome. Whew, That's all for now, John.
John Maddock ha escrito:
The problem arose when upgrading the compiler, see http://lists.boost.org/Archives/boost/2005/08/91742.php
and the error messages seem rather strange, so any ideas on this one would be welcome.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
The problem arose when upgrading the compiler, see
Thanks for the pointer, that is indeed strange, not to mention annoying :-( John.
The problem arose when upgrading the compiler, see
I'm attaching an obvious and wholly untested (except with gcc) fix, can someone try this workaround with vacpp? Thanks, John.
On Tue, 30 Aug 2005 14:16:57 +0100, John Maddock wrote
I assume you are going to limit this to config and not include changes to other impacted libraries like date-time? While the changes were apparently trivial they impact alot of files and I wonder if it's really worth it given that we don't have a regression platform for this compiler. Jeff
"Bronek Kozicki" <brok@rubikon.pl> writes:
No, RC_1_33_0 is the right branch; it's just that the branch is misnamed. I knew this would happen eventually. We've never done a point release before so it never became an issue. Shoulda probably been RC_1_33 or something. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
We've never done a point release before so it never became an issue.
Yes, let's forget about 1.30.1 ;-) Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
participants (14)
-
Aleksey Gurtovoy -
Bronek Kozicki -
David Abrahams -
Doug Gregor -
Graeme Prentice -
Jeff Garland -
Joaquín Mª López Muñoz -
John Maddock -
Martin Wille -
Neal Becker -
Paul Mensonides -
Stefan Seefeld -
Suman Cherukuri -
Vladimir Prus