Difference between revisions of "Talk:Main Page/suggestions"

Revision as of 18:10, 17 March 2024

This page collects edit suggestions from new and logged-out users when editing is temporarily disabled due to vandalism. Click the "+" at the top to leave a message. Please make sure to include a link to the page you are referencing. See /archive and /archive 1 for old suggestions that have been responded to.

new expression missing exception specs

Somewhere way down in that wall of text there is a mention of std::bad_array_new_length, but that's it. I think there should be a dedicated section "Exceptions" (as in other docs on this site) documenting std::bad_alloc and std::bad_array_new_length as well as the non-throwing versions, as this is pretty fundamental. Perhaps also an example.

Thanks! 213.68.42.195 03:02, 25 February 2019 (PST)

New user

Hello, I would like to make changes to the C++ compiler support page related to the addition of the "Modules" and "Coroutines" features to C++20. Can somebody give me permissions to edit or otherwise do the changes as per the following articles:

https://www.phoronix.com/scan.php?page=news_item&px=Coroutines-Modules-CPP20 https://herbsutter.com/2019/02/23/trip-report-winter-iso-c-standards-meeting-kona/

--Trifud (talk) 23:15, 26 February 2019 (PST)

How long time does it take for a user to be activated? --Trifud (talk) 23:09, 28 February 2019 (PST)

RFC: another implementation of Gadget-StandardRevision

(function() {
'use strict';
var styles = document.createElement('style');
styles.textContent = '[hidden] { display: none !important; }';
styles.textContent += '.stdrev-rev-hide > tbody > tr > td { border: none !important; padding: 0 !important; }'
styles.textContent += '.stdrev-rev-hide > tbody > tr > td:nth-child(2) { display: none; }'
styles.textContent += '.stdrev-rev-hide { border: none; }'
styles.textContent += '.stdrev-rev-hide > span > .t-mark-rev { display: none; }'
document.head.append(styles);
 
var rev = mw.config.get('wgTitle').indexOf('c/') === 0 ?
	[ 'C89', 'C99', 'C11' ] :
	[ 'C++98', 'C++03', 'C++11', 'C++14', 'C++17', 'C++20' ];
 
var select = $('<div class="vectorMenu"></div>').appendTo('#cpp-head-tools-right');
select.append('<h5><span>Std rev</span></h5>');
var list = $('<ul>').appendTo($('<div class="menu">').appendTo(select));
$.each(['DIFF'].concat(rev), function(i, v) {
	list.append('<li><a href="#'+v+'">'+v+'</a></li>');
});
list.on('click', 'a', function(e) {
	list.find('a').css('font-weight', 'normal');
	$(this).css('font-weight', 'bold');
	curr_rev = e.target.innerText;
	on_rev_changed();
});
 
var curr_rev = 'DIFF';
 
// Returns true if an element should be shown in the current revision, that is, either curr_rev is
// DIFF (i.e. show all), or curr_rev is within the range [since, until). The range [since, until)
// is inspected from the classes of `el`.
// `el` may be the same element as the one to be shown if it has the needed classes, or it may be a
// revision marker or a collection thereof (e.g. one expanded from {{mark since foo}}, or from the
// {{mark since foo}}{{mark until bar}} combo).
// `el` may be either a HTML element or a jQuery object.
// Note that this correctly handle the case when `el` represents an empty set of elements (in which
// case the element is always shown).
function should_be_shown(el) {
	if (curr_rev === 'DIFF') return true;
	var curr_revid = rev.indexOf(curr_rev);
	var since = 0, until = rev.length;
	$.each(rev, function(i) {
		var ssince = 't-since-'+rev[i].toLowerCase().replace(/\+/g, 'x');
		var suntil = 't-until-'+rev[i].toLowerCase().replace(/\+/g, 'x');
		if ($(el).hasClass(ssince)) since = i;
		if ($(el).hasClass(suntil)) until = i;
	});
	return since <= curr_revid && curr_revid < until;
}
 
// Called when user changes the selected revision. Inside this function, curr_rev is already set to
// the value after the change.
function on_rev_changed() {
	handle_dcl();
	renumber_dcl();
	handle_dsc();
	handle_nv();
	handle_rev();
	handle_headings();
	handle_list_items();
	$('.t-rev-begin, .t-rev-inl').toggleClass('stdrev-rev-hide', curr_rev !== 'DIFF');
	$('.t-mark-rev').each(function() {
		this.hidden = curr_rev !== 'DIFF';
		if ($(this.nextSibling).is('br'))
			this.nextSibling.hidden = curr_rev !== 'DIFF';
	});
}
 
// Returns true if the jQuery object `el` contains at least one element, and all contained elements
// are hidden; otherwise returns false.
// This is used to hide a 'parent' or 'heading' element when all its contents are hidden.
function all_hidden(el) { return $(el).length > 0 && !$(el).is(':not([hidden])'); }
 
// Hide or show the elements expanded from the {{dcl ...}} template family. See documentation at
// https://en.cppreference.com/w/Template:dcl/doc .
// The dcl items (expanded from {{dcl | ... }}) may either appear alone or as children of versioned
// declaration list (expanded from {{dcl rev begin | ... }}). In the latter case, the revision may
// be supplied by the dcl items or by the dcl-rev (in the latter case the dcl-rev has class
// t-dcl-rev-notes).
// For the use of renumber_dcl(), each dcl-rev is marked as hidden if all its children dcl items
// are hidden, and vice versa.
function handle_dcl() {
	$('.t-dcl').each(function() {
		this.hidden = !should_be_shown(this);
	});
	$('.t-dcl-rev').each(function() {
		if ($(this).is('.t-dcl-rev-notes')) {
			var hidden = !should_be_shown(this);
			this.hidden = hidden;
			$(this).find('.t-dcl').each(function() {
				this.hidden = hidden;
			});
		} else {
			this.hidden = all_hidden($(this).find('.t-dcl'));
		}
	});
	$('.t-dcl-begin .t-dsc-header').each(function() {
		var marker = $(this).find('> td > div > .t-mark-rev');
		var lastheader = $(this).nextUntil(':not(.t-dsc-header)').addBack();
		var elts = lastheader.nextUntil('.t-dsc-header').filter('.t-dcl, .t-dcl-rev');
		this.hidden = all_hidden(elts) || !should_be_shown(marker);
	});
	$('.t-dcl-h').each(function() {
		this.hidden = all_hidden($(this).nextUntil(':not(.t-dcl, .t-dcl-rev)'));
	});
}
 
// Ensure that each visible dcl item in a dcl list is contiguously numbered, and rewrite mentions
// to these numbers to use the modified numbering.
// If a list item (e.g. those expanded from @m@) contains no number after the rewrite (i.e. it's
// inapplicable in current revision), it is hidden.
// Note that the use of '~ * .t-li, ~ * .t-v' effectively establishes a kind of scoping: only
// numbers that appear after the dcl list and are more nested in the DOM hierarchy are affected
// by the renumbering.
// Requires that handle_dcl() has been called.
function renumber_dcl() {
	$('.t-dcl-begin').each(function() {
		var numbering_map = [];
		var i = 0;
		$(this).find('.t-dcl, .t-dcl-rev').each(function() {
			var num_cell;
			if ($(this).is('.t-dcl'))
				num_cell = $(this).children('td:nth-child(2)');
			else
				num_cell = $(this).find('> tr.t-dcl-rev-aux > td:nth-child(2)');
			var number_text = /\s*\((\d+)\)\s*/.exec(num_cell.text());
			if (!num_cell.attr('data-orig-num') && number_text)
				num_cell.attr('data-orig-num', number_text[1]);
			var original_num = num_cell.attr('data-orig-num');
			if (original_num) {
				if (! numbering_map[original_num])
					numbering_map[original_num] = $(this).is('[hidden]') ? null : ++i;
				num_cell.text('('+numbering_map[original_num]+')');
			}
		});
		$(this).find('~ * .t-li, ~ * .t-v').each(function() {
			if (! $(this).attr('data-orig-v'))
				$(this).attr('data-orig-v', $(this).text().replace(/[()]/g, ''));
			var original_numbers = [];
			$.each($(this).attr('data-orig-v').split(','), function(i, v) {
				var match = /(\d+)(?:-(\d+))?/.exec(v);
				if (match[2])
					for (var i = +match[1]; +i <= +match[2]; ++i)
						original_numbers.push(i);
				else
					original_numbers.push(match[1]);
			});
			var numbers = $.map(original_numbers, function(x) {
				return numbering_map[x];
			});
			var s = [];
			for (var i = 0; i < numbers.length; ++i) {
				if (numbers[i+1] - numbers[i] === 1 && numbers[i+2] - numbers[i+1] === 1) {
					var begin = numbers[i];
					while (numbers[i+1] - numbers[i] === 1)
						++i;
					s.push(begin+'-'+numbers[i]);
				} else {
					s.push(numbers[i]);
				}
			}
			if ($(this).is('.t-li')) {
				this.parentElement.hidden = numbers.length === 0;
				$(this).text(s.join(',')+')');
			} else
				$(this).text('('+s.join(',')+')');
		});
	});
}
// Hide or show the elements expanded from the {{dsc ...}} template family. See documentation at
// https://en.cppreference.com/w/Template:dcl/doc .
// The revision markers are in the first cell of each dsc item. In the general case, the visibility
// of a dsc item is control by a single revision marker. But if a specialized template is used,
// and the amount of entity names in the first cell matches the lines of the revision markers,
// then each line controls the visibility of a single entity name, and the dsc item is hidden only
// if all the entity names are hidden.
// If all the dsc items are hidden, then the corresponding headings are hidden as well.
function handle_dsc() {
	$('.t-dsc').each(function() {
		var member = $(this).find('.t-dsc-member-div');
		if (member[0]) {
			var lines = member.find('> div:nth-child(2) > .t-lines').children();
			var mems = member.find('> div:first-child .t-lines').children();
			if (lines.length !== mems.length)
				this.hidden = !should_be_shown(lines.children('.t-mark-rev'));
			else {
				lines.each(function(i) {
					var marker = $(this).children('.t-mark-rev');
					mems[i].hidden = !should_be_shown(marker);
					marker.hidden = !should_be_shown(marker);
				});
				this.hidden = all_hidden(mems);
			}
		} else {
			var marker = $(this).find('> td:first-child > .t-mark-rev');
			this.hidden = !should_be_shown(marker);
		}
	});
	$('.t-dsc .t-dsc-header').each(function() {
		var marker = $(this).find('> td > div > .t-mark-rev');
		var lastheader = $(this).nextUntil(':not(.t-dsc-header)').addBack();
		this.hidden = all_hidden(lastheader.nextUntil(':not(.t-dsc)')) || !should_be_shown(marker);
	});
	var heading_selector = ['tr:has(> td > h5)', 'tr:has(> td > h3)'];
	$.each(heading_selector, function(i, selector) {
		$(selector).each(function() {
			var section = $(this).nextUntil(heading_selector.slice(i).join(','));
			this.hidden = all_hidden(section.filter('.t-dsc'));
		});
	});
	$('.t-dsc-begin').each(function() {
		this.hidden = all_hidden($(this).find('.t-dsc'));
	});
}
// Hide or show the navbar elements expanded from the {{nv ...}} template family. See documentation
// at https://en.cppreference.com/w/Template:nv/doc .
// A line of revision marker only controls a single entity name, even if it's expanded from
// {{nv ln | ... }} that contains multiple lines.
// If a heading contains a revision marker, that revision marker controls the visibility of the
// heading and its corresponding contents; otherwise the heading is hidden when it is followed by
// content elements, and all of them are hidden.
function handle_nv() {
	$('.t-nv').each(function() {
		var marker = $(this).find('> td > .t-mark-rev');
		this.hidden = !should_be_shown(marker);
	});
	$('.t-nv-ln-table').each(function() {
		var lines = $(this).find('> div:nth-child(2) > .t-lines').children();
		var mems = $(this).find('> div:first-child .t-lines').children();
		lines.each(function(i) {
			var marker = $(this).children('.t-mark-rev');
			if (mems[i]) mems[i].hidden = !should_be_shown(marker);
			marker.hidden = !should_be_shown(marker);
		});
		this.hidden = all_hidden(mems);
	});
	var heading_selector = ['.t-nv-h2', '.t-nv-h1'];
	$.each(heading_selector, function(i, selector) {
		$(selector).each(function() {
			var section = $(this).nextUntil(heading_selector.slice(i).join(','));
			var marker = $(this).find('> td > .t-mark-rev');
			if (marker[0]) {
				section.each(function() {
					this.hidden = this.hidden || !should_be_shown(marker);
				});
				this.hidden = !should_be_shown(marker);
			}
			this.hidden = all_hidden(section.find('.t-nv-ln-table'));
		});
	});
}
// Hide or show the elements expanded from the {{rev ...}} template family. See documentation at
// https://en.cppreference.com/w/Template:dcl/doc .
// Borders are handled by class stdrev-rev-hide.
function handle_rev() {
	$('.t-rev, .t-rev-inl').each(function() {
		this.hidden = !should_be_shown(this);
	});
}
// Hide or show headings.
// If the heading contains a revision marker, that revision marker controls the visibility of it
// and its corresponding contents; otherwise, a heuristic is made: if the contents contain a dsc
// list, and its revision-related contents are hidden, then the heading and all contents are hidden
// as well.
// The heuristic requires that handle_dsc() and handle_rev() have been called.
function handle_headings() {
	var heading_selector = ['h5', 'h4', 'h3', 'h2'];
	$.each(heading_selector, function(i, selector) {
		$(selector).each(function() {
			var section = $(this).nextUntil(heading_selector.slice(i).join(','));
			var marker = $(this).find('> span > .t-mark-rev');
			if (marker[0]) {
				section.each(function() {
					this.hidden = this.hidden || !should_be_shown(marker);
				});
				this.hidden = !should_be_shown(marker);
			}
			if (section.is('.t-dsc-begin') && !section.is(':not(p, .t-rev-begin, .t-dsc-begin)')) {
				var revisioned_content = section.find('.t-dsc, .t-rev, .t-rev-inl');
				section.each(function() {
					this.hidden = this.hidden || all_hidden(revisioned_content);
				});
				this.hidden = all_hidden(revisioned_content);
			}
		});
	});
}
// Hide or show <li> elements based on the contained revision markers.
function handle_list_items() {
	$('li').each(function() {
		var marker = $(this).children('.t-mark-rev');
		this.hidden = !should_be_shown(marker);
	});
}
})();

