Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #142725

Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.c
Subject Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness
Date 2019-04-02 10:25 +0200
Organization A noiseless patient Spider
Message-ID <q7v697$u4p$1@dont-email.me> (permalink)
References <vriumul9to0v.fsf@gmail.com> <87ef6l72u5.fsf@bsb.me.uk> <f73c6d0a-cd2c-4053-a65d-774ceda8c0eb@googlegroups.com>

Show all headers | View raw


On 02/04/2019 09:31, luser droog wrote:
> On Monday, April 1, 2019 at 5:55:40 PM UTC-5, Ben Bacarisse wrote:
>>>
>>> typedef union object *object;
>>
>> I'm not a fan of hiding a pointer like this.  It tripped me up for a
>> while.  For the price of a space and a * you lose the ability to remind
>> the reader that it's pointers all the way down.  However, I'm used to
>> this construct, so I got over my initial stumble pretty quickly.  It's a
>> small point.
> 
> Point taken. I keep on doing this. And it keeps creating (some) difficulty 
> for others. I really want to abstract away from the pointerness. Would it
> help to make it "louder"? sthg like:
> 
> #define HIDDEN_POINTER_TO *
> typedef  union object  HIDDEN_POINTER_TO object;
> 
> 

A very simple solution is to give the typedef name something that
indicates it is a pointer:

	typedef union object * pObject;

It is quite common to see types that are pointers start with a "p", or
function pointer types that start with an "f".  Some people also use "s"
for structs, and "u" for unions.  I am not a fan of going overboard with
this sort of thing - you end up with "Systems Hungarian notation" (using
Wikipedia's term here), which is ugly, unhelpful, and scales extremely
badly.  But I often have a "p" on pointer types.

Obviously you can also have suffixes - "object_ptr", or whatever you
like here.  But if it is clear to the reader that this is a pointer
type, it should be fine.

The one thing I would /never/ do, however, is use a typedef of a "union
X" or "struct X" to a /pointer/ to an X.  "typedef union X X;" is fine,
IMHO, as is "typedef struct Y Y;".  I personally prefer to do that, then
use X or Y directly (maybe it is C++ influence creeping in) - other
people specifically dislike it.  It is your choice there.  But if you
have a struct or union tag X, and a typedef X, then I strongly recommend
that these represent exactly the same type.

Whether you fix that by changing the name of the underlying union type,
or by changing the name of the typedef, will depend on how you want to
use them later in the code.  If the union part is to be considered a
hidden internal structure, and everything in user code should use the
pointer type, then maybe you want:

	typedef union object_internal * object;

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[PC] Simulating Monads, Lambdas, Closures, and Laziness M Joshua Ryan <luser.droog@gmail.com> - 2019-04-01 16:26 -0500
  Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Chad <cdalten@gmail.com> - 2019-04-01 14:42 -0700
    Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness luser droog <luser.droog@gmail.com> - 2019-04-01 14:57 -0700
  Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-01 23:55 +0100
    Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness luser droog <luser.droog@gmail.com> - 2019-04-02 00:31 -0700
      Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness David Brown <david.brown@hesbynett.no> - 2019-04-02 10:25 +0200
        Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Manfred <noname@add.invalid> - 2019-04-02 14:11 +0200
          Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness David Brown <david.brown@hesbynett.no> - 2019-04-02 15:51 +0200
      Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-02 12:10 +0100
      Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness luser droog <luser.droog@gmail.com> - 2019-04-02 12:07 -0700
    Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-03 07:59 -0700
      Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-03 16:29 +0100
        Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-07 00:11 -0700
          Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness luser droog <luser.droog@gmail.com> - 2019-04-12 23:20 -0700
            Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Chad <cdalten@gmail.com> - 2019-04-13 04:42 -0700

csiph-web