Re: [boost] Classpath to C++ conversion

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-28 14:59:30

From: Andreas Pokorny <andreas.pokorny_at_[hidden]>
> On Mon, Mar 28, 2005 at 07:36:15PM +0530, Tushar <tushar_at_[hidden]> wrote:
> > On Fri, 2005-03-25 at 01:06, Andreas Pokorny wrote:
> > > On Thu, Mar 24, 2005 at 01:14:57PM +0530, Tushar <tushar_at_[hidden]> wrote:
> > > Could you elaborate "Good OOPs"? 

Andreas was asking what "Good OOPs" means.  My guess is that you
(Tushar) actually mean OOP, which stands for Object Oriented
Programming.

> > > Do you think that only object oriented librarys are good enough? 
> > Well,no. One can have good library without OOPS, but when one want to
> > use a language that supports OOPS and one wants to design using OOPS in
> > that language, then I think it is must.

C++ is much more than an OOPL.  It supports procedural
programming, OOP, generic programming, even functional
programming.  Therefore, it is not a given that a library written
in C++ must be OO.  Granted, you said that when "one wants to
design using OOPS [sic]...then...it is [a] must."  The question
Andreas raised is why OOP is required for this library.

> > > > 2.C++ has much of the libs using STL. The only problem is STL is not a
> > > > object oriented.
> > > Where is the problem? Containers are object, algorithms are not. Looks
> > > perfectly good to me. 

Agreed.  STL not being (entirely) OO is not a problem in any way.

> > Yes it is. But that is case of pure algorithms like sorting. But for
> > many case, one wants to combine data and algorithm.(If I am correct,
> > this is called encapsulation in OOPS).  So for example, I can have a
> > linked list which can sort itself. According to STL, I will create a
> > linked list and pass it to method sort. 
> 
> Now where is the problem?
> 
> Algorithms can be defined without refering to a specific type, usually
> it is enough to define the concept of the data.

Right.  The containers in the STL do have member functions, so
they are OO.  They also participate in a more generic scheme that
allows apply algorithms to iterator ranges while selecting the
most appropriate implementation.  Therefore, some functionality
that is common to several containers is not implemented via class
member functions, but rather as free functions that can be
applied to the containers.  (See
http://www.cuj.com/documents/s=8042/cuj0002meyers/ for more on
this idea.)

> > > > (See STL Tutorial and reference) This really makes it
> > > > difficult to think in OO and implement in STL. Particularly in STL,
> > > > T a,b
> > > > T a=b means a is separate entity and same for b. This make problem in
> > > > many case where one wants just pointer e.g File handling and
> > > > manipulation of large buffer.
> > > Where is the relation between value/pointer/reference semantic, and oop? 
> > > Btw, you need to understand language semantics before implementing
> > > anything in that language. 
> > > 
> > What I mean to say is that in java, I have
> [ snipping java code ]
> > What will happen in STL is that we will get array to 10 chars copied to
> > list at every insert. So at last, there should be 10 copies of same
> > string. In java, just a pointer to actual string is stored. 
> 
> So by "think in OO and implement in STL" you actually meant "think in
> java and implement in C++ using STL" (even though your example has not
> much to do with the STL). 

IOW, in Java, everything is a reference counted pointer, so
copies are cheap.  In C++, particularly in Boost, you spell that
with boost::shared_pointer.

> > > > My idea is that API specification is already defined for java. And it
> > > > seems much complete.I mean to say more complete then if start deciding
> > > > from scratch -:). Why not to use java then?
> > > I doubt that reusing the design makes much sense, because it was designed 
> > > for a different language, a language without templates, without references,
> > > multiple inheritance, without operators and without destructors. Thus there 
> > > are lots of things that can be handled nicer. 
> > As java is a subset of C++, the same design can be used. Lets go one by
> > one.
> > 1.Templates - Templates can be used for primitive types. I do not know
> > how to use it for other things like sorting of objects. Why should we
> > have a piece of code that sorts just object of class X.(I am talking
> > about run time code, not just source code). Instead we can write a
> > procedure which will sort all objects using a pointer to some abstract
> > class that will be extended by all objects that need to be sorted. When
> > using templates, other problem is that to forget to overload operators
> > like '=' and many a times this gives lots of problem. For sorting with
> > template I need to implement all '<','>','=,'==','=<','>='. I find it
> > better to implement compareTo() only. 
> 
> You lost me completely! Where is the relation between my statement and
> what you told us, (btw: you do not have to implement all relational
> operators, and have a look at the boost::operators library).
> You just showed us how bad the java api design fits into C++, since
> actually propose to replace std::sort with c's qsort. 

Again, I agree.  Tushar appears to have a poor grasp of C++ and
seems intent on implementing an awkward, subpar library as a
result.

> > > > 4.Every thing is subclass of Object(Same).
> > > Why should one pay for a deep hierarchy that is never used? You should
> > > ask yourself why java needs to have that common base class.
> > Yes. Seems I need to do more R & D over object. One need I can see now
> > is that it can act as common pointer that all can access with some
> > common method. Like, when writing LinkedList, we can write it to work
> > with object and use casting for real use. I was also thinking to
> > implement synchronization using object using wait,notify etc.
> 
> Yes, sounds like a reasonalbe design: 

Be careful.  Tushar is clearly not a native English speaker, so
your sarcasm may be lost on him.

> Either add everything you might possibly ever need in every application 
> in the library base class, or dynamically cast to the type you like, and 
> handle cast exceptions in every function of your code. 

The point you make is valid: there is a reason we don't write C++
with a common root class.  We learned long ago to avoid the
problems that creates.  (One example of the problem is that you
force MI on classes that currently derive from some type.
Another is how to integrate code from two different frameworks,
each with its own common base class.)

> You should have a look at the boost libraries in their current state,
> and think whether your plan fits into boost at all(, or in the language).

Consider, for example, how the Boost Serialization library
integrates with a UDT without requiring a common base class.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;