Wednesday, May 6, 2020

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

James Kuyper <jameskuyper@alumni.caltech.edu>: May 06 12:00AM -0400

On 5/5/20 4:36 PM, Ian Collins wrote:
 
> Just disable those you consider stupid. Do this in your projects
> makefile of whatever you use and include comments explaining why the
> warnings are disabled.
 
A policy that says "Must compile without warnings" is rendered very
nearly meaningless if you're free to turn off any warnings you don't
like. A meaningless requirement like that is one I can live with, but I
still think it's wrong-headed. Bad warnings should be turned off, and
sensible warnings should be turned on - but they are warnings, not
errors, which means that sometimes they reflect a serious problem, and
sometimes they don't. Each warning should be considered on a case by
case basis, to decide whether or not the warning is justified.
Ian Collins <ian-news@hotmail.com>: May 06 06:57PM +1200

On 06/05/2020 16:00, James Kuyper wrote:
> errors, which means that sometimes they reflect a serious problem, and
> sometimes they don't. Each warning should be considered on a case by
> case basis, to decide whether or not the warning is justified.
 
I'm not sure what you are arguing here, you say "Must compile without
warnings" is rendered very nearly meaningless if you're free to turn off
any warnings you don't like but then advocate turning bad warnings off!
 
In this case, the VS2019 warning is a bad warning.
 
--
Ian.
Jorgen Grahn <grahn+nntp@snipabacken.se>: May 06 08:23AM

On Wed, 2020-05-06, Ian Collins wrote:
 
> I'm not sure what you are arguing here, you say "Must compile without
> warnings" is rendered very nearly meaningless if you're free to turn off
> any warnings you don't like but then advocate turning bad warnings off!
 
Surely he means (classes of) warnings which everyone in the project
agrees they are never interested in, in any context, are "bad".
 
> In this case, the VS2019 warning is a bad warning.
 
Hard to tell though; maybe C4146 is a lifesaver in 2% of the cases?
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
James Kuyper <jameskuyper@alumni.caltech.edu>: May 06 08:19AM -0400

On 5/6/20 2:57 AM, Ian Collins wrote:
> On 06/05/2020 16:00, James Kuyper wrote:
...
 
> I'm not sure what you are arguing here, you say "Must compile without
> warnings" is rendered very nearly meaningless if you're free to turn off
> any warnings you don't like but then advocate turning bad warnings off!
 
I thought it was clear that I don't approve of that policy - therefore,
rendering it meaningless would be an improvement from my point of view.
 
But my comments about turning off bad warnings was not in the context of
that policy, but of a different one. Instead of "Treat all warnings as
errors", my policy is to "Treat all warnings as warnings - don't ignore
them, but don't automatically change your code to avoid them. Use
judgement to decide whether or not to modify your code to avoid
triggering any particular warning." In that context, also using your
judgement to decide which warnings to turn on and off is simply part and
parcel of the same attitude. A warning is a good one if it frequently
brings real problems to your attention. A warning is a bad one if it
frequently brings non-problems to your attention. Real-life warnings are
always a mixture of the two.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 06 01:06PM -0700

> brings real problems to your attention. A warning is a bad one if it
> frequently brings non-problems to your attention. Real-life warnings are
> always a mixture of the two.
 
Not disagreeing with anything you've said, but another viable approach
is to treat all warnings as errors and modify code as needed to avoid
any warnings. This relies on the good taste of the compiler writers.
It assumes that, even if some warnings (like Visual Studio's warning
about unary "-" on an unsigned type) might not be sensible, there are
ways to work around them without doing too much violence to the code.
If, for example, I can modify my code to avoid unary "-" on an unsigned
type *and* the resulting code is still reasonably clear, it might be
worth doing.
 
This can work if your development environment is reasonably stable over
time (as is the case for my current $DAYJOB). It's probably not viable
if you need to support multiple implementations, for example if you need
your code to build correctly on, say, Linux and Windows. It can be
simpler to follow a rule than to decide when it's ok to add exceptions.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
James Kuyper <jameskuyper@alumni.caltech.edu>: May 06 06:46PM -0400

