Friday, April 12, 2019

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

Sam <sam@email-scan.com>: Apr 11 08:53PM -0400

Vir Campestris writes:
 
> on different H/W that needed false.
 
> Why is it possible to cast a lambda to a bool? And why doesn't GCC think
> this is worth a warning, even on -pedantic?
 
Try making the lambda capture something. A capture-less lambda is equivalent
to a plain function pointer, and a pointer (expr) in boolean context is
equivalent to (expr) != null;
David Brown <david.brown@hesbynett.no>: Apr 12 09:15AM +0200

On 11/04/2019 22:27, Vir Campestris wrote:
> this is worth a warning, even on -pedantic?
 
> </rant>
> Andy
 
It does not get a warning because it is legal code - the lambda is much
like a function pointer and the bool is set to true to show the lambda
is a valid function pointer. "-pedantic" does not enable any warnings
about legal but questionable code - it merely makes the compiler
stricter about sticking to the standard and avoiding extensions.
 
Put "-Wall" in your command line, and gcc will happily warn you.
Juha Nieminen <nospam@thanks.invalid>: Apr 12 07:41AM

> /* various bits of logic */
> return false;
> };
 
Any pointer can be implicitly cast to bool. A null pointer will
evaluate to false and a non-null pointer will evaluate to true.
This includes function pointers, and your lamdba there implicitly
converts to a (non-null) function pointer (because it doesn't
capture anything), and therefore evaluates to true when assigned to
a bool.
 
Pointers implicitly casting to bool is inherited from C. Whether
that's a good or bad thing is up to opinion.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 11:32AM +0200

On 12.04.2019 09:41, Juha Nieminen wrote:
> converts to a (non-null) function pointer (because it doesn't
> capture anything), and therefore evaluates to true when assigned to
> a bool.
 
Yes, IMO that's a good & comprehensive explanation.
 
 
> Pointers implicitly casting to bool is inherited from C. Whether
> that's a good or bad thing is up to opinion.
 
But here I disagree. Technically it's up to one's opinion. But I fail to
see any advantage of the implicit conversion to `bool` in modern
programming.
 
An explicit cast like `!!p` (which used to also help with inane
sillywarnings about performance from the Visual C++ compiler) is more
clear and not significantly more to write, and avoids all the implicit
conversion problems that Andy's code is one example of.
 
Maybe one should therefore start using a type like, off the cuff,
 
class Strict_bool
{
bool m_value;
 
public:
explicit operator bool() const { return m_value; }
 
template<
class T,
class = enable_if< same_type_v<T, bool> >
 
Strict_bool( const T value ): m_value( value ) {}
};
 
I think to avoid clashes with numerous existing types called `Bool`, and
to reduce verbosity, I'd call it `Truth`.
 
Then one could talk about "Truth values". :)
 
 
Cheers!,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 03:54PM +0200

On 12.04.2019 11:32, Alf P. Steinbach wrote:
 
> I think to avoid clashes with numerous existing types called `Bool`, and
> to reduce verbosity, I'd call it `Truth`.
 
> Then one could talk about "Truth values". :)
 
Trying out that idea, I ended up with the following:
 
 
<url:
https://github.com/alf-p-steinbach/cppx-core/blob/master/source/cppx-core/language/types/Truth.hpp>
--------------------------------------------------------------------------------
#pragma once // Source encoding: UTF-8 with BOM (π is a lowercase
Greek "pi").
//
// A boolean type without implicit conversion from integral or pointer
types.
 
#include <cppx-core/language/tmp/basic-Enable_if_.hpp> //
cppx::Enable_if_
#include <cppx-core/language/syntax/macro-use.hpp> // CPPX_USE_STD
 
#include <type_traits> // std::is_same_v
 
namespace cppx
{
CPPX_USE_STD( is_same_v );
 
class Truth
{
bool m_value;
 
public:
constexpr operator bool() const { return m_value; }
 
template<
class Arg,
class = Enable_if_<is_same_v<Arg, bool>>
 
constexpr Truth( const Arg value ): m_value( value ) {}
};
} // namespace cppx
 
--------------------------------------------------------------------------------
 
I discovered that as of C++17 it can't be used for template value
parameters.
 
However, also that will possibly become supported in C++20. :)
 
 
Cheers!,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 12 04:19PM +0100

On 12/04/2019 14:54, Alf P. Steinbach wrote:
 
> --------------------------------------------------------------------------------
 
> I discovered that as of C++17 it can't be used for template value parameters.
 
> However, also that will possibly become supported in C++20. :)
 
Why are you doing this? We already have "explicit" ctor and conversion
operator:
 
constexpr explicit operator bool() const noexcept;
 
/Flibble
 
--
"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," Bryne 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."
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 05:37PM +0200

On 12.04.2019 17:19, Mr Flibble wrote:
 
> Why are you doing this? We already have "explicit" ctor and conversion
> operator:
 
> constexpr explicit operator bool() const noexcept;
 
It turned out, when I declared various compile time constants as `Truth`
instead of former `bool`, that with the `explicit` conversion to `bool`
they couldn't be used directly as template parameter arguments.
 
That's not a problem with e.g. `if` conditions, where the standard has a
wording that makes `explicit` conversion to `bool` implicit. :-o :)
 
I just didn't think of templates when I wrote the off-the-cuff 1st version.
 
It's not so big a deal to add `!!` in front, but on the other hand that
puts the burden of providing the conversion on each and every such use
of the class, instead of the class doing it in a single place.
 
So I changed to implicit conversion, so a `Truth` value can be used
directly as template parameter argument.
 
And to tackle the overload resolution issues that that in itself
introduces I added a SFINAE restriction (not shown above, but it's on
GitHub) so that it doesn't convert to anything other than `bool`.
 
 
Cheers!,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 05:39PM +0200

On 12.04.2019 17:19, Mr Flibble wrote:
 
> constexpr explicit operator bool() const noexcept;
 
Thanks, I forgot the `noexcept`, will add.
 
 
Cheers!,
 
- Alf
blt_nglC4iP5z@0uwnnh_23vzpr.org: Apr 12 03:48PM

On Fri, 12 Apr 2019 17:39:28 +0200
>On 12.04.2019 17:19, Mr Flibble wrote:
 
>> constexpr explicit operator bool() const noexcept;
 
>Thanks, I forgot the `noexcept`, will add.
 
Why not throw in a final too. If you're going for unreadable syntatic soup you
might as well use as many ingredients as possible.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 05:54PM +0200


>> Thanks, I forgot the `noexcept`, will add.
 
> Why not throw in a final too. If you're going for unreadable syntatic soup you
> might as well use as many ingredients as possible.
 
<plink>
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 12 05:15PM +0100

On 12/04/2019 16:54, Alf P. Steinbach wrote:
>> soup you
>> might as well use as many ingredients as possible.
 
> <plink>
 
Good luck with that <plink>, the poster appears to be using randomly
generated e-mail addresses.
 
/Flibble
 
--
"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," Bryne 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."
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 12 05:40PM +0100


> On 12.04.2019 09:41, Juha Nieminen wrote:
<cut>
> sillywarnings about performance from the Visual C++ compiler) is more
> clear and not significantly more to write, and avoids all the implicit
> conversion problems that Andy's code is one example of.
 
It doesn't avoid it -- it relies on it. Both the initialisation of a
bool from a pointer, and the application of ! to a pointer, use the
standard conversions, which is what you and Juha (and almost everyone!)
calls implicit conversions.
 
Of course C++ could be changed to remove this standard pointer to bool
conversion and to add a special rule about pointer operands of !, but
that's not how things stand at the moment.
 
--
Ben.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 07:12PM +0200

On 12.04.2019 18:40, Ben Bacarisse wrote:
>> clear and not significantly more to write, and avoids all the implicit
>> conversion problems that Andy's code is one example of.
 
> It doesn't avoid it -- it relies on it.
 
In the language that we have, yes.
 
 
> Both the initialisation of a
> bool from a pointer, and the application of ! to a pointer, use the
> standard conversions,
 
Yes, but that's pretty irrelevant. Nobody's contested that or failed to
understand it. Assuming that Andy posted his question more as a possibly
interesting teaser that he fully knew the answer to, than as a way to
learn what was going on.
 
 
> which is what you and Juha (and almost everyone!)
> calls implicit conversions.
 
"Implicit conversion" is a description, a descriptive term; there is no
need to be pedantic about it. In fact the formal term "standard
conversion" is more limited, namely an implicit conversion with built-in
meaning (see C++17 §7/1). As I understand it formal "standard
conversion" does therefore /not/ cover use of a non-`explicit`
conversion operator, which is a case that both formal and informal
"implicit conversion" do cover.
 
