Related
Is it ppssible to implement a concatenative inheritance or at least mixins in C++?
It feels like it is impossible to do in C++, but I cannot prove it.
Thank you.
According to this article:
Concatenative inheritance is the process of combining the properties
of one or more source objects into a new destination object.
Are we speaking of class inheritance ?
This is the basic way public inheritance works in C++. Thanks to multiple inheritance, you can even combine several base classes.
There might be some constraints however (e.g. name conflicts between different sources have to be addressed, depending on use case you might need virtual functions, and there might be the need to create explicitly a combined constructors).
Or is inheritance from instantiated objects meant ?
If it's really about objects and not classes, the story is different. You cannot clone and combine object of random type with each other, since C++ is a strongly typed language.
But first, let's correct the misleading wording. It's not really about concatenative inheritance, since inheritance is for classes. It's rather "concatenative prototyping", since you create new objects by taking over values and behaviors of existing objects.
To realize some kind of "concatenative prototyping" in C++, you therefore need to design it, based on the principle of composition, using a set of well defined "concatenable" (i.e. composable) base classes. This can be achieved, using the prototype design pattern together with the entity-component-system architecture.
What's the purpose
You are currently looking for this kind of construct, probably because you used it heavily in a dynamically typed language.
So keep in mind the popular quote (Mark Twain ? Maslow ? ):
If you have a hammer in your hand, every problem looks like nails
So the question is what you are really looking for and what problem you intend to solve. IMHO, it cannot be excluded that other idioms could be more suitable in the C++ world to achieve the same objective.
I have always heard that C++ is not Object Oriented but rather "C with Classes". So, when I mentioned to an interviewer that C++ was not really object oriented, he asked me why I didn't consider it an OO language. I haven't done any C++ since University, and I didn't have much of an answer. Is C++ Object Oriented or not? and why?
C++ is usually considered a "multi-paradigm" language. That is, you can use it for object-oriented, procedural, and even functional programming.
Those who would deny that C++ is OO generally have beef with the fact that the primitive types are not objects themselves. By this standard, Java would also not be considered OO.
It is certainly true that C++ isn't OO to the same extent as Smalltalk, Ruby, Self, etc. are, but it is definitely an effective OO language by most standards.
C++ is a multi-paradigm programming language supporting
imperative
object-oriented (class-based)
generic (template metaprogramming)
programming styles. You can choose (and mix them) freely to meet the needs for your project.
C++ is an object oriented language. The problem is that some language zealots have their own, sometimes conflicting definition of OOP. For example, some Java people say that C++ is not an OOP language because you can define functions outside of a class.
Just ignore them.
Bah! The people who say C++ isn't object oriented are the same ones that would say Spam isn't food :-)
The OO "religious nutter" crowd will say that you can only have a true OO language if absolutely everything is an object. That's fine, they can sit in their ivory towers and believe what they want. Some of us have actual jobs to do.
Provided you use the object mindset, C++ (and even C if you use all sorts of tricks with function pointers within structures) is more than enough to be considered object oriented.
Meh. Everybody has their own deinition of OOP. Alan Kay who invented the term OOP said: http://www.noulakaz.net/weblog/2007/02/12/true-meaning-of-oop/
OOP to me means only messaging, local
retention and protection and hiding of
state-process, and extreme
late-binding of all things. It can be
done in Smalltalk and in LISP. There
are possibly other systems in which
this is possible, but I’m not aware of
them.
By that definition even Java, C#, Python etc are not OO languages.
IMHO, these discussions are pointless.
The hallmarks of object-orientation are abstraction, encapsulation, polymorphism, and inheritance.
I'd say that C++ exhibits all four, so it qualifies as an object-oriented language.
It's possible write C++ as "a better C" and use a purely procedural style. Objects aren't mandated. Maybe that's what you're thinking.
C++ is an OO language.
But that is not the only style of coding that C++ can be used in. n
As such C++ is technically a multiparadigm language of which OO is just one paradigm.
The term "C with classes" has a couple of meanings.
It can refer to the fact the C++ is OO (as classes give it the OO capabilities).
It can refer to the original version of "cfront"
Which was basically C with the extension of classes and little else.
It can refer (derogatorily) to a style of programming that does not utilize the full power of C++ but only uses a small subset of the language.
The idea is that C++ is not just an object oriented language.
C++ is object oriented, because classes provide abstraction and inheritance and all that jazz. It's not always considered object oriented because code doesn't need to be object oriented. It's like saying Scheme isn't functional because it has set!.
As other have said, C++ is not a PURE OO language. Then again, the only Pure OO language I know is smalltalk. The only pure functional language I know is the Lambda Calculus. I don't know ANY pure structured languages (They all have goto and/or multiple return statements)
Most people don't like writing in pure programming languages. It cramps their style.
The term "object oriented" is too hazy to give a definite yes or no answer. I think you'll find the majority view is that C++ is an OO language, or at least that you can write in an OO way in C++. If you want a more definite answer, you'll have to ask a better defined question, such as:
Q: Does C++ have "object" (i.e. data fields + associated member functions) data types?
A: Yes.
Q: Does C++ have non-object data types?
A: Yes.
Q: Does C++ have non-member functions?
A: Yes.
C++ is object oriented. c++ is c with classes is another way to say that c++ is c with oop added (and of course, there is more than that on top of c).
If I am an interviewer asking you this question, I'm probably not caring about the yes/no answer - I really want to know what you understand about programming, and C++ or other languages. Are you just throwing out terms that you don't think about or understand, or do you actually consider carefully what you are doing and saying. So in this situation a good answer is
"I define Object oriented coding to be a, b, c, and d. I define an Object Oriented language as one which supports that definition, ie. permits me to (easily / uniformly / rigorously / other adjective ) develop code that fulfills those requirements. C++ delivers a,b,c, and partially on d. So I do ( don't ) consider C++ to be OO for those reasons."
For my personal definition, C++ is object-oriented enough, plus it supports other approaches.
Stroustrup, who designed C with classes, viz. the original implementation of the ISO C++ standard, answered the same question in ACM's OOPSLA '95. The paper's softcopy is available at http://www.stroustrup.com/oopsla.pdf.
It is indeed object oriented but not strictly though.
Say for example, we can have just
int main()
{
return 1;
}
which is nothing in the name of Object oriented and on the other hand we can have Classes, inheritance, polymorphism etc., that corresponds to Object Oriented.
It is up to us unleash the power of the language.
To the interviewer who asked you the question show a class a from C++ and ask him whether it is structured or procedured.. He will show you the same main() function I guess :)
So I guess it is based on what you have implemented that lies. But it has features that can make it to be considered as an OOP.
C++ is not an object-orientated language. The language is not any paradigm. This is in constrast to Java, which is religiously object orientated (no friend statement, for example). C++ offers object orientation, but isn't inherently object-orientated.
C++ is partially OO because the code can be written without the class and it has also multiple inheritance concept, i.e one child can have more than one parent.
Object-oriented programming (OOP) has become the preferrd programming approach by the software industries, as it offers a powerfull way to cope up with the cpmlexity of real world probleams. Among the OOP languages available today, c++ is far the most widely used language.
The languages should support several of the OOP concepts to claim that they are object oriented. depending on the fetures they support , they can be classified in to two categories.
Object-Based programming languages.
Object-Oriented programming languages.
Object-Based programming languages.
if it supports
A. DATA ENCAPSULATION
B. DATA HIDING AND ACCESS MECHANISAMS
C. AUTOMATIC INITIALIZATION& CLEAR-UP OF OBJECTS
D. OPERATOR OVER LOADING
2.Object-Oriented programming languages.
It supports all object-based programming features along with two additional features
E. INHERITANCE
F. DYNAMIC BINDING
hence Object-Oriented programming languages means
**Object-based features+ inheritance+ dynamic binding.**
Examples : C++, SMALLTALK,OBJECT PASCAL,JAVA
So , C++ is an OBJECT-ORIENTED PROGRAMMING LANGUAGE>
If you should still have some doubts in object oriented programming concepts refer the book of E.Balaguruswamy.
Even though OOP uses objects and data encapsulation, the code still writes out like a procedure. So what makes OOP loose the procedural label? Is it just because it is considered "high-level"?
Thank You.
It's not that Object-orient Programming is "non-Procedural"; it's just that the code we call "Procedural" is not Object-oriented (and not Functional and probably not a couple others)
It's not so much an either-or case, but a slow gradiate:
Spaghetti code -> Structured Code -> Object-oriented code -> Component code.
(UPDATE: Removed "Procedural" from the chart above, since it refers to all of the right 3/4rds of it)
In theory OOP and procedural programming are orthogonal concepts. The fact that they so intertwined in practice is probably more coincidence than anything else. Because it is so familiar, procedural syntax is the most human readable format around. Message-passing, functional computation expressions, and various other formats -- because of their unfamiliarity -- are simply not as easy for most programmers to work with. Couple this with the fact that most OOP systems are based on extensions to procedural languages, and it becomes pragmatically difficult to separate the two paradigms. (As a side note: That's one of the things I like about F#; as a multi-paradigm language, it helps conceptually separate the various aspects of OOP, imperative programming, functional programming, while making all of them available.)
I would say object-oriented and procedural are orthogonal concepts. Many popular object-oriented systems are extensions of procedural languages, but not all. For example, Dylan reads like a blend of functional and object-oriented programming.
This is just a 'convention' thing. When people say 'procedural', it is implied that it isn't OO, and vice-versa.
OOP does not loose procedural label. Procedural programming is imperative programming. OOP extends procedural programming. C++ and Objective C are OO extensions of C. Functional programming usually is declarative - opposite of imperative.
From Wiki (well explained):
The focus of procedural programming is
to break down a programming task into
a collection of variables, data
structures, and subroutines, whereas
in object-oriented programming it is
to break down a programming task into
objects with each "object"
encapsulating its own data and methods
(subroutines). The most important
distinction is whereas procedural
programming uses procedures to operate
on data structures, object-oriented
programming bundles the two together
so an "object" operates on its "own"
data structure.
More can be found here.
The Wikipedia article at http://en.wikipedia.org/wiki/Procedural_programming provides a decent explanation of the differences between object-oriented programming and procedural programming, but in short, object-oriented programming is about the exchange of messages between collaborating objects rather than stringing procedures together to operate upon loose data structures.
Internally, objects do resemble little procedural programs, but their data isn't publically exposed and operated upon by other objects. The "Tell, Don't Ask principle" is an object-oriented design principle that perscribes this interaction between objects. The study of this principle may help to shed further light on the nature and intent of object-oriented design over procedural design.
It never loses procedural label. Its a mis-conception. OOP is much more than encapsulation and objects. Click here for more info.
I think one of the distinctions is that virtual properties and methods are used much more heavily in object-oriented languages than are function pointers in languages like C. In C, if I say foo(x), it's pretty clear that I'm doing one of two things, and the declaration of foo(x) will tell me which one. I'm either calling a function named foo(), or I'm calling a function pointed to by a function pointer named foo(). In an object oriented language, when I write foo(x), that may get implicitly mapped to invoke code which didn't even exist when my module was compiled.
Depends on your definition of 'oriented'.
If 51% of the code is O-O, does it qualify?
OOP is not just encapsulation.
Polymorphism is one of its most powerful feature.
Note: marked as community wiki.
In recent days, I've realized how little I know about C++.
Besides:
using the STL
implementing RAII
implementing ref-counted smart pointers
writing my own policy-based template classes
overloading operators << for fun
What other techniques are must-know for a good C++ programmer?
Thanks!
I think this should cover it:
More C++ Idioms - Wikibooks
OO Design
Types of exception safety guarantees (which is what most design patterns/idioms are based on).
When to use which standard containers
Boost
The first two are 'must know' for a good C++ programmer. 'Good C++ programmers' do not overload operators for fun.
Basic:
RTTI
Virtual functions
shared_ptr etc
Templates
Virtual inheriting
Variadic macros
Also useful:
Attributes (it depends on your compiler)
Variadic templates
Variadic functions
Constexpr (sorting in compile time / calculating hash of strings etc... but the latter is related to the last section)
Lambdas
Useful for brainfucking or in special cases:
CRTP
SFINAE
inable_if (type traits)
Foreach macro
User-defined literals
(hardly a must-know, but still useful) Writing domain-specific languages with operator overloading and template metaprogramming (see Boost.Spirit for a nice example) - but this is the kind of thing that makes shooting yourself in the foot easy, too.
The way I used to improve my c++ is reading the source code of leveldb. Because leveldb is a product level code. So you can learn the cpp idiom and design pattern from a real product. Let me show you some example
Leveldb use the Pimpl idiom, almost in all of it's head file, such table.h table_build.h write_batch.h. You can learn from the code directly
Leveldb use many OO design pattern, such as build pattern, the table have the table_build class to build the table, the block have the block_build class to build the block
Leveldb also use the Iterator pattern, the iterator make us use leveldb more convenient.
So I think leveldb contain many idiom or design pattern that c++ engineer should know.
I know that in OOP we have to declare everything e.g. variables, functions, etc. inside a class like in Java, but in C++ we can declare outside the class too.
Is this the reason that, C++ is not fully OOP? Or is there anything else?
Huh? C++ is a hybrid, multi-paradigm language. It is certainly not a "pure" object-oriented language, where "everything is an object" holds true. C++ supports classes, objects, encapsulation, and so on, but since it's also (more or less) backwards-compatible with a lot of C code, it cannot be "fully object-oriented".
Object-Oriented Programming is not definition of the language, it's definition of the programming, a program. I.e. one program in C++ can be OOP, and other can be not OOP.
What you can say is that C++ fully supports means of programming in OOP paradigm.
Define fully OOP? There are as many opinions as people probably
Note as far as purity goes, IIRC all languages with valuetypes are not "pure" in the strict sense. No, boxing doesn't count.
Over the years, in discussion I've tried to go back to the core OOP features:
identity
Classification
polymorphism (not inheritance, since some OOP have no inheritance)
encapsulation
So if you can tell if two classes are not the same class (identity), you can make the classic "duck quacks" and "dog barks" example (to demonstrate inheritance/polymorphism and classification) and you can hide fields, you are pretty much there.
Applying it to all the languages is more difficult though. While I do get functional programming roughly, I'm not trained enough in the their near infinite jargon to judge all those functional-oop-imperative hybrids that are springing up,
In C++ you don't HAVE to code using OOP, you can choose not to use it. Having said that, it's "fully OOP", OOP is just just not a requirement.
not even java is a full OOP language.
in real OOP languages everything is an object, conditionals, loops, etc.
Even though the question is somewhat ugly phrased I'm not really satisfied with all the answers provdided yet.
I preffer to think of languages as "supporting a paradigm" and not "being in a paradigm".
So, when does a language support a paradigm? When it is easy to write code that satisifies the requirements of the paradigm.
How one comes to this conclusion? Consider the style linux filesystems are implemented. It is C-Code that clearly has OO properties. So, would you not consider this code to be OOP because C is not a OOP-language? I don't think so. (I guess some people will rightfully disagree as this seems to be amtter of opinion.)
What does this imply for C++? Well, C++ has a lot of facilities for making it easier to program in a OO-Style, but it also provides you with a lot of means to rape the paradigm and write code that looks OO (because you use classes, inheritance private variables) but completly violates some other OO-principles (e.g. single responsibility, open-closed, uniform access).
I would conclude that C++ supports the OO-paradigm to some extent but is clearly inferior to some of the modern OO languages.
The main concept of OOP is that every member in an object oriented programming language should be defined inside of the class, whereas in c++ the main function is defined outside of a class. That is why c++ is not fully object oriented programming language.
The main() function is not inside a class, so for this reason, one could argue that C++ is not fully OOP.
One of the reason C++ is not fully OOP is the requirement of backward compatibility with a lot of C code. Built in types are not Objects in C++ as it is less efficient if they were. Remember, C++ first target audience were existing C programmers and efficiency was (is) a great concern.
However, C++ supports all the important features of OOP.
Related Link : www.research.att.com/~bs/oopsla.pdf