Re: [lmi] depr.impldec

[Greg Chicares]

On 7/11/22 21:55, Vadim Zeitlin wrote:
> On Mon, 11 Jul 2022 19:28:50 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 7/10/22 12:29, Vadim Zeitlin wrote:
> GC> [...]
> GC> >  FWIW here is my personal strategy for defining the class' special
> GC> > functions: there are several categories of classes
> GC> > 
> GC> > 1. Value-like: for them copy special functions and dtor are explicitly
> GC> >    defaulted. Move special functions are omitted, and are not available.
> GC> 
> GC> Already I'm struggling here, but I think the issue is nomenclature.
> GC> 
> GC> Is this...
> GC> 
> GC> class custom_string
> GC> {
> GC>   public:
> GC>     custom_string(std::string const& arg) : s_(arg) {}
> GC>     custom_string() = default;
> GC> 
> GC>     custom_string& operator=(std::string const& arg) {s_ = arg; return 
> *this;}
> GC>     std::string const& value() const {return s_;}
> GC> 
> GC>   private:
> GC>     std::string s_;
> GC> };
> GC> 
> GC> a "value-like" class?
> 
>  Yes, it is, but it's also "container-like", where for me the difference is
> that non-container values are cheap to copy while containers are not
> necessarily. So for cheap to copy values move operations don't really
> provide any gain, and can be omitted -- but can also be defaulted, as here.

I'm confused enough that, for now at least, I'm going to pay no attention
to whether data members are cheap to copy, and focus on whether it's
lawful to copy them. Cheapness is not a concept I can afford right now.

I need a mental algorithm to decide what special members to default,
delete, or not declare. Obviously whatever algorithm I was using was
wrong, or has become wrong (or at least deprecated, which to me is wrong).
I have a strong sense that a dominant input to this algorithm is the
complexion of the class's data members (the nature of any base class is
another, but for now I'm focusing on data members). My theory is that
if all data members have all four copy and move operations, then I should
be able to default all four operations, absent some spoiling factor, e.g.:
 - any const data member spoils default assignments and moves
 - a base class that doesn't have all four special members is a spoiler

AFAICT, the whitelist of non-spoiling data members includes:
 - primitive non-pointer types like int
 - common library types like string, vector, map, pair
 - shared_ptr, even shared_ptr<foo const>
 - unique_ptr
and the blacklist includes:
 - const members (volatile, too, but I don't think lmi has any)
 - reference members
 - raw pointers, including pointers-to-member

I'd like to have a generic name for a class that contains only
whitelisted data members (ignoring base-class complications for now).
There are so many names for so many concepts:
  {trivial, POD, value-like, ...}
and, if my idea is valid at all, someone must have devised a better
name than class-for-which-all-defaulted-special-members-work-reliably.

> GC> For this class, would you follow guideline (1) above, making
> GC> the move special functions unavailable?
> 
>  No, I'd default them.

Good to hear.

> Although if such strings are usually short this
> wouldn't make much, or even any, difference, because moving a string using
> short string optimization is not faster than copying it (might be slower,
> actually, although I doubt the difference is going to be noticeable).

By the time I'm smart enough to optimize that manually, e.g.:
  foo(foo&&) = delete; // copying is faster than moving because [...]
compilers will have become smart enough to do it better automatically.

> GC> I think it already does the right thing by declaring no
> GC> special member function except a default ctor. The default
> GC> implementations of the other five special operations can't
> GC> be wrong, because std::string is movable and copyable.
> GC> And the move operations may be useful.
> 
>  Yes, I agree, my rules in the previous message were over-simplified. Move
> operations should be enabled/defaulted for the value-like classes if
> copying them can be expensive and, in the absence of any other information,
> this certainly could be the case for custom_string here.
Would you not use the Rule of Zero then? Class custom_string above
seems almost perfect to me as is, and I think it would become less
perfect if we added five explicitly defaulted members to it.