Summing up, pedantry has its costs, so use with care. ;-)
 
 
> Of course C++ could be changed to remove this standard pointer to bool
> conversion and to add a special rule about pointer operands of !, but
> that's not how things stand at the moment.
 
Yes.
 
Which is why I suggested a `Strict_bool` class in the immediately
following text, a clarifying supportive context and what the earlier
remarks led up to, that you snipped.
 
The current version of that class, called `Truth`, is available at <url:
https://github.com/alf-p-steinbach/cppx-core/blob/master/source/cppx-core/language/types/Truth.hpp>.
 
It's mostly a drop-in replacement for `bool`, avoiding the undesired
implicit conversions.
 
As of C++17 there is one usage where `bool` can't be replaced with
`Truth` or a similar class, namely as a template value parameter. As I
understand it that situation will change with C++20. However, template
value parameters only introduce limited scope for conversion problems.
 
 
Cheers & hth.,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 07:16PM +0200

On 12.04.2019 15:54, Alf P. Steinbach wrote:
 
> I discovered that as of C++17 it can't be used for template value
> parameters.
 
> However, also that will possibly become supported in C++20. :)
 
I didn't realize it but this kind of class solves the
sometimes-a-problem with the specialization of `std::vector<bool>`,
where indexing returns a proxy rather than a raw reference.
 
Cheers!,
 
- Alf
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 12 07:48PM +0100

>> standard conversions,
 
> Yes, but that's pretty irrelevant. Nobody's contested that or failed
> to understand it.
 
Ah, that was not clear (at least to me). I thought you objected to the
implicit conversion and were suggesting !! to avoid it. What is it that
using !! avoids?
 
>> calls implicit conversions.
 
> "Implicit conversion" is a description, a descriptive term; there is
> no need to be pedantic about it.
 
Sorry, I did not intend to be pedantic -- that's why I said almost
everyone uses that term (I certainly do). It just happens that I'd seen
the term the standard uses, so I though it best to use the official one.
 
> use of a non-`explicit` conversion operator, which is a case that both
> formal and informal "implicit conversion" do cover.
 
> Summing up, pedantry has its costs, so use with care. ;-)
 
I wasn't being pedantic (at least not intentionally). Obviously
"standard conversion" is a more limited term, but are you saying it's
the wrong one to use here? I am very much /not/ a C++ expert, so I may
not have navigated the maze of initialisation possibilities correctly.
 
--
Ben.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 09:06PM +0200

On 12.04.2019 20:48, Ben Bacarisse wrote:
 
> Ah, that was not clear (at least to me). I thought you objected to the
> implicit conversion and were suggesting !! to avoid it. What is it that
> using !! avoids?
 
Sorry, I was possibly/likely committing the novice error of assuming
telepathic readers.
 
In my defense, I just successfully yesterday fought the first current
kidney stone, by the help of a transfusion of half a litre of water
directly into the blood so helping me fill bladder enough to be able to
u***ate that bastard out. But the CT scans say there's a brother
lurking. And some other physical problems turned up today, so I was not
my ordinary good (or mediocre) self, and I'm still not; again, sorry.
 
In my head I was thinking of language design alternatives to the
implicit conversions, which would not necessitate anything but the
already existing machinery such as the `!` operator.
 
[snip]
 
Cheers!,
 
- Alf
Vir Campestris <vir.campestris@invalid.invalid>: Apr 12 09:34PM +0100

On 12/04/2019 08:15, David Brown wrote:
> Put "-Wall" in your command line, and gcc will happily warn you.
 
Not when I tried it. Though I didn't try Gcc8.
 
Andy
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 12 09:35PM +0100

>> using !! avoids?
 
> Sorry, I was possibly/likely committing the novice error of assuming
> telepathic readers.
 
We all do that. Every post has to assume some background knowledge and
context.
 
> lurking. And some other physical problems turned up today, so I was
> not my ordinary good (or mediocre) self, and I'm still not; again,
> sorry.
 
Sorry to hear that. It sounds awful. I hope things get better for you
really soon.
 
> In my head I was thinking of language design alternatives to the
> implicit conversions, which would not necessitate anything but the
> already existing machinery such as the `!` operator.
 
Ah, I see.
 
--
Ben.
Vir Campestris <vir.campestris@invalid.invalid>: Apr 12 10:02PM +0100

