- Boost - lists.boost.org

Re: [boost] [release] Bad merge?
by Reece Dunn 28 Jun '06

28 Jun '06

Rene Rivera wrote: > Reece Dunn wrote: > > > > I'm afraid I don't know how to fix this one as I don't understand how > > CVS branches work. I understand the concept of branches and > > merging from a Perforce PoV, but not how that relates to CVS. > > Hm, how to best explain this... Classically, as in revision control > lingo, CVS uses inplace branches. Think of them as having all those > Perforce branches overlaid onto the same file tree. And what you use to > differentiate them, instead of the repository paths in Perforce, is a > virtual keyed path on the version number. Thank you for the detailed explanation. > > I am currently using TortoiseCVS. Do you know if WinCVS is easier > > to use for branching? > > TCVS is marginally more convenient to use. WinCVS, if you have the > Python and TCL extensions enabled, has some nifty commands available. As > for branching the are both about the same. That is they are both equally > restricted by the terrible branching model of CVS :-) OK the fixing it > part with TCVS as that's what I use most of the time (I also use WinCVS > and the CLI). Thanks again for helping me understand this. > PS. Make use of the revision graph display. It helps to understand what > it's really doing under the hood. And of course as Dave mentioned, learn > the CLI tools also. I always try to understand the CLI tools, but I need to understand the concepts first. Your reply has helped me to understand the way that branches work in CVS and has given me a starting point to help with the CVS documentation. Thanks, - Reece _________________________________________________________________ Try Live.com: where your online world comes together - with news, sports, weather, and much more. http://www.live.com/getstarted

2 1

[system] - Grouping discussions (please read)
by Gennaro Prota 28 Jun '06

28 Jun '06

Hi guys, I'm happy to see that the system facility is getting much feedback from several developers. I would recommend however to group all of our remarks under the same thread, which will make life easier for all of us, including most importantly Beman. PS: Hoping I haven't unlawfully worn the moderator's hat here :) --Gennaro.

1 0

Re: [boost] Supressing warnings
by Martin Bonner 28 Jun '06

28 Jun '06

----Original Message---- From: Reece Dunn > void foo( int bar ){} // unreferenced parameter > void foo( int bar ){ bar; } // no warning! Or even better: void foo( int /*bar*/ ) {} // no warning. > bool foo(){ BOOL bar = TRUE; return bar; } // performance warning > bool foo(){ BOOL bar = TRUE; return bar != FALSE; } // no warning I think that transform is a BAD idea. If people start thinking it is OK to compare boolean-like values against literals, they soon start comparing against TRUE as well as FALSE. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

Re: [boost] Thanks Bjam!
by Reece Dunn 28 Jun '06

28 Jun '06

Andy Little wrote: > "David Abrahams" wrote > > "Andy Little"writes: > > > >> Whenever I invoke bjam I get this first: > >> > >> warning: Python location is not configured > >> warning: the Boost.Python library won't be built > >> Building Boost.Regex with the optional Unicode/ICU support disabled. > >> Please refer to the Boost.Regex documentation for more information > >> (and if you don't know what ICU is then you probably don't need it). > >> > >> Thanks Bjam. You know what? I really don't care! > > > > Got anything constructive to say about it? > > Nope. Just more ranting I'm afraid... > > The fact is that all my tests and examples seem to build fine without me having > done anything about configuring Python or Regex, so these messages are > completely bogus AFAICS. What purpose do they serve? What you may not realise is that Boost.IOStreams will generate warnings about mizzing ZLib and BZip2 libraries. However, for these you need to say: bjam --v2 --debug-configuration It would make sense to do the same for the Python and RegEx libraries. That way, if you run into build/configuration problems, you will be warned about the missing libraries and if you don't care (like Andy :)), then you won't see anything. It will also make things cleaner. That way, everyone is happy :). - Reece _________________________________________________________________ Try Live.com - your fast, personalized homepage with all the things you care about in one place. http://www.live.com/getstarted

2 1

bjam install issues (and fix!)
by Reece Dunn 28 Jun '06

28 Jun '06

Hi all, Sorry for the repeated noise on this one, but I haven't had a reply (apart from Hartmut who pointed me in the right direction to the solution). At the moment, there are two problems with: bjam install msvc-7.1 link=static,shared (1) The <rtti> feature isn't included in <tag> names, so Boost.Wave/FileSystem produce duplicate target errors. (2) The <link>shared feature generates a LIB target that clashes with the LIB from <link>static, again producing duplicate target errors. This needs fixing for 1.34.0! I have attached a patch that fixes the problem, but I would like to know that this is the right fix and that I haven't missed anything obvious. For issue (1), I am adding an 'r' for rtti=on. Given: bjam install msvc-7.1 rtti=on this will produce: boost_filesystem-vc7_1-gd-r.lib boost_filesystem-vc7_1-gd.lib boost_wave-vc7_1-gd.lib For issue (2) I am now adding an 'i' instead of '-imp' for the import LIB files. Given: bjam install msvc-7.1 link=static,shared this will produce: boost_filesystem-vc7_1-gd-r.lib boost_filesystem-vc7_1-gd-ir.lib boost_filesystem-vc7_1-gd-r.dll - Reece _________________________________________________________________ Try Live.com: where your online world comes together - with news, sports, weather, and much more. http://www.live.com/getstarted

