8 ms·

Considering the seemingly endless list of things that deliberately don't break with the c++ legacy, new syntax is almost the only change left. And if you were a

by usrusr 4y ago

Considering the seemingly endless list of things that deliberately don't break with the c++ legacy, new syntax is almost the only change left. And if you were about to give c++ a syntax reboot, why wouldn't you look at what successful other modern syntaxes are doing? "c++, but in a syntax for people accustomed to rust instead of in a syntax for people accustomed to C" sounds like a perfectly reasonable approach. Your perception (and mine) that rust is about to become the new default for "true native" is perfectly consistent with this, a language for the rust generation for when they have to deal with the c++ legacy. A legacy that won't be going away any time soon. I suspect that the author (authors?) wouldn't disagree at all with "use Rust when possible, Carbon when you can't", my perception (from a quick glance at the site) is that they are fully aware of the limitations of the niche they have so clearly staked out.

mempko 4y ago
The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it
- fouronnes3 4y ago
  C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.
  - AnimalMuppet 4y ago
    Given that gunpowder was invented in the 9th century, fifth century fireworks were probably pretty uninteresting...
  - pjmlp 4y ago
    Use Visual C++ and you will have modules today. I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch.
    - joshuamorton 4y ago
      > I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch. To be fair, if you're using a language that has a reasonable compilation story, this is only every a concern the first time you compile.
      - pjmlp 4y ago
        Sure I always need an excuse to go out for lunch.
  - StillBored 4y ago
    "C++ has virtually zero tooling" I read that and I was like WTF, the entire programming ecosystem exists on C/C++ tooling. But from your perspective its modules/cargo that is the tooling? That is IMHO an odd viewpoint. As someone who despises the way cargo works, and hates not having long term explicit control over my dependencies (going so far as to track and check them in along with build artifacts) I'm not convinced that the recent toss another random dependency that itself pulls dependencies into the build is a good thing. I like the fact that I have three dozen+ different ways to do regexp's in C depending on my priorities, and that picking one requires cognitive overhead and modifications to source control/etc. Its easy to add a line to a makefile/etc to pull crap off github in C, so its not like this is a hard problem to deal with in C/C++ but its one where the scale of the problem allows for optimization. AKA like the dynamic typing argument, making the programmer think about a problem I believe yields a better solution. Its also one where i'm not tied to the whimsy of the library author should I decide to fork or maintain the code long after they have gotten bored or rewritten it 3 different times. I can to this day rebuild code I wrote 20 years ago on a modern machine with little effort. Can you say the same about even 10 year old node.js or python code? Put another way, I spend a little bit more on upfront effort and it pays off long term. And I know i'm in the minority, but its also why repeatedly I've run small teams of a half dozen or so people who's products are ahead of major competitors with teams of 100's+ of engineers.
    - boardwaalk 4y ago
      You can do things the way you do them in C++ in Rust if you want. You could `cargo vendor`, you could fork a repo & depend on a specific commit, etc. It’s up to you have the self-control to do that though and not just shovel random dependencies into your project, that’s all. Mostly you seem to be complaining that it’s just to add dependencies? (maybe put a ‘sleep’ in your bash prompt or something?) and maybe that the Rust ecosystem doesn’t have as many duplicate libraries as C++? (of course it doesn’t?)
      - StillBored 4y ago
        The problem is that cargo gets in the way (as does rustc) if you try and use it in anything other than the simple import this dependency mode. I spent a hell hole of a day or two, trying to pick up a dependency outside cargo because it didn't behave in a way that meshed with the rest of my build environment. So, yes it handles a couple of the basic cases, but then your out of luck, stuck in a version hell/etc because rustc and cargo are so tightly integrated and the flags needed to emulate some of the behavior with just the compiler are poorly documented and/or version dependent. It dictates, you conform (which is basically the rust way).
  - germandiago 4y ago
    Besides having lsp (language server protocol), Visual C++, CLion and others, I have been successfully using CMake/Meson paired with Conan and I can tell from experience that it is amazing what you can achieve. Someone will say Cargo or whatever, which is nice and simple. But with these tools you can choose all details and optimizations as well, something that other tools just hide. But you can still keep it simple with a conanfile.txt for your dependencies and the stock add_executable etc. in CMake/Meson and get done with it. If you feel CMake is subpar (bc its syntax and DSL are terrible, I agree with that) then you can use Meson. It works pretty well.
  - adev_ 4y ago
    > C++ has virtually zero tooling and the committee is not interested in ever working on that This sentence makes no sense at all: 1 - Tooling does not stop to the build systems 2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memtracers, profilers, thread sanitizers, debuggers, disassemblers, static analyzers, packages managers, bindings generators, ABI checkers, crash analyzers, loggers and I am sure I forget still many others.
    - fouronnes3 4y ago
      Yeah what I meant was build system tooling, sorry for the approximation.
    - flohofwoe 4y ago
      Most of the tools you mention work below the language level, and thus work automatically for non-C/C++ languages too (or at least LLVM-based languages).
      - adev_ 4y ago
        They do work below the language level but have been generally explicitly made for C and C++ programs. e.g abi-compliance-checker The other languages benefit of them currently because they leverage LLVM (also made in C++), because their interpreter/VM are made directly in C. How is it already ? Standing on the shoulders of giants ? :)
    - deleted 4y ago
      [deleted]
  - mbrodersen 4y ago
    Hahaha you have zero clue. C++ has the best tooling in the world. From static analysers to best in class debuggers to best in class performance profiling tools etc. No other language comes even close.
    - flohofwoe 4y ago
      Most of the tools you mention are actually language agnostic (debuggers and profilers). And static analyzers are much more important for C and C++ than other languages.
    - int_19h 4y ago
      Java has far more extensive tooling in all the categories that you've mentioned. I don't know if it's "the best tooling in the world", but if I had to make an educated guess, I'd bet on Java - and I don't even like it as a language.
  - germandiago 4y ago
    > C++ has virtually zero tooling CMake, Meson, Waf, Conan, Visual Studio Code, Visual Studio, CLion, Intel VTune, GDB, LLDB, XCode, Artifactory, SonarQube, clang-tidy, clang-format, astyle, Incredibuild... > Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle You are wrong here. Cargo serves a set of fixed "this-is-how-to-do-it" thing. In C++ you can build anything. I do not mean it is better, but C++ software already exists and that is the solution that it works better for it. :) > and the committee is not interested in ever working on that https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0822r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p08... Interoperability effort for modules: https://github.com/GabrielDosReis/ipr https://github.com/GabrielDosReis/ipr
