This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] extern/fixed-memory/archive allocator


>I really like the general idea.  And I'd like to see our basic_string
>use that technique too. 

Thanks. This allows the use of basic_string/STL containers instead of
fixed char/value_type arrays in initialization routines where
dynamically allocated memory is problematic. Which, let's face it, would
be nice!

So, it can already be used with basic_string... however, I see what you
are saying. It is an interesting solution for known small containers.

> However I think we would need first to fix the
>front-end so that this works properly
>
>+       typedef char layout_type[sizeof(_Tp)] 
>+       __attribute__ ((aligned(__alignof__(_Tp))));

This works now .... see src/globals_*.cc.

>Also, I'm wondering whether it should not be
>
>   
>  typedef char storage_type[sizeof(_Tp)];
>  storage_type _M_instance  __attribute__((__aligned__(__alignof(_Tp))));
>
>(as I remember -- maybe that is fixed now -- attributes on array
>typedefs used to be silently stripped)

Naming issue noted, thanks.

I agree this would be better.

>We might want to abstract that into a standalone class, as it
>basically implement the aligned_storage functionality in TR1.

Huh. I'll look into this. 

I'm still looking for a good name for the allocator part. The choices
I've come up with leave me kind of cold: "extern_allocator" isn't
general enough, "global_allocator" is too vague, I suppose
"fixed_size_allocator" would work. Thoughts? Probably should just adopt
TR1 naming conventions if applicable.

-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]