Paolo Carlini | 3 Jul 2005 18:28
Picon

[Patch] Add __versa_string to mainline/ext

Hi everyone,

the below finally adds to mainline/ext the "modular" string framework:
in this incarnation, as an extension, I'm adding a 4th template argument
(see vstring.h and vstring_fwd.h), thus making easy testing and
comparing the available base classes.

Actually the work proceeded rather smoothly and you will find also the
I/O bits, in a basic version (no performance optimizations for
char/wchar_t exploiting protected members of streambuf).

For now, I'm only adding an handful of instantation testcases, but I'm
fairly confident that the code would also pass a full testsuite (modulo
trivial fixes like typos) because the classes are adapted from v7-branch
without substantive changes besides renamings, reformattings and other
very-very simple things. More testing during the next days, anyway. Then
I'd like to commit the patch and proceed with further improvements.

Paolo.

P.S. I considered creating a specific directory under /ext but seems
overkill for so few files. Also, both comments at the beginning of the
files and the file names themselves should make sufficiently clear the
purpose of each new file.

//////////////
2005-07-xx  Paolo Carlini  <pcarlini <at> suse.de>

(Continue reading)

Benjamin Kosnik | 4 Jul 2005 23:59
Picon
Favicon

Re: AIX bootstrap failure (Re: [v3] policy based associated containers)

On Wed, 29 Jun 2005 23:39:13 -0400
David Edelsohn <dje <at> watson.ibm.com> wrote:

> 	Following up with more detail, the problem appears to be the
> dependency list for the stamp-assoc rule.  If I decrease the length of the
> dependency list that needs to be expanded, I can proceed with bootstrap.

Can you post what modifications you made that allowed boostrap?

-benjamin

Benjamin Kosnik | 5 Jul 2005 00:00
Picon
Favicon

Re: [v3] policy based associated containers


Thanks for fixing this up guys. 

-benjamin

Sameer Atre | 5 Jul 2005 12:41
Favicon

libstdc++ - version 3 default allocator

Hi,

The older version of libstdc++ (version 2) had a macro 
__STL_DEFAULT_ALLOCATOR which could be used for redefining the default 
allocator for all STL containers in a program.

How can I get the same behaviour in version 3 of libstdc++ when I want 
to change the default allocator for all containers.

Regards,
sameer

Paolo Carlini | 5 Jul 2005 13:19
Picon

Re: libstdc++ - version 3 default allocator

Sameer Atre wrote:

> How can I get the same behaviour in version 3 of libstdc++ when I want
> to change the default allocator for all containers.

Currently, there isn't an exact replacement, I'm afraid.

Either you build the whole library passing a specific
--enable-libstdcxx-allocator= option (see
http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html) - thus changing
the default allocator for the entire library, not only the containers -
or you include from your code one of the allocators available under /ext
and then pass it to each container as the second template argument. I
would suggest experimenting a bit with the second possibility, as a start.

In general, 4.0.x is much better than any previous release series as far
as allocators are concerned.

Paolo.

Jonathan Wakely | 5 Jul 2005 13:24
Picon
Picon
Favicon

Re: libstdc++ - version 3 default allocator

On Tue, Jul 05, 2005 at 04:11:38PM +0530, Sameer Atre wrote:

> Hi,
> 
> The older version of libstdc++ (version 2) had a macro 
> __STL_DEFAULT_ALLOCATOR which could be used for redefining the default 
> allocator for all STL containers in a program.
> 
> How can I get the same behaviour in version 3 of libstdc++ when I want 
> to change the default allocator for all containers.

You must re-configure and re-compile libstdc++ if you want a different
default allocator.  See the --enable-libstdcxx-allocator=OPTION
documentation in the libstdc++ configuration docs:
http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html

Using this option can result in a libstdc++ binary that is not
compatible with default-configured builds.

Regards,

jon

--

-- 
"God is as real as I am," the old man said.  My faith was restored, for
I knew that Santa would never lie.

David Edelsohn | 6 Jul 2005 22:54
Picon
Favicon

[PATCH, libstdc++] libstdc++ pb_assoc testcase fix

	A libstdc++ testcase for pb_assoc uses the type map_t, conflicting
with that same type in system headers.  The following patch changes the
name to tree_map_t to make it more unique.  I can change it to something
else more unique if there are other preferences.

Okay for mainline?

Thanks, David

	* tree_order_statistics_join.cc: Change map_t to tree_map_t.

Index: tree_order_statistics_join.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/testsuite/ext/pb_assoc/example/tree_order_statistics_join.cc,v
retrieving revision 1.1
diff -c -p -r1.1 tree_order_statistics_join.cc
*** tree_order_statistics_join.cc	27 Jun 2005 15:30:52 -0000	1.1
--- tree_order_statistics_join.cc	6 Jul 2005 20:51:42 -0000
*************** pb_assoc::tree_assoc_cntnr<
*** 59,72 ****
    pb_assoc::order_statistics_key_cmp<std::less<int> >,
    pb_assoc::splay_tree_ds_tag,
    pb_assoc::order_statistics_node_updator<int> >
! map_t;

  int
  main()
  {
    typedef pb_assoc::order_statistics_key< int> int_order_statistics_key;

(Continue reading)

Paolo Carlini | 6 Jul 2005 23:08
Picon

Re: [PATCH, libstdc++] libstdc++ pb_assoc testcase fix

David Edelsohn wrote:

>	A libstdc++ testcase for pb_assoc uses the type map_t, conflicting
>with that same type in system headers.  The following patch changes the
>name to tree_map_t to make it more unique.  I can change it to something
>else more unique if there are other preferences.
>
>Okay for mainline?
>  
>
Ok with me. I would say wait a few hours in case of objections from the
other maintainers, then go ahead.

Thanks,
Paolo.

Jonathan Wakely | 6 Jul 2005 23:54
Picon
Picon
Favicon

Re: [PATCH, libstdc++] libstdc++ pb_assoc testcase fix

On Wed, Jul 06, 2005 at 04:54:55PM -0400, David Edelsohn wrote:

> 	A libstdc++ testcase for pb_assoc uses the type map_t, conflicting
> with that same type in system headers.  The following patch changes the
> name to tree_map_t to make it more unique.  I can change it to something
> else more unique if there are other preferences.

Am I right in thinking that any POSIX header is allowed to define any
name ending in _t, possibly as a macro, so maybe map_type or
tree_map_type would be even better?  That is also consistent with the
standard library's size_type, value_type etc.

http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html#tag_02_02_02

jon

Paolo Carlini | 7 Jul 2005 00:48
Picon

Re: [PATCH, libstdc++] libstdc++ pb_assoc testcase fix

Jonathan Wakely wrote:

>On Wed, Jul 06, 2005 at 04:54:55PM -0400, David Edelsohn wrote:
>
>>	A libstdc++ testcase for pb_assoc uses the type map_t, conflicting
>>with that same type in system headers.  The following patch changes the
>>name to tree_map_t to make it more unique.  I can change it to something
>>else more unique if there are other preferences.
>>    
>>
>Am I right in thinking that any POSIX header is allowed to define any
>name ending in _t, possibly as a macro, so maybe map_type or
>tree_map_type would be even better?  That is also consistent with the
>standard library's size_type, value_type etc.
>  
>
Also ok with me (notice that we are talking about *a testcase* therefore
consistency with the standard library names doesn't seem really
relevant. Ok, no more nitpicking for today ;)

Paolo.


Gmane