| From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
|---|---|
| To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ArchiveEntry optional arguments refactoring |
| Date: | 2019-01-23 17:05:10 |
| Message-ID: | 4a4d10a2-bffc-ed13-65a4-5fe762175eea@anastigmatix.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/23/19 10:12 AM, Dmitry Dolgov wrote:
> To make this discussion a bit more specific, I've created a patch of how
> it can look like.
A little bit of vararg-macro action can make such a design look
even tidier, cf. [1].
Or are compilers without vararg macros still in the supported mix?
-Chap
[1] https://github.com/NetBSD/src/blob/trunk/sys/sys/midiio.h#L709
The macros in [1] are not defined to create a function call, but only
the argument structure because there might be several functions to pass
it to, so a call would be written like func(&SEQ_MK_CHN(NOTEON, ...)).
In ArchiveEntry's case, if there's only one function involved, there'd
be no reason not to have a macro produce the whole call.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-01-23 17:05:43 | Re: ArchiveEntry optional arguments refactoring |
| Previous Message | Alvaro Herrera | 2019-01-23 16:58:07 | Re: ArchiveEntry optional arguments refactoring |