freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "Lowden, James K" <LowdenJK AT bernstein.com>
- To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] including readpassphrase.h
- Date: Tue, 20 Dec 2005 14:09:28 -0500
> From: ZIGLIO, Frediano, VF-IT
> Sent: Tuesday, December 20, 2005 11:08 AM
>
> Well, not using directory informations on #include was one of the
> suggestions on portability on "C++ Manuale di Stile" (Carlo Pescio
> "C++ Style Manual"), a very good book. The main reason why
> readpassphrase.h is in src/replacement is that it was on the same
> directory (I copied from a BSD style source, see license inside).
> I added #include in replacements.h after cvs commit so I decided
> to use relative include. This also assure that we use our version
> instead of possible system one (or that it do not compile...). A
> simple way to solve all issues can be - move
> src/replacements/readpassphrase.h to include/tds_readpassphrase.h
> - do adjustment for correct inclusion (include/replacements.h,
> src/replacements/readpassphrase.c) Does this solution make all
> happy ?
[The priority of search order for include paths ("" vs. <>) is part of
the C standard.]
I think it's OK to have *some* path information. The Open Group defines
some include headers as being in sys/
(http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html
).
I also think it's a good idea to have include files in one place and
source in another, if the include is to be shared. If the include is
not to be used elsewhere -- i.e. the .h file is only for one file or for
files in only one directory -- then it should stay with the files(s) and
#include "foo.h"
will work fine.
In our case, rather than:
$ mv src/replacements/readpassphrase.h \
include/tds_readpassphrase.h
I prefer:
$ mkdir include/replacements
$ mv src/replacements/readpassphrase.h \
include/replacements
and
#include <replacements/readpassphrase.h>
because it makes clear that our readpassphrase is a replacement, not a
specialized enhancement. Also, it has appealing parallelism:
src/replacements/*.c
include/replacements/*.h
How does that sound?
--jkl
-----------------------------------------
The information contained in this transmission may be privileged and
confidential and is intended only for the use of the person(s) named
above. If you are not the intended recipient, or an employee or agent
responsible
for delivering this message to the intended recipient, any review,
dissemination,
distribution or duplication of this communication is strictly prohibited. If
you are
not the intended recipient, please contact the sender immediately by reply
and destroy all copies of the original message. Please note that we do not
accept
account orders and/or instructions by e-mail, and therefore will not be
responsible
for carrying out such orders and/or instructions. If you, as the intended
recipient
of this message, the purpose of which is to inform and update our clients,
prospects
and consultants of developments relating to our services and products, would
not
like to receive further e-mail correspondence from the sender, please "reply"
to the
sender indicating your wishes. In the U.S.: 1345 Avenue of the Americas, New
York,
NY 10105.
-
[freetds] including readpassphrase.h,
Craig A. Berry, 12/18/2005
- Re: [freetds] including readpassphrase.h, James K. Lowden, 12/19/2005
- <Possible follow-up(s)>
-
Re: [freetds] including readpassphrase.h,
ZIGLIO, Frediano, VF-IT, 12/20/2005
- Re: [freetds] including readpassphrase.h, Craig A. Berry, 12/20/2005
- Re: [freetds] including readpassphrase.h, ZIGLIO, Frediano, VF-IT, 12/20/2005
-
Re: [freetds] including readpassphrase.h,
Lowden, James K, 12/20/2005
- Re: [freetds] including readpassphrase.h, Craig A. Berry, 12/20/2005
- Re: [freetds] including readpassphrase.h, ZIGLIO, Frediano, VF-IT, 12/21/2005
Archive powered by MHonArc 2.6.24.