On 5/6/20 4:06 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
...
 
> Not disagreeing with anything you've said, but another viable approach
> is to treat all warnings as errors and modify code as needed to avoid
> any warnings. This relies on the good taste of the compiler writers.
 
That's the key point. I'm not willing to rely on that - and this thread
provides an example of why.
 
I've usually seen the policy of treating all warnings as errors promoted
as an essential best-practice, without any acknowledgment that the bad
taste of some compiler writers could make such a policy problematic.
Ian Collins <ian-news@hotmail.com>: May 07 11:06AM +1200

On 07/05/2020 10:46, James Kuyper wrote:
 
> I've usually seen the policy of treating all warnings as errors promoted
> as an essential best-practice, without any acknowledgment that the bad
> taste of some compiler writers could make such a policy problematic.
 
In our case, someone just pings the team with a "hey, I'm getting this
warning" message, we kick it around and decide to either change the code
or suppress the warning. Because we use VS, clang and gcc these
discussions can be entertaining!
 
--
Ian
Paavo Helde <eesnimi@osa.pri.ee>: May 06 07:28AM +0300

05.05.2020 18:42 Tim Rentsch kirjutas:
> 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.
 
This is some serious feature creep. Do you realize you have just
casually invented a new not yet existing language, following a
complicated set of rules mixed up from two existing languages?
 
It would need a 10-year language design and standardization effort to
get it non-contradictory and useful, by which time both the target
languages have already evolved away.
 
Seriously guys, what have you got now with extern "C"? Can't you accept
it's basically just an instruction to the linker, similar to 'inline'?
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 06 10:17AM +0100

On Wed, 6 May 2020 07:28:26 +0300
> languages have already evolved away.
 
> Seriously guys, what have you got now with extern "C"? Can't you accept
> it's basically just an instruction to the linker, similar to 'inline'?
 
The original proposition here was that "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".
 
If that's still the plan, it's not just feature creep, it would break
shed loads of code. If you want to pass a C++ function as a callback to
a C library you need the function to have the C calling convention and
so label the function 'extern "C". But that has never meant that such
functions cannot access non-trivial objects of C++ class type
internally (even though such objects would be invalid in C
syntactically), nor that destructors no longer work for local objects
used in the function, nor that the functions must contain only "pure" C
syntax in some other sense.
 
Likewise, many languages use C as the 'lingua franca' for their FFIs.
If you want to call up C++ functions under such FFIs you need to
suppress name mangling by labelling them 'extern "C"'.
 
The point about callbacks or FFI interface functions which are labelled
as 'extern "C"' is that they are still C++ functions, but you can't
overload them and their arguments must have types which fall into the
subset of C which is also valid C++. That is as it should be.
 
I have to say I have never come across anyone who thinks that 'extern
"C"' means "this code must be treated by the compiler as if it were
written in C". I don't know where that idea has come from.
"Öö Tiib" <ootiib@hot.ee>: May 06 02:49AM -0700

On Wednesday, 6 May 2020 07:28:38 UTC+3, Paavo Helde wrote:
> languages have already evolved away.
 
> Seriously guys, what have you got now with extern "C"? Can't you accept
> it's basically just an instruction to the linker, similar to 'inline'?
 
It could be some other keyword (better not combination of "extern",
"const", "static" or "inline"). Something like _Pure "C". But that
would require C++ standard to specify by what C standard rules the
_Pure "C" code is compiled and how the symbols in _Pure "C" block
interact with symbols outside of it (if at all).
 
 
worrled.
Manfred <noname@add.invalid>: May 06 02:18PM +0200

On 5/6/2020 11:17 AM, Chris Vine wrote:
> syntactically), nor that destructors no longer work for local objects
> used in the function, nor that the functions must contain only "pure" C
> syntax in some other sense.
 
The way I understand it, the idea that 'extern "C"' blocks contain C
code (not that I support that) would not necessarily imply that the body
of functions declared in there would have to be C: if the extern "C"
block is in a header file and only contains the function declaration,
then it is the prototype that has to adhere to C rules, not the body as
long as it is outside of the extern "C" block (e.g. in a .cpp file)
 
