- Boost - lists.boost.org

Re: Customer Friendlier Boost Installation
by Peter 26 May '05

26 May '05

[De-Cloak] I have been reading this thread with interest. I thought I would throw my comments in regarding making the installation a little bit easier. Since I also had issues following the instructions. ------------------------------ Message: 7 Date: Wed, 25 May 2005 19:18:46 -0400 From: David Abrahams <dave(a)boost-consulting.com> Subject: [boost] Re: Customer Friendlier Boost Installation To: boost(a)lists.boost.org Message-ID: <ubr6y51yh.fsf(a)boost-consulting.com> Content-Type: text/plain; charset=us-ascii Caleb Epstein <caleb.epstein(a)gmail.com> writes: > Admittedly there should be example command lines for vc-7_1 etc and > not just gcc. Can you suggest where we should show those examples? There are quite a few toolsets! Maybe in the table? -- Dave Abrahams Boost Consulting www.boost-consulting.com ------------------------------ Hmm, is this a case of not seeing the forest because of the trees? Why use static content in this instance at all? If you really want to simplify it why not use some sort of applet? We are programmers after all =p (well I am trying to be) Ie, on the Getting started page have a "Generate Bjam command line" link, on this page the user just selects: * Compiler (Drop down list) * Optional command line switches (Check boxes, with links to what each item does) - Optional path to Python if it is getting built * Path to extracted source of boost (Defaults to c:\Temp\Boost) * Path to compiled version of boost (Defaults to c:\Boost) User clicks on submit and it presents the correct command line command. User cuts and pastes this on a command prompt they hit enter and away they go. Obviously they still need to worry about the environment variables pointing to the compiler and linker and such. For bonus points extend bjam for "bjam -check_Env gcc". This will spit out an OK message listing the env variables it recognises. It will also spit out messages for env variables that it needs but cannot find. Ie, user would run "Bjam - check_env gcc" or "Bjam -check_env CW" and so on. (once again could be part of the generate bjam command line command weblink. This should also be fairly simple to maintain if the applet gets the compilers list (and env variables/or specific exe's it is looking for) from an easily updated list that can be updated as new compiler versions or differences come out. I guess the only thing stopping this is the capabilities of the web server and finding someone who is happy to extend Bjam and write the applet. Then the process for install (with no other modifications would be): 1. Download boost source and extract 2. Download Bjam and extract 3. Run "Bjam - Check_Env" and fix any environment variable issues 4. Generate Bjam command line command from website (or from application?) and run it. 5. Update Include files path and lib file path in your favourite IDE, Make Files, ... Also keep the online documentation for those who are happy to learn about the intricacies of using Bjam. What do you think? Peter. PS I could have actually just walked straight into that tree in the forst and just be seeing stars =p

2 1

RE: [boost] Re: Re: Customer Friendlier Boost Installation
by Brian Braatz 26 May '05

26 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Hendrik Schober > > We are using more than two dozen 3rd-party SDKs and > libraries, both free software and commercial ones, > some across almost half a dozen platforms. We are > using boost since 2001. > > I have never written an MFC app. Not a single one. > (Of a dozen or so developers here, I know one who > has for some toy projects.) > > I am considered the "C++ expert" here and people > often are annoyed that I am forcing them to learn > where 'typename' is required, how template template > parameters are working, and what these 4k error > messages from template meta code mean. :^> (I would > suppose everyone here knows what virtual bases are > for.) > > I have failed to build/install boost without > putting considerably more effort into it than I > needed to put into many other libraries. That is, I > was unable to just download it and check it out. > I think this would be the same with most Win/Mac > developers here. > > > /David Bergman [Brian Braatz Writes:] Yes I understand where you are coming from. And if everything remains the same, Boost will only be available for people capable of doing this. The difficulty here, in my humble opinion, is the simple fact that this list has *extremely* smart people on it. This is great, but a difficulty with *extremely* smart people, is if THEY have an easy time of something they tend to loose sight of that being difficult for someone else. Boosters can choose to expend zero effort on this thinking. All it will mean is much less people will be exposed to boost. (that's too bad) I take my position with great authority and experience. Dare I say that my qualifications in this area far exceed the average booster. I, unlike the major of you, exist as a complete and total idiot. :) "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. " Albert Einstein

1 0

[signals] bug in named_slot_map.hpp ?
by Christophe Prud'homme 26 May '05

26 May '05

Dear boosters, line 103 of /cvsroot/boost/boost/boost/signals/detail/named_slot_map.hpp I believe it should be last_group(last) instead of last_group(group) If it is not the case then the argument last should be commented out to avoid "unused" warnings Best regards C. Index: named_slot_map.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/signals/detail/named_slot_map.hpp,v retrieving revision 1.8 diff -u -r1.8 named_slot_map.hpp --- named_slot_map.hpp 19 Apr 2005 13:50:53 -0000 1.8 +++ named_slot_map.hpp 25 May 2005 10:07:39 -0000 @@ -100,7 +100,7 @@ { init_next_group(); } named_slot_map_iterator(group_iterator group, group_iterator last, slot_pair_iterator slot) : - group(group), last_group(group), slot_(slot), slot_assigned(true) + group(group), last_group(last), slot_(slot), slot_assigned(true) { } void init_next_group() -- MIT Affiliate

3 2

Wave Bjam building problems\Joel de Guzman -did you ever find a solution?
by Brian Braatz 26 May '05

26 May '05

Attempting to BUILD WAVE, I have spent the last few hours (midnight til 5am) searching the archives and trying different things. ( the below email is the exact problem I am having) I have tried both the review version of wave and the one in CVS applied to the 1.32 release. I am using vc7.1 Has anyone found the issue below yet? Many thanks, Brian > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joel de Guzman > Sent: Sunday, February 13, 2005 2:55 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Wave review > > Hartmut Kaiser wrote: > > > > Joel de Guzman wrote: > > > >>+ when using bjam V2, VC7.1 fails with a buffer overrun (compiler > >> problem). No problem with bjam V1. I wanted to try the samples > >> but they don't have a V1 Jamfile, only V2. So I had to switch > >> to using g++ instead. So far so good. > > > > > > Sure they have, haven't they? I'm pretty sure that I've added V1 > Jamfile's. > > But thanks for reporting the V2 problems. Please add the line > > > > : <toolset>vc-7_1:<rtti>off # workaround for compiler bug > > > > to the V2 Jamfile's, without that VC7.1 simply fails - please look at > the V2 > > Jamfile of the library itself for a sample > > ($BOOST_ROOT/libs/wave/build/Jamfile.v2). > > Hi Hartmut, > > VC7.1 still bombs with "buffer overrun". Here's the bjam output: > > C:\dev\boost\libs\wave\build>bjam --v2 > ...found 108 targets... > ...updating 5 targets... > msvc.compile.c++ > ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_gram > mar.obj > instantiate_cpp_grammar.cpp > > call "C:\Program Files\Microsoft Visual Studio .NET > 2003\Vc7\bin\vcvars32.ba > t" > nul > cl /Zm800 -nologo -TP -DBOOST_ALL_NO_LIB=1 /Z7 /Od /Ob0 /EHsc /GR > /MDd -I"C > :\dev\boost" -c > -Fo"..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_ > grammar.obj" "..\src\instantiate_cpp_grammar.cpp" > > ...failed msvc.compile.c++ > ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiat > e_cpp_grammar.obj... > > Did I do something wrong? > > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

misuse of BOOST_NO_INTRINSIC_WCHAR_T in boost/lexical_cast.hpp
by Bronek Kozicki 26 May '05

26 May '05

I believe that there is no reason why BOOST_NO_INTRINSIC_WCHAR_T should be taken into account when defining DISABLE_WIDE_CHAR_SUPPORT at the beginning of lexical_cast.hpp file. The fact that on some platform wchar_t is not builtin type (as it should be) but some typedef (e.g. to short), should not disable wchar_t support in lexical_cast. If platform does not have any support for wchar_t then other macros (e.g. BOOST_NO_STD_WSTRING) will be defined, leading to definition of DISABLE_WIDE_CHAR_SUPPORT. On the other hand, if some platform emulates wchar_t and has decent support for wide strings, wide streams etc, then there is no real reason to disable lexical_cast support for wchar_t on such platform. My coleague was just bitten by this when trying to use lexical_cast on MSVC6: >>>> citation begin Using Microsoft Visual Studio 6 and DinkumWare 2.3 Standard library, I was prevented from using lexical_cast with wide strings. The BOOST_NO_INTRINSIC_WCHAR_T was defined, which prevents the wide character parts of lexical_cast from being compiled. Reading the documentation on BOOST_NO_INTRINSIC_WCHAR_T, it would seem that this was not used appropriately in lexical_cast.hpp By removing the line from lexical_cast.hpp I was able to successfully compile and use lexcical_cast with wstring. Modified lexical_cast.hpp. In this section : #if defined(BOOST_NO_STRINGSTREAM) || \ defined(BOOST_NO_STD_WSTRING) || \ defined(BOOST_NO_STD_LOCALE) || \ defined(BOOST_NO_INTRINSIC_WCHAR_T) removed || \ defined(BOOST_NO_INTRINSIC_WCHAR_T) >>>> citation end I hope that our findings are correct and this can be fixed in release 1.33 . Regards B.

1 0

[iostreams] test/Jamfile.v2
by Vladimir Prus 26 May '05

26 May '05

Hi Jonathan, if I to to libs/iostreams/test and run "cvs log Jamfile.v2", I get this: revision 1.3 date: 2005/05/02 21:20:04; author: turkanis; state: dead; lines: +0 -0 obsolete What does that mean? The log message says next to nothing, and the file removal basically breaks my V2 testing. Not to mention that it took me a while to realize the file is removed in CVS. If you modified Jamfile in some way and did not want to update Jamfile.v2 (and you don't have to, until V2 is official), you could simply drop me a note. Or you could do nothing, since as soon as I'll do another V1 vs. V2 test results comparison I'll see the difference and update Jamfile.v2 myself. Where there any specific reason for removal? - Volodya

2 2

RE: [boost] Customer Friendlier Boost Installation
by Victor A. Wagner Jr. 26 May '05

26 May '05

At 14:30 2005-05-25, Bennett, Patrick wrote: >[delete] >[Bennett, Patrick] Personally, I think the pragma 'link' options are an >absolute disaster for large projects. apparently you've worked with different folks than I. Likely, different kinds of "large projects", too. >It's far, far too easy to end up with lots of libraries getting linked >in with users having no idea how or why they're being linked against. >Since many developers tend to be rather over-eager in #including headers >(bah, just include it all!) sounds like "many developers" need to be re-edcuated. or, perhaps, you need better code walkthroughs. > it's quite common for library x to include >library y which happens to include library z. Users then wonder why >their application is suddenly dependent on libraries they never even >'use'. >Libraries linked against should always be completely explicit IMO yeah, I woulda bought that right up until Microsoft introduced incompatible options in their silly "see 8 things at a time" _GUI_ option settings (property pages). BTW, those are a perfect example of why I dislike GUI for most things, it gets abused horribly (yeah I know, let's just educate people how to write them correctly). > (or >managed by a build system that documents the dependencies). When the >linkage is explicit, the cases where libraries have too many >inter-dependencies (usually incorrect) tend to get fixed pretty quickly. > >Patrick Bennett > > > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

RE: [boost] Customer Friendlier Boost Installation
by Bennett, Patrick 25 May '05

25 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Victor A. Wagner Jr. > Sent: Wednesday, May 25, 2005 3:42 PM > To: boost(a)lists.boost.org; boost(a)lists.boost.org > Subject: Re: [boost] Customer Friendlier Boost Installation > > At 04:13 2005-05-25, Stuart Dootson wrote: > >[deleted] > >One final point - whoever came up with the autolinking scheme (think > >it was John Maddock?) - thank you very much - that makes life *so* > >much easier! > > Yes, it does! > It's a wonder that the committee didn't insist long ago that there be a > directive in the language which would pass a name(file?) to the linker for > processing. It's not like we haven't been fighting this problem since the > late 1970s and it's still a compiler specific thing. Kinda makes you > wonder exactly what things the committee deems important, and why (we > STILL > don't have #pragma once as a "standard" requirement). [Bennett, Patrick] Personally, I think the pragma 'link' options are an absolute disaster for large projects. It's far, far too easy to end up with lots of libraries getting linked in with users having no idea how or why they're being linked against. Since many developers tend to be rather over-eager in #including headers (bah, just include it all!) it's quite common for library x to include library y which happens to include library z. Users then wonder why their application is suddenly dependent on libraries they never even 'use'. Libraries linked against should always be completely explicit IMO (or managed by a build system that documents the dependencies). When the linkage is explicit, the cases where libraries have too many inter-dependencies (usually incorrect) tend to get fixed pretty quickly. Patrick Bennett

1 0

Re: [boost] Re: [repost][serialization] autolinking
by JOAQUIN LOPEZ MU?Z 25 May '05

25 May '05

Hello Robert, ----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Miércoles, Mayo 25, 2005 6:02 pm Asunto: [boost] Re: [repost][serialization] autolinking > Its not a policy that including serialization trigger autolinking. > If it > currently does, it contravenes my intention. When I last looked > at this I > wasn't convinced this was actually happening. I took precautions > to avoid > this and felt it was addressed. Your detailed investigation > motivates me to > look again and more carefully. It is also helpful for showing me > where to > look. I'll do this. Thanks for sheding light on this. > > I've been a little bogged down in this area as now the auto- > linking of DLLS > on vc6 and vc7 stopped working. I'm not sure why this is. Its > only a > problem on with these compilers. I'm still bogged down on this. > Good to know you're on it. If you need to do some fast testing on MSVC++ 6.0, I've got that environment available --just drop me a line and I'll try to lend a hand. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[test] Confusion about BOOST_CHECK_CLOSE
by Jody Hagins 25 May '05

25 May '05

I have re-read everything I can find about BOOST_CHECK_CLOSE, and the doc on floating point comparison algorithms (i.e.close_at_tolerance). However, I am still confused about how to use BOOST_CHECK_CLOSE. Could we have some clear examples of comparisons that pass/fail with different tolerance settings, and some explanation as to how changing the tolerance may affect the test? Currently, I have a test, using BOOST_CHECK_CLOSE() which passes, no matter how big/small I set the tolerance; yet the values are different. Thanks!

3 5