- fsloth 4y ago
  Regarding C++. IMHO - it’s not getting intrinsically better. More complex. Easy things become a bit less verbose, but the hardest things remain as hard and the compiler is as unhelpful as before. I agree C++11 and it’s successors are sugaring the language to be a lot nicer but fundamentally nothing has changed. Rust is fundamentally better in it’s compiler warnings (they are actually helpful), and contains specific solutions to the things that are hard and bite you in C++. C++ is not going away and it’s my main professional language but Rust does have features that are better.
  - sudosysgen 4y ago
    In my experience compiler error messages have gotten hugely better, except for template issues which are still very verbose. Especially with clang.
    - senkora 4y ago
      And template error messages should become much better with concepts in c++20.
  - spacechild1 4y ago
    > but fundamentally nothing has changed. IMO, move semantics and lambda functions have fundamentally changed the way we write C++. Also, let's not forget that C++11 introduced a formal memory model with cross-platform atomic operations and multi-threading primitives.
  - plonk 4y ago
    Fundamentally, it has smart pointers and std::make_unique now, which means I never have to touch a raw pointer in most of my code. They can even be adapted to wrap Win32 objects. That's a huge improvement and I don't mind using C++ for new projects now.
- gpderetta 4y ago
  Doesn't C++11 precede rust?
  - grimfang4 4y ago
    Almost. C++0x did, but C++11 doesn't and some compilers/IDEs (e.g. VS) didn't implement full support for C++11 for years.
  - avrionov 4y ago
    I had the same question as you so I checked. C++ 11 standard was released in 2011 of course. Rust development started in 2006 and Mozilla announced it officially in 2010.
    - arinlen 4y ago
      > C++ 11 standard was released in 2011 of course. Rust development started in 2006 and Mozilla announced it officially in 2010. Given that c++0x was a decade in the making, by that measuring stick the answer is yes, C++11 does precede Rust.
    - bzxcvbn 4y ago
      It's a bit weird to take the release date for one, and the start of the development for the other. By that measure, the first pre-alpha (!) release of Rust was in 2012; the first stable release in 2015. On the other hand, the first RFC for C++0x was in 2008.
  - tialaramex 4y ago
    Rust 1.0 is 2015. Hence this is sometimes referred to as "2015 edition" in Rust's edition system. But the sort of people who are here to tell you about how great C++ is will say well, actually Rust existed all the way back to 2006 as Graydon's personal project. There were no numbered releases until Rust 0.1 (after C++ 11) and modern features like Traits don't appear until much later, but sure, in this sense Rust existed in 2006.
