Saturday, December 9, 2017

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

mcheung63@gmail.com: Dec 09 11:08AM -0800

god punished his mother, remember this
mcheung63@gmail.com: Dec 09 11:06AM -0800

Is this a spam? god punished your mother, remember this
mcheung63@gmail.com: Dec 09 11:07AM -0800

i want to piss into your mum pussy
mcheung63@gmail.com: Dec 09 11:06AM -0800

Is this a spam? god punished your mother, remember this
mcheung63@gmail.com: Dec 08 06:35PM -0800

this asshole spams again
mcheung63@gmail.com: Dec 09 11:05AM -0800

Is this a spam? god punished your mother, remember this
jacob navia <jacob@jacob.remcomp.fr>: Dec 09 12:43AM +0100

Le 08/12/2017 à 22:42, Alf P. Steinbach a écrit :
> seeing something that I don't see up front; or it could be a sloppy edit
> thing, that it once made sense in some other context; or, it could be
> that the person is not really fluent in C++.
 
What I do not understand there is this:
 
template<class L, class R>
auto fold(L l, R r) {
using lTag = typename L::tag;
using rTag = typename R::tag;
if constexpr( is_base_of<rTag, BarTag>::value ) {
if constexpr( is_same<lTag, FooTag>::value ) {
return foldFB(l,r);
} else {
return foldBB(l,r);
} else {
return foldFF();
}
}
 
Do you read like me?
 
if (constantexpr(etc) {
}
else {
}
 
And here the if is FINISHED, but the sample code goes on with
 
else return foldFF();
 
???
 
else what?
 
Has c++ changed the semnatics of the if so that there is
 
if this
 
else that
 
and then a THIRD else???
 
I think that the writer forgot to put some condition in the second
"else". Do you agree?
 
Because if not C++ is REALLY unreadable!
jacob navia <jacob@jacob.remcomp.fr>: Dec 09 12:46AM +0100

Le 08/12/2017 à 23:29, Richard a écrit :
> The poster boy use case for constexpr if is selection between algorithms
> at compile-time. (It is the 3rd example on given on that web page; I
> would have made it the first example.)
 
I did not mention the third example because it is so buggy
 
here it is
 
template<class L, class R>
auto fold(L l, R r) {
using lTag = typename L::tag;
using rTag = typename R::tag;
if constexpr( is_base_of<rTag, BarTag>::value ) {
if constexpr( is_same<lTag, FooTag>::value ) {
return foldFB(l,r);
} else {
return foldBB(l,r);
} else {
return foldFF();
}
}
 
Note that we have
 
if ()
 
else ...
 
and then ANOTHER ELSE!
 
Either the writer forgot a condition in the second if, or C++ has become
so uynreadable that you can write this kind of stuff meaning ... meaning
what?
 
I do not know, An "if" constructs returns a BOOLEAN value, it is either
true or false, so the "else" cares about the false condition, but there
are NO MORE conditions...
 
But with C++ you really never know...
Ian Collins <ian-news@hotmail.com>: Dec 09 02:29PM +1300

On 12/09/2017 12:43 PM, jacob navia wrote:
> }
> }
 
> Do you read like me?
 
Someone (the authour) didn't check their code! The last else probably
belongs with the first if.
 
--
Ian.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 09 03:55AM +0100

On 12/8/2017 11:32 PM, jacobnavia wrote:
 
> Well, enable_if_t returns either a type or not, depending on the
> condition. If the condition is true ( supportsAPI(T{} ) it returns the
> method, if not returns int,
 
No no. It stands for the type `int` if the condition is true. Otherwise
it gives compilation failure, which is of a kind ignored for templates
(Substitution Failure for a template argument Is Not An Error, SFINAE).
 
Since it already stands directly for a type, when it compiles, the
`decltype` appears to be completely unnecessary.
 
 
Cheers!,
 
- ALf
David Brown <david.brown@hesbynett.no>: Dec 09 06:26PM +0100

On 09/12/17 00:46, jacob navia wrote:
 
> Either the writer forgot a condition in the second if, or C++ has become
> so uynreadable that you can write this kind of stuff meaning ... meaning
> what?
 
It looks to me to be a simple typo, and should be:
 
if constexpr( is_base_of<rTag, BarTag>::value ) {
if constexpr( is_same<lTag, FooTag>::value ) {
return foldFB(l,r);
} else {
return foldBB(l,r);
}
} else {
return foldFF();
}
 
 
> true or false, so the "else" cares about the false condition, but there
> are NO MORE conditions...
 
> But with C++ you really never know...
 
Yes, you know fine - C++ is not /that/ difficult. "if constexpr" gets
structured the same way as "if" does. And people get it wrong
sometimes, just as they get C wrong and any other language wrong sometimes.
 
(C++ has plenty of hard bits - like knowing when to use "decltype" - but
this is not one of them.)
bartc <bc@freeuk.com>: Dec 09 05:46PM

On 09/12/2017 17:26, David Brown wrote:
> } else {
>   return foldFF();
> }
 
That doesn't account for the { on the 'auto...' line that doesn't have a
corresponding }.
 
