On Tue, 2005-03-29 at 01:29, Rob Stewart wrote:
From: Andreas Pokorny <andreas.pokorny@gmx.de>
On Mon, Mar 28, 2005 at 07:36:15PM +0530, Tushar <tushar@mwti.net> wrote:
On Fri, 2005-03-25 at 01:06, Andreas Pokorny wrote:
On Thu, Mar 24, 2005 at 01:14:57PM +0530, Tushar <tushar@mwti.net> 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. It is. It makes it difficult to document/design things with UML and related documentation tools like doxygen or javadoc
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.)
I have gone through above doc. First I do not still understand how non-member functions increase encapsulation.e.g. He is trying to say that, I have a class X Class X { int x,y,z; X(int x,int y,int z) { Set(X);Set(y);Set(Z); } X(int x) { Set(X);SetY(0);SetZ(0); } SetX(int x);//implementation not shown. You people know it. SetY(int y) SetZ(int z) } According to author, if I change x to xx, I need to rewrite three functions.But its clearly not the case. This is simple example. But there can be many more. Its all about reusing code, be it inside class, out side class or with pure C code. One can always have minimum code for a class method that effectively uses other methods. Second point about that is, it makes some syntax issues that author also agrees.Like Wombats w; //See above doc for Wombats. w.eat("ff"); sleep(w); The biggest problem for some one new like me is of knowing capability of class. If i go through doc of class X, and there is method "eat", I know X can eat.(Like Wombats can eat.) But when I do not see "sleep" as member of that class, first impression is that X can not sleep.(I am used to think that way. Sorry).
(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.
OK. I will like to copy everything not a primitive data type. Do you think, using one more class for everything that I want to use pointer to is a good thing? Let me to go through doc of shared_pointer,then I will comment more on this issue.
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.
I agree. I have made some wrong statements. Original point was use of templates. Can any one tell me how it help to write code other then for primitive data types and classes that implements operator like =,<= to simulate primitive data type.
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.)
OK I agree. May be having a common base class will lead to some problem in case of MI.
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.