> as 'extern "C"' is that they are still C++ functions, but you can't
> overload them and their arguments must have types which fall into the
> subset of C which is also valid C++. That is as it should be.
 
i.e. the function prototype must comply to the C rules.
 
 
> I have to say I have never come across anyone who thinks that 'extern
> "C"' means "this code must be treated by the compiler as if it were
> written in C". I don't know where that idea has come from.
 
I can understand this would be to allow for e.g. inline functions that
are not only declared but also /defined/ inside the same header to be
compilable both as part of a C and C++ translation unit.
However, personally I don't see a real need for this.
While interoperability at the level of function signatures (i.e.
linkage) is definitely a must, I don't see much gain at the level of
procedure body.
James Kuyper <jameskuyper@alumni.caltech.edu>: May 06 09:19AM -0400

On 5/6/20 5:17 AM, Chris Vine wrote:
...
> I have to say I have never come across anyone who thinks that 'extern
> "C"' means "this code must be treated by the compiler as if it were
> written in C". I don't know where that idea has come from.
 
I have. CB Falconer claimed that it was not possible for a C function to
call a C++ function, directly or indirectly. It was clear that he knew
little, if anything about the C++ language linkage feature. That didn't
prevent him from having strong opinions about it. His wording was often
unclear, and he seldom responded directly to the questions I asked to
try to clarify what he meant, but during the discussion he appeared to
express all of the following misconceptions:
 
* He thought that extern "C" applied only to an entire source code module.
* He was unaware of the distinction between a function whose name had
"C" language linkage, and a function whose type had "C" language linkage.
* He thought that functions declared extern "C" were necessarily defined
using code interpreted according to the rules of the C language, and in
particular, could not refer to things defined in the C++ language.
* He sometimes appeared to consider that any function declared extern
"C" was a C function; other times, it seemed that he considered that any
function referred to in C++ code should count as a C++ function. It's
not clear whether he understood that functions with names declared as
extern "C" in C++ code could be defined in either language.
 
It took me a while to put together a good counter example, but only
because I made it an interesting intellectual problem by imposing some
strict requirements on it. The program consisted of two modules with
associated header files. #ifdef _cplusplus was used only to hide the
language linkage specifications from the C compiler. The modules both
qualified as strictly conforming C code (except for the use of
_cplusplus), and as well-formed C++ code.
 
As compiled by C++, the program contained every possible combination "C"
or "C++" function type language linkage with "C" and "C++" function name
language linkage, and also contained one object whose name had "C"
language linkage, and one whose name had "C++" language linkage.
 
To make it clear which modules were being compiled as C, and which as
C++, I made a comprehensive list of code constructs that were not syntax
errors or constraint violations, didn't have unspecified or undefined
behavior in either language, and were well-formed C++ code, but which
had different meanings in the two languages. While there are a great
many differences between the languages, surprisingly few of them pass
those filters. I had barely enough cases to put a different example in
each function. However, several of the differences that do pass those
filters are very fundamental, including differences in the way that
scopes and name spaces (NOT namespaces, which is a different concept)
are handled in the two languages.
 
If the first module was compiled in C, and the second module was
compiled in C++, and they were linked together, the combined program was
guaranteed to produce a successful termination status. It included code
compiled as C calling one function by name and one function by pointer
that were both defined in C++. The function that was called through a
pointer had a name with C++ language linkage. Both of those functions
called a function that had C++ language linkage for both it's name and
it's type. Therefore, no matter how he defined his concept of what a "C
function" (which wasn't at all clear), that program had to include a C
function calling a C++ function.
 
Compiling both modules as C, or both as C++, or the first one as C++ and
the second as C, would all result in a program that had an unsuccessful
termination status. The difference in termination status depending upon
which language was used was due entirely to the features that I put into
each function that had different behavior in the two languages, so he
could not dispute which language's rules were being used to compile each
function (this wasn't quite true - one of the differences I made use of
was sizeof('a'), but if the C implementation had sizeof(int)==1, that
expression would have the same value in both languages).
 