- mihaigalos 4y ago
  As far as I'm concerned, C++ is there for legacy purposes only. There are some nice frameworks and tools using it, sure. Yes, you are required to learn it if you are studying CS. Any serious new development today is done using more modern languages such as Rust (i.e.: the linkerd service mesh proxy [1] for encrypted pod communication in a k8s cluster). As even the Linux kernel is slowly transitioning to using Rust [2], it's only a matter of time before an inflection point is reached and it goes mainstream (if not already.) [1] https://github.com/linkerd/linkerd2-proxy https://github.com/linkerd/linkerd2-proxy [2] https://hackaday.com/2022/05/17/things-are-getting-rusty-in-kernel-land/ https://hackaday.com/2022/05/17/things-are-getting-rusty-in-...
  - pjmlp 4y ago
    Just learned that LLVM, GCC, CUDA, HPC, HFT and the whole games industry aren't serious new development.
    - mihaigalos 4y ago
      .. is it new development?
      - pjmlp 4y ago
        I guess, unless you're into retro-gaming.
        maccard 4y ago
        To be fair, parts of my work codebase are touching on 25 years old, and I work for a startup from 2020. The codebases we're building on have roots in the mid 90s, and the platforms they run on didn't support modern C++ standards for a very long time after that.
        Jensson 4y ago
        So anything including "windows.h" isn't really new development then? Sounds like a strange definition. I'd say that there is a lot of new projects being started with C++, still way more than there are new projects in Rust, at least if you only count serious ones.
- raydev 4y ago
  It's impossible to deny that C++ is improving. But it's worth investigating what you can do when you aren't tethered to wild inconsistencies and odd behaviors and workarounds because the community is terrified of breaking backcompat.
- JoshTriplett 4y ago
  C++11 was where C++ lost me, and I went from saying I knew C/C++ to saying I know C.
  - imron 4y ago
    C++14 was what got me in to Rust. I'm still in the C++ world for work, and have kept reasonably up to date with things to C++17, but I'm sitting here looking at C++20 and wondering is it really worth the effort...
  - a9h74j 4y ago
    Precisely.
- imron 4y ago
  > The problem with C++ is it keeps getting better This is debatable. It keeps getting more complex. Whether all the additions are worthwhile remains to be seen.
  - jcelerier 4y ago
    every successive C++ standard allows me to remove a lot of code which is a net benefit
