▲ 731 ▼ Supreme leader mad (sh.itjust.works) submitted 2 years ago by 0x4E4F@sh.itjust.works to c/linuxmemes@lemmy.world 101 comments fedilink hide all child comments
[–] 5C5C5C@programming.dev 11 points 2 years ago (1 child) He absolutely has not. permalink fedilink source parent hideshow 2 child comments replies: [–] ozymandias117@lemmy.world 4 points 2 years ago* (1 child) 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/20240110175755.GC1006537@mit.edu/ permalink fedilink source parent hideshow 2 child comments replies: [–] BartyDeCanter@lemmy.sdf.org 12 points 2 years 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. permalink fedilink source parent hideshow 4 child comments replies: [–] ozymandias117@lemmy.world 10 points 2 years 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 permalink fedilink source parent hideshow 4 child comments replies: [–] BartyDeCanter@lemmy.sdf.org 5 points 2 years 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. permalink fedilink source parent [–] Canuck@sh.itjust.works 1 point 2 years ago permalink fedilink source parent [–] Aatube@kbin.melroy.org 1 point 2 years ago time to go pedantic and use parts of the c++stdlib that weren't included in the stl! permalink fedilink source parent
[–] ozymandias117@lemmy.world 4 points 2 years ago* (1 child) 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/20240110175755.GC1006537@mit.edu/ permalink fedilink source parent hideshow 2 child comments replies: [–] BartyDeCanter@lemmy.sdf.org 12 points 2 years 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. permalink fedilink source parent hideshow 4 child comments replies: [–] ozymandias117@lemmy.world 10 points 2 years 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 permalink fedilink source parent hideshow 4 child comments replies: [–] BartyDeCanter@lemmy.sdf.org 5 points 2 years 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. permalink fedilink source parent [–] Canuck@sh.itjust.works 1 point 2 years ago permalink fedilink source parent [–] Aatube@kbin.melroy.org 1 point 2 years ago time to go pedantic and use parts of the c++stdlib that weren't included in the stl! permalink fedilink source parent
[–] BartyDeCanter@lemmy.sdf.org 12 points 2 years 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. permalink fedilink source parent hideshow 4 child comments replies: [–] ozymandias117@lemmy.world 10 points 2 years 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 permalink fedilink source parent hideshow 4 child comments replies: [–] BartyDeCanter@lemmy.sdf.org 5 points 2 years 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. permalink fedilink source parent [–] Canuck@sh.itjust.works 1 point 2 years ago permalink fedilink source parent [–] Aatube@kbin.melroy.org 1 point 2 years ago time to go pedantic and use parts of the c++stdlib that weren't included in the stl! permalink fedilink source parent
[–] ozymandias117@lemmy.world 10 points 2 years 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 permalink fedilink source parent hideshow 4 child comments replies: [–] BartyDeCanter@lemmy.sdf.org 5 points 2 years 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. permalink fedilink source parent [–] Canuck@sh.itjust.works 1 point 2 years ago permalink fedilink source parent
[–] BartyDeCanter@lemmy.sdf.org 5 points 2 years 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. permalink fedilink source parent
[–] Aatube@kbin.melroy.org 1 point 2 years ago time to go pedantic and use parts of the c++stdlib that weren't included in the stl! permalink fedilink source parent