Prev: Oracle SQL Class Library Up: Libraries Top: Top

4. Comments

From: jcc@gna.axis-design.fr (Jean-Christophe Collet)

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

From: eyckmans%imec.be@imec.be

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.

Having said all that, here is what you are really after :

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

Basically, in all cases we have discovered things which are not allowed by the ARM, but somehow did compile on previous compilers (g++ as well as various derivatives of cfront 2.0 and 2.1). Some of these were easy to fix, but some weren't. As a matter of fact, the SPOOK tool set is the only thing in the above list which, after modification, did make it all the way to executable code.

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

> Do you intend to get involved with one of these packages in the future? *

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 :

This is true even for the smallest of files, so I suspect there must be some very ugly stuff in the header files, but I have no idea what this might be.

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.