However the purpose of 'if constexpr...' seems clear enough even to me.
Whatever branch of 'if constexpr' happens to be true at compile-time (in
a particular expansion of the template code), is compiled
unconditionally, and the other branches ignored.
 
--
bartc
David Brown <david.brown@hesbynett.no>: Dec 09 07:00PM +0100

On 09/12/17 18:46, bartc wrote:
>> }
 
> That doesn't account for the { on the 'auto...' line that doesn't have a
> corresponding }.
 
I hadn't included that part of the function definition. But certainly
there needs to be a final } at the end to match the opening { at the
start of the function.
 
> Whatever branch of 'if constexpr' happens to be true at compile-time (in
> a particular expansion of the template code), is compiled
> unconditionally, and the other branches ignored.
 
Yes.
 
The idea is to reduce the need for SFINAE, complicated template
specialisations, and std::enable_if expressions. These are all quite
complicated, and it takes a lot of thought to understand them - "if
constexpr" is a good deal easier to grasp and to use.
 
"if constexpr" also reduces the need for pre-processor conditional
compilation - in C++, it is generally considered better to avoid
pre-processor solutions when there are alternatives.
Ian Collins <ian-news@hotmail.com>: Dec 09 12:43PM +1300

On 12/09/2017 10:16 AM, jacobnavia wrote:
> }
> };
 
> in C++ 2017.
 
The example here: https://www.viva64.com/en/b/0533/#ID0EELAK
 
presents, in my opinion, a more practical example if day to day code.
 
template <typename T>
auto GetValue(T t)
{
if constexpr (std::is_pointer<T>::value)
{
return *t;
}
else
{
return t;
}
}
 
I have had to use convoluted SFINAE style code to get a similar effect.
I'll be updating that code next time I visit it.
 
constexpr if is one of apparently innocuous changes that will prove very
useful once you hit a situation where it saves code - especially where
it moves code from run to compile time.
 
--
Ian.
bartc <bc@freeuk.com>: Dec 09 12:20AM

On 08/12/2017 18:41, Richard wrote:
 
 
> I like this summary of the new features:
 
> <https://www.viva64.com/en/b/0533/>
 
> - std::byte type
 
Finally, a C++17 feature (in fact a C++ feature) I can understand.
 
Yes, this is just a byte type, that doesn't do anything clever. Why did
it take so long to figure out that it was needed?
 
--
bartc
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 09 01:06AM

On 09/12/2017 00:20, bartc wrote:
 
> Finally, a C++17 feature (in fact a C++ feature) I can understand.
 
> Yes, this is just a byte type, that doesn't do anything clever. Why did
> it take so long to figure out that it was needed?
 
I suspect most people will do a "using std::byte;" in their headers.
 
/Flibble
 
--
"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."
Robert Wessel <robertwessel2@yahoo.com>: Dec 08 10:17PM -0600


>Finally, a C++17 feature (in fact a C++ feature) I can understand.
 
>Yes, this is just a byte type, that doesn't do anything clever. Why did
>it take so long to figure out that it was needed?
 
 
Honestly, I would have expected that you would have disliked std::byte
because it's not an arithmetic type.
bartc <bc@freeuk.com>: Dec 09 02:03PM

On 09/12/2017 04:17, Robert Wessel wrote:
>> it take so long to figure out that it was needed?
 
> Honestly, I would have expected that you would have disliked std::byte
> because it's not an arithmetic type.
 
I was trying to find one thing in C++ I couldn't criticise or dislike!
 
But yes it does have some odd restrictions, which would have been better
applied to char itself (you can multiply a char value by 3, but you
can't do what with a byte).
 
 
--
bartc
mcheung63@gmail.com: Dec 08 06:34PM -0800

rick is asshole and keep spamming the group
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)