this post was submitted on 13 Sep 2024
56 points (100.0% liked)

Programming

19357 readers
114 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
56
Safe C++ (safecpp.org)
submitted 6 months ago by mox@lemmy.sdf.org to c/programming@programming.dev
36 comments fedilink hide all child comments
top 36 comments
sorted by: hot top controversial new old
[–] onlinepersona@programming.dev 19 points 6 months ago (2 children)

C++ continues to be the dumping ground of paradigms and language features. This proposal just aims to add even more to an overloaded language.

C++ programmers mocked languages for being dynamically typed then they introduced auto, they mocked JS for callback hell and introduced lambdas, they mocked Rust devs for being lowskill C++ devs who can't manage their own memory and now they are admitting they can't manage it themselves either.

It's going to be come like the x86 instruction set or windows that is backwards compatible with stuff from 30years ago just accumulating cruft, unable to let go.

Anti Commercial-AI license

[–] GetOffMyLan@programming.dev 30 points 6 months ago* (last edited 6 months ago) (1 children)

auto isn't dynamic typing it's just type inference. It still has a fixed type you just don't have to write it. Like var in C#.

Lambdas are just a way of defining methods in place. It has nothing to do with callbacks.

But you're spot on for memory safety. Managing it yourself is risky and if it can be managed at zero cost it seems stupid not to.

[–] onlinepersona@programming.dev 2 points 6 months ago* (last edited 6 months ago) (2 children)

auto isn’t dynamic typing it’s just type inference.

I'm aware, but one of the big arguments I've heard about dynamic typing is "I don't know which type it has when I read the code". Well, auto looks just like var in that regard.

Lambdas are just a way of defining methods in place. It has nothing to do with callbacks.

Callback definition from wikipedia:

In computer programming, a callback is a function that is stored as data (a reference) and designed to be called by another function – often back to the original abstraction layer.

This is exactly what lambdas are often used for in C++.

Anti Commercial-AI license

[–] lysdexic@programming.dev 8 points 6 months ago* (last edited 6 months ago)

Well, auto looks just like var in that regard.

It really isn't. Neither in C# nor in Java. They are just syntactic sugar to avoid redundant type specifications. I mean things like Foo foo = new Foo();. Who gets confused with that?

Why do you think IDEs are able to tell which type a variable is?

Even C# takes a step further and allows developer to omit the constructor with their target-typed new expressions. No one is whining about dynamic types just because the language let's you instantiate an object with Foo foo = new();.

[–] GetOffMyLan@programming.dev 4 points 6 months ago (1 children)

The problem with dynamic typing is you can't always figure out what the type is even with investigation as it can be lots of things based on what is passed or returned. It also allows incorrect values to be passed.

People will indeed make that readability argument but if the type is not obvious and important to understanding the code then it likely shouldn't be used there.

[–] onlinepersona@programming.dev 4 points 6 months ago* (last edited 6 months ago) (1 children)

Keyword being "shouldn't". C++ doesn't care about that, it just hands you the loaded gun.

Anti Commercial-AI license

[–] GetOffMyLan@programming.dev 4 points 6 months ago (1 children)

I wouldn't call bad readability a loaded gun really. Your dev tools will hopefully make it pretty easy to learn the type. It should be a minor inconvenience at best.

[–] lysdexic@programming.dev 4 points 6 months ago

I wouldn’t call bad readability a loaded gun really.

Bad readability is a problem cause by the developer, not the language. Anyone can crank out unreadable symbol soup in any language, if that's what they want/can deliver.

Blaming the programming language for the programmer's incompetence is very telling, so telling there's even a saying: A bad workman always blames his tools.

[–] lysdexic@programming.dev 12 points 6 months ago

C++ continues to be the dumping ground of paradigms and language features. This proposal just aims to add even more to an overloaded language.

I think you could not be more wrong even if you tried, and you clearly did not even read the proposal you're commenting on.

This proposal aims to basically create an entirely different programming language aimed at being easy to integrate in extsting codebases. The language just so happens to share some syntax with C++, but you definitely can't compile it with a C++ compiler because it introduces a series of backwards incompatible changes.

It's also absurd how you complain about introducing new features. Can you point out any language that is not absolutely dead that is not introducing new features with each release?

C++ programmers mocked languages for being dynamically typed then they introduced auto (...)

I'm sorry, you are clearly confused. The auto keyword is not "dynamically typed". It is called "auto" because it does automatic type deduction. It is syntactic sugar to avoid having to explicitly specify the type name in places the compiler knows it already. Do you understand what this means?

Your comment sounds like trolling, frankly.

[–] magic_lobster_party@fedia.io 16 points 6 months ago (1 children)

Haven’t read through this, but this sounds like what C++ is to C. I’m not sure adding more complexity and features to an already complex language is the right way forward. What is needed is a language that cuts down all the burden that has accumulated in C++ over 3 decades.

Something like Zig sounds like the better path forward to me. A completely new language from scratch with cross interoperability to C++. I’m surprised it’s not mentioned even once in the page.