Features include:

1. hide section based on revision markers in the heading
2. hide <li> based on its contained revision markers
3. hide "Defined in header ..." when the corresponding entities are hidden
4. implement renumbering inside {{v}}
5. much shorter than P12's implementation! (~300LOC vs ~1800LOC)

Does it make sense to include this as an "official" gadget?

--223.3.167.101 10:25, 3 March 2019 (PST)

We don't want to have two gadgets for the same thing. What does the current gadget do that this script doesn't, and vice versa? What caused the drastic shortening? T. Canens (talk) 11:07, 23 March 2019 (PDT)

> What does the current gadget do that this script doesn't

1. be hosted on GitHub

2. have tests

With regard to functionality, I don't know of any case that is handled better by Gadget-StandardRevision than by this script, but I don't have a thorough test.

> and vice versa?

All features mentioned above. Also, it does not have the problem reported below: Gadget-StandardRevision ignores all except the first revision marker in a row, and behaves unintuitively when the markers occupy more rows than the names in the dsc item. This script takes care to handle these cases better.

> What caused the drastic shortening?

Gadget-StandardRevision clones each of the elements that may be affected by the Gadget, and has a complex data structure to keep track of these elements and their clones. A lot of work is done to construct, manipulate, and debug this data structure. By contrast, this implementation directly manipulates the affected elements, which requires much less lines of code.

--121.249.15.21 10:52, 24 March 2019 (PDT)

The current gadget is also hosted on GitHub and has tests https://github.com/p12tic/cppreference-doc --Ybab321 (talk) 10:30, 26 March 2019 (PDT)

Right, so I listed it as a thing that the current gadget do that this script doesn't :) --121.249.15.75 11:38, 26 March 2019 (PDT)

Oops, my mistake :( --Ybab321 (talk) 06:44, 31 March 2019 (PDT)

Updating the Embarcadero column

I'm a newly registered user, so cannot edit this page as it's under protection.

The Embarcadero column for C++14 and C++17 is out of date. The compiler supports all of C++14, and all of C++17 bar:

• Replacement of class objects containing reference members P0137R1
• Standardization of Parallelism TS P0024R2
• Elementary string conversions P0067R5
• Splicing Maps and Sets P0083R3
• Hardware interference size P0154R1

More info here: http://docwiki.embarcadero.com/RADStudio/Rio/en/Modern_C%2B%2B_Language_Features_Compliance_Status#C.2B.2B14_Features and http://docwiki.embarcadero.com/RADStudio/Rio/en/Modern_C%2B%2B_Language_Features_Compliance_Status#C.2B.2B17_Features

yes, their new compilers are basically Clang: Embarcadero 10.1 is Clang 3.3, Embarcadero 10.3 (linked above) is Clang 5.0. But I suppose it's fair to update the table (for now, I updated the links below the table) --Cubbi (talk) 06:40, 8 March 2019 (PST)

Standard Revision gadget problems with C++20

It seems there are some problems with displaying (not displaying) features removed in C++20, On std::allocator page choosing C++20 Standard to be displayed, every removed feature is still on the list, marked as deprecated, information "removed in C++20" disappears. Is this template problem or widget problem? Kaznov (talk) 09:38, 15 March 2019 (PDT)

sizeof parameter can't be a C-style cast

I'm not able to make this change, but would like to suggest it.

sizeof's notes ought to say something like:

With form (2), expression cannot be a C-style cast, due to ambiguity with form (1). In other words, sizeof (char)+1 is parsed as (sizeof(char)) + 1, rather than sizeof((char)+1). — Preceding unsigned comment added by Myria (talk • contribs)

std::sort() should mention strict weak ordering requirements

The description of std::sort() does not mention that the comparison operator comp must define a strict weak ordering. Unless the standard has changed, it is undefined behavior to sort with a comparison function which does not define a strict weak ordering.

It also is probably worthwhile to explicitly point out that sorting with a comparison function that does not define a strict weak ordering is undefined behavior, and in fact in common implementations can lead to a crash or infinite loop, since it's a really commonly-encountered pitfall.

It may also be worthwhile pointing out that operator< does *not* define a strict weak ordering over floating point values due to NaN behavior, and so std::sort() may crash when applied to a vector of floating point values.

I believe that std::stable_sort() has implementation defined behavior rather than undefined when there's not a strict weak ordering, so it might also be worthwhile recommending using std::stable_sort() in such cases.

SethML (talk) 10:41, 9 April 2019 (PDT)

cpp/algorithm/sort says "Compare must meet the requirements of Compare." and cpp/named_req/Compare explains strict weak ordering and all other requirements on the comparison function. I suppose it could be highlighted, something like "must meet the requirements of Compare, including the strict weak ordering requirement", but then it sounds like there are cases where the ordering is not included. Maybe a concise bad example would be worth adding.

As for stable_sort, the actual requirement uses the word of power "shall"], so it's undefined to violate that for both sort and stable_sort. --Cubbi (talk) 11:12, 9 April 2019 (PDT)

Indeed, I've been reading the standards and discovering these things. I'd had this assumption that stable_sort() was implementation-defined over poorly-ordered sequences, but it appears that it's actually undefined and could crash. In practice I think most implementations are a merge sort, which should have some reasonable behavior given input which isn't strict weak ordered. But the standard doesn't guarantee that, sadly.

The phrasing in the standard is: For algorithms other than those described in alg.binary.search, comp shall induce a strict weak ordering on the values.

I'd missed that the Compare requirement encoded the strict weak ordering requirement - that's pretty subtle. I do think that for all of the sort functions, it'd be nice to expand the compare bullet point, something like:

* Compare must meet the requirements of Compare, including the strict weak ordering requirement. If it doesn't the behavior of X_sort is undefined.

A bad example using floating point could be a good way to call out UB with floating point collections, since that's a serious gotcha.

I find it also an interesting question what the behavior of lower_bound and friends is if passed a sequence that is not partitioned with respect to the value being searched for. The standard does not use the word "shall" - it says: All of the algorithms in this subclause are versions of binary search and assume that the sequence being searched is partitioned with respect to an expression formed by binding the search key to an argument of the comparison function. What is your interpretation of the result if the sequence is not partitioned - undefined behavior, or implementation defined?

"implementation-defined" is an additional standard requirement, not made here. I would say "undefined". If you feel strongly enough about it, consider raising an editorial issue on whether 'assume' in [alg.binary.search]/1 means the same as 'shall' in [alg.sorting]/3, and what does it mean to violate it (ill-formed? undefined? unspecified?) --Cubbi (talk) 06:54, 10 April 2019 (PDT)

Also, if I comment on [Talk:Main_Page/suggestions] enough, will I gain edit access? --SethML (talk) 12:11, 9 April 2019 (PDT)

Definintion of synchronizes-with in cpp/atomic/memory order?

The page cpp/atomic/memory order tries to be fairly formal with defining the different types of memory ordering constraints, but a definition for "synchronizes-with" (which "inter-thread happens-before" depends on) appears to be missing.

more copy & pastable header

On all the pages at the top it says "Defined in <X>". I think it would be better to do "#include <X>" instead so I can copy & paste that into my code directly.

135.23.100.188 12:00, 21 April 2019 (PDT)Ben

Not all error_codes are platform-dependent

In https://en.cppreference.com/w/cpp/error error_condition and error_error are described as:

error_condition (C++11) holds a portable error code

error_code (C++11) holds a platform-dependent error code

But that doesn't seem to be correct. See for example https://akrzemi1.wordpress.com/2017/07/12/your-own-error-code/#comment-6921 or http://blog.think-async.com/2010/04/system-error-support-in-c0x-part-2.html

The descriptions are from overviews in the standard, see syserr.errcode.overview and syserr.errcode.overview. If you want to add something about the actual usage, I think we can add a "Notes" section to describe it. (By the way, the second article was written before C++11 so I doubt whether it is useful now.) --Fruderica (talk) 07:45, 27 April 2019 (PDT)

open source libs

How to add reference to open source lib? (Alex25 (talk) 01:20, 28 April 2019 (PDT))

Improving this site

I'm hardly a new user... can't I get edit rights (back)? CarloWood (talk) 09:18, 28 April 2019 (PDT)

BNFLite

Could you add nice BNFLite parsing h-library ( https://github.com/r35382/bnflite) into Text::Parse section

Language support page: list library support with the library name not the compiler name

The language support page lists compiler names in the list of library features. In a lot of Linux distributions, Clang will by default use GCC's libstdc++ instead of LLVM's libc++, which means that the relevant column to look at in that table for support when using Clang is the GCC column, not the Clang column. Likewise, clang-cl will use MSVC's standard library by default. (I think Intel's compiler behaves similarly to Clang in this regard, and indeed probably several other compilers in the table are not coupled to a particular standard library implementation.)

The current table structure seems less helpful than it could be.

Suggestion: rename the GCC column to libstdc++ and the Clang column to libc++; remove the columns for compilers that don't have their own standard library implementation; add introductory text explaining which standard library each compiler uses by default.

zygoloid (talk) 17:12, 4 May 2019 (PDT)

this has been suggested as far back as 2016 Talk:cpp/compiler_support#Splitting_and_folding the_table and I don't think there is any opposition. Someone just needs to volunteer. --Cubbi (talk) 06:08, 6 May 2019 (PDT)

Now I have placed core language features and library features into different tables, and renamed the columns when listing library features. However I think the introductory might be a hard work, since the compilers' default usage of standard library implementation is not well-documented. --Fruderica (talk) 21:54, 6 May 2019 (PDT)

Equivalence of the signature of function objects

Hi,

the documentation of (e.g.) std::accumulate says:

 op The signature of the function should be equivalent to the following:

    Ret fun(const Type1 &a, const Type2 &b);

The signature does not need to have const &.

When is a signature "equivalent" to the above? 2001:B01:2404:4:0:0:0:57 23:49, 9 May 2019 (PDT)

This is handwaving vigorously. The basic requirement is that a set of expressions must work. But of course that's a bit abstract and we want to show what a function (object) that meets the requirement should look like. Hence the weasel-wording. Perhaps we should rephrase the requirements in terms of the required expressions, and then show sample signatures as examples? T. Canens (talk) 20:23, 17 May 2019 (PDT)

