Thursday, May 14, 2020

Digest for comp.lang.c++@googlegroups.com - 14 updates in 7 topics

Nikki Locke <nikki@trumphurst.com>: May 14 10:23PM

Available C++ Libraries FAQ
 
URL: http://www.trumphurst.com/cpplibs/
 
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
 
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
 
Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website.
Tim Rentsch <tr.17687@z991.linuxsc.com>: May 14 08:11AM -0700

> too vague to say anything definite. You said that some code which
> is both valid C and valid C++ should be "automatically" compiled
> as C. [...]
 
No, I didn't. What I did say is this:
 
What I would like to see is for C++ to define how extern "C"
blocks work so that inside extern "C" { ... } what is accepted
is C syntax, and for that part of the source uses C semantics.
 
That statement is specific both about what needs to happen and in
which situations it does happen.
 
> become 4? Or must the full expression be a valid C expression? The
> whole function? The whole extern "C" block? All extern "C" blocks in a
> compilation unit?
 
All of those questions are easily answered after referring to my
stated description quoted above. (The example seems rather silly,
since there is never any reason to need sizeof('A'). But in any
case you should have no problem determining the answers. Right?)
 
> code limited to some fixed C version, meaning that I cannot use
> compiler extensions even if I explicitly switch them on on command
> line?
 
The C++ standard includes one or more normative references to the
C standard, including commonality with (parts of?) the C library.
So there is some notion that a C++ implementation has a tie to a
specific C implementation. As for extensions, a C++ compiler is
not required to implement any C extensions for extern "C" {...}
blocks; it could if that were desired, but it's not required,
and there isn't much incentive to do so. When people are writing
interfaces, normally they limit what is in them to be standard C
(or C++, depending), and don't use any extensions. The reason is
obvious: because we want the code to be acceptable to other
compilers that we might not know about, any code in the header
should be as standard as possible.
 
> function has been declared extern "C" or not? Does the meaning of code
> inside the extern "C" block silently change when I change the
> declaration of that other function to extern "C"?
 
Code inside extern "C" { ... } is treated as C code, not C++ code.
Note that the braces are an essential ingredient of this rule.
 
Functions defined like so - extern "C" <type> f( <...> ){ <...> } -
are C++ code (so the body is regular C++), but with C linkage.
That rule also holds for functions that are /declared/ with C
linkage but later /defined/ without any explicit extern "C" at the
point of definition; it doesn't matter whether the declaration is
written with (or without) braces for the extern "C".
 
It seems reasonable to allow code in extern "C" { ... } blocks to
call any functions previously declared with C linkage. This is
part of a larger question about what symbols declared outside
the immediate extern "C" { ... } should be visible within it.
Obviously that needs to be nailed down but shouldn't present
any substantial problems; at first guess, any symbol previously
declared or defined in a way that has the same meaning in C as
in C++ should be usable in an extern "C" { ... } block.
 
> recognized as valid C even though it isn't, or vice versa? Does the
> meaning of code silently change in the next compiler version where the
> bug is fixed?
 
Oh, come on. Compiler bugs are compiler bugs.
 
> These are just first issues coming to mind, and I did not even reach
> function overloading yet.
 
Do you think that's a problem? Seriously, if there is some sort
of interaction I haven't considered yet I would like to know
about it. I don't see any problem with function overloading.
 
> instruction how to name a symbol passed to the linker, the only
> difference is that in one case the symbol is defined and in the other
> case it is used. [...]
 
At some level what I am saying is that the linker/linkage view
doesn't serve this major use case very well. My proposal is an
effort to address this shortcoming.
Paavo Helde <eesnimi@osa.pri.ee>: May 14 09:42PM +0300

14.05.2020 18:11 Tim Rentsch kirjutas:
 
> What I would like to see is for C++ to define how extern "C"
> blocks work so that inside extern "C" { ... } what is accepted
> is C syntax, and for that part of the source uses C semantics.
 
I quoted above your text from May 5 to which I responded:
 
"Also, what may be more
important, code that is valid C and also valid C++, _but has a
different meaning in the two languages_, should take the C
meaning when inside the extern "C" { ... } brackets."
 
