Re: [boost] Classpath to C++ conversion

From: Andreas Pokorny (andreas.pokorny_at_[hidden])
Date: 2005-03-28 12:38:41

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:
> First, Thanks all who replied.  
> > On Thu, Mar 24, 2005 at 01:14:57PM +0530, Tushar <tushar_at_[hidden]> wrote:
> > Could you elaborate "Good OOPs"? 
> > 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.

So may i replace OOPS with "object oriented penis size"? 

> > > 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. 
> 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.

> > > (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). 

> > > 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. 

> > > 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: 
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. 

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).

Regards 
Andreas Pokorny