Subj : Re: US White House urges devs to dump C and C++
To   : Nightfox
From : tenser
Date : Sat Mar 02 2024 02:30 am

On 29 Feb 2024 at 07:27p, Nightfox pondered and said...
 
 Ni>   Re: US White House urges devs to dump C and C++
 Ni>   By: Digital Man to Nightfox on Thu Feb 29 2024 01:43 pm
 Ni> 
 Ni>  DM> There is no single programming language that is the best tool for
 Ni>  DM> everything. For systems programming (OS kernels, device drivers,
 Ni>  DM> firmware), C and C++ are still tools of primary choice (though Rust i
 Ni>  DM> making some inroads here). But if I were to develop just about anythi
 Ni>  DM> else that lives, privacy/security, or business operations depended up
 Ni>  DM> I'd use a managed language/environment.
 Ni> 
 Ni> I suppose it would make sense to use a managed language/environment.
 Ni> In some of the newer C++ standards, they've introduced some classes that
 Ni> are meant to help manage memory better for you though, suchas shared_ptr,
 Ni> unique_ptr, etc..  I've heard people say you can avoid using new &
 Ni> delete (or malloc() and free()) and use those managed pointers instead. 
 Ni> I think another issue can be buffer overruns though, and I don't recall
 Ni> offhand if a managed language normally protects against that.  In a
 Ni> quick Google search, I found a page where someone said buffer overflow
 Ni> exploits are possible in C#, though it's harder to produce them in C#.

The problem with the new facilities in C++ is that they
don't address the underlying problem, and they don't
automatically retrofit themselves onto the many billions
of lines of existing code.  The sharp edges are still
there in the language, and a programmer has to proactively
go out of the way to avoid them.

The situation with most managed/memory-safe languages is
sort of the opposite.  They're safe by default, but usually
have some escape hatch where you can do things that are
unsafe.  But you have to go out of your way to do those
things.

Bjarne Stroustrup gave a talk recently about making C++
more safe and the gist of it that I took away was that he
wants to address much of the safety concerns by teaching
programmers to write C++ differently (e.g., teach them to
use the newer idioms, `unique_ptr`, etc).  That could
certainly help, but again, history has shown us that this
doesn't scale particularly well, and in languages like C
and C++ where "undefined behavior" is both endemic and
gives compiler writers lots of leeway to mangle code in
unexpected ways (and UB in C can time travel up until C23!),
code that appears to work for _years_ can suddenly stop
doing so when you update a point revision of your compiler.
It's madness.

--- Mystic BBS v1.12 A48 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.