- Boost - lists.boost.org

Re: [boost] Re: [website] More "improvements"..
by Iain Hanson 05 Apr '05

05 Apr '05

On Tue, 2005-04-05 at 05:12 -0700, Jeff Garland wrote: > On Mon, 04 Apr 2005 23:36:13 -0500, Rene Rivera wrote [snip] > > > > That is an argument which does not apply to my design. I do not > > assume any particular pixel size! I only assume that 10 to 12 words > > per line is the most pleasing line length. That is what centuries of > > research and experimentation have shown. > > Well sorry, but I believe it does. Granted you don't assume a pixel size, but > the layout is clearly frozen. The whole context of Nielson's advice isn't on > that page. No matter what "I" would like to do in terms of line length, > scrolling, etc I can't do it. You've decided the best size for me and I have > to adjust to it whether I like it or not...well, obviously I don't like it ;-) > > Jeff > I whole heartedly agree with Jeff. It is not an issue of good layout or optimal HCI Design but about user choice. If I choose to have a tall thin browser window because I want most of my screen real estate devoted to an IDE that is *my* choice. But I don't want authors to dictate that I have to scroll or have their fixed width on my browser window. BTW the current boost home page also has a fixed minimum width which IMHO is wrong. /ikh

2 1

[in_place_factories] bug report
by David Abrahams 05 Apr '05

05 Apr '05

Is the maintainer of this code listening? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 5

[1.33.0] Release schedule suggestion
by Doug Gregor 05 Apr '05

05 Apr '05

Here's my suggestion for a release schedule. We allow two weeks to get all of the new features and bug-fixes we want into CVS, but still try to keep things sane. Then we fix bugs on the CVS trunk for a week, branch and fix bugs for another week, and then release on May 1. So, the important dates are: April 15 (two weeks from today): feature-freeze on CVS trunk. April 22 (three weeks from today): branch for 1.33.0 May 1 (just over four weeks from today): release 1.33.0 It's aggressive, but we should get this out the door well before summer (when, traditionally, Boost development slows a bit), and we can do it if we focus. If we do well keeping to a tight schedule, perhaps we'll get better about releasing more often and the whole process will become less painful. Doug

7 13

[patch] config docs
by Jonathan Wakely 05 Apr '05

05 Apr '05

The attached patch should be applied to /libs/config/config.htm so the link at the top of the page is consistent with the heading it links to (and so the path is ISO-conforming, since #include <boost\config.hpp> is windows-specific.) regards, jon

2 1

New Secure CRT functions in VC8 for boost::regex
by Bonj 05 Apr '05

05 Apr '05

Hello Is there any plans to, or has it already been done, incorporate the new secure CRT functions into boost::regex, and if so would you like me to do it. Thanks

2 1

[typeof] MSVC-specific implementation added
by Arkadiy Vertleyb 05 Apr '05

05 Apr '05

Hi all, The recently discussed MSVC-specific trick, by Igor Chesnokov, has been added to the BOOST_TYPEOF submission. As a reminder, this implementation compiles much faster, and doesn't require type/template registration. This implementation covers VC6.5/7.0/7.1, but not VC8.0 (where the loophole seems to have been fixed). Please take it in the Boost sandbox file vault, http://boost-sandbox.sourceforge.net/vault/, typeof.zip. Regards, Arkadiy

1 0

[typeof] MSVC-specific implementation added
by Arkadiy Vertleyb 05 Apr '05

05 Apr '05

Hi all, The recently discussed MSVC-specific trick, by Igor Chesnokov, has been added to the BOOST_TYPEOF submission. As a reminder, this implementation compiles much faster, and doesn't require type/template registration. This implementation covers VC6.5/7.0/7.1, but not VC8.0 (where the loophole seems to have been fixed). Please take it in the Boost sandbox file vault, http://boost-sandbox.sourceforge.net/vault/, typeof.zip. Regards, Arkadiy

1 0

Re: [errorinfo] A proposal for better error handling
by Don G 05 Apr '05

05 Apr '05

Jeff, thanks for the info. I've put a copy in the sandbox as well. Don --- Jeff Garland <jeff(a)crystalclearsoftware.com> wrote: > On Sun, 3 Apr 2005 22:44:40 -0700 (PDT), Don G wrote > > I have posted errorinfo.zip on the Yahoo files section for those > > wanting more detail. > > Hi Don - > > We are trying to get away from using Yahoo files since it > requires people to register. Could you put your files up > in the sandbox instead? You will have to register to post > files, but downloaders don't need to register. > The sandbox vault also has other nice features like a > download counter. > > Thx! > > Jeff > > http://boost-sandbox.sourceforge.net/vault/ __________________________________ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com

1 0

function arguments question
by Brock Peabody 05 Apr '05

05 Apr '05

I'm trying to build a library where the user provides a list of functions objects (or plain functions) and I need to extract the argument information from the types of these functions. Am I correct in believing that there is no generic way to do that with function objects? It will be easy to extract the signature from the boost::function objects, but I can't figure out how to extract argument information from function objects created by boost::bind. Is it possible? I guess it wouldn't be too hard to fall back on the old STL style typedefs (first_argument_type, second_argument_type) when possible and require the user to wrap functions with more parameters in a boost::function object otherwise. Would it be desirable to make the proposed function_types library work on function objects whose argument information can be queried, like the result_of template does for return types? Thanks, Brock

1 0

[filesystem] Can't compile on Tru64/gcc
by Markus Schöpflin 05 Apr '05

05 Apr '05

Hello, currently the filesystem library doesn't compile on Tru64 5.1 using gcc-3.4.3 as the compiler. schoepf@area51:~/net/src/boost/boost-HEAD/tools/regression/build> bjam -sTOOLS=gcc ...found 752 targets... ...using 3 temp targets... ...updating 4 targets... ...using <@boost!libs!filesystem!build/libboost_filesystem.a/gcc/release>exception.o... gcc-C++-action ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release/operations_posix_windows.o /net/users/schoepflin/src/boost/boost-HEAD/libs/filesystem/build/../src/operations_posix_windows.cpp:123:39: operator '&&' has no right operand set -e "g++" -c -Wall -ftemplate-depth-255 -DNDEBUG -DNDEBUG -O3 -finline-functions -Wno-inline -I"../../../bin/boost/libs/filesystem/build" -I"/net/users/schoepflin/src/boost/boost-HEAD" -I "/net/users/schoepflin/src/boost/boost-HEAD" -o "../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/release/operations_posix_windows.o" "/net/users/schoepflin/src/boost/boost-HEAD/libs/filesystem/build/../src/operations_posix_windows.cpp" The code in question is: # if defined(_POSIX_THREAD_SAFE_FUNCTIONS) \ && defined(_SC_THREAD_SAFE_FUNCTIONS) \ && _POSIX_THREAD_SAFE_FUNCTIONS >= 0 if ( ::sysconf( _SC_THREAD_SAFE_FUNCTIONS ) >= 0 ) { return ::readdir_r( dirp, entry, result ); } # endif Seems like _POSIX_THREAD_SAFE_FUNCTIONS but doesn't expand to anything. Markus

6 10