Generic programming is OOP or what, bit confused
Author
Hello all,
I was reading an article earlier today, and got very curious about a question that was asked and how it was answered:
"JB: An area of interest for you is multi-paradigm (or multiple-style) programming. Could you explain what this is for you, what you have been doing with multi-paradigm programming lately and do you have any examples of the usefulness of multi-paradigm programming?
BS: Almost all that I do in C++ is "multi-paradigm." I really have to find a better name for that, but consider: I invariably use containers (preferably standard library (STL) containers); they are parameterized on types and supported by algorithms. That's generic programming. On the other hand, I can't remember when I last wrote a significant program without some class hierarchies. That's object-oriented programming. Put pointers to base classes in containers and you have a mixture of GP and OOP that is simpler, less error prone, more flexible, and more efficient than what could be done exclusively in GP or exclusively in OOP. I also tend to use a lot of little free-standing types, such as Color and Point. That's basic data abstraction and such types are of course used in class hierarchies and in containers. "
Now, in my college class in C plus plus, we were recently introduced to learning to program "generically". We are actually writing an interpreter at this point and I am finding the project very exciting (read that as I am a geek!). Anyhow, the way presented to me in my text, it seemed that generic programming was a way to make your OO programming better. Reading that answer, it seems that the two are separate distinct styles. I was just curious what way is the correct way to think of this?
BTW, that artice is "An Interview with Bjarne Stroustrup" found here
In C++, that would be templates and meta-programming.
At the most basic level, they involve creation of "concepts". For example, a List is a concept (has elements, can be traversed, can have elements added or removed, ...). But it doesn't matter what this list actually is (linked list, vector, enumeration) or what these elements are.
Consider this:
Since we define our list as something that can be enumerated it has begin() and end() iterators (by contract - because we said so when we declared List), these point to values, and they are elements are iterated over sequentially.
But nowhere do we specify what our container is, or what its elements are.
This is what C++ standard library is about. <algorithm> specifies the elementary ADT operations, and individual headers provide implementations of basic data structures.
Boost pushes this to very limits with MPL and some other libraries. See also Loki library for smaller scale examples.
At the most basic level, they involve creation of "concepts". For example, a List is a concept (has elements, can be traversed, can have elements added or removed, ...). But it doesn't matter what this list actually is (linked list, vector, enumeration) or what these elements are.
Consider this:
template < class List >void enumerate( List &e ){ List::iterator start = e.begin(); List::iterator end = e.end(); while (start != end) { std::cout << *e; start++; }}Since we define our list as something that can be enumerated it has begin() and end() iterators (by contract - because we said so when we declared List), these point to values, and they are elements are iterated over sequentially.
But nowhere do we specify what our container is, or what its elements are.
This is what C++ standard library is about. <algorithm> specifies the elementary ADT operations, and individual headers provide implementations of basic data structures.
Boost pushes this to very limits with MPL and some other libraries. See also Loki library for smaller scale examples.
Generic programming and object-oriented programming are both approaches to making your C++ programming better. Except for the tricky issue of making compile-time and run-time polymorphism play nicely together, they don't really bear on each other.
When you write 'template <typename T> void wibble(const T& foo)', you are implying that "foo" is a wibble-able thing, and conceptually creating a separate code path for each wibble-able T. Everything is "pre-cooked"; that's generic. When you write 'void wibble(const Wibbleable& foo) { foo->wibble(); }', you are explicitly arranging for your argument to be wibble-able. You create one main code path, which will call varying other functions based on a run-time decision. That's OO.
When you write 'template <typename T> void wibble(const T& foo)', you are implying that "foo" is a wibble-able thing, and conceptually creating a separate code path for each wibble-able T. Everything is "pre-cooked"; that's generic. When you write 'void wibble(const Wibbleable& foo) { foo->wibble(); }', you are explicitly arranging for your argument to be wibble-able. You create one main code path, which will call varying other functions based on a run-time decision. That's OO.
Generic Programming is the act of programming with concepts. Lists and Maps are container/collection concepts, while searching and sorting are algorithm/strategy concepts. You're free to make you own concepts, such as Zahlman's wibble-able concept. In C++, generic programming is realised in the form of templates.
Object Oriented Programming is the act of representing a problem space as one or more objects. OOP allows you to encapuslating together both state and functions in a modular manner that can employ inheritance, composition, aggregation and run-time polymorphism. Thus by treating data and functionality as objects you can achieve inter-object communication by passing them from one to another using their publically available interfaces. In C++, OOP is realised through the use of classes et al.
Neither paradigm is perfect or best-fit for all scenarios hence the power of multi-paradigm languages is to allow them to mingle.
C++ also supports aspects of Functional Programming and Meta Programming, as well as others.
Object Oriented Programming is the act of representing a problem space as one or more objects. OOP allows you to encapuslating together both state and functions in a modular manner that can employ inheritance, composition, aggregation and run-time polymorphism. Thus by treating data and functionality as objects you can achieve inter-object communication by passing them from one to another using their publically available interfaces. In C++, OOP is realised through the use of classes et al.
Neither paradigm is perfect or best-fit for all scenarios hence the power of multi-paradigm languages is to allow them to mingle.
C++ also supports aspects of Functional Programming and Meta Programming, as well as others.
>> it seemed that generic programming was a way to make your OO programming better.
As you have already noticed, part of the problem is that there are no absolute definitions for these.
OOP means different things to different people. I strongly disagree with some of the definitions already given and can cite authoritative books that will back me up, but I can also cite other authoritative books that contradict those definitions.
>> Reading that answer, it seems that the two are separate distinct styles. I was just curious what way is the correct way to think of this?
This has been covered very well in literature and online. The C++ language has multiple paradigms because the language itself was developed from multiple sources.
I'll go to one authoritative source: Scott Meyers addressed this in the first chapter of Effective C++. See page 12 of the 3rd edition, since most of this is direct quotes. Note that Stroustrup was one of the manuscript reviewers for the text, so he knew this information long before that interview.
* C paradigm: C++ is primarily based on C. It has blocks, statements, the preprocessor, data types, arrays, pointers, free-standing functions and structures, etc., that all come from the C language. Consider that with the C99 standard, many compiler vendors supported the additions from C99, and that some of those additions were incorporated into the C++ language through TR1.
* Object-Oriented C++ paradigm: This is the "C with Classes" language, including classes, encapsulation, inheritance, polymorphism, virtual functions, and so on.
* Template C++ paradigm: These include all generic programming, template metaprogramming, and so on. These range from simple macro-like replacements to the full comprehensive metaprogramming compiled language.
* The STL paradigm: The STL had its own conventions of containers, iterators, algorithms, and other concepts. The STL was the major force for the C++ standard libraries, so their design had a strong influence on c++.
* Library-specific, vendor-specific, and API/SDK-specific paradigms: Every library was written with the intent to be used in a particular way. Generally when you follow their paradigms, development with those tools is straightforward. When you violate their paradigms you are likely to uncover bugs, corner conditions, and difficult development.
It can be very useful to think about bits of code in terms of those paradigms. This has been discussed many times over the years, and I believe it is what Stroustrup was referring to.
In that quote he specifically lists the "standard library" paradigm for containers, "generic programming" paradigm for templates, "object oriented programming" paradigm of class hierarchies, and "free-standing types" paradigms. He explains how he mixes the paradigms, which is what any experienced c++ programmer should tell you to do.
As you have already noticed, part of the problem is that there are no absolute definitions for these.
OOP means different things to different people. I strongly disagree with some of the definitions already given and can cite authoritative books that will back me up, but I can also cite other authoritative books that contradict those definitions.
>> Reading that answer, it seems that the two are separate distinct styles. I was just curious what way is the correct way to think of this?
This has been covered very well in literature and online. The C++ language has multiple paradigms because the language itself was developed from multiple sources.
I'll go to one authoritative source: Scott Meyers addressed this in the first chapter of Effective C++. See page 12 of the 3rd edition, since most of this is direct quotes. Note that Stroustrup was one of the manuscript reviewers for the text, so he knew this information long before that interview.
* C paradigm: C++ is primarily based on C. It has blocks, statements, the preprocessor, data types, arrays, pointers, free-standing functions and structures, etc., that all come from the C language. Consider that with the C99 standard, many compiler vendors supported the additions from C99, and that some of those additions were incorporated into the C++ language through TR1.
* Object-Oriented C++ paradigm: This is the "C with Classes" language, including classes, encapsulation, inheritance, polymorphism, virtual functions, and so on.
* Template C++ paradigm: These include all generic programming, template metaprogramming, and so on. These range from simple macro-like replacements to the full comprehensive metaprogramming compiled language.
* The STL paradigm: The STL had its own conventions of containers, iterators, algorithms, and other concepts. The STL was the major force for the C++ standard libraries, so their design had a strong influence on c++.
* Library-specific, vendor-specific, and API/SDK-specific paradigms: Every library was written with the intent to be used in a particular way. Generally when you follow their paradigms, development with those tools is straightforward. When you violate their paradigms you are likely to uncover bugs, corner conditions, and difficult development.
It can be very useful to think about bits of code in terms of those paradigms. This has been discussed many times over the years, and I believe it is what Stroustrup was referring to.
In that quote he specifically lists the "standard library" paradigm for containers, "generic programming" paradigm for templates, "object oriented programming" paradigm of class hierarchies, and "free-standing types" paradigms. He explains how he mixes the paradigms, which is what any experienced c++ programmer should tell you to do.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
