Anyway, I did a lot of work with InterViews and I had a look to NihLib. I Highly recommend InterViews 3.0 but found NihLib rather unusable (it's a very big tree while we need more often a lot of small trees).
One very, VERY, important criteria of a class library is its documentation. A very good library without a proper documentation is very hard to use (if not useless). There is no need for the documentation to be thick and verbose but it should gives all the info you need to use the class.
Then, there is reuse... (ako "how easy is it to derive a class ?")
InterViews is a VERY good example of a good library with appropriate doc.
From: fig.citib.com!kpt@fig.citib.com (Kevin P. Tyson)
I am in the process of reviewing/selecting C++ class libraries for our shop. We have reviewed two todate. The Booch Components and Tools.h++. We started out by deciding, loosely, what our requirements are. They major ones boil down to: (1) High quality commercial support is very important to us. (2) Support for multi-threaded programming is only slightly less important. (3) Sophsiticated and extensible memory management support is our third requirement.
We are a DCE/ENCINA shop and this is what has driven our requirements. We do distributed transaction processing based applications. Someone who does scientific programming will have different requirements and someone working on parallel processors will have their own requirements.
The next libraries we intend to examine are COOL and the USL C++ Components library. So far Booch meet the three requirements listed above but was much too low level and lacked good documentation. Tools.h++ could be extended to meet our thread safe and memory management requirements, but that would have made support difficult as it would require modifying their source code.
From: eyckmans%imec.be@zimec.be
In article <p4fieINN7si@agate.berkeley.edu>, you write: * |> Now, has anyone actually used COOL and would you have any idea why the * |> authors expressed reservations about it's quality? How does it compare * |> with other public domain libraries? Are there any good ones out there * |> that you would like to boast about? *
I have not used COOL (yet). As a matter of fact, I have not yet actively used any of the libaries mentioned below, but here goes anyway...
====
advantages
----------
- uses templates
- uses exceptions
disadvantages
-------------
- COOL templates are not 100% ARM conformant
- no garbage collection support at all
- common root class (Smalltalk)
- COOL uses an exception implementation which is not even close
to the ARM
remarks
-------
- I have not yet tried to compile it with DEC C++ v1.0.
- I think that the main objection the COOL authors have against
it, is that they feel that their class hierarchy is not optimal.
(Almost) all COOL classes either directly or indirectly inherit
from a common root class called Generic. In their documentation,
the authors state that if they were to redo it, they would
rather go for a forest of base classes.
NIH
===
advantages
----------
- used in many applications, and therefor thoroughly tested
disadvantages
-------------
- no garbage collection support at all
- no templates
- no exceptions
- common root class (Smalltalk)
remarks
-------
- I have not yet tried to compile it with DEC C++ v1.0.
LEDA
====
advantages
----------
- well designed set of data types
- looks as if it should be very efficient
- uses some template-like construct
disadvantages
-------------
- no exceptions
- LEDA `templates' are not even close to the ARM
- use is restricted to "research and education"
- use is not for free (but it's cheap)
- I cannot possibly get it to compile with DEC C++ v1.0
OATH
====
advantages
----------
- garbage collection comes "for free"
- focuses on a how to implement classes, instead of on yet
another set of classes a set of classes
disadvantages
-------------
- common root class (Smalltalk)
- no templates
- no exceptions
- garbage collection comes "for free"
- nobody can possibly get it to compile with DEC C++ v1.0
without major modifications
Hello,
First of all, let me start by giving you a bit of background information on what my organisation is (and intends to be) doing. This will allow you to read my answers to your questions in the correct context.
> How is it the various libraries won't with with DEC's C++? Are they non * > standard C++ or do they just not comply with C++ 3.0? How do you know * > that they do not work with DEC C++? *
To my knowledge, DEC C++ v1.0 is *very* ARM compliant, while most other C++ compilers are not. This is one of the reasons why we are switching to the DEC compiler. Here is a list of what we have tried to compile with it until now :
> Are these notes impressions that you've gotten from people who have used * > these various libraries? *
That depends on what libary we are talking about, so let's make a list :
our Synthesis Backbone. In addition, I picked up some info on
comp.lang.c++.
COOL : This has not been used at our site, but I have received some
info from other people (isn't usenet great?). I also looked at
the manual.
LEDA : I have looked at the manual, and have actually tried to compile
it with DEC C++ v1.0.
OATH : I have looked at the manual, and have actually tried to compile
it with DEC C++ v1.0.
I guess I've already answered this in my introduction.
> Does this mean that you've tried to get it to work with cxx but it * > won't compile? Or do you just know that it won't work becuase it uses * > non standard C++? *
This question was about LEDA, so here are the gory details of what happened :
Because of this, I just gave up. So I can't tell you whether the remaining syntax errors are solvable or not.
While I'm at it, allow me to elaborate a little bit on my statement about compiling OATH with DEC C++ v1.0. The first time round, the compiler flagged lots of errors. I was able to solve this, but than I ran into an illegal downcast upon which, unfortunately, a large part of the OATH library depends. This is why I said that major changes to the code would be needed. However, after sending my mail, I realized that there is a small possibility that this second problem (although present in the code from the beginning) was actually activated by the changes I made. So it looks like I will have to try again.