[gmx-developers] C++ decisions - header file extension - use of bool

[David van der Spoel]

On 2013-03-15 13:32, Teemu Murtola wrote:
> Hi,
>
> On Fri, Mar 15, 2013 at 9:49 AM, David van der Spoel
> <spoel at xray.bmc.uu.se <mailto:spoel at xray.bmc.uu.se>> wrote:
>
>     First is about header file name. Since we will for the foreseeable
>     future at least have both C and C++ code it would be good in my
>     opinion to have a clear distinction in file names. The C++ files
>     have extension .cpp throughout, but the header files are .h. I would
>     like to propose to mv those to .hpp.
>
>
> I seem to recall that this was discussed back in 2009, and the decision
> was to have a single .h extension (e.g., the wiki pages, written mainly
> at that time, talk about .c/.cpp, but only of .h). If you want to revert
> that decision (or some other guidelines), I suggest you also factor in
> the effort that converting existing code (~200 files and ~70k lines) to
> the new rules. While not that big in this case, it is still annoying to
> try to track guidelines that seem to change every time someone starts to
> work on C++ code... That said, I don't have that strong feelings about
> this particular header extension. You should still specify when a header
> should have which extension. E.g., if a header has a bunch of code
> behind #ifdef __cplusplus, and is otherwise C-compatible, what should it
> be? I suspect that this kind of headers will be common during a
> transition period (which can be quite long...). Right now, smalloc.h is
> an example.
I hope there are not 350 include statements per file. I have no strong 
feelings either way, but since we will be stuck with a lot of C code for 
a long time anything we can do to increase clarity is worthwhile IMHO.

All C header files that can in principle be included by C++ code need to 
have the extern "C" included. I guess we need a strict 1:1 
correspondence language wise (i.e. .c file with .h header and .cpp file 
with .hpp header) and .cpp files can include .h files (which therefore 
need to be adapted), but .c files can not include .hpp files.

I'm ready to do the renaming if we agree.


>
>     Second is the use of bool versus gmx_bool. I was convinced at first
>     that bool was the way to go, but of course this is not portable to C
>     code, so it is probably better to stick with gmx_bool.
>
>
> I'm not sure what you are suggesting here. I'm not sure what we want to
> do with C compatibility in the long run, but given that gmx_bool behaves
> badly with equality comparison (both in C and C++ code) and with
> overloading (in C++ code), I think it is a worse alternative than bool
> in code that is not forced to be C compatible. The only advantage I see
> with gmx_bool is the behavior of std::vector<bool> vs
> std::vector<gmx_bool> (which most people wouldn't probably notice,
> though, so it is very minor issue). Would you really want to ban using a
> basic C++ feature that can actually help catch very unintuitive errors?
>
> Teemu
>
Thanks for your comments. My concern was more that gmx_bool would work 
in C++ but bool will not work in C. However they can of course live side 
by side for the time being if that is not too confusing. In that case we 
can decide to go all bool (and enums!) in C++ unless there is a 
particular reason not to.

-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205.
spoel at xray.bmc.uu.se    http://folding.bmc.uu.se