From nobody Mon Sep 09 14:29:06 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X2Tjb0Qccz5WXH0 for ; Mon, 09 Sep 2024 14:29:07 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id 4X2TjZ6wQ5z4Wsr for ; Mon, 9 Sep 2024 14:29:06 +0000 (UTC) (envelope-from jan@digitaldaemon.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 51200 invoked by uid 89); 9 Sep 2024 14:29:06 -0000 Received: from c-69-142-153-99.hsd1.nj.comcast.net (HELO ?10.0.0.22?) (jan@digitaldaemon.com@69.142.153.99) by digitaldaemon.com with SMTP; 9 Sep 2024 14:29:06 -0000 Content-Type: multipart/alternative; boundary="------------7REj93NxGwsfgELJ8gCO60Mf" Message-ID: <51c6d673-fb78-4c9e-a01f-427a3cbbc1d7@digitaldaemon.com> Date: Mon, 9 Sep 2024 10:29:06 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: David Chisnall , Poul-Henning Kamp Cc: Warner Losh , Kristof Provost , Alan Somers , Dmitry Salychev , FreeBSD Hackers References: <202409082111.488LBTtI074660@critter.freebsd.dk> <202DD893-B152-4B38-AE9B-862E08785396@freebsd.org> Content-Language: en-US From: Jan Knepper In-Reply-To: <202DD893-B152-4B38-AE9B-862E08785396@freebsd.org> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:162.217.112.0/22, country:US] X-Rspamd-Queue-Id: 4X2TjZ6wQ5z4Wsr This is a multi-part message in MIME format. --------------7REj93NxGwsfgELJ8gCO60Mf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/9/24 03:01, David Chisnall wrote: > On 8 Sep 2024, at 22:11, Poul-Henning Kamp wrote: >> Warner Losh writes: >> >>> I did C++ in the kernel in the 4.x->7-current time frame. >> The logical progression of C++ adoption would start with using a C++ >> compiler as a better C compiler. > C permits implicit casts from void*, C++ doesn’t. The last codebase I worked on that had gone through this transition was littered with implicit casts which made it hard to read. At a minimum, I’d want to add an always-inline templates wrapper around malloc that did the right thing, if not an explicit move to new/delete. I have always found this to be a benefit. Where C just casts away, C++ requires to 'review' to cast and show via a *_cast < ... > mechanism that the 'cast' is actually meant that way. > C++ places type and value names in the same namespace. There are some corner cases where a structure and a variable have the same name and sizeof gives different results in C and C++ modes. > > I have never found this to be a problem. They are indeed (rare) corner cases. (I also think I have noticed that particular C++ compilers at least warns when this might happen). However, I do think if compilation would be moved from C compiler to C++ compiler that particular coding standards have do be defined and followed. The proper standard being set and followed will prevent issues. --------------7REj93NxGwsfgELJ8gCO60Mf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 9/9/24 03:01, David Chisnall wrote:
On 8 Sep 2024, at 22:11, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

Warner Losh writes:


I did C++ in the kernel in the 4.x->7-current time frame.

The logical progression of C++ adoption would start with using a C++
compiler as a better C compiler.

C permits implicit casts from void*, C++ doesn’t. The last codebase I worked on that had gone through this transition was littered with implicit casts which made it hard to read. At a minimum, I’d want to add an always-inline templates wrapper around malloc that did the right thing, if not an explicit move to new/delete.
I have always found this to be a benefit.
Where C just casts away, C++ requires to 'review' to cast and show via a *_cast < ... > mechanism that the 'cast' is actually meant that way. 
C++ places type and value names in the same namespace. There are some corner cases where a structure and a variable have the same name and sizeof gives different results in C and C++ modes.
I have never found this to be a problem. They are indeed (rare) corner cases. (I also think I have noticed that particular C++ compilers at least warns when this might happen).

However, I do think if compilation would be moved from C compiler to C++ compiler that particular coding standards have do be defined and followed.
The proper standard being set and followed will prevent issues.

--------------7REj93NxGwsfgELJ8gCO60Mf--