operator :: – ( I cannot edit https://en.cppreference.com/w/Talk:cpp/language/operator_precedence where it belongs to)

At https://en.cppreference.com/w/cpp/language/operator_precedence the token :: that is used to build nested names is listed as an "operator". But AFAIK this token is not an operator (or a very special one).

Because for any (binary) operator ★ the term A★B★C either means (A★B)★C _or_ A★(B★C) and you might add (…) to change the meaning.

But for :: you can't do this, because A::(B::C) does not compile, and (A::B)::C compiles, but is parsed as a type cast of ::C into the type A::B. :-/

What do you think? Should it be changed or at least mentioned? --Roker (talk) 04:01, 13 May 2019 (PDT)

the whole table is a loose approximation of expression grammar in human-readable terms of "precedence" and "associativity". These terms do not appear anywhere in the language specification, they are invented by the authors of the table. In the expression grammar, :: combines identifiers into primary expressions, so inasmuch as the grammar can be expressed in those terms, it has the "highest precedence". We could drop it, but then people used to seeing precedence tables from other sources such as enwiki:Operators_in_C_and_C++#Operator_precedence would say cppreference's table is incomplete and add it back. --Cubbi (talk) 06:40, 13 May 2019 (PDT)

They can already say that since cppreference's table does not include const_cast et al, though.

OTOH, the standard calls :: an operator in [over.oper]/3. --D41D8CD98F (talk) 11:06, 14 May 2019 (PDT)

Add reference to paragraph about automatically generated class member functions

Hi there.

In https://en.cppreference.com/w/cpp/language/classes, I suggest in the last paragraph we add references to the rule of zero/three/five.

The very last sentence says:

"Some member functions are special: under certain circumstances they are defined by the compiler even if not defined by the user."

This would be an optimal place to refer to the rule of zero/three/five (link: https://en.cppreference.com/w/cpp/language/rule_of_three).

217.10.52.10 05:02, 13 May 2019 (PDT) André Malcher

Help to translate

Eu gostaria de ajudar a traduzir as páginas para o português do Brasil, por que tem grande diferenças do de Portugal.

Gostaria de saber como posso fazer isso?

Add argument types in the examples

https://en.cppreference.com/w/cpp/io/c/fprintf

Stupidly enough, despite the extensive examples, there is none using the argument types (e.g. %lu)

AI using C++...

[ai.stackexchange.com/questions/6185/why-does-c-seem-less-widely-used-in-ai] is the source of the following. I have inserted links to the libraries web sites. You don't need a powerful language for programming AI. Most of the developers are using libraries like Keras,[keras.io] Torch [torch.ch], Caffe,[caffe.berkeleyvision.org] Watson [cloud.ibm.com/developer/watson/dashboard], TensorFlow,[www.tensorflow.org] etc. Those libraries are highly optimized and handle all the though work, they are built with high performance languages, like C. Python is just there to describe the neural network layers, load data, launch the processing and display results. Using C++ instead would give barely no performance improvement, but would be harder for non-developers as it require to care for memory management. Also, several AI people may not have a very solid programming or computer science background.

Another similar example would be game development, where the engine is coded in C/C++, and, often, all the game logic scripted in a high level language. Ian Martin Ajzenszmidt (talk) 05:39, 18 May 2019 (PDT)

Add See also: reference to <iomanip> from std::string?

Just a stray thought for improved navigation. For new C++ users that find themselves at [std::basic_string](https://en.cppreference.com/w/cpp/string/basic_string) and the next place many would need to go a majority of the time would be to <iomanip>. Would it be worth adding a ***See Also:*** reference to <iomanip>. Especially for those who do not yet know <iomanip> exists. Drankinatty (talk) 18:26, 18 May 2019 (PDT)

cpp/language/operator_comparison

first sentence of the the section Notes currently is:

Because these operators group left-to-right, the expression a<b<c is parsed (a<b)<c, and not a<(b<c) or (a<b)&&(b<c).

but the following would be clearer to understand:

Because these operators group left-to-right, the expression a<b<c is parsed (a<b)<c, and neither a<(b<c) nor (a<b)&&(b<c).

where can be donations be sent?

Hello ! I read about the donations, can you give me please more informations about whre can the donations be made? it will be very usefull. Thanks ! Sorry for disturbing the discussion page -Giani

contradiction in definition of std::filesystem::weakly_canonical

In the description of std::filesystem::weakly_canonical, it is stated that the parameter p must be an existing path. This is in contradiction with the description of the function std::filesystem::weakly_canonical, that states that p can consist of an existent left-hand-side and a non-existent right-hand-side.

Parallelism TS 2

• https://en.cppreference.com/w/cpp/experimental/simd needs to be linked from https://en.cppreference.com/w/cpp/experimental/parallelism_2.
• https://en.cppreference.com/mwiki/index.php?title=cpp/experimental/simd/abi_for_size needs to be renamed (as happend in the WD before the TS was published) to simd_abi::deduce.
• Most of the simd documentation needs to either be updated to TS state or written.
• I could help (author of that part of the TS).

Vir (talk) 03:12, 27 May 2019 (PDT)

First two bullets are done. --Fruderica (talk)

suggestion for the Private Inheritance section

this sentence is hard to read:

Using a member offers better encapsulation and is generally preferred unless the derived class 
requires access to protected members (including constructors) of the base, needs to override a 
virtual member of the base, needs the base to be constructed before and destructed after some 
other base subobject, needs to share a virtual base or needs to control the construction of a 
virtual base.

this is much easier, using a list:

Using a member offers better encapsulation and is generally preferred unless the derived class:
--requires access to protected members (including constructors) of the base
--needs to override a virtual member of the base
--needs the base to be constructed before and destructed after some other base subobject
--needs to share a virtual base or needs to control the construction of a virtual base

75.142.108.70 14:01, 2 June 2019 (PDT)

Suggested addition for std::time page

Please add links to the following pages in the "See also" section of https://en.cppreference.com/w/cpp/chrono/c/time

https://en.cppreference.com/w/cpp/chrono/c/asctime https://en.cppreference.com/w/cpp/chrono/c/strftime

139.181.7.34 16:30, 4 June 2019 (PDT)

the headline for the non-throwing deletes is incorrect

functions 9-12 are headlined as placement versions, whereas they are non-throwing versions.

new(nothrow) is placement-new by expr.new/15 --Cubbi (talk) 05:07, 6 June 2019 (PDT)

now I see, cpp/memory/new/operator_new calls them "replaceable non-throwing", while cpp/memory/new/operator_delete calls them "replaceable placement".. Perhaps "non-throwing" is more user-friendly even if all of them are actually non-throwing --Cubbi (talk) 06:41, 6 June 2019 (PDT)

Only for multidimensional arrays?

I think the description should read "(potentially multidimensional) array" instead of "multidimensional array".

Can a standard exception object embed a fixed-size array?

The documentation for e.g. std::runtime_error, at

 <https://en.cppreference.com/w/cpp/error/runtime_error>,

states:

 "Because copying std::runtime_error is not permitted to throw exceptions,
  this message is typically stored internally as a separately-allocated
  reference-counted string."

Would it be OK to store the message into an array data member? That means that the string could have to be truncated, so the question is whether having a maximum length falls under possible implementation-defined limits. 37.182.205.198 03:06, 13 June 2019 (PDT)

The string cannot be truncated because of the post-condition. Though I think that constructors of std::runtime_error taking const char* and const std::string& are still permitted to throw exception if the string is too long, and an array of char embedded in the exception object is also permitted --Fruderica (talk) 03:55, 13 June 2019 (PDT)

std::size_t error in example

Reverse iteration. Unsigned variable taking values lower than 0.

   for (std::size_t i = a.size()-1; i < a.size(); --i)

Should be:

   for (std::size_t i = a.size()-1; i >= 0; --i)

std::size_t is an unsigned integer type, so i >= 0 always holds and the loop you suggested is endless. On the other hand, if i == 0 then --i make i equals to the maximum value of std::size_t which is almost always larger than a.size(), so the loop will reach its end. If you don't like this, something like for (std::size_t i = a.size(); i != 0;) { --i;/*...*/} might be useful. --Fruderica (talk) 04:56, 21 June 2019 (PDT)

Typo on std::iterator page

Hi,

In the example section of the std::iterator page it says '.. _a_ input iterator ..' which should be '.. _an_ input iterator ..'.

Thanks for the truly excellent resource that is cppreference.

Best regards,

Kris van Rens 5.132.118.36 13:44, 22 June 2019 (PDT)

Enum syntax: trailing semicolon

It appears that on the enum declaration page, a trailing semicolon is missing at various places for the enum declarations.

Replace dead link in rule of three page with archive.org link

The link to the original source for the "rule of zero" on the page https://en.cppreference.com/w/cpp/language/rule_of_three is dead.

Perhaps change https://rmf.io/cxx11/rule-of-zero to https://web.archive.org/web/20160602100235/https://rmf.io/cxx11/rule-of-zero/

73.8.19.235 09:19, 10 July 2019 (PDT)joe

errno and strto* examples

On some examples, like strtol, errno is not reset before calling the function and is checked after an intermediate call to other functions, such as printf, which can set errno itself.

Although it is not relevant for the correct execution of the example, IMHO those code snippets should be a vehicle for promoting good practices. So I suggest to clear errno before calling strto* and test (or save) it immediately after the call.

79.151.6.162 10:19, 11 July 2019 (PDT)oscarfv

Subsume is synonym for implies.

On TS variant of concepts at: https://en.cppreference.com/w/cpp/experimental/constraints

You have inconsistency in your definitions/use of the word subsumes. Subsumes is synonym for implies by your first definition. (and also by C++20 standard version of concept https://en.cppreference.com/w/cpp/language/constraints)

1) "Concept P is said to subsume concept Q if it can be proven that P implies Q"

2) "A subsumes a conjunction A&&B and does not subsume a disjunction A||B"

But

Mathematically in truth/boolean logic this is tautology for conjunction (always true):

A&&B implies  A 

and also always

A&&B implies  B 

so by first definition of word 'subsume' the second statement above should be other way around

A&&B subsumes A

and also mathematically for disjunction (boolean logic):

A implies A||B  

and also

B implies A||B

Now replace word implies for subsumes in those statements and you get contradiction again to your second statement 2).

Also note:

 A||B does not imply A
 A||B does not imply B

so again does not subsume.

On another note: You derive class to model 'is-a' relationship or subset relationship. You narrow down original big class of animals.

class Cat:Animal {}

Cat is an animal. Set of cats is subset of set of all animals.

Or you have implication "x is a cat implies x is an animal" , but not otherway around 'x is animal' does not imply 'x is a cat'. In concept language: Cat is additional constraint on top of animal. (Moveable and meowavle) and additional constraint makes class smaller subset and smaller subset means. So you either say Animal set subsumes Cats sub-set. Or you use 'subsume' for the characteristics (like in concepts). Cat characteristic subsumes Animal characteristics (x is a cat assumes/implies/subsumes x is a living being).

@ sign is displayed in place of overloaded operators

Sorry about the previous message, I accidentally posted an edited page instead of the suggestion.

Edit suggestion: @ sign is being displayed instead of operators !, << and ++ in Overloaded Operators section.

overload resolution links in using-declaration

In the inheriting constructors section of the using_declaration it would be great to add a link when overload resolution is mentioned.

Unqualified name lookup->Class definition

I think a, c is incorrect because of class scope and his accessing rules - all names defined in class is available in entire class even if declaration is put below instruction of use.

d - if class is nested into another class then entire outer class will be searching and if name will still not found then local scope until definition class - because function accessing rules.

the rules you're describing are a little lower, in cpp/language/unqualified_lookup#Member_function_definition --Cubbi (talk) 08:23, 2 August 2019 (PDT)

main() is indented 4 spaces. Unlike the rest. Please make that 2 spaces.

main() is indented 4 spaces. Unlike the rest. Please make that 2 spaces.

PS Can't I get edit rights? I'm not vandalizing, so...

C fwrite missing error behaviour regarding file position.

If an error occurs, the resulting value of the file position indicator for the stream is indeterminate.

13.236.57.85 01:41, 6 August 2019 (PDT)

inconsistent find/rfind description

I don't think "find characters" is good wording for find on the main page of basic_string, should be "find substring" (or "find character sequence" as it's put in https://en.cppreference.com/w/cpp/string/basic_string/find) in order to avoid confusion with find_first_of. Also find/rfind titles should be consistent imo, "find the first/last occurrence of a substring" seems to be a good fit

https://en.cppreference.com/w/cpp/string/basic_string

find: "find characters in the string" rfind: "find the last occurrence of a substring"

180.183.72.126 22:38, 6 August 2019 (PDT) Vitaly

Template:cpp/container/lower bound

Add "(i.e. greater or equal to)" after "that is not less than" (like the text on cpp/algorithm/lower bound).

Suggestion for clarity

The description for the return value contains the phrase, "Nonzero integral value if arg is negative." While technically correct, I think it's worth considering changing "integral" to "integer." ZephyrCubic (talk) 14:34, 11 October 2023 (PDT)

this is about c/numeric/math/signbit which is actually shown in C99 and C11 synopsis with a return type of type int, so I agree, "integer" would be more to the point. --Cubbi (talk) 20:28, 11 October 2023 (PDT)

Forward declaring enums in C

c/language/enum says "...there are no forward-declared enums in C". However, C23 in 6.7.2.2 /6 explicitly allows a forward-declaration of an enum as long as the underlying type is specified ("An enum specifier of the form enum identifier enum-type-specifier may not appear except in a declaration of the form enum identifier enum-type-specifier ; ...") --2A02:586:292B:EA0E:E08F:CE97:FFEA:E15E 06:20, 15 October 2023 (PDT)

Forgot to mention that the example at 6.7.2.2/18 shows exactly this. --2A02:586:292B:EA0E:E08F:CE97:FFEA:E15E 06:47, 15 October 2023 (PDT)

Add to this c/language/declarations which says that every declaration of an enum is a definition. That should be tagged as until C23. 2A02:1388:9D:F494:0:0:5403:3A5F 00:41, 25 January 2024 (PST)

Missing redirects

cpp/numeric/math/HUGE_VALF and cpp/numeric/math/HUGE_VALL redirect to cpp/numeric/math/HUGE_VAL. c/numeric/math/HUGE_VALF and c/numeric/math/HUGE_VALL should similarly go to c/numeric/math/HUGE_VAL.--2A02:586:292B:EA0E:30A6:F697:75DA:1AC1 11:28, 15 October 2023 (PDT)

Might as well ✔ Done --Ybab321 (talk) 13:24, 15 October 2023 (PDT)

The use of the comma operator in the example code at https://en.cppreference.com/w/Template:cpp/container/constructor is unnecessary and confusing for inexperienced c++ developers Alanbirtles (talk) 23:22, 17 October 2023 (PDT)

It's kinda funny yeah, but you gotta get that comma operator experience somewhere right? Otherwise you'll be doomed to be inexperienced forever! But yeah, it's a bit comma abusive, not against changing it to two statements --Ybab321 (talk) 02:26, 18 October 2023 (PDT)

the comma has a lot of cute semi-idiomatic uses (maybe I should list them on cpp/language/operator_other#Built-in_comma_operator - the example there is just showing what it does, but not what it's good for ).. As for this example, I think it's a good idea to keep the container printing code tight so that more of the example can be about the topic of the page. Personally I'd just space-separate them with the dangling space in the end. --Cubbi (talk) 10:37, 18 October 2023 (PDT)

std::expected doesn't work on clang-16 and clang-17

std::expected not available on clang-16 or clang-17

clang-16 compile failure:

https://github.com/acgetchell/CDT-plusplus/actions/runs/6621477342/job/17985496207

clang-17 compile failure:

https://github.com/acgetchell/CDT-plusplus/actions/runs/6621477365/job/17985496236

gcc-12 compile success:

https://app.travis-ci.com/github/acgetchell/CDT-plusplus/jobs/612081167

gcc-13 compile success:

https://github.com/acgetchell/CDT-plusplus/actions/runs/6621477345/job/17985496195

It also compiles successfully on macOS with libc++ included with Xcode 15.

Calling clear after istringstream::str

I think there should be some note on `https://en.cppreference.com/w/cpp/io/basic_istringstream/str` to call `istringstream::clear` after setting a new input string by `istringstream::str`. Otherwise, if you've read on the preceding string to the end, and the eof or fail bits are set, reading from the new string will fail. 2003:DC:AF3C:5600:405F:3FE8:146F:36E7 08:32, 25 October 2023 (PDT)

Hm, this is a general property of reaching the end of a stream and then reusing it. Such a note would apply to std::istream::seekg, std::ifstream::open and std::ispanstream::span, so probably worth writing a transclusion for. Tempting to just put clear() into the code examples... In any case, I agree, that would be a good note --Ybab321 (talk) 10:39, 25 October 2023 (PDT)

there's some variety here; cpp/io/basic_ifstream/open clears all flags (but remember to close before reopening), cpp/io/basic_istream/seekg clears EOF but not others. I could see a Note on cpp/io/basic_istringstream/str "unlike ifstream::open, non-const overload of str does not clear...". And I suppose a note on ifstream::open to close before reopen. --Cubbi (talk) 12:29, 25 October 2023 (PDT)

Add to pages about language features what compilers support said features

The current compiler support page albeit helpful is hard to navigate and find specific features and what compilers support them and the version of the compiler the support is offered at. I'd be extremely helpful if right before the see more section of the page there was also a table that shows compiler support for the most major compilers for the specific feature the page is about. Or in the very least a link that sends to you to the location of said feature in the compiler support page.

What you probably want is something like the "Browser compatibility table" in MDN. Unfortunately, cppreference is not backed by any compiler vendor (unlike MDN), so there is no mechanism to keep track of the compiler implementation status except manual updates by user edits. Compatility tables spreading across the site are difficult to maintain, since users need to navigate to many different pages to update the compiler implementation status.

What the pages currently have are the "Notes" sections, which contain the notable compiler incompatibilities and these feature-test macro tables (since C++20). The way recommended by the C++ standard to check whether a language/library feature is implemented is to use the feautre-test macros. --Xmcgcg (talk) 22:54, 26 October 2023 (PDT)

This can be done with a script. I've actually written one and have been using it since last year, and I think this script is good enough to help readers. See Talk:Main Page#Proposal: add User:D41D8CD98F/append-support-info.js for all users. --D41D8CD98F (talk) 23:44, 26 October 2023 (PDT)

   ... in the very least a link that sends you to the location
   of said feature in the compiler support page ...

Exactly this can be done relatively easily. Actually, this is almost what was already done with links to general FTM tables. I only need to update {{ftm}}/{{feature test macro}} templates (to deduce a proper link from known ftm and rev) and add an anchor to each row of compiler support table, based on their FTM (this means creating only one more template alike {{tta}} = Teletype Text + Anchor, etc). No need to update individual FTM-tables (spread across pages). The main work then is to update compiler support tables by filling one additional internal field per each target entry. ⇒ No interference with server cache, no javascript, no html-injection (which is great but, maybe, not all users are interested in compiler support stuff). And the maintenance would be relatively cheap w.r.t. manpower, but not as cheap as with script-solution.) --Space Mission (talk) 15:44, 27 October 2023 (PDT)

std::error_category::message and related are not thread-safe

Relevant pages:

• std::error_code::message
• std::error_category::message
• std::system_error because of std::system_error::what

Because these types use std::strerror internally, they are not thread-safe (this is documented on the page of std::strerror).

Here's just one implementation from GCC: [1] [2]

I think it should be documented that using these types is only appropriate in single-threaded applications!

--84.190.143.49 08:22, 3 November 2023 (PDT)

Glibc has thread-safe strerror, as does musl and newlib. We can say that libstdc++'s error_category::message is not thread-safe if used with a libc that is not well-known, but I doubt whether anyone do this in practice, and whether libstdc++ officially supports such usage. --D41D8CD98F (talk) 19:47, 3 November 2023 (PDT)

In glibc, this was only added 2020-05-14 [3] and so was first released in glibc 2.32 [4]. For example, debian oldstable and oldoldstable which still are supported LTS versions use glibc versions older than this [5][6]. Many proprietary/legacy systems probably use older and will continue to do so for many years. That should be considered too apart from just the possibility of exotic libc implementations. 2003:E8:2726:6D00:80E3:B475:E170:AF01 13:12, 4 November 2023 (PDT)

memory_order should mention that read-modify-write operations always read the last value

I searched in cppreference, but it seems that currently there's no page mentioning this.

https://eel.is/c++draft/atomics#order-10

Should decltype be added to the list of operators?

I argue that it should, for consistency with c/language/typeof which is referred to as the "typeof operator" in C23 6.7.2.5. Note that there is precedent for calling decltype an operator, see n2343. If you disagree then at least remove typeof from c/language/operator_other and remove the name typeof operator from c/language/typeof since it would be weird if one is an operator and the other is not.--2A02:586:292B:EA0C:91D9:325:3A52:19C1 11:38, 4 November 2023 (PDT)

typeof should be removed from the C operator list. The term “typeof operators” is just a collection of typeof and typeof_unequal. --Xmcgcg (talk) 01:07, 5 November 2023 (PDT)

Type punning using unions in C89/C90

The page https://en.cppreference.com/w/c/language/union says the following:

> If the member used to access the contents of a union is not the same as the member last used to store a value, the object representation of the value that was stored is reinterpreted as an object representation of the new type (this is known as type punning). If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.

The highlighted part looks wrong to me, because C89 clearly defines this as implementation-specified behaviour, not undefined one. See 3.3.2.3: Structure and union members (or 6.3.2.3 in C90), here's an excerpt:

> With one exception, if a member of a union object is accessed after a value has been stored in a different member of the object, the behavior is implementation-defined.

It's also worth noting that in C99 this sentence was removed, and I have no idea, why. The TC3 for C99 was issued noticeably later.

See in addition these SO answers:
https://stackoverflow.com/questions/52290456/is-the-following-c-union-access-pattern-undefined-behavior/52291386#52291386
https://stackoverflow.com/questions/25664848/is-it-allowed-to-use-unions-for-type-punning-and-if-not-why/25672839#25672839
https://stackoverflow.com/questions/55010795/type-punning-between-integer-and-array-using-union/55012433#55012433
https://stackoverflow.com/questions/11373203/accessing-inactive-union-member-and-undefined-behavior/11373277#11373277

Also, why the "References" sections refer to C89/C90 standard as ISO/IEC 9899:1990, but provide chapter numbering as in ANSI X3.159-1989? Although the names of the chapters themselves are given without capitalization, as it's in the ISO document, not ANSI one.

--Cher-nov (talk) 03:25, 1 December 2023 (PST)

Template:cpp/compiler_support/dump incorrect usage of __has_cpp_attribute

At Template:cpp/compiler_support/dump, we can read

#ifdef __has_cpp_attribute
# define COMPILER_ATTRIBUTE(expect, name) { #name, __has_cpp_attribute(name), expect },
#else
# define COMPILER_ATTRIBUTE(expect, name) { #name, COMPILER_VALUE_INT(name), expect },
#endif

but unfortunately that is an incorrect usage of __has_cpp_attribute.

Quoting cpp/feature_test:

__has_cpp_attribute can be expanded in the expression of #if and #elif. It is treated as a defined macro by #ifdef, #ifndef, #elifdef, #elifndef(since C++23) and defined but cannot be used anywhere else.

And thus __has_cpp_attribute(name) cannot be used in the definition of another macro, like COMPILER_ATTRIBUTE.

gcc and clang will accept that code, but MSVC will not. See on compiler explorer: https://godbolt.org/z/6j6Mexeee

-- Lrineau (talk) 02:57, 21 December 2023 (PST)

Here is more conformant implementation: https://godbolt.org/z/jns9EEGab. The obvious drawback is that it requires +50+LOC, which is quite a lot for this "example". Currently, only more light-weight fix is applying to code - a plain check for gcc/clang, so msvc will also run, but w/o attributes info support. --Space Mission (talk) 16:51, 22 December 2023 (PST)

__has_c_attribute has an incorrect description

The description of __has_c_attribute in c/language/attributes should be exactly the same as the description of __has_cpp_attribute from cpp/feature_test. However, the fact that __has_c_reference can appear in #elifdef and #elifndef directives was not copied over despite these directives existing in C23. --2A02:586:292B:EA0C:5D4A:A41:7147:ECE7 06:00, 21 December 2023 (PST)

pointer to member `operator->*`

Hi everyone,

I'd like to add sqlite_orm to the list of EDSL libraries that overload the pointer-to-member `operator->*` in a meaningful way

The addition should come after cpp.react in Section "Rarely overloaded operators" of page https://en.cppreference.com/w/cpp/language/operators#Rarely_overloaded_operators.

Thanks, Klaus Triendl.kj (talk) 08:55, 25 December 2023 (PST)

I can't add even links to blogs now

Some discussion with few examples:

https://devtut.github.io/cpp/std-optional.html

https://www.codingninjas.com/studio/library/std-optional

Many points aren't mentioned inany way at std::optional. std::optional isn't the newest now...

I can't link an article like [[std::optional]] as well.

I can't use talk pages. I can't register. 95.26.137.42 00:28, 5 January 2024 (PST)

Compiler support is missing at individual pages.

Keep just 1 row from Compiler support for C++17 at std::optional.

Some reasonable duplication is helpful here. 95.26.137.42 01:24, 5 January 2024 (PST)

Programming languages, implementations, variants and extensions

I support both C and C++ together as they are related.

I am missing several C++ variants.

I prefer to have one MediaWiki namespace per each. 95.26.137.42 01:36, 5 January 2024 (PST)

Asterisks aren't clear and hovers aren't mobile, print friendly

I can't access notes at pages like cpp/compiler support.

× The incomprehensible blob from the previous post was deleted.

Please repeat using normal UTF-8 text, not "jquery", if your post had any value. --Space Mission (talk) 20:55, 5 January 2024 (PST)

Unsequenced and reproducible used incorrectly

While one could make the argument that it's obvious, I think c/language/attributes/unsequenced should mention what happens in the case the attributes get appled incorrectly. The standard says:

"[...] if a definition that does not have the asserted property is accessed by a function declaration or a function pointer with a type that has the attribute, the behavior is undefined"

so something to that effect should be added to the page. --85.74.201.230 06:02, 7 January 2024 (PST)

aligned_alloc() and alignments less than sizeof(void *)

The page for aligned_alloc() claims that

Fundamental alignments are always supported.

just after observing that

As an example of the "supported by the implementation" requirement, POSIX function posix_memalign accepts any alignment that is a power of two and a multiple of sizeof(void *), and POSIX-based implementations of aligned_alloc inherit this requirements.

The two appear to be mutually exclusive — under the POSIX model, alignments less than sizeof(void *) are not valid, which would mean that trying to use alignments of 1, 2 or 4 on a machine with 64-bit pointers won't work — though 1, 2 and 4 are "fundamental alignments".

Additionally, I can't find wording in any of the C standards to support the claim that "fundamental alignments are always supported". All it says on that subject is that

The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and size less than or equal to the size requested.

i.e. the allocation may fail, and one of the reasons it may fail is an unsupported alignment, for instance in a POSIX-based implementation, one smaller than sizeof(void *).

Al45tair (talk) 03:31, 8 January 2024 (PST)

DR 460 lays out the standard wording (and is somewhat relevant too). Does seem like posix_memalign isn't a conforming aligned_alloc --Ybab321 (talk) 12:25, 9 January 2024 (PST)

(Technical) MediaWiki version

According to Special:Version, this wiki is running on MediaWiki version 1.21.2, which has reached end-of-life since 2014! If we upgrade it, we'll be able to use have security fixes, in-site search and the awesome WikiEditor(not visual). Is there any reason the software is so outdated? Aaron Liu (talk) 11:32, 14 January 2024 (PST)

This site depends on a bunch of home-made extensions (e.g. AutoLinker and CustomList) and skins (Cppreference and Cppreference2, the latter being the default skin). I guess at least some of them are not compatible with the latest MediaWiki. --D41D8CD98F (talk) 03:42, 15 January 2024 (PST)

Assuming only extensions by Mr. Kanapickas are homemade:

• NativeSvgHandler has an updated, supported version.
• AddBodyClass has a pull request to update it.
• Skins can probably be straight up used in the new version of MediaWiki and at most output warning messages about deprecated hooks, as was the case with Cologne Blue.

AutoLinker and CustomList are indeed not updated yet. Aaron Liu (talk) 06:52, 15 January 2024 (PST)

user: Egorpugin

Requesting edit rights. Need to do some fixes to compiler support page.

As a quick alternative, could you list the proposed changes here so we can integrate them. --Space Mission (talk) 05:04, 15 January 2024 (PST)

Title in Copy elision page is confusing

Related page: https://en.cppreference.com/w/cpp/language/copy_elision

Title: 1.2 Non-mandatory copy/move elision Later in this chapter, it is indicated that from C++17 on, the optimization is mandatory. As such, similar to the inline correction for C++11, this should have an inline correction indicating that the `non-` is only until C++17 — Preceding unsigned comment added by JVApen (talk • contribs) 00:33, 15 January 2024‎

Only unnamed return value optimization is mandatory since C++17. I've adjusted the markup to clarify that. --D41D8CD98F (talk) 03:50, 15 January 2024 (PST)

Incorrect note describing sizeof with VLA types

This page c/language/array#Notes provides the following example:

int n = 5;
size_t sz = sizeof(int (*)[n++]); // may or may not increment n

which says that the expression sizeof(int (*)[n++]) may or may not increment n. This should never increment n, considering that the expression is a constant expression.

Section 6.5.3.4 "The sizeof and _Alignof operators" Paragraph 2 ISO/IEC 9899:2018

The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. The size is determined from the type of the operand. The result is an integer. If the type of the operand is a variable length array type, the operand is evaluated; otherwise, the operand is not evaluated and the result is an integer constant.

The type int (*)[n++] is not a variable length array type (it is variably modified but this is different from being a variable length array type) so the operand is not evaluated and the result is an integer constant. This can be demonstrated with a statement that requires the expression to be an integer constant expression:

int n = 5;
enum {E = sizeof(int (*)[n++])};

A better example would be:

int n = 5;
int m = 5;
size_t sz = sizeof(int (*[n++])[m++]);
// n is always incremented
// m may or may not be incremented

looks like I put that in 9 years ago trying to illustrate 6.7.6.2p5 which doesn't appear to restrict itself to VLAs or even evaluated operands, but, yes, this makes more sense, OTOH I am not sure there are compilers that skip side effects and maintaining an example on that note at all may be elevating obscure trivia. I'll put your example in though. --Cubbi (talk) 16:06, 16 January 2024 (PST)

Non-compiling exemple in alignas page

The page https://en.cppreference.com/w/cpp/language/alignas contains an example in which one of the lines is:

       << "alignof(cacheline) = " << alignof(alignas(64) char[64]) << '\n'

This line does not compile and if replaced by:

       << "alignof(cacheline) = " << alignof(cacheline) << '\n'

It is still a GNU extension (-Wgnu-alignof-extension)

Have a nice day

Joseph

195.68.40.4 05:56, 17 January 2024 (PST)

✔ Updated with type alias.) --Space Mission (talk) 14:00, 17 January 2024 (PST)