[–] PushButton@lemmy.world 16 points 6 months ago* (last edited 6 months ago)

I went for a blood test two days ago.

The girls came back sprinting with some papers, asking me how it was possible???

I asked calmly what was going on, right? That's when she said she never saw, in her entire life, such beautiful, elegant, fast and clean blood!

I was like: "darling, that's because Zig is flowing in my veins, I just can't stop using it"...

That being said, I totally agree with you.

[–] solrize@lemmy.world 11 points 6 months ago (2 children)

It's very hard for "Safe C++" to exist when integer overflow is UB. Rust also gets it wrong, though not quite in the same way. Ada gets it right.

[–] BatmanAoD@programming.dev 9 points 6 months ago (1 children)

By Ada getting it right, I assume you mean throwing an exception on any overflow? (Apparently this behavior was optional in older versions of GNAT.) Why is Ada's preferable to Rust's?

In Rust, integer overflow panics by default in debug mode but wraps silently in release mode; but, optionally, you can specify wrapping, checked (panicking), or unchecked behavior for a specific operation, so that optimization level doesn't affect the behavior. This makes sense to me; the unoptimized version is the same as Ada, and the optimized version is not UB, but you can control the behavior explicitly when necessary.

[–] solrize@lemmy.world 2 points 6 months ago (1 children)

In Ada, the overflow behaviour is determined by the type signature. You can also sometimes use SPARK to statically guarantee the absence of overflow in a program. In Rust, as I understand it, you can control the overflow behaviour of a particular arithmetic operation by wrapping a function or macro call around it, but that is ugly and too easy to omit.

For ordinary integers, an arithmetic overflow is similar to an OOB array reference and should be trapped, though you might sometimes choose to disable the trap for better performance, similar to how you might disable an array subscript OOB check. Wraparound for ordinary integers is simply incorrect. You might want it for modular arithmetic and that is fine, but in Ada you get that by specifying it in the type declaration. Also in Ada, you can specify the min and max bounds, or the modulus in the case of modular arithmetic. For example, you could have a "day of week as integer" ranging from 1 to 7, that traps on overflow.

GNAT imho made an error of judgment by disabling the overflow check by default, but at least you can turn it back on.

The RISC-V architecture designers made a harder to fix error by making everything wraparound, with no flags or traps to catch unintentional overflow, so you have to generate extra code for every arithmetic op.

[–] BatmanAoD@programming.dev 1 points 6 months ago (1 children)

It sounds like you're talking about dependent typing, then, at least for integers? That's certainly a feature Rust lacks that seems like it would be nice, though I understand it's quite complicated to implement and would probably make Rust compile times much slower.

For ordinary integers, an arithmetic overflow is similar to an OOB array reference and should be trapped, though you might sometimes choose to disable the trap for better performance, similar to how you might disable an array subscript OOB check.

That's exactly what I described above. By default, trapping on overflow/underflow is enabled for debug builds and disabled for release builds. As I said, I think this is a sensible behavior. But in addition to per-operation explicit handling, you can explicitly turn global trapping behavior trapping on or off in your build profile, though.

[–] solrize@lemmy.world 1 points 6 months ago (1 children)

In Ada? No dependent types, you just declare how to handle overflow, like declaring int16 vs int32 or similar. Dependent types means something entirely different and they are checked at compile time. SPARK uses something more like Hoare logic. Regular Ada uses runtime checks.

[–] BatmanAoD@programming.dev 1 points 6 months ago (1 children)

Whatever you want to call them, my point is that most languages, including Rust, don't have a way to define new integer types that are constrained by user-provided bounds.

Dependent types, as far as I'm aware, aren't defined in terms of "compile time" versus "run time"; they're just types that depend on a value. It seems to me that constraining an integer type to a specific range of values is a clear example of that, but I'm not a type theory expert.

[–] solrize@lemmy.world 1 points 6 months ago* (last edited 6 months ago) (1 children)

Dependent types only make sense in the context of static typing, i.e. compile time. In a dependently typed language, if you have a term with type {1,2,3,4,5,6,7} and the program typechecks at compile time, you are guaranteed that there is no execution path through which that term takes on a value outside that set. You may need to supply a complicated proof to help the compiler.

In Ada you can define an integer type of range 1..7 and it is no big deal. There is no static guarantee like dependent types would give you. Instead, the runtime throws an exception if an out-of-range number gets sent there. It's simply a matter of the compiler generating extra code to do these checks.

There is a separate Ada-related tool called SPARK that can let you statically guarantee that the value stays in range. The verification method doesn't involve dependent types and you'd use the tool somewhat differently, but the end result is similar.

[–] BatmanAoD@programming.dev 2 points 6 months ago (1 children)

For what it's worth, Ada and Spark are listed separately in the Wiki article on dependent typing. Again, though, I'm not a language expert.

[–] solrize@lemmy.world 1 points 6 months ago* (last edited 6 months ago)

