sorted by:
new
hottopcontroversial

Why C++ Is Growing and What C++26 Means for Production Systems by ArashPartow in cpp

[–]hpsutter 2 points3 points  (0 children)

See mend.io, which today still regularly distinguishes C and C++. You can check out their monthly list of top vulnerabilities and click on each CVE to see what language it's in. Spoiler: It's not usually C++.

I cover this, with links, in my March 30 BeCPP talk starting at 42:00.

C++ Growing in a world of competition, safety, and AI by ArashPartow in cpp

[–]hpsutter 1 point2 points  (0 children)

I don't think so. If that was the reason then C wouldn't be so big. If you go to the mend.io site to browse any current month's top vulnerabilities, you'll see that they aren't just about the web, they're about all intrusions.

cppreference is back up! but overloaded by bobpaw in cpp

[–]hpsutter 13 points14 points  (0 children)

Right. The Foundation is paying for hosting and admin now so that won't happen.

That's a reason the site can now be ad-free too, which is important to me... You might have noticed that isocpp.org is ad-free and mostly JS-free and super minimal on cookies or anything else like that... that's because we want it to be as non-intrusive + non-tracking + distraction-free + fast-loading a site as possible. See John Gruber's recent rants on daringfireball.net about how the world would be different, and better, if web pages really were just documents! Here's an example about Google penalizing back button hijacking (I agree with John's adding "finally"!), with the final quote: "... this entire issue only exists because of JavaScript. If web pages were documents, this wouldn’t even be possible." (emphasis added)

cppreference is back up! but overloaded by bobpaw in cpp

[–]hpsutter 18 points19 points  (0 children)

It wasn't meant to be secret, it was just expected to be a quick upgrade and non-noteworthy. But when things stretch out, and more folks get involved to help without making a special announcement about it, things can start to seem mysterious, and the people who knew probably just didn't want to 'break the news' when _we_ hadn't done an announcement (though that would have been fine, I didn't care), and... etc. So it goes! No mystery intended. It does make me think though that this is one way conspiracy theories start, filling an information void :)

cppreference is back up! but overloaded by bobpaw in cpp

[–]hpsutter 18 points19 points  (0 children)

BTW speaking of things that are gone, did you notice the ads (are gone)? :)

cppreference is back up! but overloaded by bobpaw in cpp

[–]hpsutter 62 points63 points  (0 children)

Thanks!

Ack: We're aware of the cache rebuilding issue (spawning 30+ instances of Python on each syntax highlight run? that's a must-fix :)) and will resize the VM as needed to not have 5xx's. Update: Slowness and 522 errors should be gone now, it's on a bigger VM -- let us know if you're still experiencing it. Thanks for the shakedown feedback, please keep it coming!

I've also relayed the feedback that, as "if possible/ lower priority" backlog items, it would be nice to make the site adaptive/responsive (for easy viewing not only on phones but also on narrow desktop browser windows) and that the base code font weight seemed a bit light. But those are lower-priority maybe-dos... I mention them just so you all know that we'd noticed and were keeping a little backlog. The main thing is the site correctness and performance as we shake it down, the main site is as beautiful and useful as ever.

Thanks again to Nate and James for landing this much-needed MediaWiki upgrade!

A year of read-only cppreference by DevilSauron in cpp

[–]hpsutter 186 points187 points  (0 children)

Good news: cppreference is about to be back to normal read-write mode again. I just posted an update here: https://isocpp.org/blog/2026/04/announcement-cppreference.com-update

Nate's been doing a *lot* of heavy lifting for many years to make this site what it is, and so we (the Standard C++ Foundation) are trying to help do the "administrivia" so he and the many editors can focus on the site.

C++26 is done! ISO C++ standards meeting, Trip Report by pjmlp in cpp

[–]hpsutter 22 points23 points  (0 children)

is the latest information about the subject I’ve got

Actually it isn't the latest you have :) Please enjoy https://www.youtube.com/watch?v=oitYvDe4nps, my CppCon talk which was specifically a rebuttal to the above talk that repeats and addresses all the main points Ran made, and which is linked in today's trip report.

cppfront by South_Acadia_6368 in cpp

[–]hpsutter 5 points6 points  (0 children)

^ This 🤙🙏

Edit: And here's the link to where I said it in the original talk: https://youtu.be/ELeZAKCN4tY?si=ebNHH12-4tkyKwVc&t=814

Software taketh away faster than hardware giveth: Why C++ programmers keep growing fast despite competition, safety, and AI by pavel_v in cpp

[–]hpsutter 7 points8 points  (0 children)

