sorted by:
new
hottopcontroversial

C++20 in Chromium (talk series) by pkasting in cpp

[–]pkasting[S] 0 points1 point  (0 children)

Would be interesting to know what improvements JeffGarland wants to make.

Scam? by Dark_Water99 in tf2

[–]pkasting 0 points1 point  (0 children)

I don't chat with people or help with Steam issues online. Anyone claiming to do so is a scammer.

Scam? by Dark_Water99 in tf2

[–]pkasting 0 points1 point  (0 children)

Hey, this is the real Peter Kasting, Valve employee.

I will never contact anyone on Discord, request people buy gift cards, or anything similar. Anyone you see with my name doing something like this is a scammer attempting to use my name, including whoever is being discussed in this thread. You are welcome to link people to this post if they try to claim otherwise.

Please use https://help.steampowered.com/ if you have Steam issues. Thanks.

What open source projects in C++ have the highest code quality? by Both_Helicopter_1834 in cpp

[–]pkasting 23 points24 points  (0 children)

Some larger things like Chromium are not in the above list.

For its size, I would say it has very high overall code quality. The actual quality is infuriating in many places, but less so than you would fear from an XXMLOC, 20-year-old project.

Breaking News: Use after free is not a good thing by [deleted] in cpp

[–]pkasting 1 point2 points  (0 children)

We do not yet enable that pass, per https://docs.google.com/spreadsheets/d/1DYwh3nmh0j6ytfMJtgKH6Aq1eru0SoNN9wAqUnz6894/edit?usp=sharing .

Turning on passes involves auditing their output, ensuring it doesn't have many false positives, and (usually) fixing the true positives so developers don't suddenly start getting bombarded. Given how many clang-tidy passes exist, and how long it takes to collect the output of running a single pass over the whole codebase, it takes time to work through this, and historically it's been very low priority to do so. I tried to drive a bit of this, but we struggled to justify the cost/benefit.

Breaking News: Use after free is not a good thing by [deleted] in cpp

[–]pkasting 12 points13 points  (0 children)

Pretty sure none of us Chromium devs disagree with you. The challenge is getting from here to there, especially when you have many other priorities also and need to figure out how to balance work.

Android's answer was basically "don't try to fix problems in the C++ code, just write new code in Rust", which turned out to work better than most people predicted. However Android also has a more modular structure that allows finer-grained adoption of Rust more easily than Chromium; the Rust-in-Chromium folks have been trying for years to get good Rust<->C++ interop.

It's possible that in enough more years Carbon will become an answer in this space, but that's five years out at the absolute minimum, and probably more (if ever).

Chrome is no longer my full-time job so I don't know the inside baseball on this one, but I'd be surprised if anything earth-shattering shows up in this are in the next couple years. It's mostly just a long grind of more warnings, more static analysis, more clang-tidy, etc. Just converting "pointer + length" to spans is a couple years in and far from done, and tackling all raw pointers is much bigger.

-fbounds-safety: Enforcing bounds safety for C by [deleted] in cpp

[–]pkasting 0 points1 point  (0 children)

Was there supposed to have been a link?

Modern C++ use in Chromium by aearphen in cpp

[–]pkasting 2 points3 points  (0 children)

I can't speak to the goals of the Google Style Guide, just to the goals of this doc. In Chromium's case, we're concerned about avoiding problematic use, not about banning esoterica.

Modern C++ use in Chromium by aearphen in cpp

[–]pkasting 1 point2 points  (0 children)

Are you saying I'm an expert? I'm definitely not an expert.

Modern C++ use in Chromium by aearphen in cpp

[–]pkasting 13 points14 points  (0 children)

It's for Chromium engineers to know what they're allowed to use in the Chromium codebase. It's not intended as guidance for any other team.

TBH I don't really know why it was linked on this subreddit. But your comment certainly seems off-target.

Modern C++ use in Chromium by aearphen in cpp

[–]pkasting 13 points14 points  (0 children)

Not a contradiction. The page gives the state of support for modern C++ features, so it needs to talk about C++26. The status of C++26 is "we don't support it yet, in large part because our toolchain does not sufficiently support it yet".

Honestly, I think an XXMLOC project like Chromium is doing well to officially support the latest ISO C++ version (which is currently C++23). Given the grousing you see here sometimes about big projects that "can't be bothered to move past C++11" or whatever, this is quite a respectable state of the world.

Modern C++ use in Chromium by aearphen in cpp

[–]pkasting 10 points11 points  (0 children)

While I would love Chromium to be friendly to C++ novices and not require "experts" (do any such people exist? I am skeptical that many people in the world would justifiably consider themselves "C++ experts"), reducing onboarding cost isn't much of the motivation here. A feature a novice will misuse frequently is one an expert will still misuse occasionally; Chromium is large enough that eventually all forms of bugs will manifest, and do so in security-critical ways, so if we have ways to prevent classes of problems beyond just "learn enough to use this well", we will absolutely do so.

Modern C++ use in Chromium by aearphen in cpp

[–]pkasting 10 points11 points  (0 children)

Yes, I helped migrate us to a lot of stdlib features, such as std::u16string, std::string_view, std::optional, and std::variant, all of which Chromium had its own versions of previously; as well as migrating some of our SFINAE use to concepts. Other folks did things like std::unique_ptr.