If you have changed your mind meanwhile, then that's OK.
James Kuyper <jameskuyper@alumni.caltech.edu>: May 14 05:02PM -0400

On 5/14/20 2:42 PM, Paavo Helde wrote:
> 14.05.2020 18:11 Tim Rentsch kirjutas:
>> Paavo Helde <eesnimi@osa.pri.ee> writes:
...
 
[Statement A - Helde]
>>> is both valid C and valid C++ should be "automatically" compiled
>>> as C. [...]
 
>> No, I didn't. What I did say is this:
 
[Statement B - Rentsch]
>> What I would like to see is for C++ to define how extern "C"
>> blocks work so that inside extern "C" { ... } what is accepted
>> is C syntax, and for that part of the source uses C semantics.
 
Tim considers Statement A to be significantly different from Statement B?
 
> I quoted above your text from May 5 to which I responded:
 
[Statement C - Helde]
> different meaning in the two languages_, should take the C
> meaning when inside the extern "C" { ... } brackets."
 
> If you have changed your mind meanwhile, then that's OK.
 
You consider Statement B significantly different from Statement C?
 
Could the two of you explain the differences that you see between those
statements? They all seem very similar to me. I'm not sure you're
actually disagreeing with each other. You may merely be confusing each
other with the way you choose to word your statements.
 
I'm assuming that "some code ... automatically" refers to all code which
appears inside an extern "C" block, and only such code. If so, that
aspect of those three statements lines up. Paavo - if that's not what
you meant, could you explain what you did mean?
 
Compare "code which is valid C and valid C++ ..." and "code that is
valid C and also valid C++ _but has a different meaning in the two
languages_ ..." If the code does NOT have a different meaning in the two
languages, then it doesn't matter which language's rules are used to
interpret it, so those clauses seem to say the same thing. Statement B
talks about code with C syntax, which includes code that is not valid
C++ code, while neither Statement A nor Statement C says anything about
such code. That's a difference in meaning, but not a conflict between
the statements.
 
"compiles as C", "uses C semantics", and "take the C meaning" are all
worded somewhat differently, but they all seem to me to say pretty much
the same thing. Do either of you two see a significant difference
between any pair of those phrases?
 
My personal opinion is that is unnecessary and might break some existing
code to allow C specific syntax and to mandate C semantics for all code
within an extern "C" block. Only the interfaces between the languages
need to be compatible. Currently, interoperability between C and C++
code is almost entirely implementation-defined, and I think it would be
a good idea to change that so it's (mostly?) defined explicitly by the
C++ standard. I think that what it should say is something similar to
the following:
 
Any object or function type that has "C" language linkage should be
defined solely using syntax that is supported by both C and C++, with
the same meaning in each language. This includes, recursively, the
declarations of any types that are incorporated into such a type by
name. Note: this wording describes the fundamental principle that should
be used. The actual standardese would need to be quite different and
more complicated: it would need to explicitly identify which features of
C and C++ could not be used in such declarations. That list might be
simplified by cross-referencing Annex C.
 
There's one key exception to this: the declaration of a struct type in
C++ may differ from the corresponding declaration used in C code, so
long as the C++ struct is a POD-struct that would be layout-compatible
with the declaration used in the C code, if that declaration were parsed
as C++ code.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 13 04:28PM -0700

On 5/13/2020 5:10 AM, Bonita Montero wrote:
> Compile the following like this:
> g++ -O3 -pthread SpinMutex.cpp spendCycles.s
[...]
 
I have not tried to compile it with g++ yet. I just ported it over to
Relacy simply because the porting process is a nice way to learn the
algorithm, and it helps flush out buggers. No matter how short it is.
 
The main point is that the lock logic itself works fine.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 13 04:29PM -0700

On 5/13/2020 7:02 AM, Bonita Montero wrote:
>>> puprose it is completely adequate.
 
>> If it doesn't need to be correct it can be arbitrarily simple and fast.
 
> It wouldn't be slower if it would be correct.
 
That is a strange comment to me. Humm...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 14 12:49PM -0700

On 5/12/2020 11:27 PM, Bonita Montero wrote:
 
>> You failed to close the handle to the semaphore, and failed to handle
>> EINTR. ...
 
