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

[Mark Abraham]

On Fri, Mar 15, 2013 at 1:32 PM, Teemu Murtola <teemu.murtola at gmail.com>wrote:

> Hi,
>
> On Fri, Mar 15, 2013 at 9:49 AM, David van der Spoel <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 see. I am also happy with retaining just .h and using file location to
imply whether C++ conversion has occurred, or not.

I am currently thinking that a large number of our existing .h header files
will gradually die as the functions and structures they declare become
encapsulated objects (and even our relatively well-behaved opaque-pointer C
objects will probably get renamed). There should be very little that ends
up being just a file or text copy - there's too many things that need
thinking about. So, I think the issue of relabelling a header file will not
arise much under any policy.

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?
>

Oh, I see. I now recall that gmx_bool is typedef'ed to an int, and in C++
that is distinct from bool (and vector<bool> is specialized to work as a
bitfield, IIRC).

In that case, using bool in code we write as C++ makes sense. Code imported
from C should be refactored to use bool as part of the process. Getting
help from the compiler is much more important than the hypothetical benefit
of wanting to re-typedef our in-house boolean type some later time.

I don't think we want to add a C++-only typedef of bool to gmx_new_bool (or
whatever), either.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130315/bd89ce05/attachment.html>