Re: encapsulating directory operations

On Sat, 2025-06-07 at 06:24 +0200, Bonita Montero wrote:

Am 06.06.2025 um 22:04 schrieb wij:

On Fri, 2025-06-06 at 19:26 +0200, Bonita Montero wrote:

Am 06.06.2025 um 19:24 schrieb Scott Lurndal:

Bonita Montero <Bonita.Montero@gmail.com> writes:

Am 06.06.2025 um 16:10 schrieb Scott Lurndal:

Bonita Montero <Bonita.Montero@gmail.com> writes:

Am 03.06.2025 um 20:25 schrieb Scott Lurndal:

 

        The fchownat() function shall be equivalent to the chown() and lchown()
        functions except in the case where path specifies a relative path. In
        this case the file to be changed is determined relative to the directory
        associated with the file descriptor fd instead of the current working
        directory. If the access mode of the open file description associated
        with the file descriptor is not O_SEARCH, the function shall check
        whether directory searches are permitted using the current permissions
        of the directory underlying the file descriptor. If the access mode is
        O_SEARCH, the function shall not perform the check.

 
And why is this relevant for directory_iterator or
recursive_directory_iterator ?

 
Why are you asking this question on comp.lang.c?

 
Because you can have it easier than with opendir() / readdir().

 
Personally, I'd use nftw to iterate over a path.
 
https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw..html

 
That would be much nicer with a lambda which can take the context
of the calling function.
 

 
That's a matter of opinion.

 
It results in much less code.

 
That is illusion, particularly in this case (about directory).

 
I've shown the code. In C++17 iterating through a single directory and
printing it is two lines of code.

C has to deal with hardware, that is all the basic (C++ and other languages are
fundamentally the same).
There are 'tons' of details to consider, e.g. in multi-user/tasking condition.

Most serious programs will 'invent' their own functions, even their own
'sugar syntax'...

 
Not to iterate through a directory in C++.
 

'sugar syntax'... result would be better than 'directory_iterator'.

 
Why ?

There are many kinds of 'sub-languages' that can do any specific job better..
As said, C is the basic. Actually, IMO, C++ could be better than C, but C++
invented 10 times more possibility of doing things wrong (because most are
duplications).

In general, no need for such things as 'directory_iterator' in C-library.

 
 
In C you're forced to write ten times the code if you include error
handling.

C++ is no better, probably worse. Firstly, the term 'exception' (and
'vector' probably) is disabled in human mind to think about exception.
C++ had been trying to HIDE error (exception) from its beginning, very wrong
and very unsuccessful.

Snipet from https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
-------- Returning error and the error checking
 Error (branching point information) not handled is always a hiden 'UB' waiting
 to happen. The guideline is: ALWAYS CHECK THE ERROR. This guideline extends to
 API, therefore, "__attribute__((warn_unused_result))" should be added to the
 returning Errno. As usual, exception exists.

 From function usage point of view: The general concern of error checking may
 be the complexity and readibility of the source codes. In this guidelines'
 view, without the checking and handling of the error, the evaluation
 (readibility, beauty,..) of the codes is one-sided judgement, because error
 checking and handling is part of the complete program or (function). The API
 can always move the 'unwelcome' one to somewhere, but the machine sees
 everything.
 The minimum check-and-throw pattern is better than ignoration, such coding
 (throw) is equivalent to a blended cheap-and-better assert.
 Practice proves that error checking actually reduces software development and
 maintenance time, significantly.

Notice the term 'branching point', errors are merely branching points.
For a progam to be shorter/simpler as desired, how many branching points are
handled? What is 'convenience' based on, ignorance?

Just like a lambda passed
to std::sort() which takes context of the calling function.
 

In any case, nftw is a C function and C doesn't support lamda functions.

 
Lambdas without capture can be converted to C function-pointers.