Tuesday, February 23, 2021

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

Bonita Montero <Bonita.Montero@gmail.com>: Feb 23 08:38AM +0100

> My version of "fairness", or being "starvation free", is when readers
> cannot starve out writers, and vise versa. Oh well. :^)
 
That's impossible to implement.
Readers or writers can hold the mutex as long as they want.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 23 12:25AM -0800

On 2/22/2021 11:38 PM, Bonita Montero wrote:
>> cannot starve out writers, and vise versa. Oh well. :^)
 
> That's impossible to implement.
> Readers or writers can hold the mutex as long as they want.
 
We just have radically different versions of what it means to be
starvation free. :^)
Bonita Montero <Bonita.Montero@gmail.com>: Feb 23 08:17PM +0100

>> Readers or writers can hold the mutex as long as they want.
 
> We just have radically different versions of what it means to be
> starvation free. :^)
 
The fairness of a lock doesn't depend on the implementation of the
lock but how it is used.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 23 11:29AM -0800

On 2/23/2021 11:17 AM, Bonita Montero wrote:
>> starvation free. :^)
 
> The fairness of a lock doesn't depend on the implementation of the
> lock but how it is used.
 
It does depend on the implementation if frequent reads can starve out
writers.
Richard Damon <Richard@Damon-Family.org>: Feb 23 04:51PM -0500

On 2/23/21 2:38 AM, Bonita Montero wrote:
>> cannot starve out writers, and vise versa. Oh well. :^)
 
> That's impossible to implement.
> Readers or writers can hold the mutex as long as they want.
 
And the standard definition of a 'fair locking' system is one that is
fair when the follow listed rules, like maximum hold time of a lock.
 
The only way to handle unruly clients is who hold their locks too long
is to have OS support to kill those clients and have it unlock the locks
it held on to. (It could not kill but just deny further access depending
on the resource).
Juha Nieminen <nospam@thanks.invalid>: Feb 23 11:16AM

>> probably being an array of values in the form of C/C++ source code generated
>> by a program, perhaps even your own program.
 
> Both .h and .c files are source files.
 
I know that perfectly well. However, in C/C++ style program design header
files ought have a different role than source files. Most commonly (with
very rare exceptions) a header file usually declares the public interface
of a compilation unit (ie. effectively a "module"). Only things that
should be visible to the rest of the program should be declared in the
header file, and (with certain special exceptions) all of the things
in the source file that have not been declared in the header file should
have internal linkage (ie. they are not visible anywhere else in the
program).
 
(Sometimes exceptions to this are sometimes made for the sake of making
compilation faster, by having something that has external linkage not
be declared in the header file, but that's not very relevant to this
discussion.)
 
The question presented in this thread is whether it's ok to #include
a source code file (which does not have the role of a header file)
in another source file.
 
My post argued that while this is relatively rare, there are some
situations where this is sensible. Most often this is the case with
generated code (which one wants to have internal linkage within
another compilation unit).
 
> A source file that is #include -d should have a .h suffix, even
> if it contains definitions that would prevent it from being
> included in more than one place.
 
If the file contains code that does not serve the role of being a
public interface declaration, then it's better to name it something
else than *.h, to avoid confusion.
 
> Using .c for include files causes confusion; it is a deeply entrenched
> convention that .c means "I am the root file of a translation unit".
 
Some people use some third kind of extension for code (eg. generated
code) that should be included in another source code, but which is
not a header file, such as .inc.
 
>> to write code in that compilation unit that uses the array, then this is
>> basically the only option. And I don't think there's anything wrong with it.
 
> You have the excellent option of naming it with a .h suffix.
 
I think .h (or .hh, or .hpp) should be reserved for public interface
declarations only (and possible inline function implementations of
those public functions), for clarity and to avoid confusion.
A header file should not contain internal implementation details that
are used solely in the source file to which the header file belongs to.
antispam@math.uni.wroc.pl: Feb 23 07:00PM

> > included.
 
> I find it hard to imagine a clearer indication of badly, badly broken
> code than a file that includes itself.
 
Look at hercules, file 'cpu.c'. IMO it is quite reasonable code
and has good reason to include itself. Your imagination (and
maybe experience) seem to be limited: I saw a lot of broken
code and none used self inclusion. I also saw good code that
played "interesting" tricks with inclusion.
 
--
Waldek Hebisch
antispam@math.uni.wroc.pl: Feb 23 07:22PM

> part.
 
> You can always find content for that .c part that doesn't have
> to be in the .h part. If nothing else, then a copyright header.
 
Well techincally you can have
 
#include "real_c_file.h"
 
as whole contend of "file.c". However, this is obfuscation,
justified only if some PHB imposes rule "no inclusion of .c
files". Admitedly, tricks with inclusion are need in
limited situations, but when needed may be quite useful.
 
BTW: There are folks who insits on "single source file".
If you need inclusion (and some preprocessor capabilites
are only available via inclusion) and your PHB insist
on "single source file" then self inclusion may neatly
solve (or at least delay) the problem (the real problem
of course being PHB). Of course, if you are a PHB
you can set for yourself any rules you wish. But do
not pretend that such rules have universal validity.
 
--
Waldek Hebisch
Kaz Kylheku <563-365-8930@kylheku.com>: Feb 23 07:53PM

>> code than a file that includes itself.
 
> Look at hercules, file 'cpu.c'. IMO it is quite reasonable code
> and has good reason to include itself.
 
No it doesn't. Let's see, it does this:
 
/* ... preamble, repeated for different values of _GEN_ARCH .. */
 
#if !defined(_GEN_ARCH)
 
#if defined(_ARCHMODE2)
#define _GEN_ARCH _ARCHMODE2
#include "cpu.c"
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)