I hope this question is not too silly, but what is the most basic class in standard C++?
object? Object?
class MyObject : public object{ ...
and I get "Expected class-name before token{"
Is there any map, diagram or image that shows standard c++ classes inheritance?
Something like this but for C++ ?
There is no most basic class in C++ i.e. there is no common base class for all the classes.
There is no fundamental object type in C++, unlike in e.g. Java.
In Cocoa, the NSObject class is fundamental to the framework but not to the Objective-C language itself. In Objective-C, it is possible to create a root class by not deriving from anything (but in order to make it work you'll probably have to hack your way through runtime calls).
Similarly, some C++-based frameworks may define a root class that all other classes in that framework derive from, but it is specific to the framework, not the language.
This is the simplest most basic class you can compile:
class Null
{
};
Inheritance diagram for IOstream library is here. STL is a template library and doesn't use OOP.
Related
In Java all containers are in a hierarchy of abstract base classes:
List<String> v1 = new LinkedList<String>();
AbstractSequentialList<String> v2 = new LinkedList<String>();
Is there an analogue for SequenceContainer and std::vector in C++?
No, std::vector has no (standard, documented) base class, nor does it have any virtual methods. The C++ standard library doesn't use runtime polymorphism much aside from the iostream classes.
The C++ standard library is geared more towards static, compile-time polymorphism with templates. SequenceContainer is just a name for the way some set of classes can be interacted with. The intent is that you can write template code that interacts with objects only by that documented interface and it will work with any class that fulfills those requirements.
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.
I have a lightweight c++ class needed to be ported to Objective-C to exploit the facilities provided by NSObject. There will be thousands of instances of the C++ class, and i dont want to add to much overhead by wrapping it in a NSObject derived class.
how big is NSObject?
First of all, you should descend from NSObject. There is no tangible benefit to not doing so. NSObject adds nothing in terms of storage over the lowest level representation of a class but adds an awful lot of behaviour that will allow your classes to act correctly with the runloop, with the normal collections (eg, NSArray or NSDictionary) and with just about everything else.
To answer your question specifically:
#import <objc/runtime.h>
...
NSLog(#"obj size: %zd", class_getInstanceSize([NSObject class]));
Outputs '4' on iOS and '8' on 64-bit OS X. So the answer you're looking for is 'the natural size of an integer'. NSProxy is the same size, UIView (on iOS) is 84 bytes.
Documentation for class_getInstanceSize is here — it explicitly returns "[t]he size in bytes of instances of the class cls", as the name says.
in the apple documentation it says here that
The root class of all Objective-C classes is NSObject, which is part
of the Foundation framework. All objects in a Cocoa or Cocoa Touch
application ultimately inherit from NSObject. This class is the
primary access point whereby other classes interact with the
Objective-C runtime
So I'd say that every objective-c class ultimately derives from NSObject anyway, so you have no choice. Please, correct me if I'm wrong.
EDIT:
What I've learned now is that NSObject is one root class, which implements the basic behaviour expected from every objective-c class. So basically you could write an objective-c class which implements the protocol of NSObject (I think that is objective-c speak for interface) and implement basic stuff like alloc and init yourself. Be sure to check out this thread: How to instantiate a class in Objective-C that don't inherit from NSObject
EDIT:
Some more insight into root classes in objective-c, very interesting!
Well till now I knew we implement interfaces , but today some body (you know who , i guess)) told me that If I write a interface then we implement it in class , but if it is a system Interface , Let's say INotifyPropertyChanged , the we call it Class A inherits Interface INotifyPropertyChanged.
Though I feel right , I am not sure and unsure how to explain it to him.
I need to specify in my Design doucment . So wondering what shall I mention, Inherit or Implemet.
We inherit it to implement it. What's the problem?
1-Interface is implemented by a class whether is it a normal interface or system interface.
2- One Interface can inherit another interface.
Speaking language-independant you would say "implementing an interface". The symbol in UML names it the same (there is a special implementing-arrow which is used for interfaces instead of the inheriting-arrow)
Anybody understanding UML would understand what you're meaning.
In C++ you have to consider that there aren't interfaces as they exist in other languages. A interface is a pure virtual class.
So classes which "use" this interface are strictly speaking inheriting from a pure virtual class.
If you're saying "MyClass inherits the pure virtual class IClass" someone C++-related would understand that you mean interface I think. He also would understand if you say "MyClass is implementing IClass" and in background think of a pure virtual class.
If Class A provides the method bodies (that is, code) for the methods that are declared in the interface, then Class A is implementing the interface.
In C++, because of the lack of distinction between interface and class, the source code syntax for inheriting from a class and implementing an interface is the same. Hence the confusion.