Suggestion to update c/preprocessor/conditional

I would suggest to add phrasing to c/preprocessor/conditional that indicate that operators that involve types (type casts, sizeof) are not allowed inside #if conditions.

is_corresponding_member broken link

https://en.cppreference.com/w/cpp/types/is_corresponding_member

The "Standard layout" section in language/data_members was renamed to "Standard-layout", breaking the "common initial sequence" link at the top.

--155.4.128.189 02:48, 19 January 2024 (PST)

✔ Done. The link's been fixed. Thanks. --Space Mission (talk) 05:22, 19 January 2024 (PST)

etalon, n. 1. A Fabry-Pérot interferometer. 2. archaic. An uncastrated male horse; a stallion.

Curiously, there once was even more obsolete meaning of ‘etalon’ that fell out of use by the Late Middle English period, probably in the early 14c: 3. A castrated male sheep; a wether.

I don't have a permission to modify the pages https://en.cppreference.com/w/cpp/memory/ranges/uninitialized_default_construct and https://en.cppreference.com/w/cpp/memory/ranges/uninitialized_default_construct_n.

I would really appreciate it if anyone blessed with edit access could replace etalon in the code example with e.g., letters, abcd, or anything else that you may find more appropriate. ‘Etalon’ is clearly not a meaningful identifier. — ⋖ Cy “kkm” K. N.  ∺  talk ⋗ 03:56, 19 January 2024 (PST)

I've replaced the word etalon (one of the meaning – "standard of measurement", from early 20th century French étalon) with more neutral sample which is close enough to the originally intended meaning. Will it be good enough)? Ah, thanks anyway.) ✔ Done --Space Mission (talk) 06:11, 19 January 2024 (PST)

Grammatical error in the definition of common initial sequence

In cpp/language/data_members#Standard-layout the following text appears

if __has_cpp_attribute(no_unique_address) is not ​0​, neither entities is declared with [[no_unique_address]] attribute, [...]

Obviously, "entities" was supposed to be "entity". 2A02:586:293C:DCEC:A977:6FE6:9A1:5D5 08:47, 19 January 2024 (PST)

✔ Done.) --Space Mission (talk) 13:30, 19 January 2024 (PST)

Anchor bug in cpp/compiler support

In the page cpp/compiler support, the C++23 core language features link anchors to the C++26 section. This is due to what looks like a copy/paste error: the C++23 anchor is above the C++26 section and there is no anchor above the C++23 section. The page is locked due to vandalism, hence I am posting here.

Md5i (talk) 18:40, 23 January 2024 (PST)

✔ Fixed: cpp/compiler support. Thanks.) --Space Mission (talk) 01:07, 24 January 2024 (PST)

FMA modification of macros

I can't edit the page, but the page on fma says, "f the macro constants FP_FAST_FMA, FP_FAST_FMAF, or FP_FAST_FMAL are defined, the function std::fma evaluates faster (in addition to being more precise) than the expression x * y + z for float, double, and long double arguments, respectively." This is incorrect. Either the macro order must be changed to "P_FAST_FMAF, FP_FAST_FMA, or FP_FAST_FMAL" or the types must be changed to "double, float, and long double."

https://en.cppreference.com/w/cpp/numeric/math/fma

✔ Fixed, and for C as well --Cubbi (talk) 11:23, 24 January 2024 (PST)

Comma expressions in initializers

cpp/language/initialization says that the expressions used in initializations cannot be comma expressions. That should be changed to unparenthesized comma expressions since parenthesized comma expressions are allowed in that context 2A02:1388:9D:F494:0:0:5403:3A5F 23:44, 24 January 2024 (PST)

Parenthesized expressions are classified as primary expressions. If a parenthesized expression is also accepted in certain context, the wording will include “(possibly parenthesized)” or “(possibly enclosed in parentheses)”. --Xmcgcg (talk) 02:30, 25 January 2024 (PST)

I guess no change is needed then. Still, the standard includes a note that makes it explicit and we also mention parentheses explicitly in cpp/language/operator_member_access#Built-in_subscript_operator so I still think it should be added --2A02:1388:9D:F494:0:0:5403:3A5F 06:20, 25 January 2024 (PST)

Add a new library

Pytype - A C++ type library that is as easy to use as Python built-in types.

Incorrect word in description of basic_string overload 10)

On the following page https://en.cppreference.com/w/cpp/string/basic_string/basic_string the description of the constructor overload 10) starts with word "Implicitly". However, there is a keyword "explicit" in the declaration of that overload. Probably the word "Implicitly" should be removed or changed to "Explicitly".

Ilja Keikov e-mail: [email protected] 84.50.190.130 07:11, 26 January 2024 (PST)

To explicitly convert an argument t to std::string, it must be implicitly convertible to std::string_view --Ybab321 (talk) 07:59, 26 January 2024 (PST)

Wrong version in std::vector::resize

In Template:cpp/container/resize "since=11" is used instead of "since=c++11". 2A02:586:293C:DCEC:C401:49EB:D5B7:8BB 15:13, 26 January 2024 (PST)

✔ Fixed.) --Space Mission (talk) 16:03, 26 January 2024 (PST)

Simplify the example in std::ios_base::width

I read the article on std::ios_base::width, and I think the example code is too complicated as a reference for people learning C++ because it uses too many C++ features that they likely don't yet know.

There is a gratuitous round-trip conversion from a chrono date literal at compile time to a std::chrono::year_month_day and then back to a string at runtime. Next, an IILE is used just to make a local const, and the IILE uses the C++23 UZ suffix and auto to make i an integer when declaring it as size_t is more straightforward. There is also gratuitous use of std::ranges::for_each and init-statements in both an if statement and range-based for loops. It uses C++23's lambdas without () which doesn't yet seem to be available in MSVC. The column width computation could arguably just be replaced with an array of numbers to avoid the doubly nested loop, but I didn't do this.

Example

#include <algorithm>
#include <array>
#include <iomanip>
#include <iostream>
#include <string>
 
int main()
{
    constexpr int column_size = 4;
    using table_t = std::array<std::string, column_size>;
 
    const auto data = std::to_array<table_t>
    ({
        {"Language", "Author", "Birthdate", "Death date"}, // header
        {"C", "Dennis Ritchie", "1941-09-09", "2011-10-12"},
        {"C++", "Bjarne Stroustrup", "1950-12-30", {}},
        {"C#", "Anders Hejlsberg", "1960-12-02", {}},
        {"Python", "Guido van Rossum", "1956-01-31", {}},
        {"Javascript", "Brendan Eich", "1961-07-04", {}}
    });
 
    // calculate width of each column
    std::array<int, column_size> cols_w;
    cols_w.fill(0);
 
    for (auto const& row : data)
        for (size_t i = 0; i != row.size(); ++i)
            cols_w[i] = std::max(cols_w[i], (int)row[i].size() + 2);
 
    auto print_line = [&cols_w](table_t const& tbl)
    {
        std::cout << '|';
        for (size_t i = 0; i != tbl.size(); ++i)
        {
            std::cout.width(cols_w[i]);
            std::cout << (' ' + tbl[i]) << '|';
        }
        std::cout << '\n';
    };
 
    auto print_break = [&cols_w]
    {
        std::cout.put('+').fill('-');
        for (auto w : cols_w)
        {
            std::cout.width(w);
            std::cout << '-' << '+';
        }
        std::cout.put('\n').fill(' ');
    };
 
    std::cout.setf(std::ios::left, std::ios::adjustfield);
    print_break();
    bool header = true;
    for (auto const& entry : data)
    {
        print_line(entry);
        if (header)
        {
            print_break();
            header = false;
        }
    }
    print_break();
}

+------------+-------------------+------------+------------+
| Language   | Author            | Birthdate  | Death date |
+------------+-------------------+------------+------------+
| C          | Dennis Ritchie    | 1941-09-09 | 2011-10-12 |
| C++        | Bjarne Stroustrup | 1950-12-30 |            |
| C#         | Anders Hejlsberg  | 1960-12-02 |            |
| Python     | Guido van Rossum  | 1956-01-31 |            |
| Javascript | Brendan Eich      | 1961-07-04 |            |
+------------+-------------------+------------+------------+

