Skip to content

Close a bunch of issues related to removed components as resolved #526

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jwakely merged 1 commit into from
Nov 11, 2025
+31 −24
Merged

Close a bunch of issues related to removed components as resolved #526

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion xml/issue2478.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">

<issue num="2478" status="New">
<issue num="2478" status="Resolved">
<title>Unclear how <tt>wstring_convert</tt> uses <tt>cvtstate</tt></title>
<section><sref ref="[depr.conversions.string]"/></section>
<submitter>Jonathan Wakely</submitter>
Expand All @@ -18,6 +18,8 @@ to the member functions? "Otherwise it shall be left unchanged"
implies a copy is used, but if that's really what's intended there are
simpler ways to say so.
</p>

<note>2025-11-10 Resolved by the removal of <tt>wstring_convert</tt> via paper <paper num="P2872R3"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
</discussion>

<resolution>
Expand Down
9 changes: 5 additions & 4 deletions xml/issue2479.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">

<issue num="2479" status="New">
<issue num="2479" status="Resolved">
<title>Unclear how <tt>wbuffer_convert</tt> uses <tt>cvtstate</tt></title>
<section><sref ref="[depr.conversions.buffer]"/></section>
<submitter>Jonathan Wakely</submitter>
Expand All @@ -13,11 +13,12 @@
How does <tt>wbuffer_convert</tt> use the <tt>cvtstate</tt> member?
<p/>
Is the same conversion state object used for converting both the get
and put areas? That means a read which runs out of bytes halfway
through a multibyte character will leave some shift state in cvtstate,
which would then be used by a following write, even though the shift
and put areas? That means a read which runs out of bytes halfway
through a multibyte character will leave some shift state in cvtstate,
which would then be used by a following write, even though the shift
state of the get area is unrelated to the put area.
</p>
<note>2025-11-10 Resolved by the removal of <tt>wbuffer_convert</tt> via paper <paper num="P2872R3"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
</discussion>

<resolution>
Expand Down
3 changes: 2 additions & 1 deletion xml/issue2480.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">

<issue num="2480" status="New">
<issue num="2480" status="Resolved">
<title>Error handling of <tt>wbuffer_convert</tt> unclear</title>
<section><sref ref="[depr.conversions.buffer]"/></section>
<submitter>Jonathan Wakely</submitter>
Expand All @@ -16,6 +16,7 @@ characters before a conversion error be available to the users of the
<tt>wbuffer_convert</tt> and/or the internal <tt>streambuf</tt>, or does a conversion
error lose information?
</p>
<note>2025-11-10 Resolved by the removal of <tt>wbuffer_convert</tt> via paper <paper num="P2872R3"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
</discussion>

<resolution>
Expand Down
7 changes: 4 additions & 3 deletions xml/issue2481.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">

<issue num="2481" status="New">
<issue num="2481" status="Resolved">
<title><tt>wstring_convert</tt> should be more precise regarding "byte-error string" etc.</title>
<section><sref ref="[depr.conversions.string]"/></section>
<submitter>Jonathan Wakely</submitter>
Expand All @@ -10,8 +10,8 @@

<discussion>
<p>
Paragraph 4 of <sref ref="[depr.conversions.string]"/> introduces <tt>byte_err_string</tt>
as "a byte string to display on errors". What does display mean? The string is returned
Paragraph 4 of <sref ref="[depr.conversions.string]"/> introduces <tt>byte_err_string</tt>
as "a byte string to display on errors". What does display mean? The string is returned
on error, it's not displayed anywhere.
<p/>
Paragraph 14 says "Otherwise, if the object was constructed with a
Expand All @@ -32,6 +32,7 @@ not.
<p/>
All the same issues apply to the <tt>wide_err_string</tt> member.
</p>
<note>2025-11-10 Resolved by the removal of <tt>wstring_convert</tt> via paper <paper num="P2872R3"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
</discussion>

<resolution>
Expand Down
8 changes: 3 additions & 5 deletions xml/issue2507.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,7 @@
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
<!ENTITY hellip "&#x2026;">
<!ENTITY mdash "&#x2014;">
] >
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">

<issue num="2507" status="New">
<issue num="2507" status="Resolved">
<title><tt>codecvt_mode</tt> should be a bitmask type</title>
<section><sref ref="[depr.locale.stdcvt]"/></section>
<submitter>Jonathan Wakely</submitter>
Expand Down Expand Up @@ -34,6 +31,7 @@ or as a minimal fix we provide an overloaded <tt>operator|</tt> that returns
the right type.
</p>

