Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
> >> [ lightbulb ] ... although we could improve that quite a bit if we
> >> processed each .h file separately instead of insisting on smashing
> >> everything into one compilation. Le
I believe that Dave Page wants to move to building pg for windows
using visual C++ 2010 some time this year. That alone may be enough of
a reason to check for C++0x keywords in headers:
http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx
I think th
Alvaro Herrera writes:
> Excerpts from Peter Geoghegan's message of lun dic 27 16:13:33 -0300 2010:
>> constexpr
>> decltype
>> nullptr
>> static_assert
> I think only constexpr is being currently used from this list, and it's
> easily fixed because it's not exposed beyond a single file.
If you'
Excerpts from Peter Geoghegan's message of lun dic 27 16:13:33 -0300 2010:
> I hope that we don't make the mistake of not checking for collisions
> with C++0x keywords, for which GCC 4.3+ has partial support. The new
> standard is almost complete, so it will probably become a lot more
> relevant so
On 27 December 2010 19:17, Tom Lane wrote:
> [ shrug... ] If it's not a keyword according to popularly available
> tools, then I really have zero interest in worrying about it. This
> is an exercise in making the headers useful in practice, not in academic
> standards conformance.
It isn't acad
Peter Geoghegan writes:
> I hope that we don't make the mistake of not checking for collisions
> with C++0x keywords, for which GCC 4.3+ has partial support. The new
> standard is almost complete, so it will probably become a lot more
> relevant soon. There are quite a few new keywords in C++0x, i
I hope that we don't make the mistake of not checking for collisions
with C++0x keywords, for which GCC 4.3+ has partial support. The new
standard is almost complete, so it will probably become a lot more
relevant soon. There are quite a few new keywords in C++0x, including:
constexpr
decltype
nul
BTW, the cpluspluscheck script invokes g++ with -fno-operator-names,
saying
# -fno-operator-names omits the definition of bitand and bitor, which
# collide with varbit.h. Could be fixed, if one were so inclined.
I just confirmed that those two function definitions are the only is
Magnus Hagander writes:
> On Mon, Dec 27, 2010 at 18:50, Tom Lane wrote:
>> src/tools/pginclude/ already contains several scripts for this sort of
>> thing. Bruce runs them by hand occasionally, although I just found out
>> that he's evidently not run the does-each-header-compile-standalone
>> t
On Mon, Dec 27, 2010 at 18:50, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
>>> [ lightbulb ] ... although we could improve that quite a bit if we
>>> processed each .h file separately instead of insisting on smashing
>>> everythi
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
>> [ lightbulb ] ... although we could improve that quite a bit if we
>> processed each .h file separately instead of insisting on smashing
>> everything into one compilation. Let me go try that.
> FWIW
On mån, 2010-12-27 at 12:33 -0500, Andrew Dunstan wrote:
> On a more general point, it would be useful to have some
> infrastructure for running quality checks like this and publishing the
> results. We should be way beyond the point where we rely on
> individuals doing this sort of stuff.
I had a
On Mon, Dec 27, 2010 at 12:33:00PM -0500, Andrew Dunstan wrote:
> On 12/27/2010 11:54 AM, Tom Lane wrote:
> >After a bit of experimentation, I can say that this is better than
> >Andrew's hack, but it's still a good distance shy of something that
> >should be automated or treated as a hard requirem
On 12/27/2010 11:54 AM, Tom Lane wrote:
After a bit of experimentation, I can say that this is better than
Andrew's hack, but it's still a good distance shy of something that
should be automated or treated as a hard requirement.
I'm always happy if someone produces something better than I did
Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
> [ lightbulb ] ... although we could improve that quite a bit if we
> processed each .h file separately instead of insisting on smashing
> everything into one compilation. Let me go try that.
FWIW I have this patch lingering ab
Peter Eisentraut writes:
> src/tools/pginclude/cpluspluscheck
Ah, I'd forgotten that.
> What's missing is to automate this, but it's unclear in what context,
> and perhaps also to what extend this should be a hard requirement.
After a bit of experimentation, I can say that this is better than
A
Excerpts from Peter Eisentraut's message of lun dic 27 12:54:16 -0300 2010:
> On sön, 2010-12-26 at 12:31 -0500, Tom Lane wrote:
> > We did clean up C++ keyword uses in the header files in 9.0, but your
> > report shows it's already gotten broken again. I'm disinclined to fix
> > it unless someone
On sön, 2010-12-26 at 12:31 -0500, Tom Lane wrote:
> We did clean up C++ keyword uses in the header files in 9.0, but your
> report shows it's already gotten broken again. I'm disinclined to fix
> it unless someone steps up to create an automated test that will get
> run reasonably often. We had
On 12/26/2010 12:31 PM, Tom Lane wrote:
In any case, I think it's very likely the issue is a C/C++
incompatibility in the Pg headers. It fails for me in a different place
using Pg 9.1git and g++ 4.5, complaining about the use of "private" as
an identifier in fmgr.h, because it's a keyword in
Craig Ringer writes:
> On 12/26/2010 02:14 PM, Elliot Chance wrote:
>> /usr/include/pgsql/server/nodes/primnodes.h:1155: error: expected
>> unqualified-id before using
> You've neglected to mention which version of Pg you're compiling
> against, so that line number means nothing. What's the o
20 matches
Mail list logo