2601:985:4180:D2F0:DBA:A8D2:B585:F8F3 16:12, 26 January 2024 (PST) Jack

We're more primarily a reference site than a teaching site, but I mostly agree with the complaints. What I don't agree with is that init statements in if/for statements or lambdas without redundant parentheses being complicated or gatekeeper-esque. However, I think cramming lambdas into the main function is an unacceptable allergy to simple functions. Example is updated, thanks for the suggestion (feel free to give feedback) ✔ Done --Ybab321 (talk) 03:31, 8 February 2024 (PST)

Enhanced support in XCode 15.3 for compiler support page

See https://developer.apple.com/documentation/xcode-release-notes/xcode-15_3-release-notes

New Features
The following new features have been implemented:
P0645 - Text formatting (std::format)
P2286R8 - Formatting ranges
P1206R7 - ranges::to: A function to convert any range to a container
P2520R0 - move_iterator<T*> should be a random access iterator
P1328R1 - constexpr type_info::operator==()
P2693R1 - Formatting thread::id
P2505R5 - Monadic operations for std::expected
P2711R1 - Making multi-param constructors of views explicit
P2136R3 - std::invoke_r
P2494R2 - Relaxing range adaptors to allow for move only types
P2585R0 - Improving default container formatting
P0408R7 - Efficient access to basic_stringbuf’s buffer
P2474R2 - std::ranges::views::repeat
P0009R18 - std::mdspan
P2093R14 - Formatted output (std::ostream overload is not implemented yet)

✔ Added to C++20/C++23 tables.) --Space Mission (talk) 19:28, 28 January 2024 (PST)

C Operator Precedence

When parsing an expression, an operator which is listed on some row bounds its operands tighter (as if by parentheses) than any operator that is listed on a row further below it. For example, the expression *p++ is parsed as *(p++), and not as (*p)++.

Wrong return type of invoke_r

cpp/utility/functional/invoke says that invoke_r returns "The value returned by f, implicitly converted to R, if R is not void". That should be possibly cv void. 88.197.77.134 10:52, 29 January 2024 (PST)

Yup, thanks ✔ Done --Ybab321 (talk) 14:25, 29 January 2024 (PST)

Correction to cpp/algorithm/ranges/max_element

I noticed an error on https://en.cppreference.com/w/cpp/algorithm/ranges/max_element and wanted to correct it.

It currently says "Returns `first` if the range is empty." which should be `last`.

Ted Lyngmo (talk) 13:55, 1 February 2024 (PST)

Yep, ✔ Fixed. Thanks. --Space Mission (talk) 14:32, 1 February 2024 (PST)

Raylib to C Libs

https://en.cppreference.com/w/c/links/libs

need to add Raylib to Graphics https://www.raylib.com/ 89.238.178.198 09:26, 3 February 2024 (PST)

✔ Done: RayLib's been added. --Space Mission (talk) 13:24, 3 February 2024 (PST)

Alias template partial instantiation

It is not possible to have partial instantiation of an alias template. This point is not made. I read about this on P246 of C++ Templates 2nd ed. I have also tested this and it does seem to be correct.

There is no “partial instantiation”. If you are talking about “partial specialization”, that point is already noted in the alias template page. --Xmcgcg (talk) 17:38, 3 February 2024 (PST)

Partial instantiation does exist but not for alias templates. That point is not made. Xmcgcg you have clearly not heard of partial instantiation.

Define partial instantiation and/or give us a link to the code you used to test this claim --Ybab321 (talk) 14:52, 4 February 2024 (PST)

Ok I will do when I have the time.

Type definitions are not allowed inside of offsetof in C23

This page c/types/offsetof mentions defining types in offsetof, which in C23 is undefined behavior.

offsetof(type, member-designator)

which expands to an integer constant expression that has type size_t, the value of which is the offset in bytes, to the subobject (designated by member-designator), from the beginning of any object of type type. The type and member designator shall be such that given

static type t;

then the expression &(t. member-designator) evaluates to an address constant. If the specified type defines a new type or if the specified member is a bit-field, the behavior is undefined.

Section 7.21 "Common definitions <stddef.h>" Paragraph 4 N3096

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm was the proposal which made this invalid, and it says that this was never intended to be valid.

During past discussions of the defect the committee's consensus was that despite the absence of any statement to that effect, the standard does not intend to require implementatations to accept new types in offsetof.

The sections in Notes mentioning types being defined inside of offsetof and the text saying that the type name must not have a comma outside of any parentheses should be replaced with text explaining that defining types inside of offsetof is invalid.

It may also be worth adding the same thing to va_arg, since it seems very unlikely that defining a type there is intended to be valid (it would require some recursion to even be able to evaluate an expression like va_arg(v,struct S{int a;})). Though no wording exists in the standard regarding this so it may not be worth adding.

The edit that changed offsetof's description to what it is now references N3148 DE-137 which relaxed the restriction on offsetof. The current draft seems to be outdated. 2A02:586:293C:DCEC:D93D:8861:85FD:85B6 05:18, 6 February 2024 (PST)

Update C23 working draft to N3149

Please change N3096 on c/23 to N3149. --Aaron Liu (talk) 14:17, 6 February 2024 (PST)

The title of the section was changed to make it unique, by --Space Mission (talk) 16:32, 7 February 2024 (PST)

✔ Done. See C23. --Space Mission (talk) 16:32, 7 February 2024 (PST)

Typo in operator""ns example output

In example: 10000ns = 1000 nanoseconds Should be: 1000ns = 1000 nanoseconds

In std::literals::chrono_literals::operator""ns [7] In example: 10000ns = 1000 nanoseconds Should be: 1000ns = 1000 nanoseconds

Two sections were merged and the title was extended, by --Space Mission (talk) 15:38, 7 February 2024 (PST)

✔ Fixed: check it here. Thanks. --Space Mission (talk) 15:38, 7 February 2024 (PST)

std::pmr::monotonic_buffer_resource example has UB

In lambda `pmr_alloc_and_buf` there is a `std::array` being used as a storage for allocating elements inside it. However, standard says, that C++-style objects can't provide storage -- it's the reason why `std::aligned_storage_t` is deprecated in C++23. Changing `std::array` to C-style array would work fine here with respect to the standard.

Hm, but std::array as an aggregate is composed of a C-style array, so does that not make it OK? --Ybab321 (talk) 03:02, 7 February 2024 (PST)

better std::filesystem::space example

Regarding std::filesystem::space [8] , it would be very helpful for coders to have an example of how to calculate the disk use%.

I spent a long time trying stuff, until I came across this https://stackoverflow.com/a/74569692

In hindsight it is obvious, but this is probably what many people will want to do, so please can it be included, to cut down on unnecessary the googling time. PS: Hope I can register an account here soon . Thanks

#include <cstdint>
#include <filesystem>
#include <iostream>
 
double disk_usage(const std::filesystem::space_info &si)
{
    const double used = si.capacity - si.free;
    const double usage = used/(used + si.available); // https://stackoverflow.com/a/74569692
    return usage;
}
 
void print_space_info(auto const& dirs, int width = 15)
{
    (std::cout << std::left).imbue(std::locale("en_US.UTF-8"));
    for (const auto s : {"Use%", "Capacity", "Free", "Available", "Dir"})
        std::cout << "│ " << std::setw(width) << s << ' ';
    for (std::cout << '\n'; auto const& dir : dirs)
    {
        std::error_code ec;
        const std::filesystem::space_info si = std::filesystem::space(dir, ec);
        std::cout << "│ " << std::setw(width) << disk_usage(si)*100 << ' ';
        for (auto x : {si.capacity, si.free, si.available})
            std::cout << "│ " << std::setw(width) << static_cast<std::intmax_t>(x) << ' ';
        std::cout << "│ " << dir << '\n';
    }
}
 
int main()
{
    const auto dirs = {"/dev/null", "/tmp", "/home", "/proc", "/null"};
    print_space_info(dirs);
}

Would be happy to add, but shouldn't the calculation be 1 - double(si.free) / si.capacity? Seems like either free or available should be chosen and used consistently based on whether you care about privileged or non-privileged space --Ybab321 (talk) 03:25, 9 February 2024 (PST)

✔ Done. Added the disk_usage_percent() function with consistent usage of std::filesystem::space_info::free/available, plus a few minor extensions.) --Space Mission (talk) 19:33, 9 February 2024 (PST)

Incorrect possible implementation of std::invoke

LWG3655 needs to be applied to the possible implementation in cpp/utility/functional/invoke. 2A02:1388:181:A912:0:0:58E1:1110 00:32, 8 February 2024 (PST)

Updated (and also fixed I think), thanks ✔ Done --Ybab321 (talk) 02:57, 8 February 2024 (PST)

It is fixed now, thanks. However, I think(I tested it and it fails for unions 04:40, 9 February 2024 (PST)) cpp/types/result_of#Possible implementation has a similar problem since it also uses is_base_of. There may be even more pages with the same problem. 2A02:1388:181:A912:0:0:58E1:1110 06:49, 8 February 2024 (PST)

std::expected constructor signature

In std::expected<T,E>::expected, overload (11) I'm 99% sure that this overload should not be a template.

Aye. Fixed, thanks ✔ Done --Ybab321 (talk) 02:50, 9 February 2024 (PST)

std::expected<T,E>::swap error

In the explanation of the method, the first case described as:

Otherwise, equivalent to using std::swap; swap(*this, other);.

Should actually say:

Otherwise, equivalent to using std::swap; swap(**this, *other);.

Fixed, thanks :D ✔ Done --Ybab321 (talk) 03:37, 9 February 2024 (PST)

map.emplace example doesn't show what happens if the key is duplicated

I think the example should end with an additional call with an existing key. The example output shouldn't change if my understanding is correct (that the original value remains).

69.250.84.4 05:46, 9 February 2024 (PST)

Got there eventually ^^;. Added ✔ Done --Ybab321 (talk) 14:46, 18 February 2024 (PST)

Thanks! 💖 (Same reader I guess it decided to go IPv6 this time.) 2601:154:C300:154:14C1:474E:1DBF:8C81 04:32, 27 February 2024 (PST)

std::unordered_map::operator[] complexity

188.187.79.224 11:27, 9 February 2024 (PST)

https://en.cppreference.com/w/cpp/container/unordered_map/operator_at#Complexity

Says: "Average case: constant, worst case: linear in size."

This is wrong, because in worst case operator[] could lead to std::unordered_map::rehash which is quadratic.

In case of questions, write to [email protected]

188.187.79.224 11:27, 9 February 2024 (PST)

✔ Updated: see complexity. Thanks.) --Space Mission (talk) 21:57, 12 February 2024 (PST)

But it's not true. std::unordered_map::operator[] = std::unordered_map::try_emplace = std::unordered_map::emplace, which has O(n) complexity --Ybab321 (talk) 03:05, 13 February 2024 (PST)

O(n) worst-case insertion is correct (see this page). The key is that the automatic rehashing of unordered associative containers can definitely be done in O(n) time. Either it has different implementation from rehash(), or the worst case of rehash() never applies to it. --Xmcgcg (talk) 08:21, 13 February 2024 (PST)

Incorrect declaration, description or exception number marks

Due to the lockdown I cannot edit these myself, but there are some pages that have a mismatch between the number marks of the declaration, description or exception sections.

Declarations are missing overload number marks used in description: https://en.cppreference.com/w/cpp/chrono/time_zone/to_sys

Second overload is marked as (3) instead of (2): https://en.cppreference.com/w/cpp/atomic/atomic_exchange

'-=' overloads must be marked as (2) instead of (1): https://en.cppreference.com/w/cpp/atomic/atomic_ref/operator_arith2

Exception section refers to (3) overload, but third overload is marked (2): https://en.cppreference.com/w/cpp/experimental/fs/is_block_file https://en.cppreference.com/w/cpp/experimental/fs/is_character_file https://en.cppreference.com/w/cpp/experimental/fs/is_symlink https://en.cppreference.com/w/cpp/experimental/fs/is_socket

Third overload is marked as (2) instead of (3): https://en.cppreference.com/w/cpp/experimental/fs/path/operator%3D

In the description "4)" label should be "2)": https://en.cppreference.com/w/cpp/experimental/special_functions/assoc_legendre https://en.cppreference.com/w/cpp/experimental/special_functions/assoc_laguerre

✔ Done. All items in the above are fixed and patched, thanks you. :D --Space Mission (talk) 06:06, 10 February 2024 (PST)

C round() function page bug

C documentation of round()

"The double version of round behaves as if implemented as follows:"

#include <math.h>
double round(double x)
{
    return signbit(x) ? ceil(x - 0.5) : floor(x + 0.5);
}

This implementation is incomplete and wrong! You need to the rounding mode to FE_TOWARDZERO to get the correct result of (x ± 0.5). Or else a value of x = (0.5 - DBL_EPSILON / 2) or x = (0.5 - DBL_EPSILON / 4) would give you the wrong results. The C++ page of std::round has the correct implementation.

