• @BartyDeCanter@lemmy.sdf.org
    link
    fedilink
    12
    edit-2
    9 months ago

    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.

    • @ozymandias117@lemmy.world
      link
      fedilink
      English
      109 months ago

      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

      • @BartyDeCanter@lemmy.sdf.org
        link
        fedilink
        59 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.

    • Aatube
      link
      fedilink
      19 months ago

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