"owner-concept" or "GSL" ...?

[Bonita Montero]

Can anyone explain me what the "owner-concept" or "GSL" of C++17 is?

--
http://facebook.com/bonita.montero/

[Alf P. Steinbach]

On 02.02.2017 18:49, Bonita Montero wrote:
> Can anyone explain me what the "owner-concept" or "GSL" of C++17 is?

Thanks for those pointers.

I can't find anything about it but I did find

<url: http://honermann.net/blog/?p=3>
“Why Concepts didn’t make C++17”

dated 6th of March 2016.

Has the committee turned again on this, or are perhaps the things you
refer to part of Eric Niebler's ranges proposal?


Cheers!,

- Alf

[Richard]

[Please do not mail me a copy of your followup]

Bonita Montero <Bonita....@gmail.com> spake the secret code
<o6vrfn$gme$1...@news.albasani.net> thusly:

>Can anyone explain me what the "owner-concept" or "GSL" of C++17 is?

Are you talking about the Guideline Support Library?
<https://github.com/Microsoft/GSL>

...and how it relates to who owns the memory addressed by a pointer?

<https://github.com/isocpp/CppCoreGuidelines>
<https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#i11-never-transfer-ownership-by-a-raw-pointer-t>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Bo Persson]

No recent changes.

But as the ranges proposal requires (pun intended?) concepts, that
proposal will be delayed as well.


Bo Persson

[Alf P. Steinbach]

On 02.02.2017 21:57, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Bonita Montero <Bonita....@gmail.com> spake the secret code
> <o6vrfn$gme$1...@news.albasani.net> thusly:
>
>> Can anyone explain me what the "owner-concept" or "GSL" of C++17 is?
>
> Are you talking about the Guideline Support Library?
> <https://github.com/Microsoft/GSL>

Hm, I see code like this:


// final_act allows you to ensure something gets run at the end of a scope
template <class F>
class final_act
{
public:
explicit final_act(F f) noexcept : f_(std::move(f)), invoke_(true) {}

final_act(final_act&& other) noexcept : f_(std::move(other.f_)),
invoke_(other.invoke_)
{
other.invoke_ = false;
}

final_act(const final_act&) = delete;
final_act& operator=(const final_act&) = delete;

~final_act() noexcept
{
if (invoke_) f_();
}

private:
F f_;
bool invoke_;
};


I don't like that they've renamed ScopeGuard to something else. More
names to learn, not easily recognized, and the new name points in a
misleading direction.

I don't like that there's no reference to Marginean and Alexandrescu.

I don't like that they've removed the trivial but important `dismiss`
method. That's like wanton destruction, in the usual Microsoft style.
Apparently the authors don't understand the concept here. :(

I don't like that they've simply added `noexcept` to the destructor,
apparently just for conformity's sake. For example, `final_act`
augmented with a `dismiss` method can't be used to implement a
transaction, when roll-back can fail, without an elaborate scheme for
propagating an exception across the `noexcept` barrier. The original
ScopeGuard wasn't perfect in that way, either, because it just
unreasonably /swallowed/ exceptions from the cleanup function (as I
recall Andrei didn't see that as a problem at all when I asked him about
it), but at least it didn't default to crashing the program, preventing
larger scale cleanup, on a little local cleanup failure.

If this library becomes widely used, as is possible, then it will again
be that competent people can't just rely on the common infra-structure
but must re-create parts of it to have something practically useful.


[snip]

Cheers!,

- Alf

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<o710ti$lkk$1...@dont-email.me> thusly:

>I don't like that they've renamed ScopeGuard to something else. [...]
>I don't like that [...]
>I don't like that [...]
>I don't like that [...]

You should be opening issues on their github instead of complaining
here, a place they are unlikely to be reading.

[Alf P. Steinbach]

On 04.02.2017 23:29, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
> <o710ti$lkk$1...@dont-email.me> thusly:
>
>> I don't like that they've renamed ScopeGuard to something else. [...]
>> I don't like that [...]
>> I don't like that [...]
>> I don't like that [...]
>
> You should be opening issues on their github

That's a noble thought, to help them do the Right Thing™.

But I have a long history of helping Microsoft, including numerous MSVC
(and other product) bug reports, an unending stream of such, and that I
was a Microsoft “Most Valued Professional” in Visual C++ in 2012.

And my experience is that Microsoft folks /generally/ prefer denial
mode, to wit, Windows Explorer's design level bug where it scrolls away
a list you're trying to double click in (oh It's By Design™, yeah
right), but that their compiler team generally are more reality-oriented
and often fix bugs I report, surprisingly fast. Except in one special
case where they also went into denial mode. Then one old-timer there who
did the original code design took charge and forced them. :)

So, before engaging in trying to help Microsoft, one should have a fair
understanding of what that entails, negotiating a steep wall of denial.

That can take up much of one's time, as well as some emotional attrition
cost.

> instead of complaining here, a place they are unlikely to be
> reading.

Now that's silly: I was communicating to clc++ folks. Like you.

I see no reason yet to stop doing that. ;-)


Cheers!,

- Alf