- Boost - lists.preview.boost.org

http://www.boost.org/libs/utility/iterator_adaptors.htm
by Neal D. Becker 20 Oct '04

20 Oct '04

Bad link on http://www.boost.org/libs/utility -> iterator_adaptors.htm

1 0

[thread] static builds for bcc32
by Russell Hind 20 Oct '04

20 Oct '04

The latest boost thread builds static libs for bcc32 on win32, but when I link, my app is still looking for the dynamic lib even if I'm set to use static libs? Can the static thread lib be used with bcc32? If not can it be disabled from the build so people aren't tempted to use try and use it? Thanks Russell

2 2

Re: RE: [boost] Library Proposal: database (boost::db)
by JOAQUIN LOPEZ MU?Z 20 Oct '04

20 Oct '04

Hi Brian, ----- Mensaje original ----- De: Brian Braatz <brianb(a)rmtg.com> Fecha: Viernes, Octubre 15, 2004 6:56 pm Asunto: RE: [boost] Library Proposal: database (boost::db) [...] > > I am currently going down this exact path and wanted to share what > I ran > into: > > 1- Boost does not have a 2dim "Table<>" - i.e. a Recordset > 2- Boost.multi_index only works with concrete structures > I would love it if I could use that to make a dynamic Table\ > recordset What do you mean by concrete structures? > 3- I have had to build my own Table<> by internally using > boost.multiindex Do you mean, you have actually built a Table<> class using Boost.MultiIndex? [...] > I believe boost is missing a "recordset" analolgy and I would hope > thatwhatever is created is not "struct only" like > boost.multi_index. (don't > get me wrong I LOVE the multi_index - it just doesn't work > dynamically) Well, in the past I thought about what a dynamic_multi_index_container (with run-time specification of indices) could look like: the implementation internals are not hard to solve with the same framework as Boost.MultiIndex, it is the interface that I don't have a clear idea about. Also, I don't envision a clear usage scenario for this, and there are RTTI-like issues involved as well (what should get<N>() return?) If you'd care to sketch what kind of dynamic multi_index you have in mind (from the user point of view) maybe we can come out with some solid design to implement in future releases of the lib. My intention is to stay away from relational stuff, but I'll go for a dynamic container if it can be made general purpose. On another topic, have you considered Arkadiy's RTL as another source of ideas/synergies? Seems like Arkady sort of diverted to his BOOST_TYPEOF facility, so I don't know what the current status of the lib is. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

8 17

ATTN: Branch for release is scheduled for tonight
by Aleksey Gurtovoy 20 Oct '04

20 Oct '04

I'll post another notice right before the branching, and yet another one when it's complete. -- Aleksey Gurtovoy MetaCommunications Engineering

8 10

Sprit-1.6 and latest boost
by Russell Hind 20 Oct '04

20 Oct '04

Because bcc32 can't deal with spirit-1.8, to use spirit and boost 1.31, I've replaced spirit.hpp and the spirit directory in boost with the 1.6 distribution. This doesn't work with the latest boost code, it looks like the errors are due to the changes mpl that were mentioned. Are there any plans to update spirit 1.6 to work with latest boost so those of us with older compilers can use the two together? Thanks Russell

3 9

Boost 1.31.0 just announced on freshmeat??
by Neal D. Becker 20 Oct '04

20 Oct '04

What's this? http://freshmeat.net/projects/boost/?branch_id=3248&release_id=176309

2 1

RE: [boost] Re: Any interest in adding unicode support to boost?
by Stefan Seefeld 20 Oct '04

20 Oct '04

> From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: October 19, 2004 12:19 > So I always presumed that there was a "unicode" locale that > implemented this > as well all other required information. Now that I think > about it I realize > that it was only a presumption that I never really checked. > Now I wonder > what facitlities do most libraries do provide for unicode > facets. I know > there are ansi functions for translating between multi-byte and wide > character strings. I've used these functions and they did > what I expected > them to do. I presumed they worked in accordance with the currently > selected locale and its related facets. If the > basic_string<wchar_t>::operator<(...) isn't doing "the right > thing" wouldn't > it be just a bug in the implementation of the standard > library rather than a > candidate for a boost library? The unicode standard is rather young, compared to the C++ standard library. It seems the original authors of std::locale and std::basic_string just prepared for some expected flexibility. That doesn't mean all the complexities of today's unicode could fit into that. Just look at the size requirements alone compared to 'wchar_t'... Regards, Stefan

2 1

ATTN: Branch for release completed
by Aleksey Gurtovoy 20 Oct '04

20 Oct '04

Per our standard conventions, the branch tag is "RC_1_32_0", and the main trunk state from which the branch was performed is tagged as "merged_to_RC_1_32_0". Please see http://www.boost.org/more/release_procedures.htm#Developers for a detailed procedure for merging fixes between the branch and the main trunk. To regression runners using "regression.py" driver: to switch the tests to run on the branch, you need to specify the branch name in the script's command line using the '--tag': python regression.py --tag=RC_1_32_0 ... -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

ATTN: Branch for release starts in 10 minutes
by Aleksey Gurtovoy 20 Oct '04

20 Oct '04

Please do not check in anything into the main trunk until further notice. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:Re: [boost] Re: serialization - build shared libs
by Robert Ramey 20 Oct '04

20 Oct '04

Martin Ecker wrote: >Neal Becker wrote: >> Is this perhaps a MS-windows specific problem? I did build a shared lib >> (using scons, I haven't learned jam yet), and AFAICT it is working, on >> Linux. >I'm pretty sure you will also run into problems with shared objects >under Linux. The problem is that certain global variables (e.g. for >the type registry) are defined as static member variables in header >files. Under Windows, if two different DLLs include this header file, >you will get two different copies of that static member variable - one >in each DLL - although there should only be one. Maybe the linker >under Linux is smart enough to resolve such issues. >Have you tried to serialize a class defined in one shared object > (which is registered in the type registry via BOOST_CLASS_EXPORT) from >code in another shared object? That's when you might run into >problems. You definitely will under Windows. >You might also run into problems when you dynamically (i.e. explicitly >in your code via dlopen) load a shared object, which contains classes >that use BOOST_CLASS_EXPORT to register themselves. Again, under >Windows you definitely will. I think there is a little confusion here about what it means to build the serialization library as a Shared Library or DLL. a) if you mean creating libraries which contain exactly the same functionality as libboost_serialiation.lib and libboost_wseralization.lib then there should be no problem as far as I know. Note that you might have problems if you loading/unloading the shared libraries multiple times under program control. I'm not sure. I haven't tested this and have left it for latter. Mainly this is because it should use the ABI autolink to be line with other boost libraries and work better for users. b) if you creating DLLS which instantiate serialization templates for specific classes - then you most likely have problems. There are still some issues pending. Martin has jumped ahead and addressed these issues for his application and most of his additions will likely eventually find their way into the serialization library in some form. Robert Ramey

4 16