Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #147593 > unrolled thread
| Started by | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| First post | 2019-11-04 22:55 -0800 |
| Last post | 2019-11-09 23:22 -0800 |
| Articles | 5 on this page of 65 — 12 participants |
Back to article view | Back to comp.lang.c
Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-04 22:55 -0800
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 08:12 +0100
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 03:52 -0800
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 13:12 +0100
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 04:24 -0800
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 13:33 +0100
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 04:57 -0800
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 14:08 +0100
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 05:21 -0800
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 14:27 +0100
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 05:42 -0800
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 14:51 +0100
Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-05 14:49 +0000
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 15:53 +0100
Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-05 15:59 +0000
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 17:11 +0100
Re: Is this kosher wrt Generic? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 09:19 -0800
Re: Is this kosher wrt Generic? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 07:00 -0800
Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-05 16:30 +0100
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 15:31 +0100
Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-11-06 10:34 +1300
Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-05 22:16 +0000
Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-11-06 11:34 +1300
Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-05 23:12 +0000
Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-11-06 12:29 +1300
Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-06 10:17 +0100
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 10:56 +0100
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 10:02 +0100
Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-06 10:43 +0000
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 04:56 -0800
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 14:05 +0100
Re: Is this kosher wrt Generic? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 21:03 -0800
Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-11-10 08:45 +1300
Re: Is this kosher wrt Generic? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 16:35 -0800
Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-29 12:41 +0100
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-29 04:08 -0800
Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-29 13:01 +0000
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-29 06:43 -0800
Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-29 17:31 +0000
Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-29 14:31 +0100
Re: Is this kosher wrt Generic? Öö Tiib <ootiib@hot.ee> - 2019-11-30 13:16 -0800
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-12-02 03:31 -0800
Re: Is this kosher wrt Generic? Öö Tiib <ootiib@hot.ee> - 2019-12-02 23:30 -0800
Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-12-01 12:10 +1300
Re: Is this kosher wrt Generic? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 09:35 -0800
Re: Is this kosher wrt Generic? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-05 22:49 +0000
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 05:12 -0800
Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 14:20 +0100
Re: Is this kosher wrt Generic? guinness.tony@gmail.com - 2019-11-05 16:19 -0800
Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-06 00:06 -0800
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 03:19 -0800
Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-05 22:38 -0800
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 04:50 -0800
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 05:32 -0800
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 05:56 -0800
Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-06 14:26 +0000
Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 09:04 -0800
Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-06 22:45 +0100
Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-29 14:35 -0800
Re: Is this kosher wrt Generic? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-29 23:23 +0000
Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-29 19:08 -0800
Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-29 19:12 -0800
Re: Is this kosher wrt Generic? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-30 10:44 +0000
Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 23:21 -0800
Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 23:22 -0800
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-29 19:08 -0800 |
| Message-ID | <qrsmfb$18kc$1@gioia.aioe.org> |
| In reply to | #148305 |
On 11/29/2019 3:23 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> <cut>
>> struct object_prv_vtable {
>> int (*fp_destroy) (void* const);
>> };
>>
>>
>> struct device_prv_vtable {
>> int (*fp_read) (void* const, void*, size_t);
>> int (*fp_write) (void* const, void const*, size_t);
>> };
>
> Why so many different uses of const?
The (void* const) wrt the first parameter is meant to sort of act like
the this parameter in C++. It is a constant pointer to a void. The other
const wrt the second parameter in
device_prv_vtable::fp_write
means that this is a pointer to a const void, the buffer shall not be
altered wrt writing the device.
I do it out of a habit. The first parameter points to the self. It is a
constant pointer to the object such that self cannot be altered without
some sort of alarm wrt the compiler. self is frozen, like this.
>
> In a function prototype (where there is no function body), qualifying a
> parameter as const is just noise. The caller knows the function can't
> modify any object in the calling context using that parameter since
> that's just how call by value works.
>
> Qualifying a pointer /target/ is useful in all cases where it can be
> done. It tells the reader something useful about the function, and it
> allows the compiler to check it.
>
> <cut>
>
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-29 19:12 -0800 |
| Message-ID | <qrsmmd$19ju$1@gioia.aioe.org> |
| In reply to | #148305 |
On 11/29/2019 3:23 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> <cut>
>> struct object_prv_vtable {
>> int (*fp_destroy) (void* const);
>> };
>>
>>
>> struct device_prv_vtable {
>> int (*fp_read) (void* const, void*, size_t);
>> int (*fp_write) (void* const, void const*, size_t);
>> };
>
> Why so many different uses of const?
In a sense, I wanted to sort of define the API through its prototype.
The first parameter is self, is shall not be able to be changed. Reflect
this through saying that said parameter self is void* const. Its a
habit. The buffer being fed into the write shall not be altered,
therefore it is a void const*.
>
> In a function prototype (where there is no function body), qualifying a
> parameter as const is just noise. The caller knows the function can't
> modify any object in the calling context using that parameter since
> that's just how call by value works.
>
> Qualifying a pointer /target/ is useful in all cases where it can be
> done. It tells the reader something useful about the function, and it
> allows the compiler to check it.
>
> <cut>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-30 10:44 +0000 |
| Message-ID | <87blst3apg.fsf@bsb.me.uk> |
| In reply to | #148307 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 11/29/2019 3:23 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> <cut>
>>> struct object_prv_vtable {
>>> int (*fp_destroy) (void* const);
>>> };
>>>
>>>
>>> struct device_prv_vtable {
>>> int (*fp_read) (void* const, void*, size_t);
>>> int (*fp_write) (void* const, void const*, size_t);
>>> };
>>
>> Why so many different uses of const?
>
> In a sense, I wanted to sort of define the API through its
> prototype. The first parameter is self, is shall not be able to be
> changed. Reflect this through saying that said parameter self is void*
> const. Its a habit.
There's nothing wrong with it, it's just odd. A const qualified
parameter in a prototype conveys no technical information as the
parameter may or may not be const qualified in the definition. I was
just curious to know what you wanted to convey with it.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-09 23:21 -0800 |
| Message-ID | <qq8dpa$rig$2@gioia.aioe.org> |
| In reply to | #147668 |
On 11/6/2019 5:56 AM, Thiago Adams wrote: > On Wednesday, November 6, 2019 at 10:33:11 AM UTC-3, Thiago Adams wrote: >> Option 2: With restrict signature. >> In this case we need a declaration for the 'interface' for foo. >> for instance, one name/concept that I would like to use for any >> type is destroy. All function destroy have the same signature. >> >> So the generic interface for destroy could be: >> >> void destroy(auto); >> >> and the implementation. >> >> void x_destroy(struct X* p) : destroy; >> >> the implementation must follow the destroy contract. > ... > > > This feature with contract is similar of some C++ operator > overloading. > > Some operators in C++ have strict contracts. For instance, > the operator delete must be: > > void operator delete(void * p) > > if I change the return type for instance: > > void* operator delete(void * p) > error: ‘operator delete’ must return type ‘void’ > > > In my view, destroy, init, delete , new, swap, clone etc.. > are 'universal operators', just like + , - 0 and they could exist by > default in the C language using this feature of function tags. > > Not only this, but some algorithms are just a matter of > composition and destroy and init are samples of that. > In this case the language could generate these operators for > us by composition. > > If we think in terms of sqrt we don't want function overloading > with zero or more than one argument. > In this aspect _Generic has advantages over function overloading > where anything is possible. > > > Yes. This should be able to work. Also, you are making me think of x-macros. The Chaos lib... and such. :^) Thanks. Not convenient, but can work.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-09 23:22 -0800 |
| Message-ID | <qq8dr9$rig$3@gioia.aioe.org> |
| In reply to | #147668 |
On 11/6/2019 5:56 AM, Thiago Adams wrote: > On Wednesday, November 6, 2019 at 10:33:11 AM UTC-3, Thiago Adams wrote: >> Option 2: With restrict signature. >> In this case we need a declaration for the 'interface' for foo. >> for instance, one name/concept that I would like to use for any >> type is destroy. All function destroy have the same signature. >> >> So the generic interface for destroy could be: [...] > If we think in terms of sqrt we don't want function overloading > with zero or more than one argument. > In this aspect _Generic has advantages over function overloading > where anything is possible. > > > tgmath.h ...
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web