paradox when constructor of an pure abstract base class called?

[ypjofficial]

Hello All,

I have following doubt..

class abstractclass
{
public:
abstractclass() {}
virtual void method()=0;
};

class concreteclass:p ublic abstractclass
{
public:
concreteclass() {}
void method(){}
};

void main()
{

concreteclass c;
}

now when I create the object of concreteclass, the constructor of
abstractclass will be called.and as per the logic constructors are
called while creating the object,object of abstractclass is being
created..so how come we can create an object of a abstract class?
or to put in another way is there any paradox when the constructor of
an abstract class gets called?

Thanks and Regards,
Yogesh Joshi
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Ralph]

"Francis Glassborow" <fr*****@robint on.demon.co.uk> wrote in message
news:Dm******** ******@robinton .demon.co.uk...

In article <MP************ *************** ***@arkansas.ne t>, Ralph
<nt************ *@yahoo.com> writes

It is also a reality that all implemented c runtimes today only accept a
'int' return to the OS (might not always be true - it would be up to the
vendor) and if one is not provided the implemenation dependent 'main()'
provides one for you. So the 'void' or 'int' return is only to provide thecompiler with a clue as to whether or not to generate a warning or error ifyour code does or doesn't include a return statement. Which is identical andproper compiler behavior when syntax-checking any function.

No, C++ explicitly allows the omission of a return statement from main
and specifies that in such a case 'falling off the end of main' is
implicitly a 'return 0'

There is absolutely no reason for not specifying the correct return type
(it even saves you a keystroke:-)

That is also a very interesting 'exception' for main(). Why should main() be
excluded from normal return checking?

-ralph

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Francis Glassborow]

In article <QK************ ********@arkans as.net>, Ralph
<nt************ *@yahoo.com> writes

No, C++ explicitly allows the omission of a return statement from main
and specifies that in such a case 'falling off the end of main' is
implicitly a 'return 0'

There is absolutely no reason for not specifying the correct return type
(it even saves you a keystroke:-)

That is also a very interesting 'exception' for main(). Why should main() be
excluded from normal return checking?

Basically because it isn't a function in C++ but an entry point for a
program. Of course we could have just made it like a ctor and have no
return type but we were thinking of C compatibility and the advantage of
providing a mechanism for a status return.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[kanze]

Ralph wrote:

"Francis Glassborow" <fr*****@robint on.demon.co.uk> wrote in
message news:Dm******** ******@robinton .demon.co.uk...

In article <MP************ *************** ***@arkansas.ne t>, Ralph
<nt************ *@yahoo.com> writes

It is also a reality that all implemented c runtimes today
only accept a 'int' return to the OS (might not always be
true - it would be up to the vendor) and if one is not
provided the implemenation dependent 'main()' provides one
for you. So the 'void' or 'int' return is only to provide
the compiler with a clue as to whether or not to generate a
warning or error if your code does or doesn't include a
return statement. Which is identical and proper compiler
behavior when syntax-checking any function.

Not really. The point is that a program has to return a value
to the operating system somehow when it terminates. And int (or
a subset of int values) seems to be the universal type for this,
although on some systems, a 0 value was used to indicate failure
(whereas under Unix or Windows, 0 indicates success); on such
systems, the runtime will have to map the return values to
something else, since the standard requires return 0 to signify
success.

I don't quite understand your tirade about this: Windows and
Unix are fully identical in this respect.

In C, what often happened was that the program would call exit()
from some deeply nested function, and thus never "return" from
main. In C++, this is frowned upon, since it means that
destructors of the local variables are not called.

And of course, there are programs which never terminate
normally. I've worked on a lot of programs for Unix which are
automatically started in the initialization phase of booting,
and never stop. Arguably, "void main" makes sense for such
programs, but they seem to be more common under Unix than under
Windows.
No, C++ explicitly allows the omission of a return statement
from main and specifies that in such a case 'falling off the
end of main' is implicitly a 'return 0' There is absolutely no reason for not specifying the correct
return type (it even saves you a keystroke:-)

That is also a very interesting 'exception' for main(). Why
should main() be excluded from normal return checking?

Good question. The standard says that falling off the end of
main() is the equivalent of returning 0, and falling off the end
of any other function is undefined behavior.

Generally speaking, however, it's pretty rare that just
returning zero is appropriate behavior. You normally want to
inform the system whether the program has failed or not, so it
can take appropriate actions.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]