Re: [boost] RC_1_30_0: lexical_cast.hpp broken under Mac OS X/gcc3.2.2
From: Beman Dawes [EMAIL PROTECTED] At 07:40 PM 3/12/2003, Ralf W. Grosse-Kunstleve wrote: The recent patch to lexical_cast.hpp causes problems under Mac OS X/gcc 3.2.2. The error message appears at the top of: http://cci.lbl.gov/boost/results/1047512220/dailylog_coral_test .../boost/boost/lexical_cast.hpp:92: `wstring' undeclared in namespace `std' This worked before: http://cci.lbl.gov/boost/results/1047490620/dailylog_coral_test (There are some other unrelated problems on this platform.) The same code also caused problems for Win32 GCC, Intel, and VC++ 6.0. I'veadded a quick fix for lexical_cast.hpp line 92, which cleared a lot of the problems, but not all of them. See http://boost.sourceforge.net/regression-logs/cs-win32-RC_1_30_0-diff.html AFAIK, all the new fails are because of lexical_cast.hpp use. A word on the lexical_cast_test.cpp: everything will be ok if you commented all tests about std::wstring and wchar_t with #ifndef BOOST_NO_STD_WSTRING #endif This new version of lexical_cast seems OK to me, it compiles with both gcc 3.2.2(winxp, mingw 2) and vc 7.1(final beta). ;-) I've already privately emailed Kevlin and Terje, but given time zone differences they may not see the messages right away. This sort of last minute snafu reinforces Ralf's earlier message; it really isn't good software development practice to sit on changes for months, and then try to get them working after a branch for release. -- [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost RPMS (Was: [boost] Outstanding patches and fixes)
David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Doesn't seem to be in the archives. It's from Neal D. Becker 10 Mar 2003. Here is the entire message: I really appreciate the boost rpms that have been made available. I hope we can improve one thing in the upcoming release. rpm -q --requires boost-python-devel boost-devel libpython-devel Unfortuantely, on RedHat it's called python-devel I hope there is some way to fix this. Since I never made a boost RPM, I don't think I'm the guy to address it. I believe that Malte Starostik is the right person for dealing with this issue. I'm pretty sure the different is naming is difference between Mandrake and Redhat, but have no idea how to fix it. And, while we're on it, I think it would be much better if RPM are officially available (i.e from sourceforge download page). Lastly, this issue is not release show-stopper: the *spec file which creates RPM is not in Boost CVS tree. Malte can make the changes when 1.30 is out. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast(Was: FYI)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes Kevlin Henney, the author of lexical_cast, is currently reviewing and brushing up some minor details in the proposal by Terje Slettebo (http://groups.yahoo.com/group/boost/files/lexical_cast_proposition/lexical_ cast_proposition.zip). It should only be a day or two before the CVS will contain the new version. I know that people have been waiting a _really_ long time for this to happen, and as has been stated before, the changes will be part of 1.30.0. To all of you who've been waiting, thanks for your patience! Just to let you know that a new version is now in CVS. However, it appears to break under the regression test. I expected it to break for VC6, but it is apparently failing to compile under VC7 and Intel 7.0... which is more than a little bizarre because I have been using VC7 as the main test compiler and Terje checked it against Intel 7.0. Both compile and run cleanly. If anyone has any inspired guesses as to why the sourceforge build is failing for what appears to be clean and correct code, please let me know! Thanks, Kevlin. Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: possible addition to operators library
Daniel Frey wrote: I'm not 100% sure where the problem is, but the patches are broken for me. Can someone else please confirm this? Maybe it's my mail-program, which I know is broken, but I also tried to get the files from the ASPN archive and that failed, too. Meanwhile, you (Sam) can post them to me as a private email. Please use [EMAIL PROTECTED] for this. And please make sure that you can apply the patch-files you generated. If you need some help with the patch-command, let me know. Back here in the company, I see the patches are correct. I will find a way to forward them and look at them somewhere this evening when I find some time. Sorry for the delay. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Additional mailing lists
Just today, somebody was not able to find a way to subscribe to Boost.Build mailing list ([EMAIL PROTECTED]). I recall it's not the only domain-specific mailing list. There's boost-documentation, there's ml for Spirit, and, IIRC, for Boost.Python. I think it would be good to add information about additional list. I think that index.html will list Domain-specific under Boost (Developers) and Boost Users, and mailing_lists.html will contain all further information. Is this good idea? If so, I'll go ahead and add Boost.Build ml and hopefully others add more. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Additional mailing lists
Vladimir Prus wrote: Just today, somebody was not able to find a way to subscribe to Boost.Build mailing list ([EMAIL PROTECTED]). I recall it's not the only domain-specific mailing list. There's boost-documentation, there's ml for Spirit, and, IIRC, for Boost.Python. I think it would be good to add information about additional list. I think that index.html will list Domain-specific under Boost (Developers) and Boost Users, and mailing_lists.html will contain all further information. Is this good idea? If so, I'll go ahead and add Boost.Build ml and hopefully others add more. A general question: Is it really desirable to have separate mailing lists? Maybe it's just me, but I prefer one mailing list for all discussions. Of course there are discussions I don't follow, but sometimes, you see things in an unrelated thread that can be used for the stuff you are interested in. These synergy-effects are not available when the lists are separated. I don't really bother the higher volume. IMHO two lists should work: One for general discussion and one which only has announcements for those people that are only interested in new stable versions. In the discussion list, prefixes in the subject [spirit], [lambda], [whatever] should work well and even without them a good subject is all I need. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [optional] Possible alignment bug?
Hi there
I found the following lines (57-61) in boost/optional.hpp
union dummy_u
{
char data[ sizeof(T) ];
type_with_alignment ::boost::alignment_ofT::value aligner_;
} dummy_ ;
Not that I understand a lot about alignment issues, but shouldn't
line 60 read:
typename type_with_alignment
::boost::alignment_ofT::value ::type aligner_;
I.e. ::type is missing?
Thanks,
Andreas
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Boost RPMS (Was: [boost] Outstanding patches and fixes)
Vladimir Prus said: David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Doesn't seem to be in the archives. It's from Neal D. Becker 10 Mar 2003. Here is the entire message: I really appreciate the boost rpms that have been made available. I hope we can improve one thing in the upcoming release. rpm -q --requires boost-python-devel boost-devel libpython-devel Unfortuantely, on RedHat it's called python-devel I hope there is some way to fix this. Since I never made a boost RPM, I don't think I'm the guy to address it. I believe that Malte Starostik is the right person for dealing with this issue. I'm pretty sure the different is naming is difference between Mandrake and Redhat, but have no idea how to fix it. And, while we're on it, I think it would be much better if RPM are officially available (i.e from sourceforge download page). Lastly, this issue is not release show-stopper: the *spec file which creates RPM is not in Boost CVS tree. Malte can make the changes when 1.30 is out. Should it be in the tree? (Yes, I know, we need to revitalize the installation discussion and actually get something done on that front. I only ever intended to be a moderator in this case, because of time constraints, but someone needs to take a much more active role in ensuring this area is addressed!) -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: lexical_cast.hpp broken under Mac OS X/gcc3.2.2
Terje Slettebø [EMAIL PROTECTED] writes: From: Terje Slettebø [EMAIL PROTECTED] The new version of lexical_cast is Kevlin's own, which he recently made, not my proposition. I think his version is better, though, as it's much shorter and removes duplication. Just to point out that it's the kind of duplication which is not easily removed; the new version works differently. The proposition used several overloaded function templates for the various special cases, whereas the new version uses a trait technique. Another advantage of the new version is that it doesn't require special workarounds for compilers lacking partial ordering of function templates, which the proposition needed. If these are all implementation details, I guess it would've been better to get your version working and replace the implementation with Kevlin's when it was really ready. If not, I'm not sure what would've been best, but to expect to drop in a whole new implementation the day before a release without causing major problems is clearly unrealistic. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Boost.Regex] [PATCH] Make boost work betterwhenBOOST_NO_WREGEXis defined
The following patch fixes some compilation problems when BOOST_NO_WREGEX is defined (as we do in LyX). These concern OpenBSD (first hunk: when BOOST_NO_WREGEX is defined we end up including wchar) and something I found when trying to compile with lyxstring (no need to define compare_string(wstring,wchar_t*)). Note that the patch is made agaist the LyX sources, not the boost tree. If you want a patch that is directly applyable to boost please contact me and I will create one. ~~~ OK will apply, thanks. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
On Wednesday 12 March 2003 11:50 am, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: * Boost.Python private email Final changes promised for Wednesday night. Those are done. I'd like to watch http://cci.lbl.gov/boost/ go through one more successful test cycle. * [Boost.Python] rpms and small fix for RedHat Awaiting reply. Dave? I'm not sure what this is about. Link? I reported this. A simple workaround, just remove the dependency from the .spec file. IIRC, it was libpython-devel. This is called python-devel on RH8. My suggestion, just remove it from Requires:. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Additional mailing lists
Daniel Frey wrote: A general question: Is it really desirable to have separate mailing lists? Maybe it's just me, but I prefer one mailing list for all discussions. Of course there are discussions I don't follow, but sometimes, you see things in an unrelated thread that can be used for the stuff you are interested in. That's completely the matter of convenience. For example, separate lists seems more convenient for me: I pay more intention to jamboost, and browse main list via NNTP. It's easier to search for messages via gmane, too. Of course, this can be helped with proper filters, folders, etc. But I've some problems with it. I suspect that other people might find it impossible. Note that many posts don't even have correct In-Reply-To header, which breaks threading. I doubt you can expect a lot of technology from all subscribers. These synergy-effects are not available when the lists are separated. Not sure. I have boost list, boost-user list and spirit list in news reader, so I can see what happens in all of them. Likewise, you can subscribe to all lists and store emails in one folder. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Additional mailing lists
Daniel Frey [EMAIL PROTECTED] writes: Vladimir Prus wrote: Just today, somebody was not able to find a way to subscribe to Boost.Build mailing list ([EMAIL PROTECTED]). I recall it's not the only domain-specific mailing list. There's boost-documentation, there's ml for Spirit, and, IIRC, for Boost.Python. I think it would be good to add information about additional list. I think that index.html will list Domain-specific under Boost (Developers) and Boost Users, and mailing_lists.html will contain all further information. Is this good idea? If so, I'll go ahead and add Boost.Build ml and hopefully others add more. It's a good idea to reference the other lists, but I don't love that indexing organization. I would prefer to see a single mailing lists link on the home page which points to the mailing_lists.html page. That would list every mailing list with a short description which could help people understand what they're getting into (i.e. volume, topic, required level of expertise, ...) A general question: Is it really desirable to have separate mailing lists? Maybe it's just me, but I prefer one mailing list for all discussions. We had this discussion long ago. I was stumping for a single list, to keep the cross-pollination of ideas going. IMO we just have too much going on these days IMO to do it all on one list, though. Of course there are discussions I don't follow, but sometimes, you see things in an unrelated thread that can be used for the stuff you are interested in. These synergy-effects are not available when the lists are separated. You can almost get that by reading some of the lists through gmane (nntp) and taking a quick browse every now and then. I don't really bother the higher volume. Well in that case you can just subscribe to all of them, no? IMHO two lists should work: One for general discussion and one which only has announcements for those people that are only interested in new stable versions. In the discussion list, prefixes in the subject [spirit], [lambda], [whatever] should work well and even without them a good subject is all I need. What's the advantage to you over having 4 or 5 subscriptions? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Boost RPMS (Was: [boost] Outstanding patches and fixes)
At 04:02 AM 3/13/2003, Vladimir Prus wrote: I believe that Malte Starostik is the right person for dealing with this issue. I'm pretty sure the different is naming is difference between Mandrake and Redhat, but have no idea how to fix it. And, while we're on it, I think it would be much better if RPM are officially available (i.e from sourceforge download page). Lastly, this issue is not release show-stopper: the *spec file which creates RPM is not in Boost CVS tree. Malte can make the changes when 1.30 is out. Thanks for the explanation, Volodya. I've removed the issue from the Outstanding Issues list. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
At 10:51 AM 3/12/2003, Jaakko Jarvi wrote: On Wed, 12 Mar 2003, Beman Dawes wrote: Here is my list of outstanding patches and fixes. It would be great if we could resolve the bulk of these for 1.30.0. * tuples::apply Did this every get resolved? Aleksey? Jaakko? Aleksey's message on Feb 15 had slipped by :( Looking at his proposed addition, it's really great! IMO C++ should really treat an argument list of a function as a tuple, and Aleksey's apply comes really close to that. However, with this schedule, it is up to Aleksey to decide whether to put it in to 1.30. In any case 1.31 will have bigger tuple changes (Doug's iteration mechanisms), so apply can go into 1.31 if not now. I'll remove it from the Outstanding Issues list for 1.30.0. It is too late to be adding new features to 1.30.0. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
Neal D. Becker [EMAIL PROTECTED] I reported this. A simple workaround, just remove the dependency from the .spec file. IIRC, it was libpython-devel. This is called python-devel on RH8. My suggestion, just remove it from Requires:. Just put a %if block in the .spec. I don't have time, but there should be some rpm macro or other identifying condition on RH8 for the if check below %if some condition identifying redhat Requires: python-devel %else Requires: libpython-devel %endif Joel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
Beman Dawes wrote: * [config] BOOST_DEDUCED_TYPENAME Status currently unknown. John? Aleksey? Dave will take care of it after the release. It's not urgent in any way. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast now broken for MacOS X / darwin toolset
In article [EMAIL PROTECTED], Markus Schöpflin [EMAIL PROTECTED] writes The new lexical_cast (with the latest fixes from beman) now fails with the darwin toolset. The error messages are at http://boost.sourceforge.net/regression-logs/cs-Darwin-RC_1_30_0-links.html#lexi cal_cast_test%20darwin Looks like the compiler has incorrectly deduced that the stream should use char for a std::wstring I/O. Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast(Was: FYI)
In article [EMAIL PROTECTED], Beman Dawes [EMAIL PROTECTED] writes Just to let you know that a new version is now in CVS. However, it appears to break under the regression test. I expected it to break for VC6, but it is apparently failing to compile under VC7 and Intel 7.0... which is more than a little bizarre because I have been using VC7 as the main test compiler and Terje checked it against Intel 7.0. Both compile and run cleanly. VC++7 is not giving trouble with any tests other than lexical_cast_test. On it, the message begins: D:\boost\site-RC_1_30_0\boost\lexical_cast.hpp(142) : error C2065: 'InputStreamable' : undeclared identifier Which of course, is not the case :- The problem does not appear to be with the code. The error messages from various date_time library fails for both Intel and VC++ 6.0 are similar. Here is the Intel message: D:\boost\site-RC_1_30_0\boost/lexical_cast.hpp(137): error: no operator matches these operands operand types are: std::basic_stringstreamwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const std::basic_stringchar, std::char_traitschar, std::allocatorchar return stream input; This suggests that the compiler has deduced wchar_t as being the appropriate type for the stream when it should be char. This relies on rather straightforward full template specialisation, which would seem odd to get wrong. Plus Robin Hu's posting: A word on the lexical_cast_test.cpp: everything will be ok if you commented all tests about std::wstring and wchar_t with #ifndef BOOST_NO_STD_WSTRING #endif Both seem to indicate a wstring/wchar_t problem. The problem is related to wstring and wchar_t, but is not related to compiler/library support for them. Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: lexical_cast.hpp broken under Mac OS X/gcc3.2.2
In message [EMAIL PROTECTED], David Abrahams [EMAIL PROTECTED] writes If these are all implementation details, I guess it would've been better to get your version working and replace the implementation with Kevlin's when it was really ready. If not, I'm not sure what would've been best, but to expect to drop in a whole new implementation the day before a release without causing major problems is clearly unrealistic. In which case the best option is either that the lexical_cast implementation sit out 1.30.0 or that wchar_t support is disabled as that seems to be the source of the fun. From the compiler messages I am seeing, it is uncertain whether Terje's trial implementation would have faired uniformly better. Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
* Regex make boost work better patch from Lars Gullik Bjønnes John Maddock will investigate once new machine working should be done soon. * PRB with type_traits::is_member_function_pointer Would prefer John Maddock or someone else more familiar with type traits regeneration make this change. I think Aleksey wrote that I would prefer him to make the changes as I'm not familiar with the pp lib usage. * [config] BOOST_DEDUCED_TYPENAME Status currently unknown. John? Aleksey? Dave A. introduced the macro I would prefer him to change it as he knows what's required - or have I nissed something? * [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes Awaiting response from John. I'm getting there... John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast(Was: FYI)
Kevlin Henney wrote: In article [EMAIL PROTECTED], Beman Dawes [EMAIL PROTECTED] writes VC++7 is not giving trouble with any tests other than lexical_cast_test. On it, the message begins: D:\boost\site-RC_1_30_0\boost\lexical_cast.hpp(142) : error C2065: 'InputStreamable' : undeclared identifier Which of course, is not the case :- The problem does not appear to be with the code. The code has templatetypename InputStreamable bool operator(InputStreamable output); templatetypename Char, typename Traits, typename Allocator bool operator(std::basic_stringChar, Traits, Allocator output); This seems to require partial ordering. The second overload should probably be replaced with bool operator(std::string output); bool operator(std::wstring output); on deficient compilers. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast now broken for MacOS X / darwin toolset
Kevlin Henney wrote: In article [EMAIL PROTECTED], Markus Schöpflin [EMAIL PROTECTED] writes The new lexical_cast (with the latest fixes from beman) now fails with the darwin toolset. The error messages are at http://boost.sourceforge.net/regression-logs/cs-Darwin-RC_1_30_0-links.html# lexi cal_cast_test%20darwin Looks like the compiler has incorrectly deduced that the stream should use char for a std::wstring I/O. That's because BOOST_NO_STD_WSTRING is set according to the config_info output. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] Possible alignment bug?
Andreas Huber [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi there
I found the following lines (57-61) in boost/optional.hpp
union dummy_u
{
char data[ sizeof(T) ];
type_with_alignment ::boost::alignment_ofT::value aligner_;
} dummy_ ;
Not that I understand a lot about alignment issues, but shouldn't
line 60 read:
typename type_with_alignment
::boost::alignment_ofT::value ::type aligner_;
I.e. ::type is missing?
:-0
You're absolutely right!!!
BTW: I wish I had a platform were misalignment does cause a fault, unlike
Windows.
Fixed.
Thank you!
Fernando Cacciola
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Before we get too carried away...
At 02:24 AM 3/13/2003, Daryle Walker wrote: 4. My testing was with a stock Boost 1.29.0 from a zip file. If the CVS version of Boost already has fixes for CW-DS and/or CWP8.3, I'll switch to that and apologize for wasting everyone's time. Daryle, with all the current focus on 1.30.0, I'm not sure anyone even remembers what worked and what didn't work config-wise for 1.29.0. I know all my responses to you assumed you were working with current CVS state. So, yes, I think you should either switch to the CVS main trunk, branch RC_1_30_0, or just wait until 1.30.0 release. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Outstanding patches and fixes
At 11:52 AM 3/12/2003, Alisdair Meredith wrote: I have also reported and not seen rejected: (easily lost in the volume surrounding a release) [2 Random fixes also required for Graph] === RCS file: /cvsroot/boost/boost/boost/random/uniform_smallint.hpp,v retrieving revision 1.20 diff -r1.20 uniform_smallint.hpp 190a191,192 #elif defined( __BORLANDC__ ) typedef typename detail::uniform_smallint boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false ::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; and === RCS file: /cvsroot/boost/boost/boost/random/uniform_int.hpp,v retrieving revision 1.21 diff -r1.21 uniform_int.hpp 208a209,210 #elif defined( __BORLANDC__ ) typedef typename detail::uniform_int boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false ::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; The __BORLANDC__ test should be replaced by a defect-tagging macro covering Borland's inability to use BOOST_STATIC_CONST constants as template parameters. Alisdair, no one has stepped forward to suggest how to replace the __BORLANDC__ test. Thus you need to figure this out yourself, or contact other Boost developers privately for help with it. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
At 11:42 AM 3/12/2003, Sam Partington wrote: Daniel Frey wrote: Beman Dawes wrote: * Possible addition to operators library from Sam Partington Daniel Frey and Sam discussing changes. We need some discussion of it and I would like to see it in CVS and thus in the regression tests for some time. When Sam started the proposal, the branch for 1.30.0 has already happened (IIRC) and to me, this means bug-fixes only. I don't know when exactly you are planning to release 1.30.0, but if there is enough time and Sam (and others) would like to see the addition ASAP, we can try to push things a bit. Currently, it's an 1.31.0 item as far as I'm concerned. Sam, is this OK for you? Well, I would love to get in 1.30, but I think it may take a little longer that we'd hope. I've just spotted a problem with the private operator int() implementation which breaks almost every single operators test going! I will elaborate when I've done more testing. So yes, unfortunately, I think we're looking at a 1.31 item. Daniel and Sam, I've removed this from the do-list for 1.30.0, but feel free to start making changes to the CVS main trunk any time you want. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Outstanding patches and fixes
* [config] BOOST_DEDUCED_TYPENAME Status currently unknown. John? Aleksey? Dave A. introduced the macro I would prefer him to change it as he knows what's required - or have I nissed something? BTW, I've used BOOST_DEDUCED_TYPENAME in my own code with bcc5.5.1 because this compiler ICEs sometimes if typename is given inside , as in typedef foo typename bar::type the_foo ; but not always, so I'm not sure what to do in general. bcc560 update 4 (bcc564) does not show this problem, though. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
At 07:59 AM 3/13/2003, John Maddock wrote: * Regex make boost work better patch from Lars Gullik Bjønnes John Maddock will investigate once new machine working should be done soon. OK. * PRB with type_traits::is_member_function_pointer Would prefer John Maddock or someone else more familiar with type traits regeneration make this change. I think Aleksey wrote that I would prefer him to make the changes as I'm not familiar with the pp lib usage. Yes, and it has already been done. * [config] BOOST_DEDUCED_TYPENAME Status currently unknown. John? Aleksey? Dave A. introduced the macro I would prefer him to change it as he knows what's required - or have I nissed something? Aleksey says Dave will take care of it after the release. It's not urgent in any way. * [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes Awaiting response from John. I'm getting there... Thanks for the update. We are coming down to the wire. I'll post an update to the list in a few minutes. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Additional mailing lists
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: I don't really bother the higher volume. Well in that case you can just subscribe to all of them, no? What's the advantage to you over having 4 or 5 subscriptions? The point is, that I won't subscribe to a list if it is about a topic I'm not interested in. If OTOH these discussions happens on a list that I have for other reasons, I still see some of these messages and sometimes I can use fragments for my own work. I understand that this only works up to a certain volume, though and boost probably reached the critical mass to justify a split into several lists. Whatever will be decided, I won't have a problem with it :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: lexical_cast.hpp broken under Mac OS X/gcc3.2.2
Kevlin Henney [EMAIL PROTECTED] writes: In which case the best option is either that the lexical_cast implementation sit out 1.30.0 or that wchar_t support is disabled as that seems to be the source of the fun. I have no opinion on which course is best. From the compiler messages I am seeing, it is uncertain whether Terje's trial implementation would have faired uniformly better. Maybe not, but it was ready much sooner. IIUC, we could've had months to discover and fix those problems. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast(Was: FYI)
In article [EMAIL PROTECTED], Peter Dimov [EMAIL PROTECTED] writes VC++7 is not giving trouble with any tests other than lexical_cast_test. On it, the message begins: D:\boost\site-RC_1_30_0\boost\lexical_cast.hpp(142) : error C2065: 'InputStreamable' : undeclared identifier Which of course, is not the case :- The problem does not appear to be with the code. The code has templatetypename InputStreamable bool operator(InputStreamable output); templatetypename Char, typename Traits, typename Allocator bool operator(std::basic_stringChar, Traits, Allocator output); This seems to require partial ordering. The second overload should probably be replaced with bool operator(std::string output); bool operator(std::wstring output); on deficient compilers. Agreed. However, VC7 is not such a compiler, and the error is flagged in a different location. Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast now broken for MacOS X / darwin toolset
In article [EMAIL PROTECTED], Peter Dimov [EMAIL PROTECTED] writes Kevlin Henney wrote: In article [EMAIL PROTECTED], Markus Schöpflin [EMAIL PROTECTED] writes The new lexical_cast (with the latest fixes from beman) now fails with the darwin toolset. The error messages are at http://boost.sourceforge.net/regression-logs/cs-Darwin-RC_1_30_0-links.html# lexi cal_cast_test%20darwin Looks like the compiler has incorrectly deduced that the stream should use char for a std::wstring I/O. That's because BOOST_NO_STD_WSTRING is set according to the config_info output. Is that config info correct? The error message indicated that std::wstring was supported. Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost RPMS (Was: Outstanding patches and fixes)
William E. Kempf wrote: Vladimir Prus said: Lastly, this issue is not release show-stopper: the *spec file which creates RPM is not in Boost CVS tree. Malte can make the changes when 1.30 is out. Should it be in the tree? I don't know. But the way, the same question applies to Debian package (by Steve M. Robbins). I think Malte, Steve and Beman should decide what is most convenient, because it affects them most. (Yes, I know, we need to revitalize the installation discussion and actually get something done on that front. I only ever intended to be a moderator in this case, because of time constraints, but someone needs to take a much more active role in ensuring this area is addressed!) Speaking for myself, I'm primarily interested in two things 1. Making Debian/RPM packages for Boost.Build 2. Making Debian/RPM packages for the project I have at work. Probably the latter can be used for Boost, but I can't promise absolutely anything. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Additional mailing lists
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: Vladimir Prus wrote: Just today, somebody was not able to find a way to subscribe to Boost.Build mailing list ([EMAIL PROTECTED]). I recall it's not the only domain-specific mailing list. There's boost-documentation, there's ml for Spirit, and, IIRC, for Boost.Python. I think it would be good to add information about additional list. I think that index.html will list Domain-specific under Boost (Developers) and Boost Users, and mailing_lists.html will contain all further information. Is this good idea? If so, I'll go ahead and add Boost.Build ml and hopefully others add more. It's a good idea to reference the other lists, but I don't love that indexing organization. I would prefer to see a single mailing lists link on the home page which points to the mailing_lists.html page. That would list every mailing list with a short description which could help people understand what they're getting into (i.e. volume, topic, required level of expertise, ...) It's OK for me either way. I'll wait for other opinions. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Before we get too carried away...
On Thursday, March 13, 2003, at 02:24 AM, Daryle Walker wrote: 3. To the Metrowerks guys on this list, what is the difference between regular CodeWarrior Pro and the Dev Studio I got? The web site is somewhat vague, but I think the only difference is that the number of tools in Dev Studio is a subset of the regular version, with the common tools working exactly the same. Developers Studio is a stripped down version of CodeWarrior Pro. It only has CodeWarrior for Mach-O compilers and linkers for C/C++/Objective C/Objective C++. There is no Java support, no command line tools, no cross compilers, no PEF/CFM compilers. You still need to download the Apple developers Tools to use it. Boost will have to configure itself differently depending upon whether you are using BSD C or MSL C. BSD C is only available under Mach-O. MSL C is available under Mach-O and PEF. MSL C++ will set _MSL_USING_GCC_C or _MSL_USING_MSL_C depending on which C lib is underneath. Alternatively you can test for __MSL__ which is defined as the version number if MSL C has been included, and for __MSL_CPP__ which will be defined if MSL C++ has been included. Both of these latter version numbers will always increase in value with time. -Howard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Additional mailing lists
Daniel Frey [EMAIL PROTECTED] writes: The point is, that I won't subscribe to a list if it is about a topic I'm not interested in. I guess that's a mental battle you'll have to have with yourself, then :-) If OTOH these discussions happens on a list that I have for other reasons, I still see some of these messages and sometimes I can use fragments for my own work. I understand that this only works up to a certain volume, though and boost probably reached the critical mass to justify a split into several lists. Whatever will be decided, I won't have a problem with it :) I think the die is already cast. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Update: Outstanding patches and fixes
Here is the current list: * lexical_cast problems. Hold changes for next release? * Regex make boost work better patch from Lars Gullik Bjønnes John Maddock says he will apply soon. * [status/Jamfile] Jamfile patches for Borland Dave says factor commonality out into template. Too late for 1.30.0? * [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes Awaiting response from John Maddock. * Daniel Frey: provided a fix for some warnings in the type-traits (is_class/is_enum IIRC), John Maddock is aware of it AFAIK. It looks to me like we should hold the lexical_cast changes until the next release. There are really two issues IIUC - some wide-character support problems and VC++ 6.0 support. While the wide-character problems might be possible to resolve quickly, VC++ 6.0 support is going to take some time to work out. Thus I think we should revert the RC_1_30_0 branch and move on. I had hoped to tag for release early today (Thursday). But at the best we won't be ready for that until later today. I'm going to be out-of-town from Friday morning until Sunday afternoon. Thus even if we tag for release later today, there isn't enough time to prepare the release .zip/.gz/.bz files and upload them, update the web site (which can take several hours), etc. Perhaps the best plan is to leave the RC_1_30_0 branch open for changes until Sunday, noon, US Eastern time, and then start the actual release process then. But only seriously important fixes should be committed to RC_1_30_0 between now and then. OTOH, it's very tiresome waiting for these last minute fixes, which don't seem particularly critical anyhow. Assuming lexical_cast is reverted, maybe we should just go ahead with the release now. Thoughts? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast
Kevlin Henney [EMAIL PROTECTED] writes: on deficient compilers. Agreed. However, VC7 is not such a compiler Huh? VC7 not deficient? It certainly doesn't support partial ordering. most-confused-ly y'rs, dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Before we get too carried away...
Howard Hinnant [EMAIL PROTECTED] writes: Developers Studio is a stripped down version of CodeWarrior Pro. It only has CodeWarrior for Mach-O compilers and linkers for C/C++/Objective C/Objective C++. There is no Java support, no command line tools, no cross compilers, ^ This is kind of unfortunate, because it means DevStudio users won't be able to use parts of Boost without inventing appropriate CodeWarrior project files. I understand that Metrowerks has to choose its own marketing trade-offs, but I ask that you consider this factor. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast(Was: FYI)
A very quick, but probably irrelevant, thought from someone who doesn't know the internals of lexical_cast or of the test: Remember that VC7 now supports two different types for wchar_t, depending on the option used when building a module. Could this by any slight chance be causing a problem ? Kevlin Henney wrote: In article [EMAIL PROTECTED], Beman Dawes [EMAIL PROTECTED] writes Just to let you know that a new version is now in CVS. However, it appears to break under the regression test. I expected it to break for VC6, but it is apparently failing to compile under VC7 and Intel 7.0... which is more than a little bizarre because I have been using VC7 as the main test compiler and Terje checked it against Intel 7.0. Both compile and run cleanly. VC++7 is not giving trouble with any tests other than lexical_cast_test. On it, the message begins: D:\boost\site-RC_1_30_0\boost\lexical_cast.hpp(142) : error C2065: 'InputStreamable' : undeclared identifier Which of course, is not the case :- The problem does not appear to be with the code. The error messages from various date_time library fails for both Intel and VC++ 6.0 are similar. Here is the Intel message: D:\boost\site-RC_1_30_0\boost/lexical_cast.hpp(137): error: no operator matches these operands operand types are: std::basic_stringstreamwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const std::basic_stringchar, std::char_traitschar, std::allocatorchar return stream input; This suggests that the compiler has deduced wchar_t as being the appropriate type for the stream when it should be char. This relies on rather straightforward full template specialisation, which would seem odd to get wrong. Plus Robin Hu's posting: A word on the lexical_cast_test.cpp: everything will be ok if you commented all tests about std::wstring and wchar_t with #ifndef BOOST_NO_STD_WSTRING #endif Both seem to indicate a wstring/wchar_t problem. The problem is related to wstring and wchar_t, but is not related to compiler/library support for them. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
Beman Dawes [EMAIL PROTECTED] writes: It looks to me like we should hold the lexical_cast changes until the next release. There are really two issues IIUC - some wide-character support problems and VC++ 6.0 support. While the wide-character problems might be possible to resolve quickly, VC++ 6.0 support is going to take some time to work out. Thus I think we should revert the RC_1_30_0 branch and move on. snip Thoughts? My only concern about this is that IIUC Bjorn has been making lots of promises that the new lexical_cast was going to be in 1.30.0. I don't want to break promises without due consideration. It might be better to wait a few days to clear the issues, if it looks feasible. One other possible approach would be to ship the new code in parallel somehow, but that's pretty ugly. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
Beman Dawes wrote: * Daniel Frey: provided a fix for some warnings in the type-traits (is_class/is_enum IIRC), John Maddock is aware of it AFAIK. Just to remove any doubts: This should not be a show-stopper. The warnings are in there for quite some time and type-traits are to complicated for quick hacks. If John needs more time for it, it's definitely OK for me if it is deferred until the next release. It's IMHO more important to get 1.30.0 out. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast
In article [EMAIL PROTECTED], David Abrahams [EMAIL PROTECTED] writes Kevlin Henney [EMAIL PROTECTED] writes: on deficient compilers. Agreed. However, VC7 is not such a compiler Huh? VC7 not deficient? Perhaps that claim was too broad ;-) It certainly doesn't support partial ordering. True. But the ordering of definitions is such that it does work on VC7 (swap them round and it doesn't work). The error message indicated did not seem to indicate that this was the problem. most-confused-ly y'rs, In which case, it is clear that I must be imagining all the successful compilations and test executions I have been having. My VC7 installation is stable and hasn't been messed about with. Even more-confused-ly yours, Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Outstanding patches and fixes
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: * [config] BOOST_DEDUCED_TYPENAME Status currently unknown. John? Aleksey? Dave A. introduced the macro I would prefer him to change it as he knows what's required - or have I nissed something? BTW, I've used BOOST_DEDUCED_TYPENAME in my own code with bcc5.5.1 because this compiler ICEs sometimes if typename is given inside , as in typedef foo typename bar::type the_foo ; but not always, so I'm not sure what to do in general. I guess that rules out BOOST_MSVC_TYPENAME as a name. Is typename ever required with BCC 5.5.1? With BCC5.5.1 typename is _never required_ AFAIK, but it is with BCC5.6.0(4) Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Outstanding patches and fixes
Fernando Cacciola [EMAIL PROTECTED] writes: With BCC5.5.1 typename is _never required_ AFAIK, but it is with BCC5.6.0(4) I guess in that case BOOST_TYPENAME or BOOST_NO_TYPENAME might be an appropriate name. I'm glad I didn't move on the renaming before you revealed the Borland issue! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
At 10:58 AM 3/13/2003, Daniel Frey wrote: Beman Dawes wrote: * Daniel Frey: provided a fix for some warnings in the type-traits (is_class/is_enum IIRC), John Maddock is aware of it AFAIK. Just to remove any doubts: This should not be a show-stopper. The warnings are in there for quite some time and type-traits are to complicated for quick hacks. If John needs more time for it, it's definitely OK for me if it is deferred until the next release. It's IMHO more important to get 1.30.0 out. OK, I've removed it from the outstanding list. If he gets to it, fine, otherwise it can go in the next release. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
Thomas Witt wrote: Hi, I am biased anyway, but I would vote for reverting the lexical_cast changes in RC_1_30_0. I was just looking at the new lexical_cast implementation and unless I messed up with updating my tree to RC_1_30_0 the documentation needs to be fixed as well. AFAICS the documentation nowhere mentions the change in semantics for string handling. Furthermore the documentation seems to be misleading with respect to the new semantics. Returns the result of streaming arg into a std::stringstream and then out as a Target object. Note that spaces are significant in any conversion and are not skipped. IIUC, this is no longer true for std::basic_string. I cannot resist, I particularly like this one. Where non-stream-based conversions are required, lexical_cast is the wrong tool for the job, and is not special-cased for such scenarios. To me its a clear argument for not changing the std::basic_string semantics. I got the impression that the majority on the list want's the change in string semantics and I am willing to accept this. But I would really like to see the documentation clearly state that strings are handled differently. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
Thomas Witt [EMAIL PROTECTED] writes: I got the impression that the majority on the list want's the change in string semantics and I am willing to accept this. But I would really like to see the documentation clearly state that strings are handled differently. I agree, and would go further. Without up-to-date docs the change is out-of-the-question, IMO. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
--- Beman Dawes [EMAIL PROTECTED] wrote: OTOH, it's very tiresome waiting for these last minute fixes, which don't seem particularly critical anyhow. Assuming lexical_cast is reverted, maybe we should just go ahead with the release now. Whatever you do, please give me (another...) realistic chance to check that the candidate is healthy on all platforms. IFO stronlgy favor undoing the changes to lexical_cast.hpp. Waiting with the actual release until Sunday sounds good to me. But I very much hope that everybody refrains from experimenting on the RC_1_30_0 branch. Ralf __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
--- David Abrahams [EMAIL PROTECTED] wrote: My only concern about this is that IIUC Bjorn has been making lots of promises that the new lexical_cast was going to be in 1.30.0. I don't want to break promises without due consideration. To me branching for release also is a promise: relative stability. If you miss the train do you expect it to come back just for you? Would that make sense in the grand scheme of things? Ralf __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] lexical_cast fixes
Kevlin has done an update that incorporates the overloading fix and is less permissive about which platforms will get wide character support. The Win32 tests are now looking as good or better than with the old 1.29.0 version. See http://boost.sourceforge.net/regression-logs/cs-win32-RC_1_30_0-diff.html So now we'll wait until some of the other platform tests get updated. If their results looks as good then the update can stay in 1.30.0. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Before we get too carried away...
On Thursday, March 13, 2003, at 10:34 AM, David Abrahams wrote: Howard Hinnant [EMAIL PROTECTED] writes: Developers Studio is a stripped down version of CodeWarrior Pro. It only has CodeWarrior for Mach-O compilers and linkers for C/C++/Objective C/Objective C++. There is no Java support, no command line tools, no cross compilers, ^ This is kind of unfortunate, because it means DevStudio users won't be able to use parts of Boost without inventing appropriate CodeWarrior project files. I understand that Metrowerks has to choose its own marketing trade-offs, but I ask that you consider this factor. I appreciate the suggestion. Please understand that those who make these decisions don't read the boost list. I can forward your suggestion. But it will have a significantly greater impact if those who make the decisions hear it straight from customers. This is easy to do at: http://www.metrowerks.com/mw/about/contact.htm -Howard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] lexical_cast fixes
Beman Dawes [EMAIL PROTECTED] writes: So now we'll wait until some of the other platform tests get updated. If their results looks as good then the update can stay in 1.30.0. Without a documentation update?!? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
Beman Dawes [EMAIL PROTECTED] writes: At 12:45 PM 3/13/2003, David Abrahams wrote: Thomas Witt [EMAIL PROTECTED] writes: I got the impression that the majority on the list want's the change in string semantics and I am willing to accept this. But I would really like to see the documentation clearly state that strings are handled differently. I agree, and would go further. Without up-to-date docs the change is out-of-the-question, IMO. Kevlin did update the docs; the complaint is that the updates are unclear. I thought the complaint was that the current state is plain inaccurate in major ways. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: I/O library formal review
The quick answer to my questions using a naive test of a for loop of 10 (times in seconds) cout 'x'; cout '\n'; cout newl; cout endl; cout \n; MSVC 7.0 debug mode 'strict' to console: char time 5.898 '\n' time 3.275 newl time 3.545 endl time 3.395 C string \n time 3.345 to a txt file: char time 0.11 '\n' time 0.12 newl time 0.18 endl time 0.651 flush cost? C string \n time 0.13 release mode 'strict' to console: char time 5.888 '\n' time 3.074 newl time 3.075 endl time 3.004 C string \n time 3.115 to a txt file: char time 0.09 '\n' time 0.1 newl time 0.12 endl time 0.661flush cost? C string \n time 0.1 I am left with a suspicion that fools step in where angels fear to tread, but ... this suggests that there is a modest but useful advantage to avoiding the flushing cost by encouraging newl instead of endl. This does not apply to console if, as is the case here, each char outputs is flushed. (The longer time for cout char does not seem to be an artefact). Paul -Original Message- From: Paul A. Bristow [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 11:36 AM To: Boost mailing list Subject: RE: [boost] Re: I/O library formal review -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gennadiy Rozental Sent: Tuesday, March 11, 2003 10:15 PM To: [EMAIL PROTECTED] Subject: [boost] Re: I/O library formal review * newl needs a bit more rationale. How is cout newl different from cout '\n'? How is it better? Maybe newl does not reset the manipulators? If it true it should be spelled out explicitly. In any case I also like to see an example where newl is preferable to '\n'. Is there a speed advantage - because flush is quite expensive? We should have some evidence for this? Paul ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Kevlin did update the docs; the complaint is that the updates are unclear. I thought the complaint was that the current state is plain inaccurate in major ways. The complaint is that the doc's are misleading, at times straddling the border to being outright wrong. See my citations. It was a tough day today, maybe I am just mad. Could somebody please check whether the docs explain the special behaviour for std::basic_string. If they do I'll stop complaining. If they don't they need to be fixed before release. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast fixes
In article [EMAIL PROTECTED], David Abrahams [EMAIL PROTECTED] writes Beman Dawes [EMAIL PROTECTED] writes: So now we'll wait until some of the other platform tests get updated. If their results looks as good then the update can stay in 1.30.0. Without a documentation update?!? The documentation is the same as it was yesterday. The change was in the implementation and not the interface, which is what is documented. Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
Thomas Witt [EMAIL PROTECTED] writes: David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Kevlin did update the docs; the complaint is that the updates are unclear. I thought the complaint was that the current state is plain inaccurate in major ways. The complaint is that the doc's are misleading, at times straddling the border to being outright wrong. See my citations. It was a tough day today, maybe I am just mad. Could somebody please check whether the docs explain the special behaviour for std::basic_string. If they do I'll stop complaining. If they don't they need to be fixed before release. I can't tell: Note that spaces are significant in any conversion and are not skipped is not meaningful to me. I had the impression that the semantics with respect to embedded space handling had changed so that lexical_caststd::string(foo bar) == std::string(foo bar), but that's the only phrase which even comes close to being applicable in the last year of changes to the docs. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] lexical_cast and boost-1.30
Here is the current list: It looks to me like we should hold the lexical_cast changes until the next release. There are really two issues IIUC - some wide-character support problems and VC++ 6.0 support. While the wide-character problems might be possible to resolve quickly, VC++ 6.0 support is going to take some time to work out. Thus I think we should revert the RC_1_30_0 branch and move on. I am biased anyway, but I would vote for reverting the lexical_cast changes in RC_1_30_0. I would vote to fix lexical_cast before release. I've already been waiting months for 1.30 to have the space problem fixed, I really don't want to wait months more. I know that I'm not the only one with this problem also. Frankly, wchar_t support in lexical_cast isn't as important as fixing the space problem, I'd rather the fix go in even if it regresses in this area -- unless someone pipes up to say they are actually USING wchar_t and lexical_cast on a compiler that won't grok the new code. And if there is such a person, then I'd appreciate the ugly hack of including both versions with #ifdefs. [In general, I do agree with the fellow who recommended bug-fixes-only after the branch. I consider the lexical_cast space problem a serious bug, that's all. ;-] Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast
From: Kevlin Henney [EMAIL PROTECTED] In article [EMAIL PROTECTED], David Abrahams [EMAIL PROTECTED] writes Kevlin Henney [EMAIL PROTECTED] writes: on deficient compilers. Agreed. However, VC7 is not such a compiler Huh? VC7 not deficient? Perhaps that claim was too broad ;-) It certainly doesn't support partial ordering. True. But the ordering of definitions is such that it does work on VC7 (swap them round and it doesn't work). The error message indicated did not seem to indicate that this was the problem. most-confused-ly y'rs, In which case, it is clear that I must be imagining all the successful compilations and test executions I have been having. No, you didn't; I got problem-free compilation of that version on VC7, too. Let's just say that VC7's support for partial ordering is, uhm, partial. ;) From an earlier posting: From the compiler messages I am seeing, it is uncertain whether Terje's trial implementation would have faired uniformly better. Since MSVC 6/7, and Borland C++, doesn't handle partial ordering of function templates well, or not at all, I also had to avoid that for those platforms, by having workaround code for them in my proposition. Just like you've had to avoid partial ordering in your latest version, to make it work properly on MSVC, especially version 6. My proposition would likely have fared better than the first update that was committed, due to the mentioned workaround code it had. However, since then, you've got the new version to work with tests passing on all the compilers on the Win32 tests, so it's at least as portable. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Bidirectionnal map
Beman Dawes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] You would have to go back and find the specific license. No way to tell without seeing the exact license covering the code you started with. Copyright (c) 1994 Hewlett-Packard Company Copyright (c) 1996,1997 Silicon Graphics Computer Systems, Inc. Copyright (c) 1997 Moscow Center for SPARC Technology Copyright (c) 1999 Boris Fomitchev Copyright (c) 2001-2002 David B. Held This material is provided as is, with absolutely no warranty expressed or implied. Any use is at your own risk. Permission to use or copy this software for any purpose is hereby granted without fee, provided the above notices are retained on all copies. Permission to modify the code and to distribute modified code is granted, provided the above notices are retained, and a notice that the code was modified is included with the above copyright notice. All I added was the little copyright line with my name. I'm not sure how that works, though. I was just playing monkey-see, monkey-do. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] CVS main line is all messed up
for the past 3 hours I've been getting: ...failed updating 300 targets... ...skipped 117 targets... ...updated 8 targets... when trying to make the latest CVS update: date /T update.log time /t update.log cvs -z3 update -A -P -d update.log bjam -sTOOLS=vc7 msvc vc71 bjam.log mgrep target bjam.log this also, of course, prevents me from chasing down why I got 12 missing functions when I tried to build simple_ls.cpp. I started to take a look at what's causing the errors, but... I think I'll let the folks who checked in something they shouldn't find them. One of the errors I see insists that filesystem isn't part of namespace boost. Details on request...the build log is quite large. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Review: variant iterators
Rozental, Gennadiy wrote: 1. I found this name a bit misleading. At first I though that it some king of iteration through variant types Uhm, what would be a better name? 2. From quick glance on your code it seems that visit_helper class unnessesarilly parameterized with T0 and T1. It's far from perfect, and I'll consider this one; however, I don't want to go too deep into such issues as long as the variant library interface is not (?) stable. - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Doing sets with the MPL
Hi,
In some of my MPL-using code I needed set-based functionality. So I wrote a
function that does an insertion into an ordered list of constants. However,
it seems that if I compare a list created from a bunch of constants to an
explicit list, they don't end up the same. I've attached the example code
below.
I'm wondering whether somebody can spot any errors in my code, or that I'm
probably confused about the way types propagate through meta-functions
again.
All help is greatly appreciated.
Sincerely,
Jaap Suter
template class N, class L
struct add_to_sorted_list
{
typedef typename mpl::if_
typename mpl::contains L, N ::type,
L,
typename mpl::insert L,
typename mpl::lower_bound L,
N,
mpl::less mpl::_, mpl::_
::type,
N
::type
::type type;
};
typedef mpl::list_c int, 0, 1, 2, 3 list0;
typedef mpl::list_c int, 0, 1, 3 list1;
typedef add_to_sorted_list
mpl::integral_c int, 2 ,
list1,
::type result;
BOOST_STATIC_ASSERT( is_same list0, result ::value ); // THIS FAILS;
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
