Re: [HACKERS] static assertions in C++ - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] static assertions in C++
Date
Msg-id 27655.1513028751@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] static assertions in C++  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] static assertions in C++  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: REPLICA IDENTITY FULL
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] static assertions in C++