May 2005 - Boost - lists.preview.boost.org

Re: Microsoft Pragma(lib) decls (was RE: [boost] Customer Friendlier Boost Installation)
by Victor A. Wagner Jr. 26 May '05

26 May '05

At 11:08 2005-05-26, Bennett, Patrick wrote: > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] > > On Behalf Of Victor A. Wagner Jr. [deleted] > > >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. > >[Bennett, Patrick] Both. :) That doesn't change the fact that having >object files which contain special decorations (inserted by a >vendor-specific #pragma operation) that's twice in 2 days that someone wants to pick on #pragma being "vendor specific" I never suggested either time a literal "#pragma blah" to support this. >which cause unspecified libraries to >'automatically' get linked in is a 'bad thing.' >For one, there's no official way to dump a list of these explicit link >references for any given object file or lib/dll. were the mechanism part of the standard, of course there would be an "official" way to find them >The only way to (partially) know what might get linked in ahead of time >is to go through a dedicated preprocessor step to verify what's being >linked. Of course, this just handles the case where the public >(interface) headers of all libraries referenced contain pragma/lib >entries. It doesn't account for the libraries which defined pragma/lib >entries for other libraries within their implementation headers [so the >pragma node is only in the linkable file for that static lib or dll's >import lib]. Thus, there's no way to 'know' up-front, and in an >easy/fast manner, what libraries will actually be linked in when >building a dll or exe in the presence of these lib pragma's. They're >bad, bad, bad. you assumed things I didn't suggest. >Vendors like Microsoft are certainly welcome to support them, but adding >something like this to the 'standard' would be unacceptable (to me at >least ;>). If tool authors want to provide support for Microsoft's >extension, that's fine too - it should just always be optional. > >When it comes to compiling and linking, I don't want the compiler or >linker including anything more than I explicitly told it to include. > >If you disagree, well, hey, I guess we'll just have to agree to >disagree. no, I'm gonna convince you, lol. >Cheers... >Patrick Bennett Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Microsoft Pragma(lib) decls (was RE: [boost] Customer Friendlier Boost Installation)
by Bennett, Patrick 26 May '05

26 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 10:34 PM > To: boost(a)lists.boost.org > Subject: RE: [boost] Customer Friendlier Boost Installation > > 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. [Bennett, Patrick] Well, a single full build is over 55 GB. To me at least, that's large. :) > >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. [Bennett, Patrick] Both. :) That doesn't change the fact that having object files which contain special decorations (inserted by a vendor-specific #pragma operation) which cause unspecified libraries to 'automatically' get linked in is a 'bad thing.' For one, there's no official way to dump a list of these explicit link references for any given object file or lib/dll. The only way to (partially) know what might get linked in ahead of time is to go through a dedicated preprocessor step to verify what's being linked. Of course, this just handles the case where the public (interface) headers of all libraries referenced contain pragma/lib entries. It doesn't account for the libraries which defined pragma/lib entries for other libraries within their implementation headers [so the pragma node is only in the linkable file for that static lib or dll's import lib]. Thus, there's no way to 'know' up-front, and in an easy/fast manner, what libraries will actually be linked in when building a dll or exe in the presence of these lib pragma's. They're bad, bad, bad. Vendors like Microsoft are certainly welcome to support them, but adding something like this to the 'standard' would be unacceptable (to me at least ;>). If tool authors want to provide support for Microsoft's extension, that's fine too - it should just always be optional. When it comes to compiling and linking, I don't want the compiler or linker including anything more than I explicitly told it to include. If you disagree, well, hey, I guess we'll just have to agree to disagree. Cheers... Patrick Bennett

2 1

RE: [boost] Wave Bjam building problems\Joel de Guzman -did youeverfind a solution?
by Brian Braatz 26 May '05

26 May '05

Hartmut- HI THERE! I must say, I am excited to get the build fun over with so I can use your extremely cool creation. Details: I am using V2. I am NOW much closer. I am compiling but NOT LINKING- I have removed VC70 COMPLETELY from my box and rebuilt boost with 71 (again). That an a using msvc : 7.1. : (path to cl.exe) in the user-config.jam got me to compile. Additionally, I went through and manually removed all of the references in my LIB, INCLUDE and PATH to vc70. This may sound extreme, but it allowed BJAM to compile (Bjam's interaction with those ENV vars is something I don't fully know how it works) I am now trying to build the quick start with the VC71 IDE My current problem is this link error: Linking... LINK : fatal error LNK1104: cannot open file 'libboost_wave-vc7-mt-gd-1_32.lib' Build log was saved at "file://c:\data\Irx\Irx\Arx\Main\Source\Common\Boost\V_1_32\libs\wave\sa mples\quick_start\Debug\BuildLog.htm" WaveQuickStart - 1 error(s), 0 warning(s) The LIB I have available is 'libboost_wave-vc71-mt-gd-1_32.lib not 'libboost_wave-vc7-mt-gd-1_32.lib'. I am not sure WHY the autolinking is trying to hit the vc70 version of the lib since I am using VC71's IDE. (ANYONE HAVE ANY SUGGESTIONS?) Additionally, I will try your suggestion below just to see what happens. THANK YOU Brian Braatz Info and tips for anyone who might find this mail in the archives: 1- Try to build the spirit example FIRST, if you cant build the examples with Spirit, you will not be able to get wave to compile 2- Remove all the references to other compilers in LIB, INCLUDE and PATH, this seemed to clean things up for me (though this SHOULD not be necessary I believe) 3- Maintain patience and perseverance. :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Hartmut Kaiser > Sent: Thursday, May 26, 2005 5:20 AM > To: boost(a)lists.boost.org > Subject: RE: [boost] Wave Bjam building problems\Joel de Guzman -did > youeverfind a solution? > > > Brian, > > IIRC, removing the /GR switch (generate RTTI) should solve the problem. > > But the Wave jamfiles in the Boost CVS:HEAD should work fine, didn't they? > Anyway, I'll retry to compile it today based on the Boost 1.32 release. > > Are you using Build V1 or V2? Joel reported the error went away after > switching to the V1 Jamfiles. > > Regards Hartmut > > > > 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 > > > > > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

3 3

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