Path: 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: Sun, 08 Jun 2025 03:56:47 +0800
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <5484915e06dec7fa7a1371a9eb41801a00495079.camel@gmail.com>
References: <100h650$23r5l$1@dont-email.me> <101ft3d$1feqh$2@dont-email.me>
	 <101gq6l$1rdgj$1@raubtier-asyl.eternal-september.org>
	 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 07 Jun 2025 21:56:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9bd70c4a0c87ec4ace2a3a7ed7005e97";
	logging-data="3425130"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19HXTf++0UiwcR1k4DZjJVl"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42)
Cancel-Lock: sha1:4hxkPXCLV0qgqDXTE7aWwySlvjw=
In-Reply-To: <10223hq$38g0s$1@raubtier-asyl.eternal-september.org>

On Sat, 2025-06-07 at 21:22 +0200, Bonita Montero wrote:
> Am 07.06.2025 um 20:43 schrieb wij:
>=20
> > The error from opendir(..):
> >=20
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EACCES Permission denied.
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EBADF=C2=A0 fd is not a vali=
d file descriptor opened for reading.
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EMFILE The=C2=A0 per-process=
 limit on the number of open file descriptors has
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 been reached.
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENFILE The system-wide limit=
 on the total number of open files has=C2=A0 been
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 reached.
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENOENT Directory does not ex=
ist, or name is an empty string.
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENOMEM Insufficient memory t=
o complete the operation.
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENOTDIR name is not a direct=
ory.
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...
>=20
> With C++ that's all encapsulated in filesystem_error which is derived
> from system_error. But you can omit permission denied errors with
> directory_options::skip_permission_denied. That makes sense mostly
> with recursive_directory_iterator.=C2=A0

I see std::filesystem as evidence that C++ finally admits the deficiency of
its advance error handling system (std::exception). But the result is worse=
 than C.
I am not familiar with C++ std lib, I cannot say much.

> If you want to to that in C you've
> at least ten times the code.
>=20
> > I think your 'less work' was from simplication or idealization, lots ar=
e
> > simplified and idealized.
>=20
> No, show me your C code to iterate through a directory and I show you
> the same code with up to a fifth of C++-code. When you iterate=20
> recur-sively that's a tenth of the code.
>=20
> > If you can handle errors that way, C can also do it in much simpler way=
..
>=20
> Absolutely not.
>=20
> > The basic problem of throwing error is losing error context, it is simi=
lar
> > to set a global errno (or object) and cause the program to stack unwind=
..
>=20
> The context doesn't matter. A bad_alloc doesn't need context, a
> system_error also not. And that's most of the exceptions the C++
> runtime throws (some are derived from system_error).
>=20
> > C++ has many artificial fancy things and encourages such programming st=
yle.
> > Good or bad? Both, but I would say mostly bad.
>=20
> C is bad, because you've to do simple things over and over with multiple
> times the code because there are no language-facilities to abstract your
> coding.

Most of the above replies are false owing from narrow view. I'll save my
explanations.