He responded to my counter example with confusion, but not with a
concession that he was wrong about anything.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 06 07:42PM +0100

On Wed, 6 May 2020 14:18:16 +0200
Manfred <noname@add.invalid> wrote:
[snip]
> block is in a header file and only contains the function declaration,
> then it is the prototype that has to adhere to C rules, not the body as
> long as it is outside of the extern "C" block (e.g. in a .cpp file)
 
On "not the body as long as it is outside of the extern "C" block (e.g.
in a .cpp file)", if I have understood you correctly then I do not
think you are right - see below.
 
[snip]
 
> i.e. the function prototype must comply to the C rules.
 
[snip]
> While interoperability at the level of function signatures (i.e.
> linkage) is definitely a must, I don't see much gain at the level of
> procedure body.
 
I am not completely sure I have got hold of your point, but if you are
suggesting that, in a case where you wrap a whole function body in
'extern "C" {...}' because there is no function prototype, it follows
that the function body has to be written in C, then that is wrong. You
can use standard C++ for the wrapped function body. It is the function
name and function type which acquires language linkage, together with
function pointers and variables with external linkage. (For the current
purpose the latter - variables with external linkage - are irrelevant:
local variables in the C++ function wrapped by 'extern "C"' have auto
storage duration and no linkage and the ordinary C++ rules apply.)
 
A function's type can actually have C linkage (governing calling
convention) and its name (governing name mangling) with C++ linkage.
Such a function could be passed to C code by pointer (say as a
callback) because function pointers work by address and not by name,
but the function could not be called by name by C code. However, that
also is irrelevant to the case in hand.
 
Try it and see. But possibly you were commenting on something else.
 
The main point I was making was that when interfacing with C, applying
'extern "C"' to function prototypes or implementations is commonplace
and changing its meaning would break lots of code (including some of
mine) and would not be acceptable.
 
As to whether there should be a new keyword with the meaning
"compiler, treat this code is C code and not C++ code", that is a
separate matter. I suspect it would be unused in practice, but I may
be wrong.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 06 08:04PM +0100

On Wed, 6 May 2020 19:42:07 +0100
> Try it and see. But possibly you were commenting on something else.
 
On re-reading it I think you were talking about something else. I now
think you were commenting on the proposal, not on the current position.
 
The limitation concerning function bodies wrapped with extern "C" would
make the proposal less obnoxious I agree, but still has the potential
to break code. That includes breaking some of mine (I have just had a
quick look to see).
Manfred <invalid@add.invalid>: May 06 11:29PM +0200

On 5/6/20 9:04 PM, Chris Vine wrote:
>> Try it and see. But possibly you were commenting on something else.
 
> On re-reading it I think you were talking about something else. I now
> think you were commenting on the proposal, not on the current position.
 
Indeed.
 
> make the proposal less obnoxious I agree, but still has the potential
> to break code. That includes breaking some of mine (I have just had a
> quick look to see).
 
Yes, it would break code and thus it wouldn't work.
My opinion is that it would also be not really useful (so not worth
trying to make it work).
queequeg@trust.no1 (Queequeg): May 06 12:10PM


> I'm surprised you haven't KF'd Mr. Flibble, too. I think that Rick and
> Flibble are the same kind of troll - they know perfectly well that they are
> trolling.
 
I don't think so.
 
I'm far from diagnosing anyone over the Internet, but you don't have to be
a plane crash specialist to know that something's wrong when you see a
plane hanging from a tree.
 
That said, Rick looks mentally ill to me (perhaps a form of
schizophrenia?), while Mr Flibble is just arrogant and dumb. He's dumb for
assuming that he can talk sense to a mentally ill person, and he's
arrogant, because he's doing it despite repeated requests to stop.
 
Neither of them cares about the others in the group, but I think it's for
different reasons.
 
And yes, it's best to killfile both, unless you like cheap sitcoms, but in
this case -- and this is a request to everyone -- please don't reply to
their noise. It just adds more noise.
 
