Hi all, I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this. 1. C++ requires a Good OOPs library with well defined api. Java has that . While C++ also have many of them, most do not look truly object oriented. As all of us know, Java is really a subset of C++ from pure language point of view. C++ has every thin that JAVA has except GC. But still programming in JAVA is more easy because they have a well define API to work with. I thinks, we should have some thing similar in C++ also. 2.C++ has much of the libs using STL. The only problem is STL is not a object oriented.(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. 3.There are other "standard" API to work with things like thread and networking. I know many libs are there on this boost and some other good site, but there is no uniform framework to work with in C++,one like one JAVA provides. These was some reasons why C++ libs are required. 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? 1.JAVA is not free neither under GPL. 2.GC makes problem for many programs. 3.Compilation of java to binary using GCJ or something similar gives performance problem 4.After all, many C++ programmer like me do not want to change language but I do want a good uniform library. Difference bet proposed C++ and Java 1.Everything is a pointer other them simple atomic data types.(Same) 2.There is no GC. Its here large change will be required. (Diff) 3.Arrays - I do not know. Should it be made object like in java or let it be as it is in C++. Later seems good and one can use some class like Array to have similar effects.(?) 4.Every thing is subclass of Object(Same). 5.Sync support in Object (i.e to every object) using wait and signal - I am not sure. This makes it easy but may also bring some performace problem (?) Ok, enough thinking. Now implementation. Here I am thinking of converting entire GNU Classpath to C++. One major change will be lack of GC. For others, I will have to dig deeper. For GNU Classpath people, it will be review of their code. Regards, Tushar
Tushar <tushar@mwti.net> writes:
I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this.
You should probably start by explaining what Classpath and GCJ are. I happen to know the answer for GCJ, but not Classpath. Others may not know either one. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Tushar <tushar@mwti.net> writes:
I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this.
You should probably start by explaining what Classpath and GCJ are. I happen to know the answer for GCJ, but not Classpath. Others may not know either one. ClassPath is gnu implementation of JAVA API. They use same API as java but use different implementaion. GCJ classes and classpath will be merged into one.My idea is to use code from Classpath(or GCJ. but GNU
On Thu, 2005-03-24 at 19:55, David Abrahams wrote: thing ) to write C++ lib. Regards, Tushar
Tushar <tushar@mwti.net> writes:
On Thu, 2005-03-24 at 19:55, David Abrahams wrote:
Tushar <tushar@mwti.net> writes:
I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this.
You should probably start by explaining what Classpath and GCJ are. I happen to know the answer for GCJ, but not Classpath. Others may not know either one.
ClassPath is gnu implementation of JAVA API. They use same API as java but use different implementaion. GCJ classes and classpath will be merged into one.My idea is to use code from Classpath(or GCJ. but GNU thing ) to write C++ lib.
You didn't explain what GCJ is, and given that you used the term "GCJ classes" I'm beginning to think I don't really know what you mean by GCJ. Also, I hope you understand that GPL'd code is incompatible with Boost license policy. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Tushar <tushar@mwti.net> writes:
On Thu, 2005-03-24 at 19:55, David Abrahams wrote:
Tushar <tushar@mwti.net> writes:
I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this.
You should probably start by explaining what Classpath and GCJ are. I happen to know the answer for GCJ, but not Classpath. Others may not know either one.
ClassPath is gnu implementation of JAVA API. They use same API as java but use different implementaion. GCJ classes and classpath will be merged into one.My idea is to use code from Classpath(or GCJ. but GNU thing ) to write C++ lib.
Do I understand this to mean that "ClassPath" is the entire Java API? If not, you've failed to answer Dave's query on what "Classpath" actually is. I have no idea what it is, so I cannot discuss the merits of the idea for Boost.
You didn't explain what GCJ is, and given that you used the term "GCJ classes" I'm beginning to think I don't really know what you mean by GCJ.
I also don't know what "GCJ" is. IOW, I have no idea what this proposal is for and can't comment on whether it is useful. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
On Tue, 2005-03-29 at 01:09, Rob Stewart wrote:
From: David Abrahams <dave@boost-consulting.com>
Tushar <tushar@mwti.net> writes:
On Thu, 2005-03-24 at 19:55, David Abrahams wrote:
Tushar <tushar@mwti.net> writes:
I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this.
You should probably start by explaining what Classpath and GCJ are. I happen to know the answer for GCJ, but not Classpath. Others may not know either one.
ClassPath is gnu implementation of JAVA API. They use same API as java but use different implementaion. GCJ classes and classpath will be merged into one.My idea is to use code from Classpath(or GCJ. but GNU thing ) to write C++ lib.
Do I understand this to mean that "ClassPath" is the entire Java API? If not, you've failed to answer Dave's query on what "Classpath" actually is. I have no idea what it is, so I cannot discuss the merits of the idea for Boost. For now, forget about classpath and gcj. These are implementation issues. This is all about having a java api implemented in C++. I want to know how much people thinks this can be good thing to do.
You didn't explain what GCJ is, and given that you used the term "GCJ classes" I'm beginning to think I don't really know what you mean by GCJ.
I also don't know what "GCJ" is. IOW, I have no idea what this proposal is for and can't comment on whether it is useful.
On 31 Mar 2005 12:16:35 +0530, Tushar <tushar@mwti.net> wrote:
On Tue, 2005-03-29 at 01:09, Rob Stewart wrote:
From: David Abrahams <dave@boost-consulting.com>
Tushar <tushar@mwti.net> writes:
On Thu, 2005-03-24 at 19:55, David Abrahams wrote:
Tushar <tushar@mwti.net> writes:
I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this.
You should probably start by explaining what Classpath and GCJ are. I happen to know the answer for GCJ, but not Classpath. Others may not know either one.
ClassPath is gnu implementation of JAVA API. They use same API as java but use different implementaion. GCJ classes and classpath will be merged into one.My idea is to use code from Classpath(or GCJ. but GNU thing ) to write C++ lib.
Do I understand this to mean that "ClassPath" is the entire Java API? If not, you've failed to answer Dave's query on what "Classpath" actually is. I have no idea what it is, so I cannot discuss the merits of the idea for Boost. For now, forget about classpath and gcj. These are implementation issues. This is all about having a java api implemented in C++. I want to know how much people thinks this can be good thing to do.
After minimal Java development and lots in C#, I can say I definately prefer the .NET Framework to the Java Classpath. Still, I think that neither have a place in C++, for all the same reasons others have posted to this thread.
You didn't explain what GCJ is, and given that you used the term "GCJ classes" I'm beginning to think I don't really know what you mean by GCJ.
I also don't know what "GCJ" is. IOW, I have no idea what this proposal is for and can't comment on whether it is useful.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
"Tushar" wrote: [snip]
For now, forget about classpath and gcj. These are implementation issues. This is all about having a java api implemented in C++. I want to know how much people thinks this can be good thing to do.
A system that would allow to reuse Java sources without much of pain would be Good Thing (TM). /Pavel
Uh, then maybe automated translation. (Only know of one translator: http://www.remotesoft.com/octopus but it is commercial & .NET oriented.) Any Java core class libraries w/o license issues? Kon On Mar 31, 2005, at 4:42 AM, Pavel Vozenilek wrote:
"Tushar" wrote:
[snip]
For now, forget about classpath and gcj. These are implementation issues. This is all about having a java api implemented in C++. I want to know how much people thinks this can be good thing to do.
A system that would allow to reuse Java sources without much of pain would be Good Thing (TM).
/Pavel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Uh, then maybe automated translation. (Only know of one translator: http://www.remotesoft.com/octopus but it is commercial & .NET oriented.)
Any Java core class libraries w/o license issues? Thanks for pointer. I liked it. I also want to do something similar. Only problem I have with java is GC. That is where major changes will be required. Classpath is GNU implementation of java. They use same API but with their own implementation, so I think one can use source to make a
On Thu, 2005-03-31 at 19:36, Kon Lovett wrote: lib. It need to be under GPL.
Kon
On Mar 31, 2005, at 4:42 AM, Pavel Vozenilek wrote:
"Tushar" wrote:
[snip]
For now, forget about classpath and gcj. These are implementation issues. This is all about having a java api implemented in C++. I want to know how much people thinks this can be good thing to do.
A system that would allow to reuse Java sources without much of pain would be Good Thing (TM).
/Pavel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Take a look at http://www.hpl.hp.com/personal/Hans_Boehm/gc, a conservative gc for c/c++. W/ the gc & translated classpath you almost won't know your using c++. Kon On Mar 31, 2005, at 10:45 PM, Tushar wrote:
Uh, then maybe automated translation. (Only know of one translator: http://www.remotesoft.com/octopus but it is commercial & .NET oriented.)
Any Java core class libraries w/o license issues? Thanks for pointer. I liked it. I also want to do something similar. Only problem I have with java is GC. That is where major changes will be required. Classpath is GNU implementation of java. They use same API but with their own implementation, so I think one can use source to make a
On Thu, 2005-03-31 at 19:36, Kon Lovett wrote: lib. It need to be under GPL.
Kon
On Mar 31, 2005, at 4:42 AM, Pavel Vozenilek wrote:
"Tushar" wrote:
[snip]
For now, forget about classpath and gcj. These are implementation issues. This is all about having a java api implemented in C++. I want to know how much people thinks this can be good thing to do.
A system that would allow to reuse Java sources without much of pain would be Good Thing (TM).
/Pavel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tushar wrote:
For now, forget about classpath and gcj. These are implementation issues. This is all about having a java api implemented in C++. I want to know how much people thinks this can be good thing to do.
While I agree that having a feature-rich set of (standard) libraries for C++ is a Good Thing, I particularly dislike the idea of reusing the Java API, even when ported to C++. C++ is much more expressive than Java and supports very different programming styles ('multi-paradigm'...). Regards, Stefan
From: Tushar <tushar@mwti.net>
Tushar <tushar@mwti.net> writes:
I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this.
For now, forget about classpath and gcj. These are implementation issues. This is all about having a java api implemented in C++. I want to know how much people thinks this can be good thing to do.
From what I know of the Java API, I think that is a terrible idea. As others have pointed out, the Java way is quite different from the C++ way, despite their syntactic similarities.
If you port the Java API to C++, you'll continue to write Java in C++. That's an impediment to writing quality C++ code and will be foreign to C++ developers without Java experience. Your best bet is to learn what makes C++ unique and to follow rather than buck the current best practices. To that end, a good book to read might be Dewhurst's C++ Common Knowledge. Also, the venerable Effective C++ and Effective STL books from Meyers would be good to better understand how to approach problems in C++ and what problems to avoid. To understand some of the modern, template-based approaches used in C++, try Alexandrescu's Modern C++ Design: Generic Programming and Design Patterns Applied. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
On Thu, Mar 24, 2005 at 01:14:57PM +0530, Tushar <tushar@mwti.net> wrote:
Hi all,
I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this.
The Classpath in C++ would be the runtime linker path, and a mapping of namespaces onto directories? How would one implement such a concept, and for what use? Or is the classpath the whole library api?
1. C++ requires a Good OOPs library with well defined api. Java has that . While C++ also have many of them, most do not look truly object oriented. Could you elaborate "Good OOPs"? Do you think that only object oriented librarys are good enough?
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.
(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.
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.
Difference bet proposed C++ and Java 1.Everything is a pointer other them simple atomic data types.(Same) References are helpful, try to implement a swap without references. Why should you prune C++ here?
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.
Regards Andreas Pokorny
On Thu, Mar 24, 2005 at 01:14:57PM +0530, Tushar <tushar@mwti.net> wrote:
Hi all,
I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this.
The Classpath in C++ would be the runtime linker path, and a mapping of namespaces onto directories? How would one implement such a concept, and for what use? To have same uniform API as JAVA.
Or is the classpath the whole library api?
1. C++ requires a Good OOPs library with well defined api. Java has that . While C++ also have many of them, most do not look truly object oriented. 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
On Fri, 2005-03-25 at 01:06, Andreas Pokorny wrote: First, Thanks all who replied. that language, then I think it is must.
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.
(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 void foo() { String str="0123456789"; List l; l=new List(); for(i=0;i<10;++i) l.insert(str); } 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.
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. 2.All java objects use reference for accessing real objects. So I do not think this can be problem.
Difference bet proposed C++ and Java 1.Everything is a pointer other them simple atomic data types.(Same) References are helpful, try to implement a swap without references. Why should you prune C++ here? We can. But if a have a method that need to allocate memory and return it back to caller, then how to handle this with reference. E.g
void readConfig(String **str1,String **str2) { //try to get str1 from config file //try to get str2 from config file //if failed, throw some exception //allocate str1 and copy string from config file //allocate str2 and copy from config file //if failed to allocate then throw some exception }
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. Regards, Tushar
Regards Andreas Pokorny
______________________________________________________________________
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Mar 28, 2005 at 07:36:15PM +0530, Tushar <tushar@mwti.net> wrote:
On Thu, Mar 24, 2005 at 01:14:57PM +0530, Tushar <tushar@mwti.net> 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
On Fri, 2005-03-25 at 01:06, Andreas Pokorny wrote: First, Thanks all who replied. 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
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.
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
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.
Tushar wrote:
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
I hope you're not suggesting we should restrict the design of libraries to what you think is supported by UML and by the documentation tools you mentioned. Regards, m
On Thu, Mar 31, 2005 at 01:54:34PM +0530, Tushar wrote:
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
Huh??? I use Doxygen every day with code that isn't object-obsessed. I wrote the doxygen docs for parts of GCC's STL, and found absolutely no problems describing the contents of <algorithm> using Doxygen. Why do your UML designs need to care about STL algorithms? Can't you specify the design in terms of "copy this object" so you don't care whether the copy is done using a member function or not? If your tools don't support modern C++, change your tools, not the language. IMHO implementing the Java API in C++ is a bad idea. This awful HOWTO made the same mistake of trying to make C++ more like Java: http://oopweb.com/CPP/Documents/CPPHOWTO/Volume/C++Programming-HOWTO.html And there's a reason myself and others convinced the Linux Documentation Project to do this: http://www.tldp.org/HOWTO/C++Programming-HOWTO.html jon
Hi, For some reason Tushar needs/wants to use C++, coming from a Java background. (I went the other direction. Much easier.) Perhaps some (more?) books would help: - C++ For Java Programmers by Timothy A. Budd http://www.amazon.com/exec/obidos/tg/detail/-/0201612461/002-8601771 -8450440?v=glance - Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu http://www.amazon.com/exec/obidos/tg/detail/-/0201704315/ qid=1112275961/sr=1-2/ref=sr_1_2/002-8601771-8450440?v=glance&s=books I cannot comment on the Budd volume but readers seem to like it. I can recommend the one by Alexandrescu for template programming. While reading code is still the best I do not recommend diving into Boost source. The demands of multi-compiler support make for heavy lifting; though a great way to learn multi-compiler support. I guess I am saying adapt to the idioms of the language rather than attempting to re-make it in some other language's image. Then you will be able to use the inherent expressive power. (My 1st Snobol program earned the comment "You have succeed in turning snobol into fortran." With my 2nd and subsequent programs I learned my lesson.) Best wishes, Kon On Mar 31, 2005, at 12:24 AM, Tushar wrote: [snip]
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. [snip]
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tushar wrote:
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
The joy of learning multiple languages is to be able to appreciate that there are new things to be said that can't be expressed in other languages. Why should we ever learn new languages if we are tied to only say things that can already be said in an already known language ? Regards, Stefan
From: Tushar <tushar@mwti.net>
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:
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
This is not a problem. It is your understanding of the tools.
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.
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
s/apply/applying/
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); }
Why would you do this? I realize that these are ints, but as a rule, you need to use an initializer list: X(int x, int y, int z) : x(x) , y(y) , z(z) { }
X(int x) { Set(X);SetY(0);SetZ(0); }
X(int x, int y, int z) : x(x) , y(0) , z(0) { }
SetX(int x);//implementation not shown. You people know it. SetY(int y) SetZ(int z)
}
For now, I'll refrain from making comments on the other design errors in this class and hope they exist only because you quickly created an example for your discussion.
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
No. His point is that you must look at all member functions in the class to determine whether the name change affects them. That you can say not all must be rewritten is because you looked at them and (trivially) determined that they were not affected by the name change. A friend function or, better yet, a free function that isn't a friend, is totally insulated from the name change provided the data member is private. In that case, you can completely ignore non-member functions when making that name change.
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).
Get used to thinking differently. Modern C++ favors non-member functions where possible. Even eat() would frequently be implemented thusly: void eat(Wombats const & w, std::string const & food) { w.eat(food); } That leads to altering the example to be: Wombats w; eat(w, "ff"); sleep(w); You don't have to do that in all cases, but it is necessary to make Wombats accessible via parametric rather than dynamic polymorphism (from function templates rather than via abstract interfaces). The documentation issue simply boils down to the modern notion of Concepts. To support the eat() and sleep() free functions, you can define Eater and Sleeper Concepts such that objects satisfying those concepts support this usage: Eater: eat(x, food); Sleeper: sleep(x); Now, many types can be documented as satisfying those Concepts. Once you know that, you'll know that the usage for those Concepts is valid for the type at hand.
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.
void * suffices when you want a pointer to anything. Of course you can't get back the dynamic type anymore, so it's of limited value. The point is that there are many things possible, but experience has shown that few are best practice. We long ago recognized that a common, root class is a bad idea for most cases.
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.
I don't understand your question.
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.
There are many other problems besides forcing MI. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Andreas Pokorny <andreas.pokorny@gmx.de> writes:
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:
First, Thanks all who replied.
On Thu, Mar 24, 2005 at 01:14:57PM +0530, Tushar <tushar@mwti.net> 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 xxxx size"?
Andreas, this sort of hostility is inappropriate, especially when directed at someone who's obviously new to Boost. It's important to remember when posting replies to someone you don't know that he might just be a precocious 15-year-old. Please keep the discussion on a professional level, regardless of what you think of the idea's technical merits. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Mon, Mar 28, 2005 at 03:50:36PM -0500, David Abrahams <dave@boost-consulting.com> wrote:
Andreas, this sort of hostility is inappropriate, especially when directed at someone who's obviously new to Boost. It's important to remember when posting replies to someone you don't know that he might just be a precocious 15-year-old. Please keep the discussion on a professional level, regardless of what you think of the idea's technical merits.
I am not a native english speaker, so I am not always able to interpret the spirit of an expression. This makes it of course also hard for me to foresee how my words will be interpreted by other people. Hence I should be more careful with my jokes. So I apologize for my misplaced joke. Regards Andreas Pokorny
participants (2)
-
Andreas Pokorny -
Cory Nelson -
David Abrahams -
Jonathan Wakely -
Kon Lovett -
Martin Wille -
Pavel Vozenilek -
Rob Stewart -
Stefan Seefeld -
Tushar