Re: Is STL of bad quality?
On Feb 23, 11:06 am, "dietmar_ku...@yahoo.com"
<dietmar.ku...@gmail.com> wrote:
On Feb 22, 10:17 pm, Seungbeom Kim <musip...@bawi.org> wrote:
On 2011-02-22 11:13, DeMarcus wrote:
I don't think so. The STL is very good. So my question is;
Where do I make the misconception? What have I missed?
That article is about "OO Design Quality Metrics," and STL
is not OO.
STL isn't object-oriented?
It depends on what you mean by object-oriented. (And also what
you mean by the STL, I suppose.) According to Booch, dynamic
polymorphism (inclusion) is the defining characteristic; the
polymorphism in the STL is parametric and static. (But of
course, that's just one definition of OO.)
I'd think it is: It is all about using
data structures (iterators, function objects, etc.), manipulating
them through a well-defined interface to achieve specific goals.
I'd think this high-level abstraction is an accurate description
of what STL does and is pretty much in line at least with
object-oriented programming.
I nearly hear the uproar, though, having upset both the generic
programming and the object-oriented programming communities at once!
By suggesting that they persue the same goals:-)?
But STL's interface are actually even more abstract than the usual
object-oriented interfaces: they aren't even represented in code
and trying to represent them in code is non-trivial as the work on
adding "concepts" to C++ has shown (the technical difficulties are
complex enough, not to mention the non-technical aspects). The
concepts are still interfaces used to access objects in the
object-oriented sense, i.e. combinations of data and operations
directly operating on them. Also, STL benefits greatly from
object-oriented techniques like data abstraction, encapsulation,
messaging, modularity, and polymorphism. Of course, the polymorphism
is compile-time polymorphism rather than the run-time polymorphism
generally referred to when talking about object-orientation. STL
even uses inheritance, although merely to deal with certain type
computations rather than for (run-time) polymorphism.
It's a different type of polymorphism, and the distinction isn't
just static vs. dynamic. Roughly speaking, inheritance results
in the same interface with different implementations; templates
create different interfaces using the same implementation.
Looking at the first sentence of the Wikipedia article for
Object-Oriented Design
(<http://en.wikipedia.org/wiki/Object-oriented_design>) pretty
much confirms that object-oriented design applies to STL, too:
Object-oriented design is the process of planning a system of
interacting objects for the purpose of solving a software problem.
Generic Programming is pretty much built on top of object-oriented
programming, although it deliberated uses a very different approach
than the object-oriented programming typical approach of inheritance
as its abstraction mechanism.
It's duck-typing approach isn't that different from Smalltalk
(which is generally considered OO).
The generic programming abstraction yields those immaterial
concepts which even leave the exact details of the types
appearing in signatures open, not just the implementation of
functions: compared to the abstract interfaces in STL, even
the most abstract object-oriented (non-generic) interface
feels like a tight straight-jacket.
Or a guarantee of runtime behavior:-). At least on large
projects, I wouldn't like STL-like duck typing if it weren't
resolved at compile time. It opens up the door to a whole new
lot of runtime errors.
--
James Kanze
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]