Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Mon, 09 Jun 2025 00:28:34 +0800
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <e9cb37d7efedcb52f00397bf831787344c45b912.camel@gmail.com>
References: <100h650$23r5l$1@dont-email.me> <101h0an$1tkqk$1@dont-email.me>
	 <101jk7i$34erh$1@raubtier-asyl.eternal-september.org>
	 <1nj%P.3454$mAv4.2422@fx34.iad>
	 <101nc3o$5pjd$1@raubtier-asyl.eternal-september.org>
	 <h6H%P.676329$McHf.348392@fx15.iad>
	 <101u8sb$25g28$1@raubtier-asyl.eternal-september.org>
	 <3FC0Q.931590$G6Lf.397684@fx17.iad>
	 <101v7d7$2cudl$1@raubtier-asyl.eternal-september.org>
	 <CvF0Q.1165311$McHf.1120306@fx15.iad>
	 <101v8ce$2d5it$1@raubtier-asyl.eternal-september.org>
	 <0e9619f7d873a4ec436f017bac1192c73c5283e5.camel@gmail.com>
	 <1020eu8$2pifl$1@raubtier-asyl.eternal-september.org>
	 <1e3f53801e22a94356b9b0aded0ed7d33e67fd06.camel@gmail.com>
	 <1021pgp$35sqk$1@raubtier-asyl.eternal-september.org>
	 <1858c98adc50b2bec4021f15d0c5b94e2158f6b5.camel@gmail.com>
	 <10223hq$38g0s$1@raubtier-asyl.eternal-september.org>
	 <5484915e06dec7fa7a1371a9eb41801a00495079.camel@gmail.com>
	 <1023gak$3nt1m$1@raubtier-asyl.eternal-september.org>
	 <29b9613069183212a224d4e31d6e8e3ff8344113.camel@gmail.com>
	 <10248tl$3tavs$2@raubtier-asyl.eternal-september.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 08 Jun 2025 18:28:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e93449f47b4c8a523d85b86c5101ee1c";
	logging-data="4073526"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19LvTmOEez6mtAGJaQKGi4/"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42)
Cancel-Lock: sha1:rMaIxrhfSPm1zuW+y0TQ7rpEPw0=
In-Reply-To: <10248tl$3tavs$2@raubtier-asyl.eternal-september.org>
Bytes: 4015

On Sun, 2025-06-08 at 17:06 +0200, Bonita Montero wrote:
> Am 08.06.2025 um 16:52 schrieb wij:
>=20
> > I know a bit of the development of std::filesystem. The view of mere 's=
tandard'
> > disregards fact and uses more the 'assertion' criticized.
>=20
> Another statement without arguments.

My primary interest of programming is on the theory. From your presented=
=20
wording, I don't think you can conduct a logical discussion (it seems you
continue to ask for logical proof).

> > "dont' need" is illusion, errors are always there, mostly ignored and e=
ncouraged
> > to ignore by simplification.
>=20
> If the code is written to be exception-safe, i.e. it uses
> RAII throughout, then this is easily possible.
>=20
> > C has not hard coded what 'exception' should be. E.g. C can also set an=
 error
> > object and let interested code to handle it in many ways, what's left i=
s impl.
> > issues.
>=20
> Are you serious? The fact that the exception type is transported along
> with the exception itself makes things really convenient. This way, the
> stack can be unrolled until the correct exception handler is found.
>=20
> > But, I think the 'throw' mechanism (not std::exception) is good, like m=
any
> > others. 'throw' is more like a soft assert failure, which is no error h=
andling.
>=20
> Totally different - asserts are handled at debug-time.
> Based on this statement, you didn't understand exceptions correctly.

It seems your whole idea (and 'fact') is based on C++'s propaganda.

Most of the related discussion have happened in the past I am lazy to repea=
t.=20
Just look at the fact, C++ is half-dying and accelerating (IMO, not because
of bad but of trillions ways doing it wrong).
You are repeating past errors and think your understanding and coding is=
=20
orthodox enough to be factually correct.