kllrnohj 4y ago
> I suspect that the author (authors?) wouldn't disagree at all with "use Rust when possible, Carbon when you can't" That is in fact explicitly stated on the Carbon introduction: "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."
- nextaccountic 4y ago
  Also on their FAQ https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#if-you-can-use-rust-ignore-carbon= https://github.com/carbon-language/carbon-lang/blob/trunk/do... > If you can use Rust, ignore Carbon > If you want to use Rust, and it is technically and economically viable for your project, you should use Rust. In fact, if you can use Rust or any other established programming language, you should. Carbon is for organizations and projects that heavily depend on C++; for example, projects that have a lot of C++ code or use many third-party C++ libraries.

by usrusr 4y ago

mempko 4y ago

The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it

fouronnes3 4y ago
C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.
- AnimalMuppet 4y ago
  Given that gunpowder was invented in the 9th century, fifth century fireworks were probably pretty uninteresting...
- pjmlp 4y ago
  Use Visual C++ and you will have modules today. I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch.
  - joshuamorton 4y ago
    > I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch. To be fair, if you're using a language that has a reasonable compilation story, this is only every a concern the first time you compile.
    - pjmlp 4y ago
      Sure I always need an excuse to go out for lunch.
- StillBored 4y ago
  "C++ has virtually zero tooling" I read that and I was like WTF, the entire programming ecosystem exists on C/C++ tooling. But from your perspective its modules/cargo that is the tooling? That is IMHO an odd viewpoint. As someone who despises the way cargo works, and hates not having long term explicit control over my dependencies (going so far as to track and check them in along with build artifacts) I'm not convinced that the recent toss another random dependency that itself pulls dependencies into the build is a good thing. I like the fact that I have three dozen+ different ways to do regexp's in C depending on my priorities, and that picking one requires cognitive overhead and modifications to source control/etc. Its easy to add a line to a makefile/etc to pull crap off github in C, so its not like this is a hard problem to deal with in C/C++ but its one where the scale of the problem allows for optimization. AKA like the dynamic typing argument, making the programmer think about a problem I believe yields a better solution. Its also one where i'm not tied to the whimsy of the library author should I decide to fork or maintain the code long after they have gotten bored or rewritten it 3 different times. I can to this day rebuild code I wrote 20 years ago on a modern machine with little effort. Can you say the same about even 10 year old node.js or python code? Put another way, I spend a little bit more on upfront effort and it pays off long term. And I know i'm in the minority, but its also why repeatedly I've run small teams of a half dozen or so people who's products are ahead of major competitors with teams of 100's+ of engineers.
  - boardwaalk 4y ago
    You can do things the way you do them in C++ in Rust if you want. You could `cargo vendor`, you could fork a repo & depend on a specific commit, etc. It’s up to you have the self-control to do that though and not just shovel random dependencies into your project, that’s all. Mostly you seem to be complaining that it’s just to add dependencies? (maybe put a ‘sleep’ in your bash prompt or something?) and maybe that the Rust ecosystem doesn’t have as many duplicate libraries as C++? (of course it doesn’t?)
    - StillBored 4y ago
      The problem is that cargo gets in the way (as does rustc) if you try and use it in anything other than the simple import this dependency mode. I spent a hell hole of a day or two, trying to pick up a dependency outside cargo because it didn't behave in a way that meshed with the rest of my build environment. So, yes it handles a couple of the basic cases, but then your out of luck, stuck in a version hell/etc because rustc and cargo are so tightly integrated and the flags needed to emulate some of the behavior with just the compiler are poorly documented and/or version dependent. It dictates, you conform (which is basically the rust way).
- germandiago 4y ago
  Besides having lsp (language server protocol), Visual C++, CLion and others, I have been successfully using CMake/Meson paired with Conan and I can tell from experience that it is amazing what you can achieve. Someone will say Cargo or whatever, which is nice and simple. But with these tools you can choose all details and optimizations as well, something that other tools just hide. But you can still keep it simple with a conanfile.txt for your dependencies and the stock add_executable etc. in CMake/Meson and get done with it. If you feel CMake is subpar (bc its syntax and DSL are terrible, I agree with that) then you can use Meson. It works pretty well.
