[PATCH] libstdc++: Implement C++20 features for <sstream>

Thomas Rodgers trodgers@redhat.com
Fri Oct 9 23:28:38 GMT 2020


Jonathan Wakely writes:

> On 07/10/20 18:15 -0700, Thomas Rodgers wrote:
>>@@ -500,6 +576,40 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>>       }
>> #endif
>>
>>+#if __cplusplus > 201703L && _GLIBCXX_USE_CXX11_ABI
>>+      basic_istringstream(ios_base::openmode __mode, const allocator_type& __a)
>>+      : __istream_type(), _M_stringbuf(__mode | ios_base::in, __a)
>>+      { this->init(&_M_stringbuf); }
>
> All these & operators need to be std::__addressof(_M_stringbuf)
> instead. _M_stringbuf potentially depends on program-defined types
> (the traits and allocator classes) which means user namespaces are
> considered for ADL and they could define a operator& that gets used.
>
>
>>+
>>+      explicit basic_istringstream(__string_type&& __str,
>>+	                           ios_base::openmode __mode = ios_base::in )
>>+      : __istream_type(), _M_stringbuf(std::move(__str), __mode | ios_base::in)
>>+      { this->init(&_M_stringbuf); }
>>+
>>+      template<typename _SAlloc>
>>+	basic_istringstream(const basic_string<_CharT, _Traits, _SAlloc>& __str,
>>+			    const allocator_type& __a)
>>+	: basic_istringstream(__str, ios_base::in, __a)
>>+	{ }
>>+
>>+      using __sv_type = basic_string_view<char_type, traits_type>;
>
> This typedef seems to only be used once. Might as well just use
> basic_string_view<char_type, traits_type> directly in the return type
> of view().
>
> Similarly in basic_ostringstream and basic_stringstream.
>
>>diff --git a/libstdc++-v3/src/c++20/Makefile.in b/libstdc++-v3/src/c++20/Makefile.in
>>new file mode 100644
>>index 00000000000..0e2de19ae59
>>diff --git a/libstdc++-v3/src/c++20/sstream-inst.cc b/libstdc++-v3/src/c++20/sstream-inst.cc
>>new file mode 100644
>>index 00000000000..c419176ae8e
>>--- /dev/null
>>+++ b/libstdc++-v3/src/c++20/sstream-inst.cc
>>@@ -0,0 +1,111 @@
>>+// Explicit instantiation file.
>>+
>>+// Copyright (C) 1997-2020 Free Software Foundation, Inc.
>
> Just 2020 here.
>
>>+//
>>+// This file is part of the GNU ISO C++ Library.  This library is free
>>+// software; you can redistribute it and/or modify it under the
>>+// terms of the GNU General Public License as published by the
>>+// Free Software Foundation; either version 3, or (at your option)
>>+// any later version.
>>+
>>+// This library is distributed in the hope that it will be useful,
>>+// but WITHOUT ANY WARRANTY; without even the implied warranty of
>>+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>+// GNU General Public License for more details.
>>+
>>+// Under Section 7 of GPL version 3, you are granted additional
>>+// permissions described in the GCC Runtime Library Exception, version
>>+// 3.1, as published by the Free Software Foundation.
>>+
>>+// You should have received a copy of the GNU General Public License and
>>+// a copy of the GCC Runtime Library Exception along with this program;
>>+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
>>+// <http://www.gnu.org/licenses/>.
>>+
>>+//
>>+// ISO C++ 14882:
>>+//
>>+
>>+#ifndef _GLIBCXX_USE_CXX11_ABI
>>+// Instantiations in this file use the new SSO std::string ABI unless included
>>+// by another file which defines _GLIBCXX_USE_CXX11_ABI=0.
>
> This copy&pasted comment is misleading now if we're not actually going
> to include it from another file to generate the old ABI symbols.
>
> I think just define it unconditionally and add a comment saying that
> these new symbols are only defines for the SSO string ABI.
>
>>+# define _GLIBCXX_USE_CXX11_ABI 1
>>+#endif
>>+#include <sstream>
>>+
>>+namespace std _GLIBCXX_VISIBILITY(default)
>>+{
>>+_GLIBCXX_BEGIN_NAMESPACE_VERSION
>>+
>>+template basic_stringbuf<char>::basic_stringbuf(const allocator_type&);
>>+template basic_stringbuf<char>::basic_stringbuf(ios_base::openmode,
>>+						 const allocator_type&);
>>+template basic_stringbuf<char>::basic_stringbuf(__string_type&&,
>>+						 ios_base::openmode);
>>+template basic_stringbuf<char>::basic_stringbuf(basic_stringbuf&&,
>>+						 const allocator_type&);
>>+template basic_stringbuf<char>::allocator_type
>>+basic_stringbuf<char>::get_allocator() const noexcept;
>>+template basic_stringbuf<char>::__sv_type
>
> Looks like this would be a bit simpler if it just used string_view
> here, not basic_stringbuf<char>::__sv_type, and wstring_view below
> for the wchar_t specializations.
>
> And you could use allocator<char> instead of
> basic_stringbuf<char>::allocator_type.
>
> That looks a little cleaner to me, but it's a matter of opinion.
>
> That would be necessary anyway for the basic_*stringstream types if
> they don't have the __sv_type any more.
>
>
>>diff --git a/libstdc++-v3/testsuite/27_io/basic_istringstream/cons/char/1.cc b/libstdc++-v3/testsuite/27_io/basic_istringstream/cons/char/1.cc
>>new file mode 100644
>>index 00000000000..d93141fc232
>>--- /dev/null
>>+++ b/libstdc++-v3/testsuite/27_io/basic_istringstream/cons/char/1.cc
>>@@ -0,0 +1,85 @@
>>+// Copyright (C) 2020 Free Software Foundation, Inc.
>>+//
>>+// This file is part of the GNU ISO C++ Library.  This library is free
>>+// software; you can redistribute it and/or modify it under the
>>+// terms of the GNU General Public License as published by the
>>+// Free Software Foundation; either version 3, or (at your option)
>>+// any later version.
>>+
>>+// This library is distributed in the hope that it will be useful,
>>+// but WITHOUT ANY WARRANTY; without even the implied warranty of
>>+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>+// GNU General Public License for more details.
>>+
>>+// You should have received a copy of the GNU General Public License along
>>+// with this library; see the file COPYING3.  If not see
>>+// <http://www.gnu.org/licenses/>.
>>+
>>+// 27.7.1.1  basic_stringbuf constructors  [lib.stringbuf.cons]
>
> These references are to the C++03 standard, but the functions being
> tested are not in that standard, or that section.
>
> It's 29.8.2.2 [stringbuf.cons] in the C++20 standard. To make these
> references unambiguous I've switched to saying which standard (or
> which Nxxxx working draft) the reference comes from, i.e.
>
> // C++20 29.8.2.2  basic_stringbuf constructors  [stringbuf.cons]
>
> One day I might write a script to add "C++03" or "C++11" to all the
> old comments in old tests. When I drain my TODO list of other things.
>
> I was expecting this patch to also add the five new overloads of
> basic_stringbuf::str, but that can be added later. I don't think
> adding those will change anything done in this patch.

I'm happy to do that, follow up patch?



More information about the Gcc-patches mailing list