headers
Daniel James | 1 Jun 08:58
Picon
Favicon

Re: [config] Deprecate/remove BOOST_NO_INITIALIZER_LISTS

2009/5/29 Beman Dawes <bdawes <at> acm.org>:
> On Thu, May 28, 2009 at 5:20 PM, Daniel James <daniel_james <at> fmail.co.uk> wrote:
>> 2009/5/28 Beman Dawes <bdawes <at> acm.org>:
>>>
>>> Does it matter that some standard libraries might add <initializer_list>
>>> even though the compiler doesn't have support yet?
>>
>> That's already the case for g++ 4.4 when not compiling in c++0x mode.

Sorry, I was being dense and missed your point. I've had a look at the
Visual C++ 10 beta results and that has the situation you describe and
BOOST_NO_INITIALIZER_LISTS is required in that case.

I went ahead and added a check to config/suffix.hpp to set
BOOST_NO_INITIALIZER_LISTS if the headers aren't available:

https://svn.boost.org/trac/boost/changeset/53524/trunk

Daniel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Joel Falcou | 1 Jun 09:43
Picon
Picon
Gravatar

Tickets with patches & mpl::switch_

Here is some ticket that already contains a valid patch and test

* mpl::zip doesn't support metafunction use
https://svn.boost.org/trac/boost/ticket/1992

* Various unused args warning removal in ASIO :
https://svn.boost.org/trac/boost/ticket/1341

* Various gcc warning in numeric
https://svn.boost.org/trac/boost/ticket/1338

Other things. I've submitted some MPL::switch_ correction and addition 
here:

https://svn.boost.org/trac/boost/ticket/2249

Now I'm not sure if the fix is what switch was really about after second 
thoughts. So can soemoen confirm I didn't modified the intended semantic.

--

-- 
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : (+33)1 69 15 66 35

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Joel Falcou | 1 Jun 10:09
Picon
Picon
Gravatar

Re: [Bug Sprint] Ticket #2867 - Adding a get_expected_args member to format

Steven Watanabe wrote:
> I don't like the name.  I would prefer expected_args().
> basic_format already has str (not get_str) and exceptions
> (not get_exceptions).  It has getloc, but there is no _.
> Altogether, I think that expected_args is more consistent.
so I'll regenerate a patch file with :

expected_args()
bound_args()
remaining_args()
as methods names

and appropriate tests

Shoudl this be ok then ?

--

-- 
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : (+33)1 69 15 66 35

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Joel Falcou | 1 Jun 10:10
Picon
Picon
Gravatar

Re: Ticket #637 - Adjusts mpl::pair concept to be compatible with STL pairs

Steven Watanabe wrote:
> It looks like there were patches which got lost when we moved
> to trac/svn.  Anyway,
Oh ?
>
> 1) This is not a widely needed feature.
> 2) Breaking backwards compatibility is out of the question, IMO.
> 3) Preserving backwards compatibility increases the compile time cost 
> of using mpl::pair.
>
So should we close this as wontfix ?

--

-- 
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : (+33)1 69 15 66 35

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |
headers
Joel Falcou | 1 Jun 10:10
Picon
Picon
Gravatar

Re: [Bug Sprint] Ticket #315 (new Feature Requests) - Implement operator[] for Tokenizer

Steven Watanabe wrote:
> tokenizer only has input iterators.  It can't support random access
> efficiently.
Should the ticket be clsoed as 'wontfix' then ?

--

-- 
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : (+33)1 69 15 66 35

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
vicente.botet | 1 Jun 13:02
Picon

Re: [thread] #2739 shouldn't at_thread_exit work onthemainthread?

----- Original Message ----- 
From: "Larry Evans" <cppljevans <at> suddenlink.net>
To: <boost <at> lists.boost.org>
Sent: Sunday, May 31, 2009 7:29 PM
Subject: Re: [boost] [thread] #2739 shouldn't at_thread_exit work onthemainthread?

