From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id AF3DC3858431 for ; Tue, 11 Jan 2022 18:36:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AF3DC3858431 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-60-E9GhX1K-PgGaW7_Z4GtKYg-1; Tue, 11 Jan 2022 13:36:18 -0500 X-MC-Unique: E9GhX1K-PgGaW7_Z4GtKYg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 299BF1898290; Tue, 11 Jan 2022 18:36:17 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.246]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7539A838C1; Tue, 11 Jan 2022 18:36:16 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 20BIaDa61113697 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 11 Jan 2022 19:36:13 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 20BIaCT01113696; Tue, 11 Jan 2022 19:36:12 +0100 Date: Tue, 11 Jan 2022 19:36:12 +0100 From: Jakub Jelinek To: Jonathan Wakely Cc: Harald Anlauf , GCC Mailing List , gfortran , GCC Patches Subject: Re: [PATCH] Mass rename of C++ .c files to .cc suffix Message-ID: <20220111183612.GC2646553@tucnak> Reply-To: Jakub Jelinek References: <57564370-7184-ef62-039e-60b150058fd8@suse.cz> <68946bf6-4b2f-b8f3-20b3-5cf3f2fd611c@moene.org> <713a96b5-b82e-ffd7-d03b-7e05a4dede9e@suse.cz> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 18:36:23 -0000 On Tue, Jan 11, 2022 at 06:23:51PM +0000, Jonathan Wakely via Gcc-patches wrote: > > Regarding fortran: can we have a vote on this one? > > > > Some developers (including myself) are not really familiar with C++, > > and in the past preference has been expressed on the fortran ML in > > favor of not using too much C++. > > > > I would also not really be in a position to review real C++ code. > > The discussion is purely about renaming files that are *already* C++ > source files but have the misleading .c file extension. > > Nobody is suggesting using C++ where it isn't already being used. And even gcc/fortran/ is written in C++, the gcc/ headers it uses are C++ only, they use templates etc., so gcc/fortran/ that uses those headers has to be C++ too. That doesn't mean you need to use C++ idioms everywhere in your code, those files can stay to be mostly C-like with C++ headers and use C++-only constructs only where it brings sufficient advantages. Many of the gcc/*.c sources that Martin wants to rename are also written like that. The renaming will just match the reality, clang++ will stop warning that support for .c extension for C++ is deprecated when building gcc, sites like openhub.net (if they twice a year manage to build stats for gcc, dunno what they are doing wrong or if it is because of the limiting of anonymous git on sourceware) will not claim most of GCC is written in C etc. Jakub