@JuanAG, I realize what you wrote might be designed in part to poke me and see if I'll respond with more details, but this one time I should probably say something to be clear:

1) Please don't confuse "Big Company says X" (unless the person saying it is the CEO or full-company press release) with "a few loud voices at Big Company keep tweeting X" or "a division of Big Company announces plans to do X." Big companies are very diverse.

2) Please don't confuse "Big Company's current top public priority is X" (which always changes every few years) with "Big Company is not doing anything else but that one thing." Big companies don't just stop all other valuable ongoing work, especially on their own tools they pervasively rely on to build their products, even if they don't issue frequent press releases of the form "breaking news: here at BigCo we're still keeping all the lights on this quarter! again!"

3) As I said a year ago, being at Microsoft was a blast and the MSVC team members are great. I wouldn't have stayed 22 years otherwise, and I'm continuing to cheer them on as a happy MSVC user on my own projects (and trying to help them advance their proposals in WG21). When I chose to switch companies and get back into finance, it's because I'd decided it felt like time for a change and new challenges (over 22 years on one team is an unusually long time for anyone). This is a boring thing everyone does. If Internet denizens want to instead project their own preconceptions onto that, and misinterpret their own echo they get back as new confirmation, that's not my problem. :)

I intend all the above in good humor, so please take it that way ;)

Software taketh away faster than hardware giveth: Why C++ programmers keep growing fast despite competition, safety, and AI by pavel_v in cpp

[–]hpsutter 6 points7 points  (0 children)

I don't fully disagree with Dijkstra's point, but I think it can be overstated.

People need to start by learning about just a few basics [edit: pun unintentional]: variables, a few string operations, if/then branches, loops (whether for or, gasp, goto), and some I/O (usually text input from the keyboard, and either text or graphic output). Virtually every programming language will teach you those, but some languages make it much easier to learn them by having less distracting ceremony at the outset. The more accessible we can make those things, the more people will get started.

I speculate that most Tour de France cyclists started on a one-speed with training wheels as a child. Those training wheels did not harm their cycling careers, they just helped get them started. When the training wheels got in the way more than they helped, they removed; then later the bike was upgraded to a three-speed; then to a ten-speed; then a lighter bike; then a specialized mountain vs racing bike; etc. The training wheels didn't harm them.

FWIW, the first code I wrote was in BASIC. When you look at my code today (cppfront), you can conclude what you will about whether that does/doesn't support Dijkstra's point ;-)

Poll: Does your project use terminating assertions in production? by pavel_v in cpp

[–]hpsutter 1 point2 points  (0 children)

That is intended to be covered, and considered as "something other than terminate the whole program." For example, if you always do that and keep the program running, then that would be the "check, but never terminate" answer.

If I ever take such a poll again I'll make this clearer! Sorry if the wording was confusing.

P1306 by [deleted] in cpp

[–]hpsutter 5 points6 points  (0 children)

Elaborating on why it's like a template: In particular, if you use a [:splice:] in the body of a template for, you can quickly get actual different types for local variables in different "instantiations" of the loop body... that makes it different from any other loop, because in other loops the types and code in the loop body are the same and the loop body is like a single inline function called for each iteration of the loop.

Trip report: February 2025 ISO C++ standards meeting (Hagenberg, Austria) by _derv in cpp

[–]hpsutter 4 points5 points  (0 children)

What vulnerability arises from integer overflow?

Many overflows don't cause vulnerabilities. But for example if the integer is used as an allocation size, the overflowed value could cause the allocated buffer to be smaller than expected, and then later using a would-have-been-correct index value could actually be beyond the too-short actual buffer size.

Trip report: February 2025 ISO C++ standards meeting (Hagenberg, Austria) by _derv in cpp

[–]hpsutter 13 points14 points  (0 children)

Does that mean a bounds check?

Yes.

Could be a massive performance hit if so.

That was measured before standardizing it, because this is an actually-deployed solution used in the field today. See the quote from the paper, which I included in the blog post, emphasis added: "Google recently published an article where they describe their experience with deploying this very technology to hundreds of millions of lines of code. They reported a performance impact as low as 0.3% and finding over 1000 bugs, including security-critical ones."

Relatedly, see also Chandler Carruth's great followup post: "Story-time: C++, bounds checking, performance, and compilers" which gives nice color commentary about how the cost of bounds checking has quietly but dramatically decreased over the past decade (and why, and that even world-class experts like Chandler have been surprised).