> Anyway, the prime reason I read this group is because I enjoy reading
> nonsense. I like Rick's nonsense the best. Don't care much for Flibble's
> brand of nonsense.
 
Rick is boring as hell and Flibble is dumb as f*ck. I don't want to waste
my time for neither.
 
--
https://www.youtube.com/watch?v=9lSzL1DqQn0
rick.c.hodgin@gmail.com: May 06 09:02AM -0700

On Wednesday, May 6, 2020 at 8:10:17 AM UTC-4, Queequeg wrote:
> Neither of them cares about the others in the group, but I think it's for
> different reasons.
 
I do care about the people in this group. Greatly. Hence my many
eaching posts.
 
Watch the videos. He explains everything in a teaching way. They
teach what will soon take place on the Earth, and how to avoid it.
 
Jesus didn't come to this Earth to bring religion. He came to save
people from judgment and damnation. If you care about your soul, go
to the cross and learn what Jesus did there and why. It's important
information to have, and it's why I post such things in this group.
I care about the people around me and in my life.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 06 10:14PM +0100

> to the cross and learn what Jesus did there and why. It's important
> information to have, and it's why I post such things in this group.
> I care about the people around me and in my life.
 
Fuck. Off.
 
--
"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."
felix@palmen-it.de (Felix Palmen): May 06 01:39AM +0200

> That was sarcasm.
 
Don't feed the troll. Even the first sentence was BS. There's no way KDE
will abandon Qt. The link just shows some difficulties, looks like the
typical "short-sighted" management trying to get out of a "situation".
We'll see where this leads.
 
On a very personal side node, Qt makes C++ a language worth to consider.
 
--
Dipl.-Inform. Felix Palmen <felix@palmen-it.de> ,.//..........
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 06 09:23AM +0100

On 05/05/2020 22:30, Christian Gollwitzer wrote:
 
>>> How's your Linux port doing? And the transpiler from moc-C++ to neoGFX-C++?
 
>> That is kind of my point: neoGFX doesn't have a "moc" only the bag of shite which is Qt does.
 
> That was sarcasm. My point was, that KDE will change to neoGFX not before you have written a transpiler which compiles C++ code for QT to C++ code for neoGFX, i.e. your own versino of moc. Because there is an enormous pile of code with many man-centuries of work in the KDE applications. And additionally Linux is the main platform, so if your library is Windows only, it is practically useless for KDE.
 
You are still missing the point: KDE is not on my radar as I have no plans on making a neoGFX/Qt transpiler; I don't want to infect neoGFX with anything Qt related.
 
/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."
Ned Latham <nedlatham@woden.valhalla.oz>: May 06 05:48AM -0500

Mr Flibble wrote:
> Christian Gollwitzer wrote:
> > schrieb Mr Flibble:
 
----snip----
 
> > > That is kind of my point: neoGFX doesn't have a "moc" only the
> > > bag of shite which is Qt does.
 
That's what turned me away.
 
 
> You are still missing the point: KDE is not on my radar as I have no
> plans on making a neoGFX/Qt transpiler; I don't want to infect neoGFX
> with anything Qt related.
 
I have a similar problem with infecting my code with exceptions, which
makes neoGFX problematic.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 06 12:02PM +0100

On 06/05/2020 11:48, Ned Latham wrote:
>> with anything Qt related.
 
> I have a similar problem with infecting my code with exceptions, which
> makes neoGFX problematic.
 
No exceptions? neoGFX currently also requires C++17 and OpenGL 4.0 as a minimum; given that I doubt neoGFX targets your market segment anyway even if we ignore exceptions.
 
/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."
Ned Latham <nedlatham@woden.valhalla.oz>: May 06 08:13AM -0500

Mr Flibble wrote:
 
> No exceptions? neoGFX currently also requires C++17 and OpenGL 4.0 as
> a minimum; given that I doubt neoGFX targets your market segment anyway
> even if we ignore exceptions.
 
Yep. Sadly.
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)