--2001:B400:E135:3046:3423:72F7:6AAF:938E 04:18, 10 February 2024 (PST)

✔ Done. The C and C++ pages were updated. Thanks.) --Space Mission (talk) 22:20, 11 February 2024 (PST)

Confusion about "special" member functions and constructors

From cpp/language/constructor:

> Constructor is a special non-static member function of a class that is used to initialize objects of its class type.

The word "special" can lead to confusion. Not all constructors are *special member functions*.

I propose removing the word "special" or replacing it with "kind of"

68.50.220.16 11:45, 10 February 2024 (PST) strager

Fixed. Now “special” appertains to declarator syntax. ✔ Done --Xmcgcg (talk) 05:40, 12 February 2024 (PST)

Execution library

• Sender: A description of asynchronous work to be sent for execution. Produces an operation state (below).

• Senders asynchronously “send” their results to listeners called “receivers” (below).
• Senders can be composed into task graphs using generic algorithms.
• Sender factories and adaptors are generic algorithms that capture common async patterns in objects satisfying the sender concept.

• Receiver: A generalized callback that consumes or “receives” the asynchronous results produced by a sender.

• Receivers have three different “channels” through which a sender may propagate results: success, failure, and canceled, so-named “value”, “error”, and “stopped”.
• Receivers provide an extensible execution environment: a set of key/value pairs that the consumer can use to parameterize the asynchronous operation.

• Operation State: An object that contains the state needed by the asynchronous operation.

• A sender and receiver are connected when they are passed to the std::execution::connect customization point.
• The result of connecting a sender and a receiver is an operation state.
• Work is not enqueued for execution until “start” is called on an operation state.
• Once started, the operation state’s lifetime cannot end before the async operation is complete, and its address must be stable.

• Scheduler: A lightweight handle to an execution context.

• An execution context is a source of asynchronous execution such as a thread pool or a GPU stream.
• A scheduler is a factory for a sender that completes its receiver from a thread of execution owned by the execution context.

Ericniebler (talk) 19:28, 11 February 2024 (PST)

✔ Copied to Execution Library page.) --Space Mission (talk) 22:09, 11 February 2024 (PST)

Segfault in the example of the page std::time_get<CharT,InputIt>::get, std::time_get<CharT,InputIt>::do_get

In the page std::time_get<CharT,InputIt>::get, std::time_get<CharT,InputIt>::do_get, there is an error in the code example:

   ss.imbue(std::locale("de_DE.utf8"));

   auto& f = std::use_facet<std::time_get<char>>(std::locale("de_DE.utf8"));

It should be:

   auto locale = std::locale("de_DE.utf8");
   ss.imbue(locale);

   auto& f = std::use_facet<std::time_get<char>>(std::locale("de_DE.utf8"));

Indeed, the facet `f` becomes invalid as far as the call to the function ended.

2A01:E0A:BA5:C8D0:CB4E:AC46:709F:2E 01:59, 12 February 2024 (PST)

Locales are reference counted, the code should be fine as is. What compiler are you using? --Ybab321 (talk) 04:51, 12 February 2024 (PST)

The problem is actually caused by std::use_facet. Two std::locale("de_DE.utf8") objects might not refer to the same locale object, therefore f becomes a dangling reference. The previous version of the example does not produce any output for GCC. I changed the argument to ss.getloc() and everything works fine now. ✔ Done --Xmcgcg (talk) 05:40, 12 February 2024 (PST)

Broken link in example

On the following page: https://en.cppreference.com/w/cpp/experimental/shuffle

The link in the example for the "std::experimental::shuffle" call is broken and links to a non-existent page: http://en.cppreference.com/w/cpp/experimental/shufflea

I am not sure why that is - the links the Example/code blocks look to be automatically generated?

This is indeed a typo in this auto html links database. You may find the wrong word by searching for

shufflea. It certainly should be just

shuffle. To be fixed.) --Space Mission (talk) 00:18, 14 February 2024 (PST)

Addressed by Cubbi. ✔ Done --Ybab321 (talk) 07:56, 16 February 2024 (PST)

CWG2518 - clang 17.0.1 supports static_assert(false)

I can't change the table because I'm too new a user :(

https://clang.godbolt.org/z/WKPjnGEMs

✔ Done: here. Thanks. --Space Mission (talk) 20:21, 14 February 2024 (PST)

Fix spelling error

Original content removed. It was the content of std::format.

You can provide the exact location of the error. We will handle it. --Xmcgcg (talk) 06:48, 16 February 2024 (PST)

Addressed. ✔ Done --Ybab321 (talk) 07:56, 16 February 2024 (PST)

Typo on strfromf

On https://en.cppreference.com/w/c/string/byte/strfromf

The line: int strfroml( char *restrict s, size_t n, const char *restrict format, long double fp );

should be: int strfromld( char *restrict s, size_t n, const char *restrict format, long double fp ); 50.168.87.114 14:57, 16 February 2024 (PST)

The standard says strfroml is correct. Was that changed in the password protected draft? If yes, please provide a source showing the change. 2A02:586:293C:DC56:B9C4:EE4A:86D5:16D0 16:08, 16 February 2024 (PST)

Can someone correct the page title of c/string/byte/strfromf? 2A02:586:293C:DC56:2C46:9513:3BA0:9F84 04:29, 17 February 2024 (PST)

Fixed by Space Mission ✔ Done --Ybab321 (talk) 14:29, 18 February 2024 (PST)

faulty example

I do not get the examples given. Both examples do in fact insert a separator when running the code.

I beg your pardon? --Ybab321 (talk) 14:29, 18 February 2024 (PST)

Bit-field of width zero in a union

As a special case, a bit-field structure member with a width of 0 indicates that no further bit-field is to be packed into the unit in which the previous bit-field, if any, was placed.

As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary.

Apply N2829 to c/error/assert

That is the same change as P2264R7 for cpp/error/assert but for C. 2A02:586:293C:DC56:1576:6BEE:E002:DCA 18:16, 18 February 2024 (PST)

Syntax highlighting missing keywords

It's minor, but all new C++ 20 keywords are not syntax highlighted on the site: char8_t, concept, consteval, constinit, co_await, co_return, co_yield, requires

There are also some C++11 keywords that are not highlighted (incomplete list): static_assert, thread_local, nullptr

Maybe there is a reason not to or there is a technical limitation, but I think all the reserved keywords in the top table should be highlighted as such. https://en.cppreference.com/w/cpp/keyword

Kkitanov (talk) 00:42, 19 February 2024 (PST)

Small fix for std::expected

In description of the converting copy/move constructors:

> If T is not (possibly cv-qualified bool)

should be replaced with:

> If T is not (possibly cv-qualified) bool

Fixed. ✔ Done --Xmcgcg (talk) 05:44, 20 February 2024 (PST)

Bug in filesystem space example

The example here

 https://en.cppreference.com/w/cpp/filesystem/space

is buggy.

Please use this code instead:

 https://wandbox.org/permlink/SEw1elbZYfSAxeJ8

Reason:

      reserved  ^  -----    ^           ^
                v  |___|    |           |
                ^  |   |    | free      |
      available |  |   |    |           |
                v  |___|    v           | capacity
                   |   |    ^           |
                   |   |    | used      |
                   |   |    |           |
                   -----    v           v
                   

Assume these numbers

capacity  = 100
free      = 55
available = 50

used      = capacity - free  = 45
reserved  = free - available = 5

Correct) (https://wandbox.org/permlink/SEw1elbZYfSAxeJ8)

privileged = false    [disk-usage-for-normaler-user]
==================
usage = used / (used+available)          = (capacity - free) / (capacity - free + available) 
      = 45 /  95


privileged = true     [disk-usage-for-privileged-user]
==================
usage = used / (used+available+reserved) = (capacity - free) / (capacity) 
      = 45 / 100

Wrong) (current implementation)

privileged = false    [disk-usage-for-normaler-user]
==================
usage = (capacity - available) / capacity
      = 50 / 100


privileged = true     [disk-usage-for-privileged-user]
==================
usage = (capacity - free) / capacity     
      = 45 / 100

Thanks.

Corrected, thanks a lot for the explanation ✔ Done --Ybab321 (talk) 07:20, 20 February 2024 (PST)

It is still wrong. It is not like my code, which does the right thing. Why do I say my code (linked above) does the right thing? Because I ensured it works exactly like the Linux df command - and that does the right thing. Please go through my code and understand how it (still) differs from the current version here. Then please correct it. Thanks

Ah, I'll have to rescind my thanks for the explanation then, will try to find the difference when I get a chance --Ybab321 (talk) 10:42, 21 February 2024 (PST)

