- Boost - lists.boost.org

build / install in 1.32
by John Maddock 07 Nov '04

07 Nov '04

Should the following messages be generated during an install? They are rather alarming IMO, there are a huge number of them, and I predict will generate queries along the lines of "is this right, did my build succeed?" HardLink stage\lib\boost_thread-vc71-mt.lib Could Not Find c:\data\boost\release\boost\stage\lib\boost_thread-vc71-mt.lib HardLink stage\lib\libboost_thread-vc71-mt-sgd.lib Could Not Find c:\data\boost\release\boost\stage\lib\libboost_thread-vc71-mt-sgd.lib HardLink stage\lib\libboost_thread-vc71-mt-s.lib Could Not Find c:\data\boost\release\boost\stage\lib\libboost_thread-vc71-mt-s.lib Thanks, John.

3 2

Getting the reference out of boost::any
by Mikhail Glushenkov 06 Nov '04

06 Nov '04

I became interested in subj and quickly found a discussion on boost mailing list dated Jan 2003 (http://lists.boost.org/MailArchives/boost/msg42284.php) where the majority seemed to agree on changing current semantics of boost::any_cast to allow getting the reference to held object. However, these changes never made it to the CVS. Was it by intent or was this issue banally forgotten?

1 0

Unicode strings update
by Erik Wien 06 Nov '04

06 Nov '04

Hi. I just thought I would post a little update on what's happpening with the Unicode library I started a thread about a little while ago. (I apologize for not replying as much as I should have done in that thread, but I have been completely buried in work lately, and simply haven't had the time. =\ ) My college (HiG) has now basically approved the project as a bachelors thesis (at least for the time being), and it is looking very likely that we will go through with it. There's one little snag though. HiG would like to have one person from the boost community functioning as a "contact person" for the project. I'm not sure exactly what kind of workload that imply for such a person (I will try to find out very soon), but I am fairly certain it will just be a matter of answering a few e-mails from them from time to time. After all, the main development will be done in collaboration with the community as a whole, and not that single person. What I basically want to know is, would anyone out there like to take on that resposibillity? I don't think this is an absolute requirement for final approval, but it sure would help! =) Let me just finish off by thanking for all comments you guys made in my first thread. I'm in the process of compiling a list of all the things you pointed out there, and I will most certainly take everything said into concideration when the development (hopefully) gets on the way. As always... Any comments are welcome! ;) Regards - Erik

7 12

usage of uniform_int
by Masaki Nomura 06 Nov '04

06 Nov '04