I'll look at the wiki article again but I can pretty much promise that Ada doesn't have dependent types. They are very much a bleeding edge language feature (Haskell will get them soon, so I will try using them then) and Ada is quite an old fashioned language, derived from Pascal. SPARK is basically an extra-safe subset of Ada with various features disabled, that is also designed to work with some verification tools to prove properties of programs. My understanding is that the proof methods don't involve dependent types, but maybe in some sense they do.

Dependent types require the type system to literally be Turing-complete, so you can have a type like "prime number" and prove number-theoretic properties of functions that operate on them. Apparently that is unintentionally possible to do with C++ template metaprogramming, so C++ is listed in the article, but actually trying to use C++ that way is totally insane and impractical.

I remember looking at the wiki article on dependent types a few years ago and finding it pretty bad. I've been wanting to read "The Little Typer" (thelittletyper.com) which is supposed to be a good intro. I've also played with Agda a little bit, but not used it for real.

[–] lysdexic@programming.dev 2 points 6 months ago

It’s very hard for “Safe C++” to exist when integer overflow is UB.

You could simply state you did not read the article and decided to comment out of ignorance.

If you spent one minute skimming through the article, you would have stumbled upon the section on undefined behavior. Instead, you opted to post ignorant drivel.

[–] hector@sh.itjust.works 10 points 6 months ago (2 children)

This is cool in theory but this is yet another competing standard of static analysis.

We got clang-tidy, CPPAnalyser, etc… etc…

[–] mox@lemmy.sdf.org 8 points 6 months ago* (last edited 6 months ago) (1 children)

this is yet another competing standard of static analysis.

No, it isn't.

Those are linters. They might or might not discover problematic use of unsafe language features lurking in existing code.

This proposal is a new iteration of the language and standard library. It would provide safe language features for preventing such problems existing in the first place.

[–] thesmokingman@programming.dev 8 points 6 months ago* (last edited 6 months ago) (1 children)

Right now, we have to compile the compiler for this ourselves. Pardon my skepticism; I’m not sure this is mature enough.

Edit: I’m talking about the project not the idea. Sean Baxter has shown up everywhere for awhile talking about this. I think his idea has a ton of maturity. I don’t know that the project itself has enough maturity to mainline yet.

[–] mox@lemmy.sdf.org 9 points 6 months ago (1 children)

That's fair. I think the last word in the URL does a good job of representing the implementation's claimed level of maturity:

draft

:)

[–] thesmokingman@programming.dev 6 points 6 months ago (2 children)

You said

This proposal is a new iteration of the language and standard library. It would provide safe language features for preventing such problems existing in the first place.

Either it’s a draft or it’s a new iteration of the language. Can’t be both.

[–] mox@lemmy.sdf.org 12 points 6 months ago* (last edited 6 months ago) (1 children)

Either it’s a draft or it’s a new iteration of the language. Can’t be both.

It's a draft of a proposal for a new iteration. Is that so difficult to understand?

[–] thesmokingman@programming.dev 7 points 6 months ago (2 children)

Annnnnnnnnnnnd we’re done. Good luck! I highly recommend you take some time to understand how draft can mean more in the technical space. It might help you in the future when you are discussing things like drafts, specifications, and proposals.

[–] FizzyOrange@programming.dev 9 points 6 months ago

He never said it was an Internet Draft. Try actually reading. It might help you in the future when you are discussing things.

[–] mox@lemmy.sdf.org 9 points 6 months ago

https://en.wikipedia.org/wiki/Internet_Draft

I think it's pretty clear that IETF drafts are not what author meant when he wrote draft, and I'm pretty sure the IETF doesn't have much to do with C++ standards.

Are you under the impression that there is no other sense of the word?

It might help you in the future when you are discussing things like drafts, specifications, and proposals.

As it turns out, I have done more than a little of that. Thankfully, I don't usually see such condescending remarks in the process, nor such insistence on misunderstanding. Good luck to you, too.

[–] 4am@lemm.ee 2 points 6 months ago (1 children)

This is “It’s just a THEORY” but for programmers

[–] magic_lobster_party@fedia.io 4 points 6 months ago

It’s a concept of a plan

[–] iAvicenna@lemmy.world 6 points 6 months ago* (last edited 6 months ago) (1 children)

I am also curious how much of those "%70 of the vulnerabilities" would be detected by tools like valgrind, CPPcheck etc (either directly in the former case or indirectly in the latter). If a major part, then the main problem is people not incentivized to / not having enough time to use these tools.

[–] hector@sh.itjust.works 2 points 6 months ago* (last edited 6 months ago)

Valgrind is pretty crazy to find bugs and memory leaks !

[–] thesmokingman@programming.dev 1 points 6 months ago

Where does the document number come from? I can’t find anything about the SG or linked orgs that defines a sequence.

[–] pelya@lemmy.world 1 points 6 months ago

Extend C++ for safety

I stopped reading after this. Why do you think C++ is unsafe in the first place? Someone decided ro extend it, and now you cannot even read an error message without finishing an university course on lambda calculus first.