Paolo Carlini | 1 Jun 13:00 2008
Picon

[Patch] Two changes to the C++0x vector

Hi,

the below solves two issues in the C++0x vector, a small optimization 
issue pointed out by Herve (thanks again!) and a correctness issue (a 
risk of memory leak) noticed while dealing with the former.

Tested x86_64-linux, will go ahead tomorrow for mainline and, because of 
the correctness bit, probably will go in 4_3-branch too.

Paolo.

/////////////////////
2008-06-02  Paolo Carlini  <paolo.carlini <at> oracle.com>

	* include/bits/vector.tcc (vector<>::_M_insert_aux): In C++0x mode,
	avoid a memory leak if the first __uninitialized_move_a throws.
	(vector<>::_M_fill_insert): Do not always copy to __x_copy, similarly
	to _M_insert_aux.
	* testsuite/23_containers/vector/modifiers/moveable.cc: Adjust.
	* testsuite/23_containers/vector/resize/moveable.cc: Likewise.

Index: include/bits/vector.tcc
===================================================================
--- include/bits/vector.tcc	(revision 136250)
+++ include/bits/vector.tcc	(working copy)
 <at>  <at>  -1,6 +1,6  <at>  <at> 
(Continue reading)

Sebastian Redl | 1 Jun 14:19 2008
Picon

[Patch RFC] N2179: Exception Propagation

Hi,

The attached patch modifies libsupc++ to implement std::exception_ptr. 
It should apply cleanly to the trunk as of two days ago. No regressions 
on x86-64 and i686 targets. A small number of test cases for 
exception_ptr is included.

A write-up of what I changed is here:
http://www.codesourcery.com/archives/cxx-abi-dev/msg01924.html
This is also the formal description of the necessary extension of the 
C++ ABI.

The following backward compatibility statements apply:

1) Code that links dynamically against libsupc++ should continue to work 
without changes.

2) Object files generated by different compiler versions can be linked 
together freely. (Barring restrictions from other places.)

3) Code that links statically against libsupc++ need only be relinked to 
use the new library.

4) Code consisting of multiple dynamic modules, some of which are 
statically linked against libsupc++, needs to be consistent in the 
version it links to. Having both an old and a new version of libsupc++ 
in a single loaded process is not supported; throwing exceptions between 
modules will lead to crashes and even silent misbehavior.

It is my understanding that throwing exceptions between modules that 
(Continue reading)

Benjamin Kosnik | 4 Jun 17:57 2008
Picon

[v3] allocator typedef


This changes the typedef used to refer to the allocator parameter in
ext/pb_ds code to "allocator_type," from "allocator." This change
brings the policy-based data structure code into alignment with
existing conventions for such containers as vector, list, etc. 

More importantly, this is the first step in allowing some of the pb_ds
testing framework (random-based eh testing) to work with C++ and C++0x
containers. 

tested x86_64/linux
tested x86_64/linux performance

-benjamin
2008-06-04  Benjamin Kosnik  <bkoz <at> redhat.com>

	* include/ext/pb_ds/assoc_container.hpp: Change allocator typedef
	to allocator_type, as per existing conventions.	
	* include/ext/pb_ds/detail/binomial_heap_base_/
	binomial_heap_base_.hpp: Same.
	* include/ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp: Same.
	* include/ext/pb_ds/detail/pat_trie_/pat_trie_.hpp: Same.
	* include/ext/pb_ds/detail/bin_search_tree_/bin_search_tree_.hpp: Same.
	* include/ext/pb_ds/detail/gp_hash_table_map_/gp_ht_map_.hpp: Same.
	* include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp: Same.
	* include/ext/pb_ds/detail/trie_policy/trie_policy_base.hpp: Same.
	* include/ext/pb_ds/detail/pairing_heap_/pairing_heap_.hpp: Same.
	* include/ext/pb_ds/detail/binomial_heap_/binomial_heap_.hpp: Same.
	* include/ext/pb_ds/detail/left_child_next_sibling_heap_/
(Continue reading)

Rodolfo Lima | 5 Jun 06:42 2008

[c++0x] shared_ptr get() and use_count() inconsistency

Hi, I've been playing with shared_ptr and its aliasing constructor and 
the following code doesn't work as expected:

int main()
{
     std::shared_ptr<int> aux;
     int i;
     std::shared_ptr<int> aux2(aux, &i);
     assert(aux2.use_count() == 0);
     assert((bool)aux2, false); // assert failure here
     assert(aux2.get() == NULL); // assert failure here
}

