Hello Andrey,

Once again, thank you for your thoughts.

I believe that your views boil down to three fundamental questions:

Is the enhancement necessary? I agree that it is not.

Is the enhancement generally useful? I believe that it is. Of course, this
is subjective. Experienced C++ programmers are used to exploring the
ramifications of classes. I suggest that this can also be viewed as a
barrier. The compiler purposefully introduces behavior that can be
undesirable. Consider all the grief that the "usual integer promotions" has
caused.

Will the enhancement cause undesirable behavior and/or damage? I believe
that it does not. Of course, the topic of destruction is the big one. I do
not feel so strongly about it to suggest that this must be an all or nothing
implementation. To me, that is for a future discussion.

Regards,
Steve

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of
Andrey Semashev via Std-Proposals
Sent: Tuesday, November 12, 2019 10:44
To: std-proposals_at_[hidden]
Cc: Andrey Semashev <andrey.semashev_at_[hidden]>
Subject: Re: [std-proposals] explicit class

On 2019-11-12 19:19, Steve Weinrich wrote:
>
> Consider this case (note that this is true for most classes that refer
> to
> resources):
>
> Class OperatingSystemFile {
> public:
> // Various interesting stuff
> private:
> F mTheFile; // The type of F is something specific to the OS };
>
> What does "operator == ()" mean? There are (at least) three
> reasonable
> definitions: 1) Do not allow it; 2) We are referring to the same file;
> 3) Two different files have the same content. The default
> implementation is a binary comparison of "mTheFile". That definition
> does not match any of the above three possibilities. In fact, on Unix
> and Windows systems, it could never be true because file handles are not
duplicated.

All that depends on what F is. If it's a (shared) pointer to some structure
that contains data related to the file (e.g.
shared_ptr<FILE>), comparison of the pointer values makes perfect sense.

But I wasn't suggesting that the default comparison operators are always
what you want. Just like with other functions, you are free to define your
own behavior. It's just you often have to define these operators manually
and in a very obvious and tedious way - by applying the comparison operator
to each member of the class and returning the accumulated result.

> "People normally don't write a program that never terminates."
>
> When talking about C++, we must consider more than just the "normal" uses.

Sure, but that doesn't include unrealistic use cases. And, as others have
noted, in C++ a program is expected to terminate.

> "Global objects must be destroyed at program termination, so having
> their destructor deleted would be a compile time error."
>
> Consider a POD.

It doesn't matter, it still has a destructor, even if trivial. Marking it
deleted will not make the type non-POD, but it will make the type unusable
for global (and most other) objects.

> However, the compile time error
> would be beneficial. This is because it would make the programmer
> aware that there may be a situation that they did not consider! Once
> again providing some help to a less-than-perfect programmer.

I'm sorry, I don't see how this would be beneficial. Is that
less-than-perfect programmer unaware that a destructor needs to be called
for a global object?

> On every computer I have used (since 1972) some hardware is eventually
> mapped to fixed memory locations. On Unix and Windows systems, this
> is in the kernel. On todays "little" processors, (like the Arduino),
> this is in user space because that is the only space. There is a
> technique to describe this memory (using placement new) that allows
> one to describe the bits in a nice way.
>
> class HardwareResource {
> public:
> uint8_t mControl1 : 3;
> uint8_t mData1 : 5;
> };
>
> HardwareResource & hr = * new (0x500) HardwareResource; // 0x500 is
> O/S provided. We use a reference because there is nothing to delete!
>
> "HardwareResource" is a perfect candidate for "explicit class". Its
> sole purpose is to describe some memory that cannot be allocated or
destroyed.
> There are no default operations that make any sense.

You at least need a default constructor to make the placement new compile.

Also, I'm not sure placement new (and bit fields) is the best interface for
working with memory-mapped hardware. Such mapped regions often have special
conventions wrt. caching, memory ordering and allowed access alignment and
granularity. I wouldn't trust a compiler to generate instruction sequences
for working on these bit fields.

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals