[HN Gopher] Modern C for C++ Peeps (2019)
       ___________________________________________________________________
        
       Modern C for C++ Peeps (2019)
        
       Author : signa11
       Score  : 80 points
       Date   : 2021-05-26 09:19 UTC (13 hours ago)
        
 (HTM) web link (floooh.github.io)
 (TXT) w3m dump (floooh.github.io)
        
       | bluetomcat wrote:
       | > Wrap your structs in a typedef
       | 
       | I tend to disagree. Unless you are providing an API for third-
       | party use and want to make your data types opaque to callers, do
       | not ever use typedef with structs and pointers. A declaration
       | like "struct foo *f" tells you two things - f itself is a
       | pointer, and the pointed-to value is not a scalar (i.e. has named
       | members). The "_t" suffix idiom is predominantly used by the
       | standard library for integral scalars with certain properties and
       | semantics, e.g. pid_t, uid_t, gid_t, time_t.
        
         | jimbob45 wrote:
         | Agreed. If you typedef your struct, I can't know if you wrapped
         | it in a weird macro or if your data type is actually a renamed
         | primitive. Once I gain familiarity with your codebase, it won't
         | matter, but it otherwise unnecessarily raises the barrier of
         | entry.
         | 
         | That said, typedefs/macros may be essential for portability
         | concerns.
        
           | Gibbon1 wrote:
           | > can't know if you wrapped it in a weird macro
           | 
           | The solution to that problem is don't do that.
        
         | ynfnehf wrote:
         | The _t suffix is also reserved by posix. (And by the C standard
         | if the name starts with int or unit.)
         | 
         | I agree with just using struct foo, as does the Linux style
         | guide.
         | 
         | (Edit: I just noticed the page mentions this, but it is perhaps
         | useful to reiterate.)
        
           | mlex wrote:
           | Somewhat related; I feel like C reserves a lot of names that
           | though different standards, is there a good list of all of
           | those so I know to avoid them? (e.g. underscore prefixes)
        
             | zabzonk wrote:
             | This part of the GCC docs covers all of them, AFAIK:
             | 
             | https://www.gnu.org/software/libc/manual/html_node/Reserved
             | -...
        
         | IanGabes wrote:
         | Huh. This is interesting, I can empathize with both sides of
         | the argument. Are C text editors not able to take care of
         | syntax highlighting the differences between a typedef'd scalar
         | and a typedef'd struct? Colouring the type one way or another I
         | figure would be sufficient.
        
         | visualradio wrote:
         | If programmers do want to wrap structs in a typedef without
         | using the "_t" suffix, the Vulkan API appears to have settled
         | on upper-camel case:                   typedef struct
         | VkMemoryBarrier {             VkStructureType    sType;
         | const void*        pNext;             VkAccessFlags
         | srcAccessMask;             VkAccessFlags      dstAccessMask;
         | } VkMemoryBarrier;
        
       | klaussilveira wrote:
       | Somewhat relevant: https://250bpm.com/blog:4/
        
       | rwmj wrote:
       | "Modern C" now effectively includes __attribute__((cleanup)), in
       | as much as it's widely used by large free software projects and
       | supported in both GCC and Clang.
        
         | teddyh wrote:
         | Documentation:
         | 
         | "cleanup ( _cleanup_function_ )
         | 
         | The cleanup attribute runs a function when the variable goes
         | out of scope. This attribute can only be applied to auto
         | function scope variables; it may not be applied to parameters
         | or variables with static storage duration. The function must
         | take one parameter, a pointer to a type compatible with the
         | variable. The return value of the function (if any) is ignored.
         | 
         | If -fexceptions is enabled, then _cleanup_function_ is run
         | during the stack unwinding that happens during the processing
         | of the exception. Note that the cleanup attribute does not
         | allow the exception to be caught, only to perform an action. It
         | is undefined what happens if _cleanup_function does_ not return
         | normally."
         | 
         | -- https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Common-
         | Variabl...
        
         | mrpippy wrote:
         | Is it widely used? I've only come across it in GLib (g_auto*),
         | but even then it couldn't be used in GStreamer because they
         | also support building with MSVC.
        
           | fpoling wrote:
           | systemd code uses it widely.
        
         | WalterBright wrote:
         | This comes from the Scope Guard Statement in D, from an idea
         | originally proposed by Andrei Alexandrescu and Petru Marginean.
         | 
         | https://dlang.org/spec/statement.html#ScopeGuardStatement
        
       | bierjunge wrote:
       | Nice intro, but it's very vague and not nearly a complete
       | overview.
       | 
       | There is a good book written by Jens Gustedt [0] which is a great
       | guide for C with all the new stuff. The book itself is CC
       | licensed and code examples are MIT licensed. Jens is one of the
       | good guys.
       | 
       | [0] https://modernc.gforge.inria.fr/
        
       ___________________________________________________________________
       (page generated 2021-05-26 23:02 UTC)