<note>2025-11-10 Resolved by the removal of <tt>codecvt_mode</tt> via paper <paper num="P2871R3"/> in Kona, 2023. Status changed: New &rarr; Resolved.</note>
</discussion>

<resolution>
Expand Down
10 changes: 6 additions & 4 deletions xml/issue3095.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<?xml version='1.0' encoding='utf-8' standalone='no'?>
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">

<issue num="3095" status="New">
<issue num="3095" status="Resolved">
<title><tt>strstreambuf</tt> refers to nonexistent member of <tt>fpos</tt>, <tt>fpos::offset</tt></title>
<section><sref ref="[depr.strstreambuf.virtuals]"/></section>
<submitter>Billy O'Neal III</submitter>
Expand All @@ -11,20 +11,22 @@
<discussion>
<p>
<tt>strstreambuf</tt> refers to a nonexistent member function of <tt>fpos</tt> in the specification of the member function
<tt>seekpos</tt>, <sref ref="[depr.strstreambuf.virtuals]"/>/18 (emphasize mine):
<tt>seekpos</tt>, <sref ref="[depr.strstreambuf.virtuals]"/>/18 (emphasize mine):
</p>
<blockquote><p>
For a sequence to be positioned, if its next pointer is a null pointer, the positioning operation fails.
Otherwise, the function determines <tt>newoff</tt> from <span style="color:#C80000;font-weight:bold"><tt>sp.offset()</tt></span>:
</p></blockquote>
<p>
The intent is clearly to get the corresponding <tt>streamoff</tt> from the <tt>fpos</tt>, as p19 says "the resultant
offset <tt>newoff</tt> (of type <tt>off_type</tt>)". The mechanism to make that conversion is a normal explicit conversion,
The intent is clearly to get the corresponding <tt>streamoff</tt> from the <tt>fpos</tt>, as p19 says "the resultant
offset <tt>newoff</tt> (of type <tt>off_type</tt>)". The mechanism to make that conversion is a normal explicit conversion,
as indicated in the last row of the table in [fpos.operations].
</p>

<note>2018-06-18 after reflector discussion</note>
<p>Priority set to 4</p>

<note>2025-11-10 Resolved by the removal of <tt>strstreambuf</tt> via paper <paper num="P2867R2"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
</discussion>

<resolution>
Expand Down
14 changes: 8 additions & 6 deletions xml/issue3109.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<?xml version='1.0' encoding='utf-8' standalone='no'?>
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">

<issue num="3109" status="New">
<issue num="3109" status="Resolved">
<title><tt>strstreambuf</tt> is copyable</title>
<section><sref ref="[depr.strstreambuf]"/></section>
<submitter>Jonathan Wakely</submitter>
Expand All @@ -10,18 +10,20 @@

<discussion>
<p>
In C++03 <tt>strstreambuf</tt> was not copyable, because <tt>basic_streambuf</tt> wasn't copyable.
In C++11 we made <tt>basic_streambuf</tt> copyable by derived classes, and <tt>strstreambuf</tt>
doesn't define any special members, so it (unintentionally?) became copyable, with completely
In C++03 <tt>strstreambuf</tt> was not copyable, because <tt>basic_streambuf</tt> wasn't copyable.
In C++11 we made <tt>basic_streambuf</tt> copyable by derived classes, and <tt>strstreambuf</tt>
doesn't define any special members, so it (unintentionally?) became copyable, with completely
unspecified semantics.
<p/>
VC++ and libc++ make it movable not copyable, and libstdc++ still follows C++03, so it's neither
movable nor copyable. Making it movable seems to be the sane option, and consistent with
VC++ and libc++ make it movable not copyable, and libstdc++ still follows C++03, so it's neither
movable nor copyable. Making it movable seems to be the sane option, and consistent with
<tt>filebuf</tt> and <tt>stringbuf</tt>.
</p>

<note>2018-06-18 after reflector discussion</note>
<p>Priority set to 4</p>

<note>2025-11-10 Resolved by the removal of <tt>strstreambuf</tt> via paper <paper num="P2867R2"/> in Tokyo, 2024. Status changed: New &rarr; Resolved.</note>
</discussion>

<resolution>
Expand Down