- adev_ 4y ago
  > C++ has virtually zero tooling and the committee is not interested in ever working on that This sentence makes no sense at all: 1 - Tooling does not stop to the build systems 2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memtracers, profilers, thread sanitizers, debuggers, disassemblers, static analyzers, packages managers, bindings generators, ABI checkers, crash analyzers, loggers and I am sure I forget still many others.
  - fouronnes3 4y ago
    Yeah what I meant was build system tooling, sorry for the approximation.
  - flohofwoe 4y ago
    Most of the tools you mention work below the language level, and thus work automatically for non-C/C++ languages too (or at least LLVM-based languages).
    - adev_ 4y ago
      They do work below the language level but have been generally explicitly made for C and C++ programs. e.g abi-compliance-checker The other languages benefit of them currently because they leverage LLVM (also made in C++), because their interpreter/VM are made directly in C. How is it already ? Standing on the shoulders of giants ? :)
  - deleted 4y ago
    [deleted]
- mbrodersen 4y ago
  Hahaha you have zero clue. C++ has the best tooling in the world. From static analysers to best in class debuggers to best in class performance profiling tools etc. No other language comes even close.
  - flohofwoe 4y ago
    Most of the tools you mention are actually language agnostic (debuggers and profilers). And static analyzers are much more important for C and C++ than other languages.
  - int_19h 4y ago
    Java has far more extensive tooling in all the categories that you've mentioned. I don't know if it's "the best tooling in the world", but if I had to make an educated guess, I'd bet on Java - and I don't even like it as a language.
- germandiago 4y ago
  > C++ has virtually zero tooling CMake, Meson, Waf, Conan, Visual Studio Code, Visual Studio, CLion, Intel VTune, GDB, LLDB, XCode, Artifactory, SonarQube, clang-tidy, clang-format, astyle, Incredibuild... > Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle You are wrong here. Cargo serves a set of fixed "this-is-how-to-do-it" thing. In C++ you can build anything. I do not mean it is better, but C++ software already exists and that is the solution that it works better for it. :) > and the committee is not interested in ever working on that https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0822r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p08... Interoperability effort for modules: https://github.com/GabrielDosReis/ipr https://github.com/GabrielDosReis/ipr
fsloth 4y ago
Regarding C++. IMHO - it’s not getting intrinsically better. More complex. Easy things become a bit less verbose, but the hardest things remain as hard and the compiler is as unhelpful as before. I agree C++11 and it’s successors are sugaring the language to be a lot nicer but fundamentally nothing has changed. Rust is fundamentally better in it’s compiler warnings (they are actually helpful), and contains specific solutions to the things that are hard and bite you in C++. C++ is not going away and it’s my main professional language but Rust does have features that are better.
- sudosysgen 4y ago
  In my experience compiler error messages have gotten hugely better, except for template issues which are still very verbose. Especially with clang.
  - senkora 4y ago
    And template error messages should become much better with concepts in c++20.
- spacechild1 4y ago
  > but fundamentally nothing has changed. IMO, move semantics and lambda functions have fundamentally changed the way we write C++. Also, let's not forget that C++11 introduced a formal memory model with cross-platform atomic operations and multi-threading primitives.
- plonk 4y ago
  Fundamentally, it has smart pointers and std::make_unique now, which means I never have to touch a raw pointer in most of my code. They can even be adapted to wrap Win32 objects. That's a huge improvement and I don't mind using C++ for new projects now.
gpderetta 4y ago
Doesn't C++11 precede rust?
- grimfang4 4y ago
  Almost. C++0x did, but C++11 doesn't and some compilers/IDEs (e.g. VS) didn't implement full support for C++11 for years.
- avrionov 4y ago
  I had the same question as you so I checked. C++ 11 standard was released in 2011 of course. Rust development started in 2006 and Mozilla announced it officially in 2010.
  - arinlen 4y ago
    > C++ 11 standard was released in 2011 of course. Rust development started in 2006 and Mozilla announced it officially in 2010. Given that c++0x was a decade in the making, by that measuring stick the answer is yes, C++11 does precede Rust.
  - bzxcvbn 4y ago
    It's a bit weird to take the release date for one, and the start of the development for the other. By that measure, the first pre-alpha (!) release of Rust was in 2012; the first stable release in 2015. On the other hand, the first RFC for C++0x was in 2008.
- tialaramex 4y ago
  Rust 1.0 is 2015. Hence this is sometimes referred to as "2015 edition" in Rust's edition system. But the sort of people who are here to tell you about how great C++ is will say well, actually Rust existed all the way back to 2006 as Graydon's personal project. There were no numbered releases until Rust 0.1 (after C++ 11) and modern features like Traits don't appear until much later, but sure, in this sense Rust existed in 2006.
mihaigalos 4y ago
As far as I'm concerned, C++ is there for legacy purposes only. There are some nice frameworks and tools using it, sure. Yes, you are required to learn it if you are studying CS. Any serious new development today is done using more modern languages such as Rust (i.e.: the linkerd service mesh proxy [1] for encrypted pod communication in a k8s cluster). As even the Linux kernel is slowly transitioning to using Rust [2], it's only a matter of time before an inflection point is reached and it goes mainstream (if not already.) [1] https://github.com/linkerd/linkerd2-proxy https://github.com/linkerd/linkerd2-proxy [2] https://hackaday.com/2022/05/17/things-are-getting-rusty-in-kernel-land/ https://hackaday.com/2022/05/17/things-are-getting-rusty-in-...
- pjmlp 4y ago
  Just learned that LLVM, GCC, CUDA, HPC, HFT and the whole games industry aren't serious new development.
  - mihaigalos 4y ago
    .. is it new development?
    - pjmlp 4y ago
      I guess, unless you're into retro-gaming.
      - maccard 4y ago
        To be fair, parts of my work codebase are touching on 25 years old, and I work for a startup from 2020. The codebases we're building on have roots in the mid 90s, and the platforms they run on didn't support modern C++ standards for a very long time after that.
        Jensson 4y ago
        So anything including "windows.h" isn't really new development then? Sounds like a strange definition. I'd say that there is a lot of new projects being started with C++, still way more than there are new projects in Rust, at least if you only count serious ones.
raydev 4y ago
It's impossible to deny that C++ is improving. But it's worth investigating what you can do when you aren't tethered to wild inconsistencies and odd behaviors and workarounds because the community is terrified of breaking backcompat.
JoshTriplett 4y ago
C++11 was where C++ lost me, and I went from saying I knew C/C++ to saying I know C.
- imron 4y ago
  C++14 was what got me in to Rust. I'm still in the C++ world for work, and have kept reasonably up to date with things to C++17, but I'm sitting here looking at C++20 and wondering is it really worth the effort...
- a9h74j 4y ago
  Precisely.
imron 4y ago
> The problem with C++ is it keeps getting better This is debatable. It keeps getting more complex. Whether all the additions are worthwhile remains to be seen.
- jcelerier 4y ago
  every successive C++ standard allows me to remove a lot of code which is a net benefit

kllrnohj 4y ago

> I suspect that the author (authors?) wouldn't disagree at all with "use Rust when possible, Carbon when you can't" That is in fact explicitly stated on the Carbon introduction: "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."

nextaccountic 4y ago
Also on their FAQ https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#if-you-can-use-rust-ignore-carbon= https://github.com/carbon-language/carbon-lang/blob/trunk/do... > If you can use Rust, ignore Carbon > If you want to use Rust, and it is technically and economically viable for your project, you should use Rust. In fact, if you can use Rust or any other established programming language, you should. Carbon is for organizations and projects that heavily depend on C++; for example, projects that have a lot of C++ code or use many third-party C++ libraries.