Re: [PATCH 00/37] removal of some c++ keywords

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 31, 2018, 00:48 UTC
Message-ID: <CACsJy8C98HD59DGgqyWtZzj2RVqFe9GN=810A6fs2mMYBh_53Q@mail.gmail.com>
In-Reply-To: <CAGZ79kZ-hZzKtv05d5_7O2ndNZvGkU7qYnrn52zwpqSTqCiygQ@mail.gmail.com>

On Wed, Jan 31, 2018 at 6:01 AM, Stefan Beller <sbeller@google.com> wrote:

Show 26 quoted lines

> On Tue, Jan 30, 2018 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> Is it simpler (though hacky) to just  do
>>>
>>> #ifdef __cplusplus
>>> #define new not_new
>>> #define try really_try
>>> ...
>>>
>>> somewhere in git-compat-util.h?
>>
>> Very tempting, especially given that your approach automatically
>> would cover topics in flight without any merge conflict ;-)
>>
>> I agree that it is hacky and somewhat ugly, but the hackiness
>> somehow does not bother me too much in this case; perhaps because
>> attempting to use a C++ compiler may already be hacky in the first
>> place?
>>
>> It probably depends on the reason why we are doing this topic.  If a
>> report about our source code coming from the C++ oriented tool cite
>> the symbol names seen by machines, then the "hacky" approach will
>> give us "not_new" where Brandon's patch may give us "new_oid", or
>> whatever symbol that is more appropriate for the context it appears
>> than such an automated cute name.

Well. the world after post processing is always ugly. But we could try "#define new new__" to get the not so ugly names. new_oid is definitely better regardless of c/c++ though so I could see that as a good cleanup.

Show 8 quoted lines

>>> Do we use any C features that are incompatible with C++? (or do we not
>>> need to care?)
>>
>> Good question.
>
> implicit casts from void?
> e.g. xmalloc returns a void pointer, not the type requested.
> https://embeddedartistry.com/blog/2017/2/28/c-casting-or-oh-no-we-broke-malloc

That causes lots of warnings but not errors (I bit the bullet and tried to compile git with g++). The next set of changes would be to reorganize nested enum/struct declarations. Even if nested, C considers these flat while C++ sees them in namespaces. There's some warnings about confusion with the new cool feature string literals, but that's easy to fix.

There's also C99 designator in builtin/clean.c (I thought we avoided C99, I can start using this specific feature more now :D)

I was stuck at the thread_local thing in index-pack.c and gave up. So I don't know what else we would need to change.

-- 
Duy