Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

301–310 of 395 posts

Re: Modern C++ Won't Save Us

#301

Post by maccard »

simias wrote: post #248
noselasd wrote: post #212

Earlier quoted context omitted.

Sure, but that's not the issue. You should be using a std::optional like e.g. if (my_optional) do_stuff(*my_optional); Here's one (explicit)conditional. However if the dereferencing, *my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed

This is solved in Rust by letting you test and unwrap at the same time: if let Some(obj) = my_optional { do_stuff(obj); } >However if the dereferencing, my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed So basically that turns C++ optional types into fancy linter hints which won't actually…

You can also do it in a one-liner in C++ if you're using shared pointers:

    if(auto obj = my_weak_ptr.lock())
    {
        do_stuff(obj);
    }
> Having to pay for a check is "paying for what you use". If you don't like it then don't make the object nullable in the first place and save yourself the test.

The point is that I can choose _when_ to pay that cost (e.g. I can eat the nullability check at this point, but not at this point, and I can use more sophisticated tooling like a static analyser to reason that the null check is done correctly).

Is it more error prone? yes. Does it allow for things to horribly wrong? yes. Is "rewriting it in rust" a solution? No. If I want to pay the cost of ref-counting, I can use shared/weak ptrs.

Re: Modern C++ Won't Save Us

#302

Post by eska »

jcelerier wrote: post #191
Tracist wrote: post #116

Earlier quoted context omitted.

> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. The whole comment sounds so much like well written satire, but I think he's being serious.

> https://jaxenter.com/security-vulnerabilities-languages-1570... there's a world in terms of safety between C and C++.

