| ▲ | Night_Thastus 8 hours ago |
| Nothing particularly notable here. A lot of it seems to be 'We have something in-house designed for our use cases, use that instead of the standard lib equivalent'. The rest looks very reasonable, like avoiding locale-hell. Some of it is likely options that sand rough edges off of the standard lib, which is reasonable. |
|
| ▲ | ryandrake 6 hours ago | parent | next [-] |
| > We have something in-house designed for our use cases, use that instead of the standard lib equivalent Yea, you encounter this a lot at companies with very old codebases. Don't use "chrono" because we have our own date/time types that were made before chrono even existed. Don't use standard library containers because we have our own containers that date back to before the STL was even stable. I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them. |
| |
| ▲ | LexiMax 4 hours ago | parent | next [-] | | > I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them. The STL makes you pay for ABI stability no matter if you want it or not. For some use cases this doesn't matter, and there are some "proven" parts of the STL that need a lot of justification for substitution, yada yada std::vector and std::string. But it's not uncommon to see unordered_map substituted with, say, sparsehash or robin_map, and in C++ libraries creating interfaces that allow for API-compatible alternatives to use of the STL is considered polite, if not necessarily ubiquitous. | |
| ▲ | mtklein 5 hours ago | parent | prev [-] | | ... and for many of those blank .cpp file projects, the style guide should probably just read "start a blank .rs file instead." | | |
| ▲ | acdha 4 hours ago | parent [-] | | Look, I even share your language preference but this is still unnecessary. | | |
| ▲ | galangalalgol 4 hours ago | parent [-] | | Are there really any good reasons to start a brand new project in c++ though? No one who can write modern c++ has any trouble with rust in my experience, and all the other common options are even quicker to pick up. Creating bindings isn't hard anymore if your niche library doesn't have any yet. Syntactic preference I guess, but neither c++ or rust are generally considered elegant or aesthetic choices. | | |
| ▲ | cpgxiii 3 hours ago | parent | next [-] | | Because "brand new" doesn't mean devoid of context. Within your domain, there will still be common libraries, interfaces, and tools. C++ is very flexible, with a lot of very mature tooling and incredibly broad platform support. If you're writing some web server to run on the hardware of your choosing, then sure, that doesn't matter. But if you're writing something deeply integrated with platform/OS interfaces, or graphics, or needs to support some less common platforms, then C++ is often your only practical option for combining expressiveness and performance. | | |
| ▲ | galangalalgol 41 minutes ago | parent [-] | | This is the sort of info I was trolling for, but what are those platforms and os? Targets llvm doesn't handle yeah c++ makes sense, or c. A sibling mentions xcode, which makes sense. Graphics seems questionable, vulkan support is fine. Windows support has seemed finetoo, the same gui has worked as what we wrote for Linux. | | |
| ▲ | jupp0r a few seconds ago | parent [-] | | Dependencies. There are billions of lines of C++ out there that have been optimized and production hardened over decades that you might want to reuse. Rust lang interoperability with anything but C sucks in practice. |
|
| |
| ▲ | bigstrat2003 an hour ago | parent | prev | next [-] | | Maybe, maybe not. But either way it's just plain rude to charge into a C++ thread to drop a comment saying how the language sucks and you should use (insert other language) instead. | |
| ▲ | BearOso 4 hours ago | parent | prev | next [-] | | Rust becomes a significant burden if you need a GUI or hardware-accelerated graphics. | |
| ▲ | kstenerud 3 hours ago | parent | prev | next [-] | | Yes. If you're targeting Apple platforms and want to allow clients to use your product in Xcode (the common case) or even need Swift/ObjC interop yourself, using rust or anything not explicitly supported by Apple and Xcode is just too fiddly. | | | |
| ▲ | 2 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | CamperBob2 3 hours ago | parent | prev [-] | | (Shrug) If I want Rust, I'll feed my C++ to an LLM and tell it to port it to Rust. Since we've been assured that Rust magically fixes everything that's wrong, bad, or unsafe about C++, this seems like a sound approach. | | |
| ▲ | galangalalgol an hour ago | parent [-] | | We probably aren't that far off actually. Even taking asm with no symbols back into rust works well. You have truth, just have the agent repeat until the asm matches. Doesn't work on giant codebases, but on a few functions it absolutely does. And while the llm may get the algorithm wrong, the type system does seem to help it generate useful code in rust for a starting place v |
|
|
|
|
|
|
| ▲ | vitaut 6 hours ago | parent | prev | next [-] |
| Somewhat notable is that `char8_t` is banned with very reasonable motivation that applies to most codebases: > Use char and unprefixed character literals. Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t* is not interconvertible with char* (what ~all Chromium, STL, and platform-specific APIs use), so using u8 prefixes would obligate us to insert casts everywhere. If you want to declare at a type level that a block of data is string-like and not an arbitrary binary blob, prefer std::string[_view] over char*. |
| |
| ▲ | ChrisSD 5 hours ago | parent [-] | | `char8_t` is probably one of the more baffling blunders of the standards committee. | | |
| ▲ | jjmarr 5 hours ago | parent [-] | | there is no guarantee `char` is 8 bits, nor that it represents text, or even a particular encoding. If your codebase has those guarantees, go ahead and use it. | | |
| ▲ | 20k 4 hours ago | parent | next [-] | | char8_t also isn't guaranteed to be 8-bits, because sizeof(char) == 1 and sizeof(char8_t) >= 1. On a platform where char is 16 bits, char8_t will be 16 bits as well The cpp standard explicitly says that it has the same size, typed, signedness and alignment as unsigned char, but its a distinct type. So its pretty useless, and badly named | | | |
| ▲ | dataflow 5 hours ago | parent | prev | next [-] | | How many non-8-bit-char platforms are there with char8_t support, and how many do we expect in the future? | | | |
| ▲ | Maxatar 2 hours ago | parent | prev [-] | | There's no guarantee char8_t is 8 bits either, it's only guaranteed to be at least 8 bits. |
|
|
|
|
| ▲ | zeroq 2 hours ago | parent | prev [-] |
| Not an Googler, but my, probably way too much romanticized, understanding of Google was that they never ask you about specific tech because for everything there's an in-house version. The problem is that too many people drank too much koolaid and trying to parrot everything to a letter without understanding the bigger picture. The best example would be Kubernetes. Employed by many orgs that have 20 devs and 50 services. |
