Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: wij 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> <101u8sb$25g28$1@raubtier-asyl.eternal-september.org> <3FC0Q.931590$G6Lf.397684@fx17.iad> <101v7d7$2cudl$1@raubtier-asyl.eternal-september.org> <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.