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

linuxmemes

21393 readers
1367 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
  •  

    Please report posts and comments that break these rules!


    Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.

    founded 1 year ago
    MODERATORS
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] [email protected] 25 points 7 months ago (2 children)

    For an example from the other poster’s explanation:

    https://lwn.net/Articles/249460/

    This was pre c++11 - not sure if he’s changed his mind at all with more modern c++

    [–] [email protected] 3 points 7 months ago (1 children)

    I don't think its the ergonomics of the language he has an issue with. If anything C++1x probably just made the original critiques of bloat worse.

    [–] [email protected] 13 points 7 months ago (1 children)

    In that post, his critiques were around the problems with the STL and everyone using Boost. The STL has improved significantly since then, and it would be a limited subset of c++ if it was ever allowed

    There have been mailing list conversations earlier this year, citing that clang/gcc now allowing c++ in their own code might mean they’ve taken care of the issues that made it unusable for kernel code

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

    I’m not saying it will happen, but it’s not being shot down as an absolute insanity anymore, and I wouldn’t have expected Rust to be allowed in the kernel, either

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

    Oh interesting. I didn't realize boost was the main issue. Most people I've talked to were complaining about VTables introducing a bunch of indirection and people blindly using associative containers.

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

    Vtable equivalents are used extensively in the kernel

    You’ll find structs all over the place setting them up, e.g. every driver sets up a .probe function that the core will call, since it doesn’t know what driver it’s loading

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

    Right the issue was more because they're so easy to throw in without thinking about it so people overuse them. That may just be older devs complaining about newbies though.

    [–] [email protected] 11 points 7 months ago (1 children)
    [–] [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] 1 points 7 months ago

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

    [–] [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.