1 0

[system] - system_error::what()
by Oliver.Kowalke＠qimonda.com 28 Jun '06

28 Jun '06

Hello, in the current implementation system_error::what() returns something like runtime_error::what() + " : " + system_message(); which results in some ugly ' : no such device' format if I only want a system specific error description returned. I suggest that system_error gets two ctors: system_error( error_code const&); // what() returns only system specific error description provided by system_message system_error( error_code const&, std::string const& desc) // what() returns desc which could be formated by the user as needed const char * system_error::what() const throw() { return runtime_error::what(); } regards, Oliver

1 0

Re: [boost] Supressing warnings
by Reece Dunn 28 Jun '06

28 Jun '06

Oliver Kullman wrote: > > NOTE: Instead of disabling the warnings, you can remove the warning by > > updating the code. For example: > > > > void foo( int bar ){} // unreferenced parameter > > void foo( int bar ){ bar; } // no warning! > > > > this is FALSE: No - it is one way to prevent the bug. > void foo(int){} This doesn't work if you have: /** @brief something * @param bar Oh dear, this is missing! */ void foo( int bar ){} Either not specifying bar or commenting it out will mean that Doxygen will not be able to identify the bar parameter. > > bool foo(){ BOOL bar = TRUE; return bar; } // performance warning > > bool foo(){ BOOL bar = TRUE; return bar != FALSE; } // no warning > > this is a perversion. Agreed. I was giving *examples* of *possible ways* of removing the warnings without using pragmas. I wasn't suggesting that this should be the way the code is written! > > class foo > > { > > bar & m_bar; > > foo( bar & b ): m_bar( b ){} > > > > // disable the no default compiler assignment operator warning: > > inline foo & operator=( const foo & ); > > }; > > again this is a perversion: the C++ should follow the LANGUAGE, and the special > handling of the *special member function* is important part of C++. No. You miss the issue here. The problem is that m_bar is a *reference* and *you can't assign a reference*! > In the above example, first "inline" shouldn't be there, and then it's not > about warnings, but about semantics: either we want the implicitely declared > copy assignment operator, and then we *must not* add that line, or we don't > want it, and then we *must* add the line --- there is no choice. The inline *should* be there. This is like deriving from boost::noncopyable which uses the above trick to prevent copying. In this case, I don't think it is possible to use noncopyable as this is about the default assignment operator in foo. By adding the line: inline foo & operator=( const foo & ); I am telling the compiler that I am providing my own assignment operator, so the compiler doesn't automatically generate one. This is the classic way to implement non-copyable behaviour (as well as providing a similar copy constructor). In fact, this highlights a potential issue in the code. The standard says that you can't change a reference, so the assignment operator will copy values not what is being pointed to. This can lead to a bug if you assign one foo to another. In this case the warning has identified a potential problem and the above will identify any places where that problem is manifest. Also, explicitly disabling the variable not used warning will mask this bug: class foo { int bar; foo( int bar ): bar( bar ) {} // oops! This will be picked up by warnings! }; - Reece _________________________________________________________________ Try Live.com: where your online world comes together - with news, sports, weather, and much more. http://www.live.com/getstarted

4 3

Re: [boost] [release] Bad merge?
by Reece Dunn 28 Jun '06

28 Jun '06

Rene Rivera wrote: > Something strange is going on, or went on, recently with CVS. The > Jamfile.v2 on the RC_1_34_0 branch is no longer in a branch, and has the > wrong version number on it (1.35.0 instead of 1.34.0). This is easy > enough to fix, but I'm afraid this might be an indication of an errant > merge of code, or of the branch somehow getting reset/moved. That was most likely me :(. I fixed an issue with the serialization library aliases and then updated the 1.34 branch with the fix, hence the 1.35 version. Looking at Jamfile.v2 from the web CVS viewer, I can see Jamfile.v2 when selecting the RC_1_34_0 sticky tag. I don't understand what you mean by "no longer in a branch" because I can see it there. How do I fix that problem? There should be an e-mail sent to boost-cvs and boost-build about the submitted changes, but I am getting a Mail Delivery Failure for my sourceforge user e-mail. I have a support request about this that the sourceforge team is looking into. > Whomever has been doing recent checkins to CVS please verify your > changes on the branch and fix any problems ASAP. I'm afraid I don't know how to fix this one as I don't understand how CVS branches work. I understand the concept of branches and merging from a Perforce PoV, but not how that relates to CVS. I am currently using TortoiseCVS. Do you know if WinCVS is easier to use for branching? - Reece _________________________________________________________________ Try Live.com - your fast, personalized homepage with all the things you care about in one place. http://www.live.com/getstarted

2 1

QuickBook extra Keywords
by Andy Little 27 Jun '06

27 Jun '06

Would it be presumptious to add "typeof", "decltype", "concept","where" etc to the QuickBook keywords list? regards Andy Little

3 3

GIL - formal review
by Lubomir Bourdev 27 Jun '06

27 Jun '06

I am not sure what the next step is regarding GIL - we haven't yet heard much suggestions for GIL improvements. If the moderators think it is not premature, we would like to request a formal review. I prefer that it be scheduled after July 25, as I will be on vacation until then. Thanks, Lubomir

1 0