I know there's no C++0x standard yet, blah blah blah, but in current 
libstdc++ implementation shared_ptr's get returns something different 
than NULL even when use_count()==0.

The current standard draft says that use_count() should return 0 if the 
shared_ptr is empty, and get() should return NULL if the shared_ptr is 
also empty.

The current implementation simply returns the stored pointer, whether 
use_count() is 0 or not.

I've attached a patch with two possible solutions. The first 
(shared_ptr.diff) just checks if use_count()==0 before returning the 
stored pointer, if it is, returns NULL. Is also changes operator-> and 
operator* to use get() with the correct semantics. This problem is that 
this solution incurs some overhead, with an addition of an comparison.

(Continue reading)

Johannes Singler | 5 Jun 10:29 2008
Picon

[PATCH][libstdc++-v3 parallel mode] random_shuffle fixes

Fixes two small things in parallel random_shuffle.

Tested x86_64-unknown-linux-gnu: No regressions

Please approve for mainline and gcc-4_3-branch.

2008-06-05  Johannes Singler  <singler <at> ira.uka.de>

          * include/parallel/random_shuffle.h:
            (parallel_random_shuffle_drs) Get the actual number of
            threads after entering the parallel region. Indentation.
          * include/parallel/algo.h: (random_shuffle(begin, end))
            Add namespace qualification to avoid ambiguity.

Johannes

Benjamin Kosnik | 5 Jun 17:13 2008
Picon

Re: [PATCH][libstdc++-v3 parallel mode] random_shuffle fixes


> 2008-06-05  Johannes Singler  <singler <at> ira.uka.de>
> 
>           * include/parallel/random_shuffle.h:
>             (parallel_random_shuffle_drs) Get the actual number of
>             threads after entering the parallel region. Indentation.
>           * include/parallel/algo.h: (random_shuffle(begin, end))
>             Add namespace qualification to avoid ambiguity.

Looks good!

-benjamin

Peter Dimov | 5 Jun 19:44 2008
Picon

Re: [c++0x] shared_ptr get() and use_count() inconsistency

Rodolfo Lima:

> The current standard draft says that use_count() should return 0 if the 
> shared_ptr is empty, and get() should return NULL if the shared_ptr is 
> also empty.

http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#711

Rodolfo Lima | 5 Jun 20:14 2008

Re: [c++0x] shared_ptr get() and use_count() inconsistency

Peter Dimov escreveu:

>> The current standard draft says that use_count() should return 0 if 
>> the shared_ptr is empty, and get() should return NULL if the 
>> shared_ptr is also empty.
> 
> http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#711

Thanks Peter. But I prefer the second solution you gave because it would 
lead to, IMHO, a sane smart pointer semantics.

Say you want to pass a weak_ptr to a function but only if it points to a 
not empty shared_ptr. One might write:

void func(std::weak_ptr<int> x) {}

std::shared_ptr<int> aux();
int i;
std::shared_ptr<int> sptr(aux, &i);

if(sptr)
	func(sptr);

In this case func would receive an weak_ptr that doesn't point to 
anything, although it was coded to not allow this, I mean, one would 
expect that if ptr.use_count()==0, (bool)ptr == false, but this doesn't 
hold above.

I know this is offtopic to this list, so I'm moving this to 
comp.lang.c++.moderated
(Continue reading)

Joseph S. Myers | 5 Jun 22:09 2008

libstdc++ tests and targets without iconv

Some libstdc++ tests such as 17_intro/headers/all.cc include 
<ext/codecvt_specializations.h> unconditionally along with all the other 
library headers.  This header includes <iconv.h> unconditionally.  This 
fails for targets without this header.  This leads to:

FAIL: 17_intro/headers/all.cc (test for excess errors)
FAIL: 17_intro/headers/all_c++200x_compatibility.cc (test for excess errors)
FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess errors)
FAIL: ext/headers.cc (test for excess errors)

Should these tests use dg-require-iconv or similar so they are disabled on 
such targets, should the tests only include 
<ext/codecvt_specializations.h> if _GLIBCXX_HAVE_ICONV, or should 
<ext/codecvt_specializations.h> condition out its contents unless 
_GLIBCXX_HAVE_ICONV?

--

-- 
Joseph S. Myers
joseph <at> codesourcery.com

Benjamin Kosnik | 5 Jun 23:37 2008
Picon

Re: libstdc++ tests and targets without iconv

> should the tests only include 
> <ext/codecvt_specializations.h> if _GLIBCXX_HAVE_ICONV,

This, for the tests that you specified. 

For the functional tests (ext/codecvt) it looks like dg-require-iconv
is already being used.

-benjamin


Gmane