| Title: | Languages |
| Notice: | Speaking In Tongues |
| Moderator: | TLE::TOKLAS::FELDMAN |
| Created: | Sat Jan 25 1986 |
| Last Modified: | Wed May 21 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 394 |
| Total number of notes: | 2683 |
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | Interoffice Memorandum
| | | | | | | |
+---------------------------+
To: Friends of C++ Date: 24-August-90
From: Craig Hansen-Sturm
Dept.: OSG Languages
E-mail: DECWET::HANSEN
DTN: 206-865-8886
Location: ZSO
Subject: C++ Software Components
The OSG Languages Group is currently assessing the needs of C++ developers.
As a member of the C++/OOP community, your input would be invaluable in deter-
mining whether there is a need for a comprehensive, standardized, and reuseable
set of C++ libraries based on the "software component/IC" metaphor.
In particular, we are trying to determine what collections of C++ libraries are
of most use to the non-casual C++ programmer.
Please take the time to answer the following questionaire. We greatly value
your input. Please forward this survey to anyone else in the C++ community
who you feel might be interested.
Craig Hansen-Sturm
OSG Languages
_____________________________________________________________________________
Question I:
How important do you view having a standardized, reuseable, and well-
integrated collection of C++ software components is to a C++ language
product?
____________________________________________________________________________
Question II:
When designing an application, what modules or class definitions have you
typically created in the past which you felt were not specific to the task
at hand ? e.g., which you felt should have been part of an application-
independent C++ library?
_____________________________________________________________________________
Question III:
Broadly speaking, what kinds of libraries do you feel should be provided
by a well-integrated C++ language environment. Please rank the following
rather broad categories in terms of overall importance to you. Feel free
to comment if a particular library you require does not fall into one of
these categories:
1) Foundation Classes (e.g., basic container classes, data structures,
basic math library).
2) Application Framework Classes (e.g., such as MACapp, InterViews,
and ET++).
3) Application Interface Classes (e.g., such as C++ bindings for
DECwindows/MOTIF, CDA, SQL data-base, or the C run time library).
4) Application Support Classes (e.g., such as garbage collection,
persistent object package, meta-class emulation, EIFFEL-style
constraints package, threads package).
_____________________________________________________________________________
Question IV:
Regarding the Foundation classes (category 1 of question II), please
list in order of decreasing preference any libraries in this category
you would like to see in a C++ product.
Would a supported version of the NIH OOPS library package satisfy your
needs in this area? Are there any third-party vendors which might
satisfy your needs in this area as well?
_____________________________________________________________________________
Question V:
Regarding Application Framework Systems (category 2 of question II),
please comment on whether supported (and possibly enhanced) versions
of ET++ or InterViews would satisfy your needs in this area.
_____________________________________________________________________________
Question VI:
Regarding Application Interface Classes (category 3 of question II),
please list in order of decreasing preference any C++ interface (wrapper)
classes you would like to see in a C++ product.
_____________________________________________________________________________
Question VII:
Regarding Application Support Classes (category 4 of question II),
please list in order of decreasing preference any libraries in this
category you would like to see in a C++ product.
In particular, how do you feel about the following:
i) C++ threads package.
ii) persistent object package.
iii) garbage collector.
iv) meta-class simulation (accessing "meta-class" and runtime informa-
tion about objects).
v) constraints/assertions package (simulating EIFFEL-style pre/post
conditions).
vi) any other packages you see as being relevant.
_____________________________________________________________________________
Question VIII:
Assuming that a compiler supporting parameterized types is not available,
would you tolerate using a class library which required using a seperate
preprocessor to instantiate template types?
_____________________________________________________________________________
Question IX:
Are there any particular C++ applications which you view to be of such
critical importance that they should be included in a general C++ type
library?
_____________________________________________________________________________
Question X:
Please provide any other comments you feel might be relevant to providing
a C++ software components package.
_____________________________________________________________________________
Send all replies to DECWET::HANSEN.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 282.1 | survey results | DECWET::HANSEN | DECwest Compiler Development | Wed Sep 19 1990 19:20 | 317 |
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | Interoffice Memorandum
| | | | | | | |
+---------------------------+
To: Friends of C++ Date: Sept-14-1990
From: Craig Hansen-Sturm
Dept.: OSG Languages
E-mail: DECWET::HANSEN
DTN: 206-865-8886
Location: ZSO
Subject: C++ Software Components -- Survey Results
Enclosed are the results of the C++ library survey. At the time of writing,
September 13, 1990, twenty-six software engineers, the majority of whom have
fair-to-extensive C++ experience, have replied. As anticipated, the overwhel-
ming response to the survey was positive: 96% viewed providing a nontrivial
set of C++ libraries, which go beyond the functionality of the current set
of AT&T components, as being important, perhaps even strategic, to any DIGITAL
C++ offering.
At this time, the author would like to thank all of the respondents for taking
the time to answer this survey.
-- Craig Hansen-Sturm
OSG C++ Language and Documentation Group
+-----------------------------------------------------------------------------+
| Synopsis |
+-----------------------------------------------------------------------------+
There is a strong demand within the C++ Community to provide a comprehensive
set of reuseable C++ Software Components. While there is a general consensus
among users that providing a Compiler and Debugger are the most critical parts
of any DEC C++ product, it has become clear that providing an extensive lib-
rary offering is critical to the success of C++ as a product -- particularly
in a multivendor arena, where libraries will become an increasingly important
discriminating factor between the various compiler vendors. 96% of the engi-
neers who responded to this survey were emphatically supportive of this endea-
vor, and felt that an inordinate amount of time was wasted "reinventing the
wheel" during C++ application development. Furthermore, there was a tendency
among the respondents to view the current AT&T library offering as being
inadequate.
The following table summarizes our results:
+-----------------------------------------------------------------------------+
| |
| Foundation Classes (basic data structures) |
| |
| 89% requested that this should be included in a DEC C++ product |
| |
| MOTIF C++ Bindings |
| |
| 73% requested that this should be included in a DEC C++ product |
| |
| C++ Thread Library |
| |
| 66% requested that this should be included in a DEC C++ product |
| |
| OS Interface Shell (libC.a written in class-form, memory/file management) |
| |
| 66% requested that this should be included in a DEC C++ product |
| |
| C++ Persistence Package (OODB wrapper and/or object-stream/file IO classes) |
| |
| 62% requested that this should be included in a DEC C++ product |
| |
| Garbage Collector |
| |
| 58% requested that this should be included in a DEC C++ product |
| |
| Meta-Class Simulation |
| |
| 42% requested that this should be included in a DEC C++ product |
| |
| RPC Wrapper |
| |
| 35% requested that this should be included in a DEC C++ product |
| |
| Exception Handling/Trap-Handler/Error-Handler Classes |
| |
| 31% requested that this should be included in a DEC C++ product |
| |
| Constraints/ASSERT Package (Eiffel-Style constraints simulation) |
| |
| 27% requested that this should be included in a DEC C++ product |
| |
| Typesafe Mathlibrary |
| |
| 27% requested that this should be included in a DEC C++ product |
| |
| InterViews Support (MOTIF bindings for Mark Linton's InterViews package) |
| |
| 23% requested that this should be included in a DEC C++ product |
| |
+-----------------------------------------------------------------------------+
Below the 20% threshold (a rather arbitrary cutoff point), the following re-
quests appeared:
+-----------------------------------------------------------------------------+
| |
| CDA Wrapper |
| |
| 19% requested that this should be included in a DEC C++ product |
| |
| Network Management Library |
| |
| 12% requested that this should be included in a DEC C++ product |
| |
| Graphical Objects Package |
| |
| 12% requested that this should be included in a DEC C++ product |
| |
| PHIGS/GKS Wrapper |
| |
| 8% requested that this should be included in a DEC C++ product |
| |
| C++ Curses |
| |
| 8% requested that this should be included in a DEC C++ product |
| |
| ET++ Support |
| |
| 4% requested that this should be included in a DEC C++ product |
| |
| CMA Wrapper |
| |
| 4% requested that this should be included in a DEC C++ product |
| |
| ATIS Wrapper |
| |
| 4% requested that this should be included in a DEC C++ product |
| |
| Function Continuation/Closure Simulation |
| |
| 4% requested that this should be included in a DEC C++ product |
| |
| Infinite Precision Arithmetic |
| |
| 4% requested that this should be included in a DEC C++ product |
| |
+-----------------------------------------------------------------------------+
+-----------------------------------------------------------------------------+
| Excerpts from the Survey's Contributors |
+-----------------------------------------------------------------------------+
This section is intended to give a feel for how the various users replied
to the survey. What is most striking to me, is the amazing enthusiasm which
permeates through the respondant's replies. What follows is a list of res-
ponses to the question:
"How important do you view having a standardized, reuseable, and well-
integrated collection of C++ software components is to a C++ language
product ?"
+-----------------------------------------------------------------------------+
| |
| "*** very important ***" |
| |
| "This is one of the top three factors which influence my opinion and day |
| to day use of C++ Compilers." |
| |
| "This is what SmallTalk did, and this is what made it so easy to use. You |
| don't have to re-invent the wheel each time. The company with the best |
| library is going to be the company with the best C++ sales. It's a given." |
| |
| "If by 'software components', you mean class library, then my response is |
| 'very important'. This comes from my extensive experience on the lisp |
| machine, where classes defining windows, processes, and editors make |
| developing new applications very easy." |
| |
| "I believe this is a very important component for productiv application of |
| a C++ programing environment for solving real (product) problems." |
| |
| "Other C++ products have shipped without a collection of predefined ob- |
| jects, so I wouldn't say this feature would be critical. However, I |
| would **love** to get my hands on a compiler that came with this collec- |
| tion of objects....I think this would help distinguish DEC's offering in |
| this space." |
| |
| "I'm far more interested in getting a modern, reliable C++ compiler to use |
| in program development than any amount of library material that might come |
| with it." |
| |
| "Given a good compiler and debugger, the particular application probably |
| will determine which kinds of libraries are needed; I'm not sure one can |
| easily say which things are more important than others. I'd like to |
| emphasize "the more the merrier", since the more classes there are (in |
| different forms), the more likely we'll satisfy the needs for any given |
| application. But I understand there are resource constraints....." |
| |
| "Very important for product differentiation. Very important to me as a |
| developer. Just look at the ADA toolshed and see how many wheels have |
| been reinvented for ADA!" |
| |
| "At least as important as the standard C libraries are to C. A good set |
| of library objects would help get more people using C++ and it will get |
| those that are using C++ to utilize the OOP features of C++." |
| |
| "Extremely. What I attended the X and C++ BOF at the last X conference |
| the meeting boiled down to customer's grips about the lack of the above." |
| |
| "Critical! I believe this to be the raison d'etre of C++." |
| |
| "Critical in getting our C++ product accepted in the C++ market. All |
| other vendors provide a class library of some sort. The less toy-like |
| the better. If we could indicate that this library was being used to |
| build production quality software within DIGITAL then I think it would |
| be a big selling point." |
| |
| "I think that one or more C++ library offerings will be important to the |
| success of a C++ language product." |
| |
| "In order to compete effectively against other products, extremely." |
| |
| "A set of reusable C++ software components (baseline classes) is very |
| important -- our customers expect to have such a collection: they |
| have the smalltalk (or TRELLIS) model in mind where such a collection |
| exists." |
| |
| "Very important !!!" |
| |
| "Extremely important. So C++ users don't have to pay the initial cost |
| of building commonly used classes." |
| |
| "I would say that it is a MUST for any 'serious' C++ implementation. |
| |
| 1/ Without a common library of components, sharing classes between |
| groups (e.g. Digital) would imply shipping the whole library of |
| base classes. |
| |
| 2/ Code reuse would be nearly impossible without a standard inter- |
| face to basic classes. This is one thing we have to promote |
| internally. |
| |
| 3/ Efficiency would of course be much greater if there [were] one |
| single organization maintaining those classes...." |
| |
| "[Having libraries] is not as important as having a DIGITAL C++ product |
| out as soon as possible." |
| |
| "Although we did not take advantage of any externally developed classes, |
| I suspect that they will become fairly valuable. The biggest key will |
| be good documentation and support as the user will have to be convinced |
| that they can learn how to use the externally developed class faster |
| than developing their own." |
| |
| "All the standard functionality that a user expects in a run-time library |
| or libraries should be useable from C++." |
| |
| "I think this is VERY important, provided that the components are flexi- |
| ble and reusable enough. More about what this means below, but, for ex- |
| ample, I don't think the NIH libraries fill the bill. Though it's impor- |
| tant, it's very hard to do. But if we can [succeed], it will give us a |
| tremendous market edge." |
| |
+-----------------------------------------------------------------------------+
+-----------------------------------------------------------------------------+
| Conclusion |
+-----------------------------------------------------------------------------+
In many ways, I sensed an air of almost desperation among many of the respon-
dents -- particularly among those engineers currently involved in full-scale
C++ developement. Many of these engineers sent me interesting war stories of
their having to write and design extensive non-application specific class lib-
raries before even beginning development on their "real" projects. Clearly,
this is excessive and wasteful when viewed on a corporate scale. For this rea-
son, it is sincerely hoped that DIGITAL's leaders will take notice and begin to
realize that initiating a nontrivial C++ library project, e.g., one which has
a vision beyond merely cloning AT&T's current product offering, is extremely
profitable both in terms of enhancing the sales of any DIGITAL C++ offering,
and in terms of reducing the amount of redundant developement currently going
on within the corporation. For it is fairly obvious that in times of economic
hardship, one possible approach to remaining cost effective is to "empower
the engineer" by providing him with tools enabling him to perform large-scale
software-developement at increasingly higher levels of abstraction with in-
creasingly fewer (human) resources. Libraries and object-oriented application
frameworks lie at the foundation of any such endeavor.
In anycase, perhaps the best summary was provided by Prof. Steve Reiss from
Brown University, the author of FIELD. Simply put, when asked whether DIGITAL
should provide extensive C++ libraries, he snarped:
"yeah....I want them."
+-----------------------------------------------------------------------------+
| Contributors |
+-----------------------------------------------------------------------------+
For a list of the contributors or any other information about this survey,
feel free to send mail to the author, decwet::hansen.
| |||||