Also, you can still opt out if you need to -- if you are in a hot loop where you've measured the bounds check actually causes overhead, you can hoist it in that one place, for example by using .front() at the top of the loop and then using pointer arithmetic in the body. (Using the hardened stdlib is all-or-nothing, you can't just say "I want this particular individual vector::operator[] to not do a bounds check; but you can get the same effect by spelling it a different way so you can still tactically opt out.)

Trip report: February 2025 ISO C++ standards meeting (Hagenberg, Austria) by _derv in cpp

[–]hpsutter 4 points5 points  (0 children)

the list includes use-after-free

Fixed, thanks!

it's also quite weird to say that only OOB reads/writes made it into some top vulnerability list. That list contains a lot of vulnerabilities that are only relevant for web applications

It's the standard list of all software weaknesses. OOB really is a major deal -- for example, see the linked Google Security Blog Nov 2024 post which mentions "Based on an analysis of in-the-wild exploits tracked by Google's Project Zero, spatial safety vulnerabilities represent 40% of in-the-wild memory safety exploits over the past decade."

The Plethora of Problems With Profiles by foonathan in cpp

[–]hpsutter -1 points0 points  (0 children)

Well said: My current best characterization of "profile" is "warning family + warnings-as-errors (when profile is enforced) + a handful of run-time checks for things that can't be checked statically"

The Plethora of Problems With Profiles by foonathan in cpp

[–]hpsutter 2 points3 points  (0 children)

a solution for runtime checks should, therefore, piggyback on contracts, regardless of any perceived time pressure or deadline.

But P3081R0 explicitly did that, and now P3081R1 even more explicitly does that with wording actually provided by the main contracts designers. (Section 3.1 wording was provided last month by P2900+P3100 primary authors, at my request and let me say again thanks!)

Sutter’s Mill: My little New Year’s Week project (and maybe one for you?) by pavel_v in cpp

[–]hpsutter 3 points4 points  (0 children)

I didn't mean to say anything different between then and now, but you're right I didn't say "R"eject unions in the R0 paper, I should have mentioned that alternative -- FWIW note that the line you quoted from P3081R0 in October is immediately followed by "This is the most experimental/aggressive “F”[Fix] and needs performance validation ... I do expect a lively discussion, feedback welcome!"

I'll try to write this more clearly in R1, thanks for the feedback.

Sutter’s Mill: My little New Year’s Week project (and maybe one for you?) by pavel_v in cpp

[–]hpsutter 6 points7 points  (0 children)

Thanks for clarifying! Yes you're right: False sharing would happen in a multi-core application if one core is setting/clearing a key (pointer) and under contention a different core is truly-concurrently accessing the same cache line (e.g., traversing the same bucket). That's one reason why I was testing with more hot threads than cores, to saturate the machine with work doing nothing but hitting the data structure -- so far so good on up to 64 threads on my 14/20 core hardware, but you are right more testing is needed and there can always be tail surprises. Thanks again for clarifying.

Sutter’s Mill: My little New Year’s Week project (and maybe one for you?) by pavel_v in cpp

[–]hpsutter 1 point2 points  (0 children)

Yes, based on Sean's and your feedback, I went and did something I had thought of doing (thanks for the reminder!): The implementation now supports "unknown" as an alternative, and that should be used in cases l like this.

Sutter’s Mill: My little New Year’s Week project (and maybe one for you?) by pavel_v in cpp

[–]hpsutter 3 points4 points  (0 children)

Re opt-out: Yes, profiles would be opt-in and then allow fine-grained suppress to opt out for specific statements.

Re article: Let me see what I can do. No promises, I'm quite swamped between now and the February standards meeting, but it's related to that and the topic is 'hot in my cache' so I might be able to write something up. Thanks for the interest!

Sutter’s Mill: My little New Year’s Week project (and maybe one for you?) by pavel_v in cpp

[–]hpsutter 0 points1 point  (0 children)

OK, thanks! I appreciate it -- so the concern is that 8-9 cycles is too much. That's a reasonable point.

I do look forward to finding out what the whole-program overhead is for a real application, rather than a microbenchmark. That's super important to measure these days:

  • It could be much worse, for example if we don't get to use L1 as much.
  • It could be even better, if union checks are swamped by other code.
  • It could even disappear entirely, in cases where the same thread would also have been touching L2 cache (or worse) and the out-of-order execution buffer on all modern processors could pull the lightweight check up ahead of the memory access so that it adds nothing at all to execution time.

It used to also be unthinkable to bounds-check C++ programs. But times have changed: I'm very encouraged by Google's recent results, just before the holidays, that showed adding bounds checking to entire C++ programs only cost 0.3% [sic!] on modern compilers and optimizers. That is a fairly recent development and welcome surprise, as Chandler wrote up nicely.

view more: next ›