On 12/04/2019 18:12, Alf P. Steinbach wrote:
> understand it. Assuming that Andy posted his question more as a possibly
> interesting teaser that he fully knew the answer to, than as a way to
> learn what was going on.
 
It was a teaser. Except for why the compiler doesn't think it worth
mentioning that the 20 lines of code that follows can never be executed.
 
Just like if you type
 
if([](){})
 
it's precisely and exactly equivalent to if(true). Except as an entry in
the obfuscated C++ contest...
 
BTW you might like to look at lithotripsy. And drink more!
 
Andy
SergIo <invalid@invalid.com>: Apr 12 12:26PM -0500


> You don't know what C++ is because you're too damn retarded.
> Everyone here hates you, I'm quite sure.
> You're less than useless.
 
C++ is still not a B-
 
 
ALGOL
LISP
Fortran II
 
SNOBOL
 
BASIC
 
RPG (ugh)
 
FORTRAN 66
 
Prolog
 
Scheme
 
SMALL
Turbo Pascal
Objective C
 
Fortran 2018 (yes..)
 
https://en.wikipedia.org/wiki/Timeline_of_programming_languages
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 12 09:37AM +0200

On 11.04.2019 12:02, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
>> $use_cppx( is_empty );
 
> You understand that this is a C++ newsgroup, right?
 
As I understand it you indicate that in your opinion the above is not C++.
 
It's equivalent to
 
using cppx::is_empty;
 
and the notation really saves typing when a number of names from a
namespace are used:
 
$use_std( cout, cerr, endl );
 
instead of C++17
 
using std::cout, std::cerr, std::endl;
 
or C++14 or earlier
 
using std::cout; using std::cerr; using std::endl;
 
The `$` here saves one from the eye-soring uppercase `CPPX_USE_CPPX`.
General rule: replace `$` with prefix `CPPX_`, uppercase the rest.
 
But if you like all uppercase, and/prefixes, or are a stickler for
pedantic formal correctness, then by all means uglify. The library
supports that for those who want it. So you're not forced to use `$`.
 
And technically you'd be right: the `$` is not permitted in C++ names,
for what once was /political correctness/ issues: that ASCII was not
just very English-centric, and not just had "American" in the name, but
actually had a symbol that denoted something American! :-o In an
intended more culture-neutral replacement for ASCII the `$` was
therefore replaced with the international currency symbol `¤`, which was
proposed by Italy and subsequently used by Russia, which naturally
didn't like the `$` very much. Today that nonsense (there is yet no
common international currency) symbol that no-one uses still occupies
valuable space on our keyboards, which especially is annoying to
non-English-country programmers, who'd rather have the `$` there.
 
On some systems (my own direct experience was on the HP3000) the `$` is
needed for system function names. And in nearly all other aspects the
C++ standard goes to pains to not exclude any system. And as far as I
know all extant C++ compilers accept the `$`; they just say a resounding
no to political correctness, and yes to practicality.
 
Some time after I started experimenting with `$`, Herb Sutter did the
same, probably for the exact same reasons: that it's an unused
"namespace", providing more clean notation for those who use it first.
 
But part of his feedback was that some companies use preprocessing (via
other tools than the C++ preprocessor) where the `$` in ordinary code is
problematic. Just like certain characters in file names can be
problematic for some tools. So Herb decided to drop the `$` convenience,
but I, for my library aimed more at small scale programming (in large
scale almost any overhead is justifiable) and learners, don't need to
support a few big companies' preprocessing requirements.
 
Thank you for providing an opportunity to mention all this.
 
Maybe you learned something?
 
 
>> return EXIT_FAILURE;
>> }
 
> All things considered, I think that's actually quite fitting.
 
Negativity oozes out of you.
 
It's true, I did a stupid thing with mutexes in the code. But it's dumb
to point out that the code doesn't work, in a response to a question
about why it doesn't work. It's a kind of wanna-be-bully thing, idiocy.
 
So, now you got some negativity back, how does that feel? Better?
 
 
Cheers!,
 
- Alf
Cholo Lennon <chololennon@hotmail.com>: Apr 12 02:34AM -0300

According to this (questionable) index, C++ is getting more and more
popular...
 
April Headline: Programming Language C++ is doing well in the TIOBE Index
https://www.tiobe.com/tiobe-index/
 
--
Cholo Lennon
Bs.As.
ARG
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)