What version of C++

[woodb...@gmail.com]

Shalom

The following is from one of the replies in this thread:

https://www.reddit.com/r/cpp/comments/hpw6az/memory_readwrite_library/

if (auto code = read_process_mem(...); code == mem_hengst::succes)//c++20 if init
{ //succes } else { //failure }


My question is regarding the comment:
//c++20 if init

. I thought that was part of 2017 C++. Was
something tweaked in 2020 C++ in that area or
is the comment wrong? Thanks in advance.


Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards

[Öö Tiib]

On Sunday, 12 July 2020 22:52:15 UTC+3, woodb...@gmail.com wrote:
> The following is from one of the replies in this thread:
>
> https://www.reddit.com/r/cpp/comments/hpw6az/memory_readwrite_library/
>
> if (auto code = read_process_mem(...); code == mem_hengst::succes)//c++20 if init
> { //succes } else { //failure }
>
> My question is regarding the comment:
> //c++20 if init
>
> . I thought that was part of 2017 C++. Was
> something tweaked in 2020 C++ in that area or
> is the comment wrong? Thanks in advance.

Yes you are correct that the pointless optional init statement
was added by C++17 into if but also "succes" is not a word
and // comment goes until end of line. So the whole thing there
screams that it is some quick pseudo-code garbage.

[woodb...@gmail.com]

Why do you point out that // comment goes until the end
of the line?

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
> Yes you are correct that the pointless optional init statement
> was added by C++17

Pointless...

I suppose the 'for' loop syntax is pointless too, because the exact same
thing can be achieved with a 'while' loop.

While we are at it, 'while' is pointless too, because the same thing
can be achieved with 'if' and 'goto'. And 'switch' is pointless because
the same thing can be done with 'if ... else if ...' (In fact,
concatenated ifs are even more versatile than 'switch' because the
comparison and the types involved don't have to all be the same,
which makes 'switch' even more pointless.)

And why do we even need support for declaring variables inside blocks?
It's enough to declare all variables at the beginning of the function.
Everything else is pointless.

[Öö Tiib]

Because code like posted does not compile:

if (condition)
{ //succes } else { //failure }

Was it too hard to write something that follows language rules?

if (condition)
{ /*success*/ } else { /*failure*/ }

Or why not? Just to be demonstratively sloppy, lousy, shoddy and
dirty?

[Öö Tiib]

On Monday, 13 July 2020 09:20:24 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > Yes you are correct that the pointless optional init statement
> > was added by C++17
>
> Pointless...
>
> I suppose the 'for' loop syntax is pointless too, because the exact same
> thing can be achieved with a 'while' loop.

It was added for backward compatibility with C so why to bother?
Bart in comp.lang.c keeps critiquing it sometimes ... I don't care.
Something with backward compatibility to seventies may look awkward,
it is fine.

>
> While we are at it, 'while' is pointless too, because the same thing
> can be achieved with 'if' and 'goto'.

Yeah why C++17 did not add pointless optional init statement
to while as well to make it somewhat like half of that "good old" for?

> And 'switch' is pointless because
> the same thing can be done with 'if ... else if ...' (In fact,
> concatenated ifs are even more versatile than 'switch' because the
> comparison and the types involved don't have to all be the same,
> which makes 'switch' even more pointless.)

Switch got also that pointless init statement. What is wrong with
switch is that there must be "break;" everywhere while it is more
logical to have "do not break;" on that very rare case when we do
not want to break. But again for backward compatibility with code
written in seventies it is OK perhaps.

> And why do we even need support for declaring variables inside blocks?
> It's enough to declare all variables at the beginning of the function.
> Everything else is pointless.

Because features that make code easier to follow are not pointless.

That is logically sound:

value x = source();
if ( x.has(certain_property) ) x.do_something();

I read it "value x is acquired from source, if x has certain property
then do something with x".

Garbage features that make code less logically sound, uglier and
harder to follow however are clearly pointless. That is logically
unsound:

if ( type x = source(); x.has(some_property) ) x.do_something();

Even Yoda did not have his reasoning so messed up.
Better have block if you want to narrow the scope of x;
no need to screw up its coherence:

{
value x = source();
if ( x.has(certain_property) ) x.do_something();
}

[woodb...@gmail.com]

I don't think it's a garbage feature. I'd rather remove
std::any than the 2017 changes to 'if' statements.


Brian
Ebenezer Enterprises
https://webEbenezer.net

[Mr Flibble]

std:::any is great because type erasure is great.

/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."

[woodb...@gmail.com]

On Monday, July 13, 2020 at 11:27:11 AM UTC-5, Mr Flibble wrote:
> On 13/07/2020 17:15, woodb...@gmail.com wrote:
> >
> >
> > I don't think it's a garbage feature. I'd rather remove
> > std::any than the 2017 changes to 'if' statements.
>
> std:::any is great because type erasure is great.
>

I'm not seeing interest in std::any here or on Reddit.

[Mr Flibble]

And that matters why exactly? That has no bearing on whether or not people actually use std::any.

[Keith Thompson]

Öö Tiib <oot...@hot.ee> writes:
> On Monday, 13 July 2020 03:28:28 UTC+3, woodb...@gmail.com wrote:

[...]

>> Why do you point out that // comment goes until the end
>> of the line?
>
> Because code like posted does not compile:
>
> if (condition)
> { //succes } else { //failure }
>
> Was it too hard to write something that follows language rules?
>
> if (condition)
> { /*success*/ } else { /*failure*/ }
>
> Or why not? Just to be demonstratively sloppy, lousy, shoddy and
> dirty?

I think everyone here knows that // comments go to the end of
the line. The meaning of the code snippet was clear enough. Sure,
it was a bit sloppy, but why go out of your way to be insulting?

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Mr Flibble]

On 13/07/2020 18:50, Keith Thompson wrote:
> Öö Tiib <oot...@hot.ee> writes:
>> On Monday, 13 July 2020 03:28:28 UTC+3, woodb...@gmail.com wrote:
> [...]
>>> Why do you point out that // comment goes until the end
>>> of the line?
>>
>> Because code like posted does not compile:
>>
>> if (condition)
>> { //succes } else { //failure }
>>
>> Was it too hard to write something that follows language rules?
>>
>> if (condition)
>> { /*success*/ } else { /*failure*/ }
>>
>> Or why not? Just to be demonstratively sloppy, lousy, shoddy and
>> dirty?
>
> I think everyone here knows that // comments go to the end of
> the line. The meaning of the code snippet was clear enough. Sure,
> it was a bit sloppy, but why go out of your way to be insulting?

Insulting bigots is allowed.

[woodb...@gmail.com]

On Monday, July 13, 2020 at 1:05:01 PM UTC-5, Mr Flibble wrote:
> On 13/07/2020 18:50, Keith Thompson wrote:
> > Öö Tiib <oot...@hot.ee> writes:
> >> On Monday, 13 July 2020 03:28:28 UTC+3, woodb...@gmail.com wrote:
> > [...]
> >>> Why do you point out that // comment goes until the end
> >>> of the line?
> >>
> >> Because code like posted does not compile:
> >>
> >> if (condition)
> >> { //succes } else { //failure }
> >>
> >> Was it too hard to write something that follows language rules?
> >>
> >> if (condition)
> >> { /*success*/ } else { /*failure*/ }
> >>
> >> Or why not? Just to be demonstratively sloppy, lousy, shoddy and
> >> dirty?
> >
> > I think everyone here knows that // comments go to the end of
> > the line. The meaning of the code snippet was clear enough. Sure,
> > it was a bit sloppy, but why go out of your way to be insulting?
>
> Insulting bigots is allowed.
>

I refuse to be canceled by boneheads.


Brian
Ebenezer Enterprises

[Öö Tiib]

I am not certain about std::any ... maybe it is niche type
useful for someone?

Same is with std::valarray. May be someone needs specially
it and no full-blown linear algebra libraries like Armadillo
or Eigen?

Also there are some standard features that I never use not because
I don't want to but because major vendor like Microsoft never
fixes their implementation. For example their <ctime> is always
buggy in some way.

But I use ifs a lot and for what these needed such extension?
It helps with nothing. Just another "don't use" rule in coding
standard.

[Öö Tiib]

On Monday, 13 July 2020 20:50:32 UTC+3, Keith Thompson wrote:
> Öö Tiib <oot...@hot.ee> writes:
> > On Monday, 13 July 2020 03:28:28 UTC+3, woodb...@gmail.com wrote:
> [...]
> >> Why do you point out that // comment goes until the end
> >> of the line?
> >
> > Because code like posted does not compile:
> >
> > if (condition)
> > { //succes } else { //failure }
> >
> > Was it too hard to write something that follows language rules?
> >
> > if (condition)
> > { /*success*/ } else { /*failure*/ }
> >
> > Or why not? Just to be demonstratively sloppy, lousy, shoddy and
> > dirty?
>
> I think everyone here knows that // comments go to the end of
> the line. The meaning of the code snippet was clear enough. Sure,
> it was a bit sloppy, but why go out of your way to be insulting?

Sorry, if I insulted someone. Wasn't planned.

[Ian Collins]

On 14/07/2020 08:20, Öö Tiib wrote:
> On Monday, 13 July 2020 19:15:23 UTC+3, woodb...@gmail.com wrote:
>>
>> I don't think it's a garbage feature. I'd rather remove
>> std::any than the 2017 changes to 'if' statements.
>
> I am not certain about std::any ... maybe it is niche type
> useful for someone?

I have used it on occasion, most recently in a library used to read
kernel statistics from a C interface. Snippet:

std::any
NamedKstatsType::value() const
{
switch( stat->data_type )
{
case KSTAT_DATA_CHAR:
return stat->value.c;
case KSTAT_DATA_INT32:
return stat->value.i32;
case KSTAT_DATA_UINT32:

etc...

--
Ian.

[Keith Thompson]

Öö Tiib <oot...@hot.ee> writes:
[...]

> Also there are some standard features that I never use not because
> I don't want to but because major vendor like Microsoft never
> fixes their implementation. For example their <ctime> is always
> buggy in some way.

[...]

Can you be more specific about that? How is Microsoft's <ctime>
implementation buggy?

[Öö Tiib]

On Monday, 13 July 2020 23:34:07 UTC+3, Keith Thompson wrote:
> Öö Tiib <oot...@hot.ee> writes:
> [...]
> > Also there are some standard features that I never use not because
> > I don't want to but because major vendor like Microsoft never
> > fixes their implementation. For example their <ctime> is always
> > buggy in some way.
> [...]
>
> Can you be more specific about that? How is Microsoft's <ctime>
> implementation buggy?

For example issue closed as "not bug" 4 days ago while
07:26:18 +0100 and 09:26:18 +0200 are clearly unequal time values.

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
>> > Yes you are correct that the pointless optional init statement
>> > was added by C++17
>>
>> Pointless...
>>
>> I suppose the 'for' loop syntax is pointless too, because the exact same
>> thing can be achieved with a 'while' loop.
>
> It was added for backward compatibility with C so why to bother?
> Bart in comp.lang.c keeps critiquing it sometimes ... I don't care.
> Something with backward compatibility to seventies may look awkward,
> it is fine.

You make it sound that you find the for() look pointless. However,
I wouldn't be surprised if you use it all the time nevertheless.
Or do you always use 'while' loops because they achieve the same
thing?

> if ( type x = source(); x.has(some_property) ) x.do_something();
>
> Even Yoda did not have his reasoning so messed up.
> Better have block if you want to narrow the scope of x;
> no need to screw up its coherence:
>
> {
> value x = source();
> if ( x.has(certain_property) ) x.do_something();
> }

Yes, I'm sure that you also always use 'while' loops that do the
same thing as the equivalent 'for' loops, even though this adds
ugly-looking code blocks that don't seem attached to anything
and adds an extra indentation level.

[Öö Tiib]

On Tuesday, 14 July 2020 09:47:37 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> >> > Yes you are correct that the pointless optional init statement
> >> > was added by C++17
> >>
> >> Pointless...
> >>
> >> I suppose the 'for' loop syntax is pointless too, because the exact same
> >> thing can be achieved with a 'while' loop.
> >
> > It was added for backward compatibility with C so why to bother?
> > Bart in comp.lang.c keeps critiquing it sometimes ... I don't care.
> > Something with backward compatibility to seventies may look awkward,
> > it is fine.
>
> You make it sound that you find the for() look pointless. However,
> I wouldn't be surprised if you use it all the time nevertheless.
> Or do you always use 'while' loops because they achieve the same
> thing?

No. The "for" was first meant to be useful in situation where we
want to sequentially execute certain processing /for/ values in
certain sequence.

It is logically different from (but may implemented as subset of)
situations for what "while" was meant. On case of "while" we want
to repeat same processing (logically unconstrained of what) /while/
certain condition keeps being met.

Both can be used in situations very far away from what I described
above but doing so is not cooperative as it confuses readers and
so I do not like that. The change of standard extends "if" and
"switch" with something that even does not logically belong into
those ... perhaps to support more abuse.

>
> > if ( type x = source(); x.has(some_property) ) x.do_something();
> >
> > Even Yoda did not have his reasoning so messed up.
> > Better have block if you want to narrow the scope of x;
> > no need to screw up its coherence:
> >
> > {
> > value x = source();
> > if ( x.has(certain_property) ) x.do_something();
> > }
>
> Yes, I'm sure that you also always use 'while' loops that do the
> same thing as the equivalent 'for' loops, even though this adds
> ugly-looking code blocks that don't seem attached to anything
> and adds an extra indentation level.

You make it sound like you are sure that I always care about loop
iterator's life-time and what value it has when that lasts after
loop? You may be feel sure but you are mistaken. On vast majority
of cases it is totally unimportant.

[Keith Thompson]

Can you expand on that? What's the bug? What calls produce what
unexpected results? Do you have a link to a bug report?

[Öö Tiib]

OK, but that seems like taking value from tagged union and then
wrapping it back again into std::any. Do I understand it
correctly?
That makes sense when receiving end is already made to need
std::any. That can happen and reasons of it can be "any". :D
But I have observed that tagged unions (or std::variants) are
slightly more convenient and efficient to use than std::any.

[Ian Collins]

On 14/07/2020 20:35, Öö Tiib wrote:
> On Monday, 13 July 2020 23:32:36 UTC+3, Ian Collins wrote:
>> On 14/07/2020 08:20, Öö Tiib wrote:
>>> On Monday, 13 July 2020 19:15:23 UTC+3, woodb...@gmail.com wrote:
>>>>
>>>> I don't think it's a garbage feature. I'd rather remove
>>>> std::any than the 2017 changes to 'if' statements.
>>>
>>> I am not certain about std::any ... maybe it is niche type
>>> useful for someone?
>>
>> I have used it on occasion, most recently in a library used to read
>> kernel statistics from a C interface. Snippet:
>>
>> std::any
>> NamedKstatsType::value() const
>> {
>> switch( stat->data_type )
>> {
>> case KSTAT_DATA_CHAR:
>> return stat->value.c;
>> case KSTAT_DATA_INT32:
>> return stat->value.i32;
>> case KSTAT_DATA_UINT32:
>>
>> etc...
>
> OK, but that seems like taking value from tagged union and then
> wrapping it back again into std::any. Do I understand it
> correctly?

Yes.

> That makes sense when receiving end is already made to need
> std::any. That can happen and reasons of it can be "any". :D
> But I have observed that tagged unions (or std::variants) are
> slightly more convenient and efficient to use than std::any.

A variant may have been a better choice, but given the types used are
either integral types or std::string, I expect the efficiency should be
about the same.

--
Ian

[Öö Tiib]

On Tuesday, 14 July 2020 11:31:54 UTC+3, Keith Thompson wrote:
> Öö Tiib <oot...@hot.ee> writes:
> > On Monday, 13 July 2020 23:34:07 UTC+3, Keith Thompson wrote:
> >> Öö Tiib <oot...@hot.ee> writes:
> >> [...]
> >> > Also there are some standard features that I never use not because
> >> > I don't want to but because major vendor like Microsoft never
> >> > fixes their implementation. For example their <ctime> is always
> >> > buggy in some way.
> >> [...]
> >>
> >> Can you be more specific about that? How is Microsoft's <ctime>
> >> implementation buggy?
> >
> > For example issue closed as "not bug" 4 days ago while
> > 07:26:18 +0100 and 09:26:18 +0200 are clearly unequal time values.
>
> Can you expand on that? What's the bug? What calls produce what
> unexpected results? Do you have a link to a bug report?

Sorry. I felt I posted link.

<https://developercommunity.visualstudio.com/content/problem/1105670/stdstrftime-displays-timezone-utc-as-utc1-using-st.html>

There have been similar issues ...
<https://developercommunity.visualstudio.com/content/problem/434145/strftime-wcsftime-incorrect-time-zone-offset.html>
Unsure if it it is fixed and in what version.

May be that it is because of some logical inconsistency in standards.
The results on Linux, Mac and/or Windows are always different
somewhat. Before C++11 it was best to use custom, per-platform
code to achieve consistent transformations between text and time
values. Boost.Date-Time had also its quirks and inefficiencies.
After C++11 I have gradually started to use <chrono> with helpers
like that <https://github.com/HowardHinnant/date>.

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
> You make it sound like you are sure that I always care about loop
> iterator's life-time and what value it has when that lasts after
> loop? You may be feel sure but you are mistaken. On vast majority
> of cases it is totally unimportant.

Well, nobody is forcing you to declare a variable in the condition of
an 'if' statement. However, if the situation ever arises where that's
the handiest and most convenient thing to do, the feature is there.

[woodb...@gmail.com]

Amen.

[Real Troll]

On 14/07/2020 13:48, woodb...@gmail.com wrote:
>
> Amen.

I thought you were Jewish!

[Öö Tiib]

I do not find any place in my code where it is handy.
So as I do not see where it is handy (it certainly wasn't in OP
pseudocode) but see pile of ways how to abuse it I see it as
pointless feature. Implementations to implement that feature,
my tools to detect its usage and marking as misuse just added
pointless work for no gain.

[woodb...@gmail.com]

This guy gives some background on the word

https://duckduckgo.com/?q=amen+hebrew&t=hk&iar=videos&iax=videos&ia=videos&iai=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dhq9yt0RXTww

[woodb...@gmail.com]

The committee is increasingly daft, and 2020 C++ is a
disappointment to me so far, but this change to 'if' and
'switch' statements makes sense.


Brian

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
> my tools to detect its usage and marking as misuse just added
> pointless work for no gain.

Who forced you to do that, other than yourself?

[Ian Collins]

On 15/07/2020 01:03, Öö Tiib wrote:
> On Tuesday, 14 July 2020 14:28:24 UTC+3, Juha Nieminen wrote:
>> Öö Tiib <oot...@hot.ee> wrote:
>>> You make it sound like you are sure that I always care about loop
>>> iterator's life-time and what value it has when that lasts after
>>> loop? You may be feel sure but you are mistaken. On vast majority
>>> of cases it is totally unimportant.
>>
>> Well, nobody is forcing you to declare a variable in the condition of
>> an 'if' statement. However, if the situation ever arises where that's
>> the handiest and most convenient thing to do, the feature is there.
>
> I do not find any place in my code where it is handy.

Scope limitation?

if( const auto it {tests.find(key)}; it != tests.end() )
{
// do something with the iterator;
}

That was from some code I'm currently working on.

--
Ian.

[Öö Tiib]

Nothing. It feels to be pointless like rvalue reference to const
argument. Rvalue reference to const may be useful in rare case
that I do not have in actual code and declaring variables in
switch or if may be useful in rare case that I do not even
know of.