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

Groups > comp.lang.c > #142883

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

Show key headers only | View raw

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> 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.  [...]

Yes, that's pretty much where I am, except that I'm willing to
tolerate pointed-to types are "logically incomplete" and only
"almost always" treated as opaque.

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