> On 05/31/09 11:43, vicente.botet wrote:
> [snip]
> >>
> 
> > Thanks Larry for the informations. The fact the program fails let me
> > think that in your platform the bug is not present, as the function
> > is called. To be sure you can remove the abort and check that the
> > file test_ticket_2739.output in the directory
> > bin.v2/libs/thread/test_tickets/test_ticket_2739/ ... contains the
> > line "mycallable2".
> 
> Done.  Results in the attachment.
> 
> >
> > On which platform are you testing?
> 
> Also in attachment after line containing #platform.
> 
> > with which standard Clib?
> 
> My synaptic screen shows:
> 
>   Package: libc6
>            GNU C Library: Shared libraries
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul A. Bristow | 1 Jun 14:29

Re: float_mem_cast

> -----Original Message-----
> From: boost-bounces <at> lists.boost.org [mailto:boost-bounces <at> lists.boost.org]
On
> Behalf Of Steven Watanabe
> Sent: 26 May 2009 21:26
> To: boost <at> lists.boost.org
> Subject: Re: [boost] float_mem_cast
> 
> AMDG
> 
> Steven Ross wrote:
> > My samples use the typecast because it's necessary when sorting on a
> > floating point key that isn't identical to the data type (such as key
plus
> > data sorting); should they use it from the detail namespace?  If that's
> > reasonable, then I'll move it.
> >
> 
> Nevermind what I said.  I didn't understand that users would need to
> call the function.
> Just leave it in spreadsort.hpp.

This would indeed seem to quite widely useful - but if you just leave it
there, how will anyone find it?

It really would be much more useful and discoverable with some docs and
tests however minor, even if it stays in spreadsort.hpp?

Paul
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Flinn | 1 Jun 14:47
Picon

[Serialization]#3118 basic_binary_oarchive.hpp - save_override possible loss of data warnings

I've posted the following ticket in light of the current bug sprint.
-----------
The following save_override overloads cause possible loss of data 
warnings on MSVC8 and XCode3.1.2/gcc4.0.1

   void save_override(const version_type & t, int)
   void save_override(const class_id_type & t, int)
   void save_override(const class_id_reference_type & t, int)

with their respective assignments:

   const unsigned char x = t.t;
   const int_least16_t x = t.t;

While a possible fix would be:

   const unsigned char x = static_cast<unsigned char>(t.t);
   const int_least16_t x = static_cast<int_least16_t>(t.t);

there is still a possibility of a silent loss of data.

We could be safer and use numeric_cast, but that would possibly impact 
code size and performance, and would introduce a library dependency.

Why are the xxx_type strong typedef's using int rather than the smaller 
types that are being serialized?

Any thoughts on the best solution?

Thanks, Jeff
(Continue reading)

Permalink | Reply | 5 comments |
headers
Steven Watanabe | 1 Jun 15:18
Picon

Re: [Bug Sprint] Ticket #315 (new Feature Requests) - Implement operator[] for Tokenizer

AMDG

Joel Falcou wrote:
> Steven Watanabe wrote:
>> tokenizer only has input iterators.  It can't support random access
>> efficiently.
> Should the ticket be clsoed as 'wontfix' then ?

I think so.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Thorsten Ottosen | 1 Jun 15:19

Re: Interest check: container with preallocated buffer

Dmitry Vinogradov skrev:
> Thorsten Ottosen wrote:
>> Dmitry Vinogradov skrev:
>>> Boost.Array offers constant size container with preallocated buffer, 
>>> Boost.Optional provides from zero to one element. There are no STL 
>>> container with preallocated buffer and it seems custom allocator does 
>>> not help to do this with existing containers.
>>>
>>> Does any container exist to offer functionality like Boost.Array but 
>>> allowing to store from 0 to N elements? Is there any interest in such 
>>> container?
>>>
>>> PS. It's similar to fixed_string but as a generic container.
>>
>> Please see
>>
>> http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip
>>
>> http://www.cs.aau.dk/~nesotto/boost/trunk/libs/auto_buffer/doc/html/
> 
> 
> By the way, you can use boost::serialization::array to serialize 
> contained data.
> http://www.boost.org/doc/libs/1_39_0/libs/serialization/doc/wrappers.html#arrays 

No, I was looking for the optimized code without really finding it. Thanks.

> And, is it really needed to serialize capacity? (named "count"?!) I 
> think it's unnecessary thing. Boost.Serialization library does not 
> serialize capacity for standard containers.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane