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


Groups > comp.lang.c > #142783

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

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness
Date 2019-04-03 16:29 +0100
Organization A noiseless patient Spider
Message-ID <87k1gbjedy.fsf@bsb.me.uk> (permalink)
References <vriumul9to0v.fsf@gmail.com> <87ef6l72u5.fsf@bsb.me.uk> <86h8bfm8x2.fsf@mailhub.linuxsc.com>

Show all headers | View raw


Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> [trimming without any further indication]
>
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> M Joshua Ryan <luser.droog@gmail.com> writes:
>>
>>> 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 its pointers all the way down.
>
> I have a different view.  When the primary type of an interface
> is a pointer type and not the pointed-to type, it's better for
> the interface to define a typedef name that includes the *, and
> use that name in declaring the various interface functions, both
> for parameters and return values.  Client code normally uses the
> pointer type, not the pointed-to type;  following the principle
> of information hiding, the pointerness is better held inside the
> typedef name than forcing client code to be reminded at every
> turn of more information than is needed.

I must say I've flip-flopped on this point over the years so I should
describe my statement as where am I now rather than it being some fixed
view.

I agree with you in one case that I forgot to mention.  Where there is a
very clean separation between client code and implementation, and the
client API uses a pointer to an incomplete type (the old "opaque" data),
I will usually make the interface type include the pointer.  On the
other side, I probably wouldn't even use the typedef.

<cut>
-- 
Ben.

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