By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,193 Members | 826 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,193 IT Pros & Developers. It's quick & easy.

Abstract and concrete classes in c++

P: n/a
What are abstract classes and concrete classes
Jul 23 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a

Anitha wrote:
What are abstract classes and concrete classes


An abstract class is one which defines an interface, but it may not
provide implementations for all its member functions. Generally an
abstract class is used as the base class from which other classes are
derived. The derived class provides implementations for the member
functions that are not implemented in the base class.
A derived class that implements all the missing functionality is called
a concrete class

Jul 23 '05 #2

P: n/a
A concrete class is used to define a useful object that can be
instantiated as an automatic variable on the program stack. The
implementation of a concrete class is defined. The concrete class is
not intended to be a base class and no attempt to minimize dependency
on other classes in the implementation or behavior of the class

Jul 23 '05 #3

P: n/a

Anitha wrote:
What are abstract classes and concrete classes

Get a good C++ book and study it before posting...

Jul 23 '05 #4

P: n/a

<ta*************@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
A concrete class is used to define a useful object that can be
instantiated as an automatic variable on the program stack. The
implementation of a concrete class is defined. The concrete class is
not intended to be a base class


No, this is not true ... concrete classes can certainly be used as base
classes in a properly designed C++ program. A concrete class typically
represents an particular implementation of the concepts expressed in a given
abstract interface class. However, it may be appropriate to implement only
part of the interface in a particular concrete class, which will then be
used as a base class for types further down the hierarchy. It all depends
on what you want to do.

Advice to the OP: google the subject line, and then check out the book
reviews at www.accu.org and buy a book to help you further.

HTH,

Dave Moore
Jul 23 '05 #5

P: n/a
Dave Moore wrote:

[ ... ]
No, this is not true ... concrete classes can certainly be used as base classes in a properly designed C++ program.


How do you implement operator= safely for this situation?

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jul 23 '05 #6

P: n/a

"Jerry Coffin" <jc*****@taeus.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
Dave Moore wrote:

[ ... ]
No, this is not true ... concrete classes can certainly be used as

base
classes in a properly designed C++ program.


How do you implement operator= safely for this situation?
Jerry.


I'm lost as to what you're trying to get at here. What problem do you
foresee with implementing the = operator for non-abstract classes? I have
many classes that have no pure virtual functions. Yet I implement the =
operator wherever I need it. How are the two issues related?

-Howard

Jul 23 '05 #7

P: n/a

"Jerry Coffin" <jc*****@taeus.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
Dave Moore wrote:

[ ... ]
No, this is not true ... concrete classes can certainly be used as

base
classes in a properly designed C++ program.


How do you implement operator= safely for this situation?


Well, if your base class has a copy assignment that can throw, then you
cannot write a copy-assignment operator that satisfies the "strong
guarantee" wrt exception safety. There is of course also a item in Scott
Meyers "More Effective C++" entitled "Make all non-leaf classes abstract",
which refutes my claim. So, I probably over-qualified my initial statement
by saying "properly designed C++ program", because strong exception safety
might be a requirement for "proper design" in many cases.

The fact is that I myself do not require the strong guarantee for my own
applications (scientific, numerical programs for which I am currently the
only user), and so I don't always think in terms of strong exception safety.
I will consider myself reprimanded 8*).

Actually this brings up a question ... If all of the data members in a class
(including any base classes) are statically allocated objects of built-in
type (i.e. no pointers or ctors), then does the implicitly generated copy
assignment operator implicitly provide the strong guarantee? Or even
better, the no-throw guarantee? It seems like it should, because the "only
thing that can go wrong" during construction in such a case is a stack
overflow (in which case we are dead anyway), or am I oversimplifying things.

Dave Moore
Jul 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.