Adding spirit::is_container to boost::traits
Is there any intention of including is_container [1] into boost::traits? I find myself using that particular Spirit header, which could be useful if isolated into traits. Cheers, Madera [1] http://www.boost.org/doc/libs/1_55_0/libs/spirit/doc/html/spirit/advanced/cu...
On Tue, May 27, 2014 at 11:20 AM, Rodrigo Madera <rodrigo.madera@gmail.com> wrote:
Is there any intention of including is_container [1] into boost::traits?
I find myself using that particular Spirit header, which could be useful if isolated into traits.
That traits is meant for users to specialize if they work with non-STL container types. It doesn't seem very appropriate for boost.traits because they can't deduce it in C++03 and in C++17 we will have concepts lite anyway.
Cheers, Madera
[1] http://www.boost.org/doc/libs/1_55_0/libs/spirit/doc/html/spirit/advanced/cu...
Regards, -- Felipe Magno de Almeida
On Tue, May 27, 2014 at 11:28 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
That traits is meant for users to specialize if they work with non-STL container types. It doesn't seem very appropriate for boost.traits because they can't deduce it in C++03 and in C++17 we will have concepts lite anyway.
I beg to differ. The need to identify container types (be it STL or user defined types) arises in some contexts. It would be very useful to have these in a standard boost library like traits, and not (ab)using Spirit internals for that. To me, having is_container looks interesting for boost::traits. Regards, Madera
On Tue, May 27, 2014 at 12:08 PM, Rodrigo Madera <rodrigo.madera@gmail.com> wrote:
On Tue, May 27, 2014 at 11:28 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
That traits is meant for users to specialize if they work with non-STL container types. It doesn't seem very appropriate for boost.traits because they can't deduce it in C++03 and in C++17 we will have concepts lite anyway.
I beg to differ.
The need to identify container types (be it STL or user defined types) arises in some contexts.
I agree completely with this statement. But that is not what spirit::traits::is_container is.
It would be very useful to have these in a standard boost library like traits, and not (ab)using Spirit internals for that.
+1 again.
To me, having is_container looks interesting for boost::traits.
Having a is_container would be great, and we will have that in C++17 AFAIK. You might be able to SFINAE something to detect begin, end and the necessary member typedefs, but there's no way to test ownership AFAIK.
Regards, Madera
Regards, -- Felipe Magno de Almeida
On May 27, 2014, at 5:08 PM, Rodrigo Madera <rodrigo.madera@gmail.com> wrote
On Tue, May 27, 2014 at 11:28 AM, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
That traits is meant for users to specialize if they work with non-STL container types. It doesn't seem very appropriate for boost.traits because they can't deduce it in C++03 and in C++17 we will have concepts lite anyway.
I beg to differ.
The need to identify container types (be it STL or user defined types) arises in some contexts. It would be very useful to have these in a standard boost library like traits, and not (ab)using Spirit internals for that.
To me, having is_container looks interesting for boost::traits.
My view is that can't have enough type traits, however they need to have very clear meaning to be usable and reliable. What does is_container mean? Does it imply that I can access a begin() member function? What about versioning: some C++11 STL containers have a shrink_to_fit member function that the C++98 STL containers don't have.
On Tue, May 27, 2014 at 12:30 PM, Thijs (M.A.) van den Berg <thijs@sitmo.com> wrote:
What does is_container mean? Does it imply that I can access a begin() member function?
What about versioning: some C++11 STL containers have a shrink_to_fit member function that the C++98 STL containers don't have.
I would bet something like [1]. Or, alternatively, if the user explicitly specializes his homebrew container as such. Madera [1] http://en.cppreference.com/w/cpp/concept/Container
On May 27, 2014, at 5:34 PM, Rodrigo Madera <rodrigo.madera@gmail.com> wrote:
On Tue, May 27, 2014 at 12:30 PM, Thijs (M.A.) van den Berg <thijs@sitmo.com> wrote:
What does is_container mean? Does it imply that I can access a begin() member function?
What about versioning: some C++11 STL containers have a shrink_to_fit member function that the C++98 STL containers don't have.
I would bet something like [1]. Or, alternatively, if the user explicitly specializes his homebrew container as such.
Madera
Ah, the concept of course, that a very clear definition. Thanks for pointing that out. Sounds like a great idea, it could be very helpful.
On May 27, 2014 11:30:38 AM EDT, "Thijs (M.A.) van den Berg" <thijs@sitmo.com> wrote:
What does is_container mean? Does it imply that I can access a begin() member function?
That would be better managed via specializations of std:: begin(). ___ Rob (Sent from my portable computation engine)
On May 28, 2014 10:19:24 AM EDT, Rodrigo Madera <rodrigo.madera@gmail.com> wrote:
On Tue, May 27, 2014 at 3:25 PM, Rob Stewart <robertstewart@comcast.net> wrote:
That would be better managed via specializations of std:: begin().
So you support the idea as well, right?
I was taking the wind out the sail of the one rationale for is_container. I'm neither for our against the general idea at this time, anyway. ___ Rob (Sent from my portable computation engine)
participants (4)
-
Felipe Magno de Almeida -
Rob Stewart -
Rodrigo Madera -
Thijs (M.A.) van den Berg