Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #142783
| 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> |
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
[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