pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedC++ Headers
15+ messages / 7 participants
[nested] [flat]
* C++ Headers
@ 2001-05-19 14:21 mlw <markw@mohawksoft.com>
0 siblings, 2 replies; 15+ messages in thread
From: mlw @ 2001-05-19 14:21 UTC (permalink / raw)
To: pgsql-hackers
Is any support for reworking the postgres headers such that they can be used,
cleanly, in a C++ program?
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-19 15:25 Bruce Momjian <pgman@candle.pha.pa.us>
parent: mlw <markw@mohawksoft.com>
1 sibling, 0 replies; 15+ messages in thread
From: Bruce Momjian @ 2001-05-19 15:25 UTC (permalink / raw)
To: mlw <markw@mohawksoft.com>; +Cc: pgsql-hackers
My guess it that certain defines have to be #ifdef'ed out for C++. Can
you list them again. We have talked about this in the past, but haven't
gotten a solution yet.
> Is any support for reworking the postgres headers such that they can be used,
> cleanly, in a C++ program?
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-19 15:26 Tom Lane <tgl@sss.pgh.pa.us>
parent: mlw <markw@mohawksoft.com>
1 sibling, 2 replies; 15+ messages in thread
From: Tom Lane @ 2001-05-19 15:26 UTC (permalink / raw)
To: pgsql-hackers
mlw <markw@mohawksoft.com> writes:
> Is any support for reworking the postgres headers such that they can be used,
> cleanly, in a C++ program?
You'll get no support for a request for a blank check. What do you have
in mind exactly?
ISTM that making the backend's internal headers C++-clean has already
been looked into, but rejected on grounds that I don't recall clearly.
Check the list archives.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-19 16:04 Larry Rosenman <ler@lerctr.org>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 15+ messages in thread
From: Larry Rosenman @ 2001-05-19 16:04 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [010519 10:29]:
> mlw <markw@mohawksoft.com> writes:
> > Is any support for reworking the postgres headers such that they can be used,
> > cleanly, in a C++ program?
>
> You'll get no support for a request for a blank check. What do you have
> in mind exactly?
>
> ISTM that making the backend's internal headers C++-clean has already
> been looked into, but rejected on grounds that I don't recall clearly.
> Check the list archives.
I do know that you can use libpq-fe.h cleanly in a C++ program (the
table posted earlier today gets populated by a C++ app), modulo the
Oid type conflicts with an SNMP++ header, handled by a quick #define.
LER
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-19 17:09 Myron Scott <mscott@sacadia.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 15+ messages in thread
From: Myron Scott @ 2001-05-19 17:09 UTC (permalink / raw)
To: pgsql-hackers
Tom Lane wrote:
> mlw <markw@mohawksoft.com> writes:
> > Is any support for reworking the postgres headers such that they can be used,
> > cleanly, in a C++ program?
>
> You'll get no support for a request for a blank check. What do you have
> in mind exactly?
>
> ISTM that making the backend's internal headers C++-clean has already
> been looked into, but rejected on grounds that I don't recall clearly.
> Check the list archives.
>
I have used:
#ifdef __cplusplus
extern "C" {
#endif
headers......
#ifdef __cplusplus
}
#endif
on many backend header files for use
on my threaded version of postgres.
I seems to work fine as I have not had any problems
yet.
Myron Scott
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-19 17:17 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Myron Scott <mscott@sacadia.com>
0 siblings, 1 reply; 15+ messages in thread
From: Bruce Momjian @ 2001-05-19 17:17 UTC (permalink / raw)
To: mscott@sacadia.com; +Cc: pgsql-hackers
> Tom Lane wrote:
>
> > mlw <markw@mohawksoft.com> writes:
> > > Is any support for reworking the postgres headers such that they can be used,
> > > cleanly, in a C++ program?
> >
> > You'll get no support for a request for a blank check. What do you have
> > in mind exactly?
> >
> > ISTM that making the backend's internal headers C++-clean has already
> > been looked into, but rejected on grounds that I don't recall clearly.
> > Check the list archives.
> >
>
> I have used:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> headers......
>
>
>
> #ifdef __cplusplus
> }
> #endif
>
>
> on many backend header files for use
> on my threaded version of postgres.
> I seems to work fine as I have not had any problems
> yet.
The only mention I see of this is in c.h:
#ifndef __cplusplus
#ifndef bool
typedef char bool;
#endif /* ndef bool */
#endif /* not C++ */
If you need more cplusplus stuff, lets figure it out and add it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-20 00:34 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 15+ messages in thread
From: Tom Lane @ 2001-05-20 00:34 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The only mention I see of this is in c.h:
> #ifndef __cplusplus
> #ifndef bool
> typedef char bool;
> #endif /* ndef bool */
> #endif /* not C++ */
> If you need more cplusplus stuff, lets figure it out and add it.
Actually, that portion of c.h is a time bomb that is likely to blow up
in the face of some poor C++ user. There's no guarantee that a C++
compiler's built-in bool type will be compatible with "char", is there?
If it happened to be, say, same size as "int", then a C++ module
would interpret lots of things differently from a C module.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-21 09:01 Christof Petig <christof@petig-baender.de>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 15+ messages in thread
From: Christof Petig @ 2001-05-21 09:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > The only mention I see of this is in c.h:
>
> > #ifndef __cplusplus
> > #ifndef bool
> > typedef char bool;
>
> > #endif /* ndef bool */
> > #endif /* not C++ */
>
> > If you need more cplusplus stuff, lets figure it out and add it.
>
> Actually, that portion of c.h is a time bomb that is likely to blow up
> in the face of some poor C++ user. There's no guarantee that a C++
> compiler's built-in bool type will be compatible with "char", is there?
> If it happened to be, say, same size as "int", then a C++ module
> would interpret lots of things differently from a C module.
This in fact has happened within ECPG. But since sizeof(bool) is passed to
libecpg it was possible to figure out which 'bool' is requested.
Another issue of C++ compatibility would be cleaning up the usage of
'const' declarations. C++ is really strict about 'const'ness. But I don't
know whether postgres' internal headers would need such a cleanup. (I
suspect that in ecpg there is an oddity left with respect to host variable
declaration. I'll check that later)
Christof
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-22 04:19 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Christof Petig <christof@petig-baender.de>
0 siblings, 1 reply; 15+ messages in thread
From: Bruce Momjian @ 2001-05-22 04:19 UTC (permalink / raw)
To: Christof Petig <christof@petig-baender.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
> This in fact has happened within ECPG. But since sizeof(bool) is passed to
> libecpg it was possible to figure out which 'bool' is requested.
>
> Another issue of C++ compatibility would be cleaning up the usage of
> 'const' declarations. C++ is really strict about 'const'ness. But I don't
> know whether postgres' internal headers would need such a cleanup. (I
> suspect that in ecpg there is an oddity left with respect to host variable
> declaration. I'll check that later)
We have added more const-ness to libpq++ for 7.2.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-22 20:34 Nathan Myers <ncm@zembu.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 15+ messages in thread
From: ncm@zembu.com @ 2001-05-22 20:34 UTC (permalink / raw)
To: pgsql-hackers
On Tue, May 22, 2001 at 12:19:41AM -0400, Bruce Momjian wrote:
> > This in fact has happened within ECPG. But since sizeof(bool) is passed to
> > libecpg it was possible to figure out which 'bool' is requested.
> >
> > Another issue of C++ compatibility would be cleaning up the usage of
> > 'const' declarations. C++ is really strict about 'const'ness. But I don't
> > know whether postgres' internal headers would need such a cleanup. (I
> > suspect that in ecpg there is an oddity left with respect to host variable
> > declaration. I'll check that later)
>
> We have added more const-ness to libpq++ for 7.2.
Breaking link compatibility without bumping the major version number
on the library seems to me serious no-no.
To const-ify member functions without breaking link compatibility,
you have to add another, overloaded member that is const, and turn
the non-const function into a wrapper. For example:
void Foo::bar() { ... } // existing interface
becomes
void Foo::bar() { ((const Foo*)this)->bar(); }
void Foo::bar() const { ... }
Nathan Myers
ncm@zembu.com
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-22 21:52 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Nathan Myers <ncm@zembu.com>
0 siblings, 1 reply; 15+ messages in thread
From: Bruce Momjian @ 2001-05-22 21:52 UTC (permalink / raw)
To: pgsql-hackers
> On Tue, May 22, 2001 at 12:19:41AM -0400, Bruce Momjian wrote:
> > > This in fact has happened within ECPG. But since sizeof(bool) is passed to
> > > libecpg it was possible to figure out which 'bool' is requested.
> > >
> > > Another issue of C++ compatibility would be cleaning up the usage of
> > > 'const' declarations. C++ is really strict about 'const'ness. But I don't
> > > know whether postgres' internal headers would need such a cleanup. (I
> > > suspect that in ecpg there is an oddity left with respect to host variable
> > > declaration. I'll check that later)
> >
> > We have added more const-ness to libpq++ for 7.2.
>
> Breaking link compatibility without bumping the major version number
> on the library seems to me serious no-no.
>
> To const-ify member functions without breaking link compatibility,
> you have to add another, overloaded member that is const, and turn
> the non-const function into a wrapper. For example:
>
> void Foo::bar() { ... } // existing interface
>
> becomes
>
> void Foo::bar() { ((const Foo*)this)->bar(); }
> void Foo::bar() const { ... }
Thanks. That was my problem, not knowing when I break link compatiblity
in C++. Major updated.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-23 01:27 Nathan Myers <ncm@zembu.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 15+ messages in thread
From: ncm@zembu.com @ 2001-05-23 01:27 UTC (permalink / raw)
To: pgsql-hackers
On Tue, May 22, 2001 at 05:52:20PM -0400, Bruce Momjian wrote:
> > On Tue, May 22, 2001 at 12:19:41AM -0400, Bruce Momjian wrote:
> > > > This in fact has happened within ECPG. But since sizeof(bool) is
> > > > passed to libecpg it was possible to figure out which 'bool' is
> > > > requested.
> > > >
> > > > Another issue of C++ compatibility would be cleaning up the
> > > > usage of 'const' declarations. C++ is really strict about
> > > > 'const'ness. But I don't know whether postgres' internal headers
> > > > would need such a cleanup. (I suspect that in ecpg there is an
> > > > oddity left with respect to host variable declaration. I'll
> > > > check that later)
> > >
> > > We have added more const-ness to libpq++ for 7.2.
> >
> > Breaking link compatibility without bumping the major version number
> > on the library seems to me serious no-no.
> >
> > To const-ify member functions without breaking link compatibility,
> > you have to add another, overloaded member that is const, and turn
> > the non-const function into a wrapper. For example:
> >
> > void Foo::bar() { ... } // existing interface
> >
> > becomes
> >
> > void Foo::bar() { ((const Foo*)this)->bar(); }
> > void Foo::bar() const { ... }
>
> Thanks. That was my problem, not knowing when I break link compatiblity
> in C++. Major updated.
Wouldn't it be better to add the forwarding function and keep
the same major number? It's quite disruptive to change the
major number for what are really very minor changes. Otherwise
you accumulate lots of near-copies of almost-identical libraries
to be able to run old binaries.
A major-number bump should usually be something planned for
and scheduled.
Nathan Myers
ncm@zembu.com
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-23 15:35 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Nathan Myers <ncm@zembu.com>
0 siblings, 0 replies; 15+ messages in thread
From: Bruce Momjian @ 2001-05-23 15:35 UTC (permalink / raw)
To: pgsql-hackers
> > > > We have added more const-ness to libpq++ for 7.2.
> > >
> > > Breaking link compatibility without bumping the major version number
> > > on the library seems to me serious no-no.
> > >
> > > To const-ify member functions without breaking link compatibility,
> > > you have to add another, overloaded member that is const, and turn
> > > the non-const function into a wrapper. For example:
> > >
> > > void Foo::bar() { ... } // existing interface
> > >
> > > becomes
> > >
> > > void Foo::bar() { ((const Foo*)this)->bar(); }
> > > void Foo::bar() const { ... }
> >
> > Thanks. That was my problem, not knowing when I break link compatiblity
> > in C++. Major updated.
>
> Wouldn't it be better to add the forwarding function and keep
> the same major number? It's quite disruptive to change the
> major number for what are really very minor changes. Otherwise
> you accumulate lots of near-copies of almost-identical libraries
> to be able to run old binaries.
>
> A major-number bump should usually be something planned for
> and scheduled.
That const was just one of many const's added, and I am sure there will
be more stuff happening to C++. I changed a function returning short
for tuple length to int. Not worth mucking it up.
If it was just that one it would be OK.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-23 21:36 Nathan Myers <ncm@zembu.com>
0 siblings, 1 reply; 15+ messages in thread
From: ncm@zembu.com @ 2001-05-23 21:36 UTC (permalink / raw)
To: pgsql-hackers
On Wed, May 23, 2001 at 11:35:31AM -0400, Bruce Momjian wrote:
> > > > > We have added more const-ness to libpq++ for 7.2.
> > > >
> > > > Breaking link compatibility without bumping the major version number
> > > > on the library seems to me serious no-no.
> > > >
> > > > To const-ify member functions without breaking link compatibility,
> > > > you have to add another, overloaded member that is const, and turn
> > > > the non-const function into a wrapper. For example:
> > > >
> > > > void Foo::bar() { ... } // existing interface
> > > >
> > > > becomes
> > > >
> > > > void Foo::bar() { ((const Foo*)this)->bar(); }
> > > > void Foo::bar() const { ... }
> > >
> > > Thanks. That was my problem, not knowing when I break link compatiblity
> > > in C++. Major updated.
> >
> > Wouldn't it be better to add the forwarding function and keep
> > the same major number? It's quite disruptive to change the
> > major number for what are really very minor changes. Otherwise
> > you accumulate lots of near-copies of almost-identical libraries
> > to be able to run old binaries.
> >
> > A major-number bump should usually be something planned for
> > and scheduled.
>
> That const was just one of many const's added, and I am sure there will
> be more stuff happening to C++. I changed a function returning short
> for tuple length to int. Not worth mucking it up.
>
> If it was just that one it would be OK.
I'll bet lots of people would like to see more careful planning about
breaking link compatibility. Other changes that break link compatibility
include changing a struct or class referred to from inline functions, and
adding a virtual function in a base class.
It's possible to make a lot of improvements without breaking link
compatibility, but it does take more care than in C. If you wonder
whether a change would break link compatibility, please ask on the list.
Nathan Myers
ncm@zembu.com
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: C++ Headers
@ 2001-05-23 22:57 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Nathan Myers <ncm@zembu.com>
0 siblings, 0 replies; 15+ messages in thread
From: Bruce Momjian @ 2001-05-23 22:57 UTC (permalink / raw)
To: pgsql-hackers
> > If it was just that one it would be OK.
>
> I'll bet lots of people would like to see more careful planning about
> breaking link compatibility. Other changes that break link compatibility
> include changing a struct or class referred to from inline functions, and
> adding a virtual function in a base class.
>
> It's possible to make a lot of improvements without breaking link
> compatibility, but it does take more care than in C. If you wonder
> whether a change would break link compatibility, please ask on the list.
Our C++ interface needs serious work, and I don't want to burden a
maintainer with adding muck for backward compatibility.
We do update libpq occasionally and don't keep link compatibility. We do
keep interface compatibility with the backend.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2001-05-23 22:57 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2001-05-19 14:21 C++ Headers mlw <markw@mohawksoft.com>
2001-05-19 15:25 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-05-19 15:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2001-05-19 16:04 ` Larry Rosenman <ler@lerctr.org>
2001-05-19 17:09 ` Myron Scott <mscott@sacadia.com>
2001-05-19 17:17 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-05-20 00:34 ` Tom Lane <tgl@sss.pgh.pa.us>
2001-05-21 09:01 ` Christof Petig <christof@petig-baender.de>
2001-05-22 04:19 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-05-22 20:34 ` Nathan Myers <ncm@zembu.com>
2001-05-22 21:52 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-05-23 01:27 ` Nathan Myers <ncm@zembu.com>
2001-05-23 15:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-05-23 21:36 Re: C++ Headers Nathan Myers <ncm@zembu.com>
2001-05-23 22:57 ` Bruce Momjian <pgman@candle.pha.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox