Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@polymtl.ca>, John Baldwin <jhb@freebsd.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 1/3] Fix mismatched struct vs class tags.
Date: Wed, 30 Nov 2016 17:08:00 -0000	[thread overview]
Message-ID: <0cdddefe-faf8-9431-9fda-06f5bfff74ca@redhat.com> (raw)
In-Reply-To: <c74eb4ee48d4b6851f9d7c527e04f040@polymtl.ca>

On 11/30/2016 04:50 PM, Simon Marchi wrote:
> On 2016-11-30 11:23, John Baldwin wrote:
>> One other clangism is that clang warns about compiling a .c file in C++.
>> It wants an explicit '-x c++' to force the language mode.  However,
>> simply
>> adding this to CXX_FLAGS doesn't work as it is included in both compiling
>> and linking (and for the link it causes clang to try to parse all the
>> object
>> files as C++ source leading to bizarre errors).
> 
> I think you could add it in its own variable:
> 
> FORCE_LANG_FLAG = -x c++
> 
> and add that to INTERNAL_CFLAGS.
> 

Sounds like it'd work.  At least for gcc and clang.

>> I assume a massive .c -> .cc
>> (or .cxx, etc.) rename is not in the roadmap (it would presumably be very
>> disruptive to pending patchsets)?
> 
> I think it will have to be done at some point... it will be a bit weird
> and counter intuitive for newcomers to see .c files containing C++.
> That, and analysis tools that select the language based on the
> extension.  For example, I use Eclipse CDT for my development, and it
> assumes C code for .c files by default.  I can go change some obscure
> setting to force it to consider it as C++, but it would be nicer for
> everybody if we didn't have to do that.  Actually, I just checked and
> it's the same with vim and emacs.  If we want to do it right, we would
> have to rename .h into .hpp or .hh as well.  And it would be as painful
> to do it in 5 years as it would be to do it now, so I don't see why we
> would wait...

".hh" and ".hpp" just look weird to me (for not being used to it,
no doubt).  But how are these tools handling the massive number
of projects that use ".h" for C++ code?

( For emacs, we could put something in gdb/gdb-code-style.el / gdb/.dir-locals.el )

Thanks,
Pedro Alves


  reply	other threads:[~2016-11-30 17:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23 20:07 [PATCH 0/3] Fix various C++ related clang warnings John Baldwin
2016-11-23 20:08 ` [PATCH 1/3] Fix mismatched struct vs class tags John Baldwin
2016-11-23 20:58   ` Simon Marchi
2016-11-23 23:23     ` John Baldwin
2016-11-24 17:02       ` Pedro Alves
2016-11-24 17:47         ` John Baldwin
2016-11-24 18:50           ` Pedro Alves
2016-11-24 19:15             ` John Baldwin
2016-11-30 11:39               ` Pedro Alves
2016-11-30 16:23                 ` John Baldwin
2016-11-30 16:38                   ` Pedro Alves
2016-11-30 16:52                     ` Simon Marchi
2016-11-30 16:51                   ` Simon Marchi
2016-11-30 17:08                     ` Pedro Alves [this message]
2016-11-30 17:54                       ` Simon Marchi
2016-11-30 17:59                     ` Eli Zaretskii
2016-11-23 20:08 ` [PATCH 3/3] Do not use std::move when assigning an anonymous object to a unique_ptr John Baldwin
2016-11-23 21:19   ` Simon Marchi
2016-11-23 23:31     ` John Baldwin
2016-11-24  0:08       ` Simon Marchi
2016-11-24 16:52         ` Pedro Alves
2016-11-23 20:08 ` [PATCH 2/3] Add noexcept to custom non-throwing new operators John Baldwin
2016-11-24 17:03   ` Pedro Alves
2016-11-23 22:18 ` [PATCH 0/3] Fix various C++ related clang warnings Simon Marchi
2016-11-23 23:23   ` John Baldwin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0cdddefe-faf8-9431-9fda-06f5bfff74ca@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jhb@freebsd.org \
    --cc=simon.marchi@polymtl.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox