«

If we provide a any non-default ctor, then the compiler doesn't
supply the default ctor even if needed. This behaviour is due the
following reason as per my understanding:
It is for DISALLOWING an object to be created without arguments.
For example, for a class named Test, creating
Test obj;
may not have to be allowed for the particular class Test. Under this
circumstance, we expect a provision from the compiler, not to
supply the default ctor.
Is my understanding correct ?

Or is there any other reason for the compiler not providing the
default ctor when we have defined some ctor ?

Kindly clarify.

Thanks
V.Subramanian

, India wrote:
> If we provide a any non-default ctor, then the compiler doesn't
> supply the default ctor even if needed. This behaviour is due the
> following reason as per my understanding:
> It is for DISALLOWING an object to be created without arguments.

This needs to be expressed more carefully: It is for disallowing object creation
using a constructor that has been generated by the compiler. Altough this
statement may seem not to be different from the original statement of yours, it
encloses the case where a explicitly declared constructor has default values for
its arguments:
class Test
{
Test (int i = 2);
};
Here we can construct an object without passing arguments but it is still not
the default constructor.

> For example, for a class named Test, creating
> Test obj;
> may not have to be allowed for the particular class Test. Under this
> circumstance, we expect a provision from the compiler, not to
> supply the default ctor.
> Is my understanding correct ?

I very much think so.

Regards,
Stuart

On Nov 26, 8:00 am, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.com> wrote:
> If we provide a any non-default ctor, then the compiler doesn't
> supply the default ctor even if needed. This behaviour is due the
> following reason as per my understanding:
> It is for DISALLOWING an object to be created without arguments.
> For example, for a class named Test, creating
> Test obj;
> may not have to be allowed for the particular class Test. Under this
> circumstance, we expect a provision from the compiler, not to
> supply the default ctor.
> Is my understanding correct ?

Not really. The compiler supplied default constructor is more
or less a no-op. Presumably, if you provide a constructor (any
constructor), then a no-op is not an appropriate initialization,
so the compiler won't generate one.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Nov 26, 12:49 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Nov 26, 8:00 am, "subramanian10...@yahoo.com, India"
>
> <subramanian10...@yahoo.com> wrote:
> > If we provide a any non-default ctor, then the compiler doesn't
> > supply the default ctor even if needed. This behaviour is due the
> > following reason as per my understanding:
> > It is for DISALLOWING an object to be created without arguments.
> > For example, for a class named Test, creating
> > Test obj;
> > may not have to be allowed for the particular class Test. Under this
> > circumstance, we expect a provision from the compiler, not to
> > supply the default ctor.
> > Is my understanding correct ?
>
> Not really. The compiler supplied default constructor is more
> or less a no-op.

Not when data members and base classes declare none-trivial default
ctors.

> Presumably, if you provide a constructor (any
> constructor), then a no-op is not an appropriate initialization,
> so the compiler won't generate one.

If you provide a constructor (any constructor), then a compiler
generated default constructor might bring about rational errors.So you
must decide whether or not to provide a default ctor and accept the
responsability yourself.

regards,
FM.

terminator wrote:

>
> Not when data members and base classes declare none-trivial default
> ctors.

Actually, even more so in that case. If the data members have explicit
default constructors, then the constructor the user provides
T() { }
to replace the implicitly generated one, is very trivial.
The only time it's not trivial is where the default constructors of
the sub classes and members do not have the proper initialization
behavior.


Where the wheels come off is the inane C++ concept of the
"we don't always initialize POD types" behavior. The value
initializaiton is a half-assed attempt to reign in this
behavior without addressing the underlying problem.

On Nov 26, 3:55 pm, Ron Natalie <r...@spamcop.net> wrote:
> terminator wrote:
>
> > Not when data members and base classes declare none-trivial default
> > ctors.
>
> Actually, even more so in that case. If the data members have explicit
> default constructors, then the constructor the user provides
> T() { }

Not for all cases:just take STL classes : zeroing is not 'no op'.

regards,
FM.

terminator wrote:
> On Nov 26, 3:55 pm, Ron Natalie <r...@spamcop.net> wrote:
>> terminator wrote:
>>
>>> Not when data members and base classes declare none-trivial default
>>> ctors.
>> Actually, even more so in that case. If the data members have explicit
>> default constructors, then the constructor the user provides
>> T() { }
>
> Not for all cases:just take STL classes : zeroing is not 'no op'.
>
> regards,
> FM.
I have no clue what you are talking about. But STL or class or
otherwise, if all the subobject have proper default constructors,
thats all the default constructor need do (and it is identical
to the one the compiler would generate).

On Nov 26, 2:49 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Nov 26, 8:00 am, "subramanian10...@yahoo.com, India"
>
> <subramanian10...@yahoo.com> wrote:
> > If we provide a any non-default ctor, then the compiler doesn't
> > supply the default ctor even if needed. This behaviour is due the
> > following reason as per my understanding:
> > It is for DISALLOWING an object to be created without arguments.
> > For example, for a class named Test, creating
> > Test obj;
> > may not have to be allowed for the particular class Test. Under this
> > circumstance, we expect a provision from the compiler, not to
> > supply the default ctor.
> > Is my understanding correct ?
>
> Not really. The compiler supplied default constructor is more
> or less a no-op. Presumably, if you provide a constructor (any
> constructor), then a no-op is not an appropriate initialization,
> so the compiler won't generate one.
>
> --
> James Kanze (GABI Software)

Then shouldn't the same reasoning be applied to the
copy ctor ? ie Take the copy ctor for example. Suppose we
have provided some ctor and not the copy ctor. Then the
compiler shouldn't supply the copy ctor too, even if it
is needed. But it provides the copy ctor. What is the
difference between the two scenarios ?

I am unable to understand.

Kindly clarify my doubt.

Please excuse me for asking it again.

Thanks
V.Subramanian

On Nov 27, 7:32 am, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.com> wrote:
> On Nov 26, 2:49 pm, James Kanze <james.ka...@gmail.com> wrote:
> > On Nov 26, 8:00 am, "subramanian10...@yahoo.com, India"

> > <subramanian10...@yahoo.com> wrote:
> > > If we provide a any non-default ctor, then the compiler doesn't
> > > supply the default ctor even if needed. This behaviour is due the
> > > following reason as per my understanding:
> > > It is for DISALLOWING an object to be created without arguments.
> > > For example, for a class named Test, creating
> > > Test obj;
> > > may not have to be allowed for the particular class Test. Under this
> > > circumstance, we expect a provision from the compiler, not to
> > > supply the default ctor.
> > > Is my understanding correct ?

> > Not really. The compiler supplied default constructor is
> > more or less a no-op. Presumably, if you provide a
> > constructor (any constructor), then a no-op is not an
> > appropriate initialization, so the compiler won't generate
> > one.

As has been pointed out, this is a (intentional) simplification.
The rationale here really does concern simple objects, made up
of basic types.

> Then shouldn't the same reasoning be applied to the
> copy ctor ?

Not necessarily, because the copy constructor copies everything.
It's never a no-op, so all elements of the target are
initialized.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Nov 26, 5:39 pm, Ron Natalie <r...@spamcop.net> wrote:
> terminator wrote:
> > On Nov 26, 3:55 pm, Ron Natalie <r...@spamcop.net> wrote:
> >> terminator wrote:
>
> >>> Not when data members and base classes declare none-trivial default
> >>> ctors.
> >> Actually, even more so in that case. If the data members have explicit
> >> default constructors, then the constructor the user provides
> >> T() { }
>
> > Not for all cases:just take STL classes : zeroing is not 'no op'.
>
> > regards,
> > FM.
>
> I have no clue what you are talking about. But STL or class or
> otherwise, if all the subobject have proper default constructors,
> thats all the default constructor need do (and it is identical
> to the one the compiler would generate).

Do I have to declare a default constructor that does not do anything?
Vector provides a default ctor that zeros the size and probably the
capacity,so it is not 'no op'.

regards,
FM.