Robert Ramey | 1 Oct 01:05

Re: [archive] -- error compiling CVS Head

Kim Barrett wrote:
>> Brian Schrom wrote:
>>  > There are a few other warning messages if you care to know about
>> them:
>>>
>>>  ./boost/archive/polymorphic_iarchive.hpp:60: warning: 'class
>>>  boost::archive::polymorphic_iarchive' has virtual functions but
>>  > non-virtual destructor
>
> At 9:04 PM -0700 9/29/06, Robert Ramey wrote:
>> This is explained in the code in the cited place.  it turns out
>> that for particular reasons, polymophic archives can't be
>> destroyed through the base class pointer.  For this
>> reason, the destructor is marked "protected"
>
> The explanation in that comment is:
>
>   ... there is no way to forward to the "true" destructor.
>
> I would have thought that simply making the polymorphic_[i,o]archive
> destructors virtual (as was discussed a few weeks ago when I brought
> up the problem of destructor slicing for these classes) would solve
> this problem. What am I overlooking?

Well, that's what I thought.  Then I looked into it.  When I tried it
I got problems due the the fact that the most derived class is
derived from multiple bases. see 
http://www.boost.org/libs/serialization/doc/class_diagram.html
It's easy to see by making the change to "virtual" with your original 
example.
(Continue reading)

Shams | 1 Oct 01:55
Picon
Favicon

Boost logging/xml/sql library

Hi,

Does boost have a official logging/xml/sql library yet?

Thanks
S
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Shams | 1 Oct 01:55
Picon
Favicon

Sandbox cvs nightly

Hi,

I am having problems accessing the sandbox cvs to checkout
the boost cvs tree since I want to try the 1.34 branch.

Is there a zip of the sandbox cvs nightly?

Thanks
S
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Shams | 1 Oct 01:56
Picon
Favicon

MPI, Interprocess and Asio

Hi,

Basically I am looking for a unified library in Boost that will also me to handle and dispatch
events and also allow communication between processes on a local pc and also a remote
pc. Is there such a boost library?

ALSO:

MPI:
Does it support communication from a local pc to a remote pc?
Does it support handling and dispatch of events?
Does it support marshalling/unmarshalling of user-defined types?

Inteprocess:
Does it support communication to a remote pc or is it only for processes running on the local pc?
Does it support handling and dispatch of events?
Does it support marshalling/unmarshalling of user-defined types?

Asio:
Does it support handling and dispatch of events?
Does it support marshalling/unmarshalling of user-defined types?

Thanks
S
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Jeremy Siek | 1 Oct 04:54
Picon

Re: [fusion] Support for classic boost::tuple

Hi Guys,

On Sep 29, 2006, at 10:25 AM, David Abrahams wrote:
> Joel de Guzman <joel <at> boost-consulting.com> writes:
>
>> To me it's like, generalizing that something with a wing,
>> a propeller, and all things that comprise an airplane-- is an
>> airplane. No, not necessarily. The presence of these elements
>> do not complete the picture. It can be, say, *just a collection
>> of parts*. Hence, pair<iterator,iterator> is just a collection
>> of 2 iterators, nothing more.
>
> External, non-intrusive, adaptation of a 3rd party type to make it
> model a particular concept that it doesn't model "inherently" is a
> fundamental generic programming maneuver.  I don't see anything
> particularly wrong with making a pair of iterators model Range.

Yes.

I also agree with Joel's position on airplanes (I misunderstood
what he was saying at first... but yes, a pile of airplane
parts is not an airplane), which is why I've always been in favor
of explicit concept conformance. I see the concept_map declaration
as the final touch that turns the parts into an airplane.

> Jeremy Siek has described cases to me wherein one type can play two
> different roles with the *same* library.  For that you need two
> different concept maps, to map the type into its different roles.
> Thus his recent "scoped concept_map" proposal.

(Continue reading)

Joel de Guzman | 1 Oct 06:31
Picon
Favicon

Re: [fusion] Support for classic boost::tuple

Jeremy Siek wrote:
> Hi Guys,

Hi!

> I think the main thing to take away from this is that scoped
> concept maps are good. They allow you to have it both ways,
> in different parts of your program.
> 
> And yes, we could solve the problem by requiring wrappers,
> but wrapping stuff is a pain.

I'd like to know more about scoped concept maps and how it can
help in this scenario. Any pointers? Links?

Regards,
--

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Jeremy Siek | 1 Oct 06:59
Picon

Re: [fusion] Support for classic boost::tuple

Hi Joel,

On Sep 30, 2006, at 10:31 PM, Joel de Guzman wrote:
> I'd like to know more about scoped concept maps and how it can
> help in this scenario. Any pointers? Links?

Here's the URL for the paper.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2098.pdf

Cheers,
Jeremy

__________________________________
Jeremy Siek <siek <at> cs.colorado.edu>
http://www.cs.colorado.edu/~siek/
Visiting Assistant Professor
Department of Computer Science
University of Colorado at Boulder

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Tomas Pecholt | 1 Oct 10:33
Picon
Favicon

Re: Idea to support unicode strings

Nils Springob wrote:
>> However it isn't basic_string and it means it is isolated from the rest of 
>> standard library. In perfect world I would expect to read/write utf_strings 
>> from std::streams in the same way it is provided for std::string i.e. all the
>> operations like operator>>, getline and so on should be usable on 
>> utf_strings.
> It is always possible to access the basic_string<> data by calling raw()! The
> standard requires character access, which can't be implemented efficiently for
> utf8 and utf16 encoded strings.

I see! I have some tips to your code:

1) insert(size_type, uint32_t &). This doesn't compile without using 
boost. It should be written as insert(size_type, utf32_char &)

2) I have also other compiler problem on line
static const size_type npos = string_type::npos;
With my msvc8 I Am getting error C2057: expected constant expression. I 
don't understand because string_type::npos IS constant expression. Do 
you know what's the problem here?

3) In append, assign and ctor members you should call raw_string.reserve 
before appending characters to be more effective. I know that sometimes 
the exact number of characters (code units) isn't known but it's better 
to reserve at least the minimal count.

4) This is rather cosmetic. I think something like ustring<windows_1252> 
would be both more tabular and more boost-way than current 
windows_1252_string. You can do it easily by uniting all your 
utf*_traits classes into one template and specializing on predefined 
(Continue reading)

Ion GaztaƱaga | 1 Oct 11:58
Picon

Re: MPI, Interprocess and Asio

> Inteprocess:
> Does it support communication to a remote pc or is it only for processes running on the local pc?
No.
> Does it support handling and dispatch of events?
No.
> Does it support marshalling/unmarshalling of user-defined types?
No.

As you can see, Interprocess is pretty limited for your needs :-(

For the moment, Interprocess offers generic wrappers over common 
intra-machine, interprocess mechanisms (shared memory, memory mapped 
files, mutex/condition/message queue...)

Interprocess has not (yet) higher level mechanisms. In theory, one could 
use Interprocess to build more advanced serialization features for 
intra-machine communication.

Regards,

Ion
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Rogier van Dalen | 1 Oct 12:03
Picon

Re: Work that has been done on Unicode

On 9/16/06, loufoque <mathias.gaunard <at> etu.u-bordeaux1.fr> wrote:
>
> Since no one has old code for reuse, I will start to write a few usable
> tools from scratch.
> Note that I am not an Unicode expert nor a C++ guru.
> I am just willing to work in that area and hope my code could be useful
> to some.

I'm sorry to enter the discussion this late, but I was unable to reply
earlier. Graham Barnett and I started on a Unicode library implementation a
year ago but failed to deliver anything. I can offer you two things. One is
some codecvt facets for UTF-8 and UTF-16, slightly faster and more up to
date than I think are in Boost now. I've been thinking how this whole
Unicode thing should proceed recently, so I'll also offer some advice.

Feel free to comment and give ideas, since I think the design is the
> most important thing first, especially for usage with boost, even though
> this topic has already been discussed a few times.
>
> string/wstring is not really suited to contain unicode data, since of
> limitations of char_traits, the basic_string interface, and the
> dependance on locales of the string and wstring types.
> I think it is better to consider the string, char[], wstring and
> wchar_t[] types to be in the system locales and to use a separate type
> for unicode strings.
>
> The aim would then be to provide an abstract unicode string type
> independent from C++ locales on the grapheme clusters level, while also
> giving access to lower levels.
> It would only handle unicode in a generic way at the beginning (no
(Continue reading)


Gmane