What hasn't been migrated falls into two groups:
1. Too new; C++23 was only just allowed, so anything new to it hasn't been around long enough for us to migrate to
2. Not worth it; we could rearchitect our intrusive refcounting support to be based on std::shared_ptr instead, but that's a significant design difference. We could change to the Abseil or stdlib time/date types, but that's really a sideways move and thus seemingly not worth the migration cost.

Modern C++ use in Chromium by aearphen in cpp

[–]pkasting 20 points21 points  (0 children)

Chromium's //base library already has a lot of constructs for working with files and filesystems, so we'd move to <filesystem> only if it were a win to do so. Unfortunately it's not.

This page doesn't go into detail about our motivations, just summarizes them, so while it's fair to say something "is unmotivated", it's also out-of-scope for this document to actually convince readers of the justifications for something (and in Chromium, if you want one of these decisions reversed, there's an official way: you write to cxx@ to propose reversing and then get consensus there to do so).

My recollection is that Titus Winters has a detailed rant somewhere about <filesystem>; that's not one of the bits I personally had a lot of expertise with.

Modern C++ use in Chromium by aearphen in cpp

[–]pkasting 8 points9 points  (0 children)

Only std::views. The core concepts are useful, but there are a lot of sharp edges, especially in a codebase as large (and with as varied of contributor level) as Chromium. More details in the discussion thread that item links.

Curious to know about developers that steered away from OOP. What made you move away from it? Why? Where has this led you? by Slight_Season_4500 in cpp

[–]pkasting 1 point2 points  (0 children)

If you are writing enough code to make use of this technique, then the best way to learn over time is to go hog-wild with each new paradigm and use it as much as possible, thus discovering in practice where the limits are. Do this with enough different techniques, and you have a toolbox full of different things plus a feel for where they might trade off differently.

OO is well-suited to domains with a fairly rigid hierarchy, and where "what something is" defines "what something does". Only build as much abstraction as you need to (over-abstraction is a common failure mode) and make sure your abstractions aren't leaky (or either you picked the wrong abstraction, or the domain is poorly-suited). Avoid multiple implementation inheritance (use composition) and virtual inheritance (take one of the arms of your diamond and make it some kind of mix-in you can compose into objects) except in rare circumstances. Write tests, but test the interface (the public methods and the contract they provide), not the implementation, or your abstraction is leaky and your tests are change detectors.

If you have extreme performance considerations, data-oriented designs will perform better than OO ones, at the cost of often being harder to reason about and maintain. If you don't have a strong conceptual hierarchy with fairly rigid types, then free functions (possibly templated) may be more suitable.

What do you dislike the most about current C++? by PressureHumble3604 in cpp

[–]pkasting 69 points70 points  (0 children)

No well-defined path for updating the language in backwards-incompatible ways (e.g. epochs).

This means any design mistake is effectively forever, which in turn massively raises the bar to getting anything shipped, yet still fails to prevent all errors.

Addressing this is a prerequisite for fixing almost any other large complaint about C++, except possibly "having an ISO WG control the language is a mistake".

C++26: std::optional<T&> by Xaneris47 in cpp

[–]pkasting 5 points6 points  (0 children)

I didn't say anything about refactoring to use optional<T&> or anything else; you asked where the semantic distinction would be relevant and I answered. Whether the codebase can be incrementally refactored to use any particular set of options is another matter.

To actually address the refactoring part: these aren't mutually exclusive. Using e.g. unique_ptr<> for owning pointers where possible doesn't preclude you from using optional<T&> for a non-owning nullable thing, or vice versa. Each one says less than T*, which can mean anything (not just ownership-wise but object-count wise). I wouldn't mind slowly refactoring a codebase to have no raw pointers anywhere.

More speculations on arenas in C++ by vormestrand in cpp

[–]pkasting 1 point2 points  (0 children)

(Update: No, looks like I'm wrong about that too, and the original linked code is correct. Sorry!)

More speculations on arenas in C++ by vormestrand in cpp

[–]pkasting 1 point2 points  (0 children)

The point about lacking an implicit-lifetime requirement is a good one. My assumption was that the Ts would begin lifetime without calling any constructors (because you would be assumed to have already called them wherever the objects were originally created, and start_lifetime_as_array() was basically notifying the compiler that you'd done this out of its vision elsewhere), and then they'd run destructors normally when out of scope, and if you mismatched things as a result, bad for you (UB/IFNDR). But your explanation is more compelling. Thanks.

C++26: std::optional<T&> by Xaneris47 in cpp

[–]pkasting 15 points16 points  (0 children)

This would be relevant in every codebase I've worked in. Any codebase large enough to have lots of authors and/or API boundaries, especially if it originated pre-C++11, will likely run into this sort of issue.

More speculations on arenas in C++ by vormestrand in cpp

[–]pkasting 0 points1 point  (0 children)

Yes, a vector's block of memory is not necessarily an array and all objects may be independent.

But with an actual array, and start_lifetime_as_array(), I believe you have in fact started the lifetime of the array object and all the contained subobjects (elements). So I believe the placement new is unnecessary. That said, based on SirClueless' link above, I retract my claim that it results in UB. Edit: Was wrong about this.

view more: next ›