Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: The big three
83 views
Skip to first unread message
Richard Damon
Aug 28, 2016, 7:20:19 PM8/28/16
to
On 8/28/16 12:40 AM, Stefan Ram wrote:
> I found a slide in the Web:
>
> Special member functions - "The Big Four", "The Big Three"
>
> - default constructor (the fourth of The Big Four) -
> initializes a new object without any arguments
>
> - copy constructor - initializes a new object from an existing
> object of the same type
>
> - copy assignment - assigns from an object of the same type
>
> - destructor - cleaning up when an object cease to exist
>
> . But I believe that usually »The Big Three« are
> mentioned, not »The Big Four«. Why is this so?
>
> (The move operations have changed things a bit,
> but for this question one can assume C++03.)
>
One reason is that the presence of the 'Big Three' (or some of them)
does imply that you really MUST have a default constructor. Many object
types are not default constructable. You also don't need to worry about
a default constructor being implicitly defined, as the presence of the
copy constructor will block the implicit creation of the default
constructor.
On the other hand, the language says that unless you explicitly define a
copy constructor, an implicit one will be created.
The idea of the Big Three is that if you need to define one of these
members, you likely need to explicitly define the others, as they WILL
be created implicitly, and the definition is likely wrong. The default
constructor does not fall into this category.
> I found a slide in the Web:
>
> Special member functions - "The Big Four", "The Big Three"
>
> - default constructor (the fourth of The Big Four) -
> initializes a new object without any arguments
>
> - copy constructor - initializes a new object from an existing
> object of the same type
>
> - copy assignment - assigns from an object of the same type
>
> - destructor - cleaning up when an object cease to exist
>
> . But I believe that usually »The Big Three« are
> mentioned, not »The Big Four«. Why is this so?
>
> (The move operations have changed things a bit,
> but for this question one can assume C++03.)
>
One reason is that the presence of the 'Big Three' (or some of them)
does imply that you really MUST have a default constructor. Many object
types are not default constructable. You also don't need to worry about
a default constructor being implicitly defined, as the presence of the
copy constructor will block the implicit creation of the default
constructor.
On the other hand, the language says that unless you explicitly define a
copy constructor, an implicit one will be created.
The idea of the Big Three is that if you need to define one of these
members, you likely need to explicitly define the others, as they WILL
be created implicitly, and the definition is likely wrong. The default
constructor does not fall into this category.
Öö Tiib
Aug 29, 2016, 2:30:28 AM8/29/16
to
functions that are detectable to be likely wrong by so simple check?
The checks about if something is "trivial" or "standard layout" seem
far more complicated. Also, if it was design error then why it
hasn't been repaired?
Vir Campestris
Aug 29, 2016, 4:07:49 PM8/29/16
to
On 29/08/2016 07:30, Öö Tiib wrote:
> Also, if it was design error then why it
> hasn't been repaired?
Most likely because it would break too much existing code. We have a lot
> Also, if it was design error then why it
> hasn't been repaired?
of old baggage in this industry.
Andy
Juha Nieminen
Sep 5, 2016, 2:23:00 AM9/5/16
to
Öö Tiib <oot...@hot.ee> wrote:
> Does anyone know why the language was designed to create implicitly
> functions that are detectable to be likely wrong by so simple check?
> The checks about if something is "trivial" or "standard layout" seem
> far more complicated. Also, if it was design error then why it
> hasn't been repaired?
There are valid situations where you may want to define only one of them
> Does anyone know why the language was designed to create implicitly
> functions that are detectable to be likely wrong by so simple check?
> The checks about if something is "trivial" or "standard layout" seem
> far more complicated. Also, if it was design error then why it
> hasn't been repaired?
without any need to define the others (ie. not defining the others will
not break anything).
On that subject, one feature I would like to see is the ability to call
the compiler-generated default implementation from your own. (This could
be especially useful in copy constructors and assignment operators.)
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Öö Tiib
Sep 5, 2016, 4:29:45 AM9/5/16
to
On Monday, 5 September 2016 09:23:00 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > Does anyone know why the language was designed to create implicitly
> > functions that are detectable to be likely wrong by so simple check?
> > The checks about if something is "trivial" or "standard layout" seem
> > far more complicated. Also, if it was design error then why it
> > hasn't been repaired?
>
> There are valid situations where you may want to define only one of them
> without any need to define the others (ie. not defining the others will
> not break anything).
In one of such situations we would need to explicitly default the others
> Öö Tiib <oot...@hot.ee> wrote:
> > Does anyone know why the language was designed to create implicitly
> > functions that are detectable to be likely wrong by so simple check?
> > The checks about if something is "trivial" or "standard layout" seem
> > far more complicated. Also, if it was design error then why it
> > hasn't been repaired?
>
> There are valid situations where you may want to define only one of them
> without any need to define the others (ie. not defining the others will
> not break anything).
if we wanted those. It seems rather slight inconvenience. Far better than
current situation where we have the likely wrong implicit defaults unless
we explicitly delete those.
>
> On that subject, one feature I would like to see is the ability to call
> the compiler-generated default implementation from your own. (This could
> be especially useful in copy constructors and assignment operators.)
are virtual functions. It feels quite cheap to achieve comparable with
virtual function call instead of non-virtual. Unfortunately there's
still some months left until Christmas. ;)
woodb...@gmail.com
Sep 7, 2016, 12:44:46 AM9/7/16
to
Had a very shiny nose
And if you ever saw it,
You would even say it glows,
And all of the other reindeer
Used to laugh and call him names,
They never let poor Rudolph
Join in any reindeer games,
Brian
Ebenezer Enterprises - If you can't join 'em, beat 'em.
http://webEbenezer.net
0 new messages