You're misrepresenting the report in order to justify your bias. Direct quote from the report:

    This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructure like Open SSL and the Linux kernel. This winning combination of volume and centrality explains the high number of known open source vulnerabilities in C.`
In other words the report explains this with 1) there being more C code in volume and 2) more C code in security-relevant projects (which are reviewed more by security researchers). It also states explicitly that your conclusion is not to be drawn from this.

Re: Modern C++ Won't Save Us

#303

Post by jstimpfle »

lmm wrote: post #300
jstimpfle wrote: post #294

Earlier quoted context omitted.

> At that point you're not using global state in the library, which was the point. Yes. But I want to make clear that you are still using global state for all uses within the project itself. The library can be implemented in whatever way. For example, setting the pointer in a global variable on API entry ;-) > That doesn't solve the problem at all. WHICH problem? I don't think there is one. > Indeed, and they're seen…

> Yes. But I want to make clear that you are still using global state for all uses within the project itself. But if we believe in using libraries then often our project will itself be a library. > The library can be implemented in whatever way. For example, setting the pointer in a global variable on API entry ;-) And then you have the problem I mentioned: if there is a diamond dependency on your library then the th…

> The problem of not being able to break down your project and understand it piecemeal.

That's just incredibly untrue. It's FUD spread by OOP and FP zealots.

> All those global things are a common source of bugs, as different pieces of the program make subtly different assumptions about them.

Do you want to say that my logging routine is more complex because my windowing handle is stored in a globally accessible place?

> Perhaps a certain amount of global state is unavoidable. That's not an argument against minimizing it.

My advice is to make clear what the data means. Make it simple. Don't put a blanket over what's already hard to grasp.

Re: Modern C++ Won't Save Us

#304

Post by eska »

comex wrote: post #238
jcelerier wrote: post #191

Earlier quoted context omitted.

> https://jaxenter.com/security-vulnerabilities-languages-1570... there's a world in terms of safety between C and C++.

The comparison in that link is pretty meaningless; it scores languages by how many vulnerabilities have been reported in code written in them, without even making an attempt to divide by the total amount of code written in them, let alone account for factors like importance/level of public attention, what role the code plays, bias in the dataset, etc.

To be fair the report explicitly states this limitation. jcelerier just conveniently forgot to mention it.

Re: Modern C++ Won't Save Us

#305

Post by Althorion »

colanderman wrote: post #297
Althorion wrote: post #265

Earlier quoted context omitted.

> include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics Can you, from the top of your head, tell me what irregular modified cylindrical Bessel functions are and the last time you needed to use one? And yet, they were included in the standard library in C++17: https://en.cppreference.com/w/cpp/numeric/special_math/cyl_b...

I can't, but I bet they have a standard and well-accepted definition in the mathematical community. In fact, pretty much any real-valued mathematical function passes the test. The interface is settled, almost by definition since C++ functions are inspired by mathematical functions: pass in arguments, return result. Use range/domain exceptions or NaN for reporting such errors. The semantics are obvious: compute the na…

There’s nearly a limitless amount of standard and well-defined functions with a single usage, like those. There’s hardly a point in implementing them in the standard library and C++ is the only language that I’m aware of that has those.

If the goal was to create a specialized library for solving differential equations, those would be handy there. But if not, even if you tried implementing everything that you could potentially think of to implement, there are hundreds of things that are orders of magnitude more useful to have and equally well-defined and standardized—even if we limit ourselves to mathematics alone, I’d much rather see basic constants like π or e included, or quaternions, or arbitrary precision integers, or decimal numbers… or dozens upon dozens of other things before that.

But mainly, I find it impossible to maintain the claim that any general-usage language, like C++, that implements such niche functions is trying to keep its standard library small and ‘include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics’.

Re: Modern C++ Won't Save Us

#306

Post by lmm »

jstimpfle wrote: post #303
lmm wrote: post #300

Earlier quoted context omitted.

> Yes. But I want to make clear that you are still using global state for all uses within the project itself. But if we believe in using libraries then often our project will itself be a library. > The library can be implemented in whatever way. For example, setting the pointer in a global variable on API entry ;-) And then you have the problem I mentioned: if there is a diamond dependency on your library then the th…

> The problem of not being able to break down your project and understand it piecemeal. That's just incredibly untrue. It's FUD spread by OOP and FP zealots. > All those global things are a common source of bugs, as different pieces of the program make subtly different assumptions about them. Do you want to say that my logging routine is more complex because my windowing handle is stored in a globally accessible plac…

> Do you want to say that my logging routine is more complex because my windowing handle is global data?

If your logging routine touches your windowing handle that certainly makes it more complex. If I'm meant to know that your logging routine doesn't touch your windowing handle, that's precisely the statement that it isn't global data.

Re: Modern C++ Won't Save Us

#307

Post by jstimpfle »

lmm wrote: post #306
jstimpfle wrote: post #303

Earlier quoted context omitted.

> The problem of not being able to break down your project and understand it piecemeal. That's just incredibly untrue. It's FUD spread by OOP and FP zealots. > All those global things are a common source of bugs, as different pieces of the program make subtly different assumptions about them. Do you want to say that my logging routine is more complex because my windowing handle is stored in a globally accessible plac…

> Do you want to say that my logging routine is more complex because my windowing handle is global data? If your logging routine touches your windowing handle that certainly makes it more complex. If I'm meant to know that your logging routine doesn't touch your windowing handle, that's precisely the statement that it isn't global data.

It is global data, because it can (and should be) used without threading it through 155 functions.

In terms of the relational data model, it is global data because there is always one, and only one, of it.

Re: Modern C++ Won't Save Us

#308

Post by galangalalgol »

swiftcoder wrote: post #50
the_trapper wrote: post #46

Earlier quoted context omitted.

Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.

It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations. That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are no…

Cargo is the problem for those organizations. People who worry about security and safety often develop on airgapped networks. You can go nostd for small stuff. For bigger stuff you could mirror crates.io but that isn't a well supported workflow and it's a lot o code from a lot of randos. The notion of a blessed subset would help get more buy in from that community. Even still, rustup isn't working on airgapped Dev nets and it's a nice feature especially if you are crosscompiling.

Re: Modern C++ Won't Save Us

#309

Post by micv »

kibibu wrote: post #284
paulmooreparks wrote: post #134

Earlier quoted context omitted.

Why is it difficult to believe? I've also written plenty of C++ code without memory bugs. It's not that hard if you play by a few simple rules.

I haven't written c++ seriously for a number of years. Do you still have to do all that "rule of three" boilerplate stuff to use your classes with the STL? Is it better or worse now with move constructors?

It's a bit better with C++11 syntax where you can use = delete to remove the default constructors/destructors, e.g.:

  class Class
  {
      Class();
      Class(const Class&) = delete;
      Class& operator = (const Class&) = delete;
      ~Class() = default;
  };
Which I find slightly cleaner than the old approach of declaring them private and not defining an implementation, but the concept hasn't changed much. I'd love a way to say 'no, compiler, I'll define the constructors, operators, and destructors I want - no defaults' but that's not part of the standard.

Move constructors are an extra that, if I remember correctly, don't get a default version, thankfully.

Re: Modern C++ Won't Save Us

#310

Post by 0815test »

galangalalgol wrote: post #308
swiftcoder wrote: post #50

Earlier quoted context omitted.

It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations. That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are no…

Cargo is the problem for those organizations. People who worry about security and safety often develop on airgapped networks. You can go nostd for small stuff. For bigger stuff you could mirror crates.io but that isn't a well supported workflow and it's a lot o code from a lot of randos. The notion of a blessed subset would help get more buy in from that community. Even still, rustup isn't working on airgapped Dev ne…

Cargo now supports airgapped use (no crates.io, no github) since the latest release.
Post reply on HN