

A small C hack - private members in C structures - prez
http://jacquesmattheij.com/A+small+C+hack

======
rcfox
I'm sorry, but ew, no, gross! This is a terrible suggestion for several
reasons:

1\. It will only work for the last elements of the struct. If the struct is
extended to have more elements later, elements that are added after the ifdef
block will appear in the same memory location as those inside. Boom!

If you notice this and add to the middle of the struct, anything that depends
on specific ordering of the data (packets, files?) will break. (Note: In some
cases, extending these kinds of structs with more elements at the end of the
struct is acceptable. However, see the paragraph above.)

2\. You're not fooling anyone. Any code that uses this struct will need to
include your header. They will be able to see that there is a conditional part
of the struct, and will be able to define the appropriate macro to have
everything included. (In my opinion, headers are a sort of implicit
documentation. If you want to know what you can do with some bit of code, look
at the header that is included.)

3\. We already have an idiom for solving this sort of problem, called the
opaque structure.

~~~
prez
Well, you're right, I just thought it was an interesting usage.

I don't think I would ever use it in code or suggest it to anyone.

------
smh
This sort of thing will likely cause more problems than it solves. Such a
struct can't be moved, copied, or put in an array without potential memory
corruption.

I'd suggest doing this:

    
    
      typedef struct {
        int a;
        int b;
        /* private */
        int c;
        int d;
      } STYPE;
    

Sure, other programmers are free to ignore the comment and use the private
fields anyway, but that suggests a bigger problem that can't be fixed with a
clever pre-processor hack.