Ok, I looked at yours in detail now and you refactored (or may I say: overcomplicated) the code, but the result is in fact correct. But (as implied) I really do find it quite complex, to be honest (that's the reason I originally thought it was actually different).

Just consider the following, which is your current implementation

privileged = false    [disk-usage-for-normaler-user]
==================
usage = ((si.capacity-(si.free - si.available) - (si.free-(si.free - si.available))) / (si.capacity-(si.free - si.available))
          ------------------------------------   ----------------------------------     ------------------------------------
                   capacity                                  unused_space                       capacity
      = ((si.capacity-si.free)) / (si.capacity-(si.free - si.available))
      = 50 / 100

That (ultra-long) line on top is the calculation expansion.

My code is much simpler (and easier to understand -- at least for me):

   const std::uintmax_t used{si.capacity - si.free};
   const std::uintmax_t total_usable{privileged ? si.capacity : (used + si.available)};
   if (constexpr auto X{static_cast<std::uintmax_t>(-1)};
       total_usable == 0 || si.capacity == X) {
       return X; // signal error
   }
   return 100 * used / total_usable;

Just look at that conditional operator (ternary conditional). Is that not much simpler???! Also the comment in my version can help users: https://wandbox.org/permlink/SEw1elbZYfSAxeJ8

Could we not change the code to be similar to that??? Thanks!!

(The error handling is also different: istead of returning blank 100, I return X. But about that I don't care too much.)

The code is fine as is, cramming stuff into one line doesn't make the code simpler, it just takes away the possibility of adding names to identify the calculations. Try to identify logical or semantic issues, or general engineering improvements in your code reviews; pointing out mere differences between two pieces of code isn't productive, nor persuasive. --Ybab321 (talk) 07:40, 22 February 2024 (PST)

Your use of capacity and si.capacity is confusing. So your point of "adding names to identify" is mute. My name is total_usable, which is better. Mine even has a description with a comment. And my version has higher performance. Think about it.

C++23: flat_map::emplace has incorrect complexity

For cpp/container/flat_map/emplace, complexity is dictated as N + M log M, where N is the original flat_map size, and M is the number of inserted elements.

Some pages (e.g. flat_map::emplace) appear to have been at least partially copied from map instead.

Fixed flat map emplace (though it could be expressed more precisely by writing out the implementation like the standard does, that's on the todo list). ✔ Done --Ybab321 (talk) 08:00, 22 February 2024 (PST)

Confusion in std::list<T,Allocator>::size description

Hi,

In the description of "std::list<T,Allocator>::size" it is stated that:

"Returns the number of elements in the container, i.e. std::distance(begin(), end())."

This is confusing, since starting from C++11, the size() method has constant complexity while the std::distance has linear complexity for bidirectional iterators. So, I suggest removing this confusing statement ('i.e. std::distance(begin(), end())') from the description.

Thanks, Misak Shoyan

The complexity is stated in the complexity section. I see no possible source of confusion over the time complexity of that function --Ybab321 (talk) 07:45, 22 February 2024 (PST)

Missing overload

On page std::ostream_iterator<T,CharT,Traits>::operator= there is a missing overload:

   ostream_iterator& operator=(const ostream_iterator&) = default;

See file stream_iterator.h line 236. --2A02:85F:FC70:F0CB:8952:BAE1:2759:C6C9 09:54, 22 February 2024 (PST)

Added, thanks. ✔ Done --Ybab321 (talk) 10:19, 22 February 2024 (PST)

Not compilable code for example which goes into Comiler Explorer in std::ranges::to

https://godbolt.org/z/os4YKEEbv - working example 178.148.7.85 23:22, 22 February 2024 (PST) Sakhil

libc++ has <print> now, that's great (also thanks ADL for making us aware of this :D). Updated the link, thanks. ✔ Done --Ybab321 (talk) 03:04, 23 February 2024 (PST)

Missing semicolumn at the end of the example code

Semincolumn is missing at the end of the sample code below:

... // array of 5 pointers to functions returning pointers to arrays of 3 ints int (*(*callbacks[5])(void))[3]; ...

Thanks, semicolon inserted (what am I, javascript?) ✔ Done --Ybab321 (talk) 03:04, 23 February 2024 (PST)

Compiler support for C++23 - Some Explanation of the numbers

Regarding:

[ https://en.cppreference.com/w/cpp/compiler_support/23] and those like it.

Might I suggest that somewhere on this page there is some explanation of the version numbers and how to find them. I have just spent some time trying to find if my Visual Studio 2022 compiler had some feature, to find that none of the obvious "version numbers" displayed by the visual interface are the relevant one, and that the only way to determine this is to look up a table such as

[ https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering]

or reading the article by Raymond Chen here

[ https://devblogs.microsoft.com/oldnewthing/20221219-00/?p=107601]

or to compile something like:

std::cout << "_MSC_FULL_VER:\n" << _MSC_FULL_VER <<std::endl;

Practically - maybe make the column heading a link to the Wikipedia table, or a page where you explain what the reference means. I would happily contribute such an intermediate page.

Paul McGinnie (not a user with an account) 81.174.231.177 03:36, 26 February 2024 (PST)

If you mouse-hover the version number cell it gives you the useful version number. Not that I'm against your suggestions --Ybab321 (talk) 09:34, 26 February 2024 (PST)

Return value description in Template:cpp/container/try_emplace_assoc

Hi,

First of all, thanks for this wonderful website, I'm using it almost every day.

I think that in the return value section, the description of false boolean value should rather talk about no action happening instead of assignment being done. Feels a bit like a copy-pasta from insert_or_assign. :) I don't have an account here, so I can't edit the page myself.

Cheers!

45.135.60.1 12:24, 26 February 2024 (PST) Krzesimir Nowak

Fixed.✔ Done --Xmcgcg (talk) 18:15, 29 February 2024 (PST)

Incorrect return type for C++98's std::deque::insert

Hi,

The declaration for std::deque::insert( const_iterator pos, size_type count, const T& value ) is incorrect for C++98. According to https://cplusplus.com/reference/deque/deque/insert/ and the STL's implementation (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_deque.h), this method should return void, and not an iterator.

Since this page is protected, I can't edit it, hopefully someone with the rights can do that instead.

2A02:8440:C207:342D:6972:67C3:F744:F283 17:48, 26 February 2024 (PST)

the change is mentioned on the page under cpp/container/deque/insert#Defect_reports. It's true that gnu stdlib doesn't implement it as a retroactive defect report, while microsoft and llvm all return iterators. --Cubbi (talk) 19:50, 26 February 2024 (PST)

std::expected::emplace initializer_list argument not a reference

According to P0323r11 and some implementations, it looks like the type of the initializer_list argument is just std::initializer_list<U> and not std::initializer_list<U>&. This also matches the other constructors, etc.

Brad Spencer (talk) 07:04, 27 February 2024 (PST)

✔ Patched. Thanks. --Space Mission (talk) 08:28, 27 February 2024 (PST)

in 'Compiler support for C++23' deducing this marked as full support for gcc and clang, but is only partial

both clang and gcc are missing P2797R0/CWG2692 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2797r0.html)

sources:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609

https://clang.llvm.org/cxx_status.html#cxx23

Invalid examples of std::signal

I have found several pages that contain incorrect usages of std::signal.

cpp/utility/program/signal: The example does not make the signal handler 'extern "C"' even though the declaration at the top of the page indicates that it expects this.

cpp/utility/program/raise: The example does not make the signal handler 'extern "C"', and prints inside of the signal handler which isn't signal safe.

cpp/utility/program/abort: Same as above.

c/program/raise: The example prints inside of the signal handler which isn't signal safe.

c/program/SIG_ERR: Same as above.

as discussed in c/program/signal and cpp/utility/program/signal, signal safety only applies to async signals, which aren't used in those examples. C++ linkage support is implementation-defined but I suppose C linkage would indeed be prudent for use in examples. --Cubbi (talk) 10:20, 28 February 2024 (PST)

on second thought, it looks like the changes in http://wg21.link/p0270 technically eliminated sync signal wording with a note "It may make sense to eventually relax these restrictions invoked through an explicit synchronous raise() call. It's unclear that this is important enough to bother.".. while I doubt any programmers (and therefore compiler vendors) expect existing sync signals to suddenly turn into free-for-all UB, maybe it is worth the effort to show async-signal-safe examples even if invoked synchronously --Cubbi (talk) 10:43, 28 February 2024 (PST)

std::map<Key,T,Compare,Allocator>::try_emplace -- ignored vs assignment map

The body return value section found on map::try_emplace [[9]] says it returns "false if the assignment took place". However, other parts of the page mention no such assignment. Rather, it appears to ignore the input in the even a false statement is returned.

204.113.92.35 11:51, 29 February 2024 (PST) Clint Chelak, [email protected]

Fixed.✔ Done --Xmcgcg (talk) 18:15, 29 February 2024 (PST)

final specifier

The final specifier cannot be placed on a class declaration such as class A final; This is not particularly clear on the page for final.

Added an explicit note on it. ✔ Done --Ybab321 (talk) 09:36, 7 March 2024 (PST)

Ok Thanks. The example struct final final; is clearly a declaration and needs removing or something.

Why would it need removing? It's not a class declaration, as the explanatory text points out --Ybab321 (talk) 08:12, 14 March 2024 (PDT)

float.h: MAX_EXP: naming / definition questionable,

FLT_MAX_EXP DBL_MAX_EXP LDBL_MAX_EXP

maximum positive integer such that FLT_RADIX raised by power one less than that integer is a representable finite float, double and long double respectively (macro constant)

That description matches with the value produced for e.g. DBL_MAX_EXP, but why that cumbersome way, and misleading name? The value returned isn't 'MAX_EXP' but 'MIN_TOO_BIG_EXP'.

176.4.134.52 18:45, 2 March 2024 (PST)

C just isn't a language that espouses good identifier naming, your complaint is completely valid --Ybab321 (talk) 09:35, 7 March 2024 (PST)

Add "some" to examples intro in cpp/language/ub

In the "Explanation" section, under "undefined behavior", change "Examples" to "Some examples". 2600:8800:1180:25:F5FB:C6B8:87F2:F13C 11:29, 3 March 2024 (PST)

✔ Done.) --Space Mission (talk) 12:49, 3 March 2024 (PST)

What are the "A program is well-formed" tags about in cpp/language/ub?

In the "Explanation" section there are awkward sentences like "A program is well-formed" tacked on to the end of some of the paragraphs. Should it be "Such a program..." instead? And are they necessary to disambiguate some question, or is it just obvious whether such a program is well- or ill-formed? 2600:8800:1180:25:F5FB:C6B8:87F2:F13C 11:29, 3 March 2024 (PST)

Those "tags" are unnecessary/not entirely accurate and have been removed.) ✔ Done. --Space Mission (talk) 14:11, 3 March 2024 (PST)

Typo in explanation

line: -c + d; // equivalent to (-c) + d, NOT -(a + b)

should be: -c + d; // equivalent to (-c) + d, NOT -(c + d)

80.188.171.120 04:35, 6 March 2024 (PST) Miroslav Rýzek

Fixed.✔ Done --Xmcgcg (talk) 18:01, 6 March 2024 (PST)

std::mutex example could use structured binding

Hello. New user here. I'd like to make a small change to the example code for std::mutex. It could make use of structured binding in its range-based for loop, e.g.

for (const auto& [url, page] : g_pages)
  std::cout << url << " => " << page << '\n';

PaulCpp (talk) 12:13, 6 March 2024 (PST)

Updated.✔ Done --Xmcgcg (talk) 18:01, 6 March 2024 (PST)

Two libraries

It would be good to add https://github.com/jeremy-rifkin/cpptrace and https://github.com/jeremy-rifkin/libassert to https://en.cppreference.com/w/cpp/links/libs. They are diagnostic-related libraries but probably fit best under logging. I would add them, however, apparently I cannot as my account is considered new.

C23 feature support by compiler

https://en.cppreference.com/w/c/compiler_support/23

typeof() support listed for MSVC is incorrect.

Support does exist as of MSVC/Visual Studio 2022 17.9

https://learn.microsoft.com/en-us/cpp/c-language/typeof-c?view=msvc-170

Version supporting was released February 13, 2024

2001:470:8B06:100:B43F:65F6:9FE7:7B64 16:51, 7 March 2024 (PST) gdwnldsKSC

Libraries: PcapPlusPlus missing license & configuration

Hey,

I noticed that PcapPlusPlus is missing license & configuration info on the page: https://en.cppreference.com/w/c/links/libs

Missing data is:
- license: Unilicense
- configuration: CMake (since v22.11)

Reference: https://github.com/seladb/PcapPlusPlus

Thanks!

178.235.17.242 05:42, 8 March 2024 (PST) WojtekMs

✔ Added.) --Space Mission (talk) 16:38, 8 March 2024 (PST)

The link to PcapPlusPlus can be found here: https://en.cppreference.com/w/cpp/links/libs#Communication --Space Mission (talk) 16:45, 8 March 2024 (PST)

CTRE

Looking through this list, I was surprised to not see CTRE. The compile time regular expression library is praised often on conferences and podcasts. Unlike std::regex, this parses the regex at compile time and makes a dedicated parser for the regex you want to use. I believe this belongs in the group Text.Parsing. URL: https://github.com/hanickadot/compile-time-regular-expressions Type: header only License: Apache 2 Description: Fast compile-time regular expressions with support for matching/searching/capturing during compile-time or runtime.

Not having CTRE was unwise indeed.) ✔ Added. --Space Mission (talk) 03:32, 10 March 2024 (PDT)

Update description of example for transform

The example for transform: https://en.cppreference.com/w/cpp/algorithm/transform contains an extra step that is not described in the preceding text, which says, "The following code uses transform to convert a string in place to uppercase using the std::toupper function and then transforms each char to its ordinal value:..." In fact, the example also has a step where each ordinal value is added to itself, apparently to demonstrate that transform can apply binary operators. It would be good for the explanatory text to be updated.

Alex Szatmary, http://sites.google.com/site/alexszatmary/ 174.178.62.175 14:02, 10 March 2024 (PDT)

Static data members declared inline

One of the reasons for the introduction of the inline word is that a non-literal type can be initialised in a header file as so:

struct Monster { Monster(long num) { std::cout << "Starting monster " << num << std::endl; } };

struct Level { inline static Monster fav = Monster{9}; // OK since C++17 };

The page only gives an example with an int.

Modification of the example in c/io/fputwc to be compatible with MSVC

In the example of the page c/io/fputwc, there is the following code:

   if (fputwc(L'🍌', stdout) == WEOF)

L'🍌' is a wchar_t which is implementation defined, and, on MSVC for instance, wchar_t is 2 bytes long. This is an issue because the banana emoji cannot be represented in 2 bytes or less. I would suggest to use the Timer Clock emoji (⏲), for instance, which can be represented in 2 bytes. This would make this example compliant on all platforms.

2A01:E0A:BA5:C8D0:903E:5584:51F6:1C47 05:41, 15 March 2024 (PDT)

Modification of the example in c/language/string_literal

In the example of the page c/io/fputwc, there is the following code:

  wchar_t s5[] = L"a猫🍌";

wchar_t is implementation defined, and, on MSVC for instance, wchar_t is 2 bytes long. This is an issue because the banana emoji cannot be represented in 2 bytes or less. I would suggest to use the Timer Clock emoji (⏲), for instance, which can be represented in 2 bytes. This would make this example compliant on all platforms.

2A01:E0A:BA5:C8D0:903E:5584:51F6:1C47 06:10, 15 March 2024 (PDT)

quite a few cppreference examples showcase features that aren't supported by some of the big 3 implementations (or in a few cases even features not supported by any of the big 3). Trimming examples to what works in that intersection would both lose examples that demonstrate practical (just not universal) use, and the examples that shame vendors into improvement (this worked in the past - though I know MS will never do this one). Besides, U+23F2 wouldn't show anything that U+732B doesn't already. --Cubbi (talk) 10:12, 15 March 2024 (PDT)

Misprints in cpp/atomic/atomic

std::atomic<U*> is stated to be defined in <memory>. This is a misprint. This remark is related to std::atomic<std::shared_ptr<U>> and std::atomic<std::weak_ptr<U>>. There is a similar misprint with <stdatomic.h>. This header should be moved from std::atomic<std::weak_ptr<U>> to #define _Atomic(T).

Suggest changes in cpp/algorithm/upper_bound explanation

As explained, if the order is determined by comp: the function returns the first iterator iter in [first, last) where bool(comp(value, *iter)) is false, or last if no such iter exists.

But actually it keeps incrementing first iterator while comp(value, *iter) == false. When count == 0 the incremented iterator is returned. And comp(value, *iter) for this iterator will return True. So in fact the std::upper_bound returns the first iterator next to the last iterator where bool(comp(value, *iter)) is false or the first iterator where bool(comp(value, *iter)) is true.

The working example is here: binary-search-comparator-checker

For the comparison, the explanation on the cpp/algorithm/lower_bound page is correct.

Viktor Kustov [email protected]

--178.66.130.191 19:10, 17 March 2024 (PDT)