Can an interface in C++ have non virtual functions ?
or
An interface in C++ can contain only non virtual function (proto types)?
Generally an "interface" class (in just about all OO languages) is a class with just an interface, no data and no implementation.
In C++ such a class is a class with only pure abstract functions, so no you can't have an "interface" class in C++ if you have non-virtual functions.
C++ does not have interfaces per se. Thus no restrictions are imposed on them.
Abstract classes are usually used to represent interfaces. It is a matter of convention whether you define default implementations for virtual methods and allow final methods in interface-like classes.
Related
If I have a class defined as :
// foo.h
class Foo
{
public:
virtual void GetFoo();
}
And I want a TForm to inherit from it, for example
class TFMainWindow : public TForm, public Foo
{
...
}
I get the error
[bcc32c Error] TFMainWindow.h(36): Delphi style classes have to be derived from Delphi style classes
How do I rsolve this issue?
TForm derives from TObject, which is a "Delphi-style class", ie it is implemented in Delphi pascal, not in C++. in Delphi, TObject is the root of all class object instances.
Delphi does not support multiple inheritance of classes, like C++ does. Only single inheritance. A Delphi class can have only 1 base class at most. But, it can implement multiple interfaces.
So, in C++Builder, when a C++ class has TObject as an ancestor, any other non-base ancestors MUST be interfaces only, which your Foo is not. An interface in this case is any class that has no data members, and only pure virtual methods and __property declarations are allowed.
If Foo::GetFoo() were a pure virtual method instead, then your code would work as expected, eg:
class Foo
{
public:
virtual void GetFoo() = 0;
};
class TFMainWindow : public TForm, public Foo
{
...
public:
void GetFoo();
...
};
This is simply a limitation of how C++ and Delphi interact with each other.
This is documented behavior:
C++ and Delphi Class Models: Inheritance and Interfaces
Unlike C++, the Delphi language does not support multiple inheritance. Any classes that you create that have RTL ancestors inherit this restriction. That is, you can not use multiple base classes for a Delphi style C++ class, even if the RTL class is not the immediate ancestor.
Using Interfaces Instead of Multiple Inheritance
For many of the situations where you would use multiple inheritance in C++, Delphi code makes use of interfaces instead. There is no C++ construct that maps directly to the Delphi concept of interface. An Delphi interface acts like a class with no implementation. That is, an interface is like a class where all the methods are pure virtual and there are no data members. While an Delphi class can have only a single parent class, it can support any number of interfaces. Delphi code can assign a class instance to variables of any of those interface types, just as it can assign the class instance to a variable of any ancestor class type. This allows polymorphic behavior for classes that share the same interface, even if they do not have a common ancestor.
In C++Builder, the compiler recognizes classes that have only pure virtual methods and no data members as corresponding to Delphi interfaces. Thus, when you create a Delphi style class, you are permitted to use multiple inheritance, but only if all of the base classes except the one that is a RTL or Delphi style class have no data members and only pure virtual methods.
Note: The interface classes do not need to be Delphi style classes; the only requirement is that they have no data members and only pure virtual methods.
Differences in object models between Delphi and C++ is also why C++ classes that are derived from TObject MUST be constructed in dynamic memory with new, even though C++ normally allows classes to be constructed in static/automatic memory without the use of new.
When and Why to use abstract classes/methods?
When creating a class library which will be widely distributed or reused—especially to clients, use an abstract class in preference to an interface; because, it simplifies versioning. This is the practice used by the Microsoft team which developed the Base Class Library. ( COM was designed around interfaces.) Use an abstract class to define a common base class for a family of types. Use an abstract class to provide default behavior. Subclass only a base class in a hierarchy to which the class logically belongs.
I did not understand the explanation in the above quote. Please explain why should an abstract class be used for creating a class library?
You should read articles of such kind very carefully. As I Understood, the main part of article is dedicated to c# language. In terms of such language there is big difference between interfaces and abstract classes. For example, interfaces in terms of c# language is just set of "pure" virtual methods (they cannot have definition within interface, only classes can implement it). Interfaces cannot have constructors. Abstract classes can have constructors. Moreover, c# does not support multiple inheritance ( as opposite to c++ language). In such way, c# interfaces and abstract classes look very different than c++'s one
It might be a silly question but I never saw a question about it or read about it.
Imagine that we have this:
class Numeric
{
public:
virtual ~Numeric() {}
virtual int getNumeric() const = 0;
};
This is considered an interface.
And now I insert an enumerator (It can be something else, like a typedef, etc.)
class Numeric
{
public:
enum Numbers
{
One,
Two,
};
virtual Numbers getNumeric() const = 0;
};
Still being an interface or it is now considered an abstract class?
As I said, it might be silly but I really wonder to know that.
If you are looking for an official answer, then I'm afraid there is none.
The draft of the C++11 standard I am having here merely says [10.4 class.abstract]:
An abstract class can also be used to define an interface for which
derived classes provide a variety of implementations.
All other instances of the word "interface" in the entire ~1300 pages PDF only refer to generic programming or other things not related to OOP or abstract classes.
For example this one here [24.2.1 iterator.requirements.general]:
Most of the library’s algorithmic templates that operate on data
structures have interfaces that use ranges.
This obviously has nothing to do with abstract classes.
Bjarne Stroustrup himself, if you accept his words as "half-official", doesn't really help you in this regard, either. Quoting from the glossary on his homepage:
abstract class - a class defining an interface only; used as a base
class.
You will have to live with the fact that the C++ language itself as well as C++ developers and experts use the word "interface" as a superset for "abstract class". Unlike e.g. in Java, where interfaces are an actual language element with its own interface keyword, there is no such thing in C++.
Everything else is opinion-based.
Your second class Numeric is an interface.
If a class has one or more pure virtual functions, then this class is called an "abstract class".
Generally, if all of a classes' functions are pure virtual functions, then this class is called an "interface".
C++ does not have an explicit interface concept, so the above two classes are called the interface or abstract class, somewhat interchangably.
In my opinion, your second class can be considered an interface. I don't think there is a standard which defines interfaces in C++. However in languages which have interfaces, for example, Java, you can usually have enums defined inside an interface.
I would consider a class with no implementation to be an interface.
Example:
Iterators are pure abstractions: Anything that behaves like an
iterator is an iterator.
What does it mean?
An abstract class has at least one pure virtual function. This is standard C++ terminology.
Some people use the term pure abstract class to describe a class that has nothing but pure virtual functions (in other words, no data members and no concrete functions). This is equivalent to Java interfaces.
Now to your actual question:
Iterators are pure abstractions: Anything that behaves like an iterator is an iterator.
This has nothing to do with abstract classes (pure or otherwise). All it's saying is that anything that fulfils the iterator contract is an iterator. It doesn't even have to be a class (think pointers).
Nothing. The C++ Standard states only that a), a class is abstract if it has at least one pure virtual function, direct or inherited, and b), you can't instantiate an abstract class directly. There's no such thing as a pure abstract class.
I would think a pure abstract class is the C++ equivalent of an interface.
See here:
A pure Abstract class has only abstract member functions and no data
or concrete member functions. In general, a pure abstract class is
used to define an interface and is intended to be inherited by
concrete classes. It's a way of forcing a contract between the class
designer and the users of that class. The users of this class must
declare a matching member function for the class to compile.
An abstract class is a class with some functionality but some that needs to be implemented, whereas a pure abstract class has none of its functionality implemented.
This is a bit like an interface in other languages such as C# and Java.
A pure abstract class would serve the purpose of specifying a 'contract' that concretions of the pure abstract class must adhere to.
Abstract Class *will atleast have one pure virtual function and can have data members.
Pure Abstract Class is just like an interface. Only pure virtual functions can be defined here. No data members or method definition can be done here.
For more information visit: (https://en.wikibooks.org/wiki/C%2B%2B_Programming/Classes/Abstract_Classes/Pure_Abstract_Classes)
In C++ there is not pure abstract class. There are only abstract class and pure virtual function (function has been marked with = 0). Class with at least one pure virtual function becomes abstract. However pure virtual function can have implementation.
In your example, you're talking about Iterators. In C++, and more specifically in the standard library, the term Iterators doesn't refer to a pure abstract class but to what are called concepts. Concepts are used with templates rather than with virtual/inheritance-based polymorphism. Currently (C++11), concepts are only defined in the library documentation, i.e. they do not (yet) exist as part of the C++ language itself. The standard library documents concepts, for example the "Iterator" concept, as a set of requirements for any type/object to be accepted as a type parameter of a template that wants to work with an "Iterator". A set of requirements is defined in terms of which expressions are valid on an object, regardless of its type. It's a form of duck-typing. For example, see : http://en.cppreference.com/w/cpp/concept/Iterator
As far as I know, both abstract methods and pure virtual functions do NOT provide any functionality ... So can we say they're both the same thing ?
Also, suppose a class (not necessarily declared as abstract) contains a number of implemented methods (not abstract or virtual), but contains a pure virtual function. Is this class then abstract ?
Yes, they are the same thing. In C++, an abstract method is just another way of describing the characteristics of a pure virtual function. Both just mean a method with no implementation provided that needs to be implemented in a sub-class before the class can actually be instantiated.
The situation with pure virtual functions and abstract classes in C++ is similar as they essentially mean exactly the same thing. Any abstract class must have at least 1 pure virtual function or else it could be instantiated and wouldn't be abstract. Likewise, any class with at least 1 pure virtual function must be abstract because it needs to be extended so that method can actually be implemented.
Therefore, a class is abstract if and only if it contains at least 1 pure virtual function/abstract method.
Later on, languages like Java and C# made things like this more explicit, allowing a special keyword to define a class abstract rather than the presence of a pure-virtual function. C++ lets you do the same things as these languages, but they're just a little more explicit about it. :D
You don't explicitly declare classes or methods as abstract in C++. The presence of pure virtual methods is what makes them abstract.
Yes, abstract methods are the exact same thing as pure virtual functions; the terms are often used interchangeably. IMO, "Pure virtual function" is the C++ technically correct term which specifically denotes the fact that the function is set to 0:
class myClass {
public:
virtual void vfunc() = 0; // pure specifier
};
An abstract class is defined by:
a class that is designed to be
specifically used as a base class. An
abstract class contains at least one
pure virtual function.
So basically, an abstract class is an abstract class because it's designed to be a base class (some base classes by definition need to have implementable methods which will need to be pure virtual). These classes become abstract classes simply by how they are used and extended from. Unlike languages like Java, there is no abstract or interface keyword modifier so this is why we need a "verbal contract" to talk about abstract classes in C++.
In C++, a pure virtual member function leads to the enclosing type being an "abstract type".
Functions themselves cannot be abstract, though the term is frequently misused in this manner.
I would say yes, abstract methods and pure virtual functions are conceptually the same thing.
Also, suppose a class (not necessarily declared as abstract) contains a number of implemented methods (not abstract or virtual), but contains a pure virtual function. Is this class then abstract ?
A class with at least 1 pure virtual function is called an abstract class.