> I didn't think about EINTR but that doesn't matter in this case.
 
You never would have thought about EINTR.
 
 
Tim Rentsch <tr.17687@z991.linuxsc.com>: May 14 06:29AM -0700

Tiib writes:
 
 
>> [redacted]
 
> Why should I write you benchmarks when you post groundless
> bullshit? Benchmarks written by me can't cure your stupidity.
 
I think of <unnamed> as a kind of netnews intelligence test.
The smarter someone is, the sooner they will cease responding
to any of <unnamed>'s postings.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 14 12:09PM -0700

On 5/14/2020 6:29 AM, Tim Rentsch wrote:
 
> I think of <unnamed> as a kind of netnews intelligence test.
> The smarter someone is, the sooner they will cease responding
> to any of <unnamed>'s postings.
 
Well... Shi%! I have learned that trying to help it results in massive
insults.
Tim Rentsch <tr.17687@z991.linuxsc.com>: May 14 06:55AM -0700


> [...]
 
> You need new eyes. Yours (as provided by your father and mother) do
> not see anything beyond 60 FPS.
 
Not true. Tests done with pilots, using flight simulators, found
that pilots could easily tell that 60 FPS wasn't fast enough to
be realistic.
 
> This announcement is like the ads for some loudspeakers boasting 30
> khz frequency range when your ear doesn't go beyond 17khz. The rest
> is only audible by your dog...
 
Also wrong, although for different reasons. First frequency
response of human ears differs a lot for different individuals,
and tests have been done that found, for some people, even though
their response drops off in the low 20's of kHz it picks up again
in the high 30's of kHz. Second there is an unstated assumption
that if we can't hear sine waves above 20 kHz then there is no
perceptible information content above 20 kHz. This assumption is
known to be false. Time delays are perceptible down into the
range of a small number of microseconds, translating to
frequencies on the order of 200 kHz. These things have been
known for decades, but some engineering types keep repeating the
same bogus assertions about what frequency response is needed,
etc.
gazelle@shell.xmission.com (Kenny McCormack): May 14 06:14AM

In article <r9falf$15u$1@dont-email.me>,
>coroutines, and modules. Modules promise a lot: compile-time
>improvement, isolation of macros, the abolition of header files, and
>ugly workarounds."
 
So, you are saying that modules promises these things:
 
1) compile-time improvement
2) isolation of macros
3) the abolition of header files
4) ugly workarounds
 
Good. I'm there.
 
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/God
"Öö Tiib" <ootiib@hot.ee>: May 13 11:27PM -0700

On Thursday, 14 May 2020 09:14:11 UTC+3, Kenny McCormack wrote:
> 3) the abolition of header files
> 4) ugly workarounds
 
> Good. I'm there.
 
 
The quotes indicate that it is not Lynn McGuire but Rainer Grimm
who is saying that.
Juha Nieminen <nospam@thanks.invalid>: May 14 08:32AM


>> Good. I'm there.
 
> The quotes indicate that it is not Lynn McGuire but Rainer Grimm
> who is saying that.
 
A misplaced Oxford comma?
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 14 02:24AM +0100

Just did a bit of naughty type punning:
 
namespace std
{
template <> struct hash<neolib::uuid>
{
typedef neolib::uuid argument_type;
typedef std::size_t result_type;
result_type operator()(argument_type const& aUuid) const
{
if constexpr (sizeof(std::size_t) == sizeof(uint64_t))
{
// type punning is serious business...
struct badf00d
{
uint64_t bat;
uint64_t pangolin;
};
badf00d covid19;
std::memcpy(&covid19, &aUuid, sizeof(covid19));
return covid19.bat ^ covid19.pangolin;
}
else
{
// type punning is serious business...
struct badf00d
{
uint32_t bat1;
uint32_t bat2;
uint32_t pangolin1;
uint32_t pangolin2;
};
badf00d covid19;
std::memcpy(&covid19, &aUuid, sizeof(covid19));
return covid19.bat1 ^ covid19.bat2 ^ covid19.pangolin1 ^ covid19.pangolin2;
}
}
};
}
 
https://github.com/i42output/neolib/blob/master/include/neolib/uuid.hpp#L123
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)