Dear all: Would anyone let me know the usage of the boost::uniform_int combined with the one argument operator() of the variate_generator? I'd like to change the maximum parameter of the distribution at every step. #include <iostream> #include <boost/random.hpp> int main( void ) { boost::variate_generator< boost::mt19937, boost::uniform_int< std::size_t > > gen( boost::mt19937( 3 ), boost::uniform_int< std::size_t >() ); for ( std::size_t i(1); i < 100; ++i ) std::cout << gen( i ) << std::endl; return 0; } The gcc aborted the compile with the following errors: /usr/include/boost/random/variate_generator.hpp: In member function `typename Distribution::result_type boost::variate_generator<Engine, Distribution>::operator()(T) [with T = unsigned int, Engine = boost::mt19937, Distribution = boost::uniform_int<size_t>]': uniform_int.cpp:9: instantiated from here /usr/include/boost/random/variate_generator.hpp:107: error: no match for call to `(boost::uniform_int<size_t>) ( boost::random::detail::pass_through_engine<boost::random::detail::pass_through_engine<boost::mt19937> >&, unsigned int&)' With regards, Masaki Nomura

2 2

Re: [boost] Re: 1.32 documentation issue
by JOAQUIN LOPEZ MU?Z 06 Nov '04

06 Nov '04

----- Mensaje original ----- De: Beman Dawes <bdawes(a)acm.org> Fecha: Martes, Noviembre 2, 2004 9:06 pm Asunto: Re: [boost] Re: 1.32 documentation issue > At 12:39 PM 11/2/2004, Robert Ramey wrote: > > >Actually after poking around in other pages - specifically the > spirit >documentation I find that its not uncommon for links to > point to > >www.boost.org rather than have a relative path that would keep > the > session > >in the same documentation tree. This would seem to conflict > with the > idea > >that boost should be usable as a CDROM distribution. > > > >I don't know if there's time for this but the inspect should be > enhanced > to > >check for this and all the offending global links should be > altered to > >relative ones. > > We tried to do that at one time, but gave up because it is a bit > tricky. > Some absolute www.boost.org references are correct, such as to the > LICENSE > file, so it isn't as simple as just searching for "www.boost.org/" > in .htm? > files. > > I've just taken a look (using grep) at the CVS RC (not the > tarball) and it > seems that while the problem does happen, particularly in spirit > and graph > libraries, it isn't really horrible. > > I'd say we can wait until after the release ships, then see if we > can come > up with some logic that doesn't generate a lot of false positives. > Automatic detection aside, would it be possible to fix the offending links manually before release? Maybe it's not that straightforward, if those links are generated from BoostBook source. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[1.32 release] Runaway compile process in regression tests
by Zak Kipling 06 Nov '04

06 Nov '04

I'm running the regression tests for the 1.32 draft tarballs -- no problems on x86/debian, but on an amd64/gentoo (gcc 3.3.4 prerelease) machine it still hasn't completed after nearly two days, apparently due to a runaway cc1plus process, compiling numeric/conversion/test/converter_test.cpp. This appears to be due to a bug in gcc -- see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300. I should have a patch to gcc tested soon; I don't think it's a problem with Boost as such, although there might be a workaround for current compilers (I don't think I understand the numeric converters library well enough to be sure). Zak.

2 1

Compile fix for Boost.Test for aCC on HP-UX
by Ferdinand Prantl 05 Nov '04

05 Nov '04

Hello, you can find a small fix for boost/test/detail/basic_cstring/basic_cstring.hpp attached and a dirty workaround for a compiler bug in aCC for boost/test/unit_test_suite.hpp. As of the latter; the compiler seems to get confused by equal names in different namespaces and classes; renaming Impl helps or making the previous structure friend helps too (this I chose to minimize the change). Ferda HP-UX B.11.11 U 9000/800 aCC: HP ANSI C++ B3910B A.03.37 <<basic_cstring.hpp.diff>>

2 1

[Config] proposal of new macro, BOOST_DECL :follow up for boost::noncopyable & vc7.1 & dll
by Francis ANDRE 05 Nov '04

05 Nov '04

Hi Developers When using the boost.thread package as a dll under vc7.1, one gets for each reference of boost::mutex the C4275 warning for the inherited noncopyable class (in fact 5 times, one for mutex, one for timed_mutex, one for try_mutex, one for thread, and one for thread_group!!) c:\boost\include\boost-1_32\boost\thread\mutex.hpp(34) : warning C4275: non - DLL-interface 'boost::noncopyable_::noncopyable' used as base for DLL-interface 'boost::mutex' In order to avoid such warning, it would be nice to redefine -- again(sic) -- the BOOST_DECL macro and put it as a decorator for all dependent classes used by the boost libraries that could be generated as a dll.(thread, regex, filesystem, and so on). With the empty string as default value in boost/config.hpp, it would the responsability of each boost libraries to setup BOOST_DECL to the correct value when using it as a dll. Cheers Francis ANDRE

5 7

GUI Library Proposal for a Proposal
by Brian Braatz 05 Nov '04

05 Nov '04

(was RE: [boost] Re: GUI library - something to think about) Both http://www.torjo.com/win32gui/save_dlg.html and http://www.litwindow.com/Library/Documentation/documentation.html are extremely interesting. What I see (just after taking a peek at both): Win32Gui Interesting design No macros Looks tied to Win32Gui LitWindow Also interesting design Does have macros Also sits on top of WxWidgets, but it looks like the WxWidgets layer could be abstracted out. I propose that BOTH authors collaborate (on this list) to achieve the following: * Combination of the best of both frameworks * Can sit on WxWidgets OR can have a win32 and xwindows underlying implementation * This would allow it to be in boost, but also be LEAN and not need another framework I believe that if you took both of your thoughts, and accomplished the above bullet points, not only would it be good for boost, but it would really mean that boost had something that was much cooler than what I see available from other (ahem) vendors. I.e. instead of making a boost library that just "provides a layer" over GUI things, this combination would be actually moving the technology forward. (they don't call it "boost" for nothing :) ) I ask that both of you gentlemen seriously consider my proposal. I would also offer to help in any way that I can as I think you both have some really groundbreaking ideas in the realm of GUI frameworks. (fingers crossed) Brian :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of John Torjo > Sent: Wednesday, November 03, 2004 9:14 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: GUI library - something to think about > > > struct SomeSettings { > > int m_aMember; > > SomeOtherStruct m_struct; > > vector<string> m_strings; > > }; > > > > the neccessary data adapter definition which you must include in a > > source file looks like this > > > > IMPLEMENT_CONTAINER_ADAPTER(vector<string>) > > > > BEGIN_DATA_ADAPTER(SomeSettings) > > PROP(m_aMember) > > PROP(m_struct) > > PROP(m_strings) > > END_DATA_ADAPTER() > > > > > Sure thing, but how about *true* bindings? > http://www.torjo.com/win32gui/save_dlg.html > > (if you download the code, you'll find quite a few examples: > examples/smart_dialogs) > > Note that you can add correspondences directly to your data + validation > code (no macros whatsoever). > >

10 11

RE: [boost] Re: GUI Library Proposal for a Proposal
by Brian Braatz 05 Nov '04

05 Nov '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jared McIntyre > Sent: Friday, November 05, 2004 7:28 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: GUI Library Proposal for a Proposal > > >Edward Diener wrote: > >> > >>No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go > >>there, or have anything to do with supporting any other GUI > implementation. > >> > > > >Also, wxWindows is a huge library. If we were to introduce > >something in boost, I'd very much like it to be as small and light > >weight (as win32gui is supposed to be), not a collection of > >multi-megabyte dlls required, just to wrap win32 or what ever the > >underlying library is. > > > >If people want more powerful components, they can be added > >afterwards, but the underlying library around core OS controls > >should be as small as possible. > > > >Thanks > > > >Russell > > Honestly, I don't buy into the idea of cross platform GUI at all. I > have lots of reasons born out of experience with them that I won't > get into here, but in general, I find they are nice for the > developer, but poor for the user. I would much rather write my > backend code in a cross-platform language, and hook it up to a GUI > designed for each platform I support. That is why, at first glance > anyway, I like the idea behind the Lit Window design. Most of the > backend is GUI neutral, allowing you to do more work in your > cross-platform code. In theory, this could be used to simplify the > platform specific GUI code that needs to be written. I'd much rather > see C++ go a route of making it easier to develop for different GUI > libraries than to actually develop one of its own (since I don't > think it would get much use anyway). > > JJared McIntyre > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost [Brian Braatz] " I'd much rather > see C++ go a route of making it easier to develop for different GUI > libraries than to actually develop one of its own (since I don't > think it would get much use anyway)." Yes, and that is what my original mail that started this thread suggested :) Where it gets confusing to talk about, is that by doing that, you end up doing a "little bit" of the work that "already exists" elsewhere. That is ok.

1 0