From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] static assertions in C++ |
Date: | 2017-12-11 21:45:51 |
Message-ID: | 27655.1513028751@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 11/29/17 10:03, Tom Lane wrote:
>> Right now, we have the property that every build enforces static
>> assertions, albeit with variable quality of the error messages.
>> I strongly disagree that it's okay to throw that property away.
>> I do think that we could put an #error here instead, and wait to see
>> if anyone complains before expending effort on a workaround.
> I guess the question is whether we would rather be able to have users
> continue to use older C++ compilers, or be super picky about static
> assertions.
Uh, what is this "continue to use" bit? We've never supported
building the backend with C++ compilers. Nor, since the whole
point here is that StaticAssert doesn't work with C++, is there
any existing tradition of building extensions that use StaticAssert
with C++. So I think it's highly likely that if we put in
an #error there, there will be exactly zero complaints.
I'd much rather continue to be sure that StaticAssert does what it
says on the tin than retroactively improve the compatibility situation
for older compilers.
(BTW, why is it that we can't fall back on the negative-width-bitfield
trick for old g++?)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-12-11 21:56:46 | Re: [HACKERS] static assertions in C++ |
Previous Message | Peter Eisentraut | 2017-12-11 21:40:07 | Re: REPLICA IDENTITY FULL |