this post was submitted on 13 Apr 2024
730 points (95.9% liked)

linuxmemes

20880 readers
7 users here now

I use Arch btw

Sister communities:

Community rules

  1. Follow the site-wide rules and code of conduct
  2. Be civil
  3. Post Linux-related content
  4. No recent reposts

Please report posts and comments that break these rules!

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
730
Supreme leader mad (sh.itjust.works)
submitted 7 months ago by [email protected] to c/[email protected]
101 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 5C5C5C 11 points 7 months ago (1 children)

He absolutely has not.

[–] [email protected] 4 points 7 months ago* (last edited 7 months ago) (1 children)

That’s my guess, but there was a conversation on the mailing list a few months ago that wasn’t just immediately shut down, even by other prolific developers

Ts’o seems skeptical, but is at least asking whether c++ has improved

https://lore.kernel.org/lkml/[email protected]/

[–] [email protected] 12 points 7 months ago* (last edited 7 months ago) (2 children)

Take a look at what even the proposer is saying wouldn't be allowed in:

 (1) new and delete.  There's no way to pass GFP_* flags in.

 (2) Constructors and destructors.  Nests of implicit code makes the code less
     obvious, and the replacement of static initialisation with constructor
     calls would make the code size larger.

 (3) Exceptions and RTTI.  RTTI would bulk the kernel up too much and
     exception handling is limited without it, and since destructors are not
     allowed, you still have to manually clean up after an error.

 (4) Operator overloading (except in special cases).

 (5) Function overloading (except in special inline cases).

 (6) STL (though some type trait bits are needed to replace __builtins that
     don't exist in g++).

 (7) 'class', 'private', 'namespace'.

 (8) 'virtual'.  Don't want virtual base classes, though virtual function
     tables might make operations tables more efficient.

C++ without class, constructors, destructors, most overloading and the STL? Wow.

[–] [email protected] 10 points 7 months ago (2 children)

That doesn’t really surprise me, as most of those are the same requirements from any embedded development use case using c++ that I’ve worked on

4 and 5 are the only ones stricter than I’m used to

[–] [email protected] 5 points 7 months ago

I've only worked on a few embedded systems where C++ was even an option, but they allowed 2, 4, 5, and 7. Though, for the most part most classes were simple interfaces to some sort of SPI/I2C/CAN/EtherCAT device, most of which were singletons.

[–] [email protected] 1 points 7 months ago

time to go pedantic and use parts of the c++stdlib that weren't included in the stl!