🚀 go-pugleaf

"Templates I can live without [macros will do for now] but exceptions
would really make my coding life easier."
 
I also feel that built-in exception handling is more important that templates
but, as a library developer, I would really like to have both.  I can kludge my
way around not having these by providing front-end functions for constructors
(for exception handling) and macros (for templates).  For library code, this
creates yet another level of complexity for users of the library that just
isn't necessary.  There's also an issue of whether front-ends for all
constructors in a library should be created.  If not, users may get confused
about which way to create their objects and will likely spend time chasing down
more bugs in their program that should not have been there in the first place.
These are probably expensive bugs since they may not be uncovered until the
product has actually shipped.  If front-ends are provided for a library (and
that could be a lot of unnecessary work itself), then how about the
constructors for the other libraries that someone may want to use for their
program?  The case I'm trying to build is that all of this confusion is really
not necessary with exception handing built into the compiler.
 
Templates would also be very helpful to library developers that provide
collection-type classes.  One interface to a particular type of collection
class is all that is needed with templates.  Users can then instantiate these
collection classes using whatever types they want.  The alternatives are to get
the library developer or the application programmer to either create derived
collection classes for each type the application programmer wants the
collection to contain or to create a macro to do the same thing.  The template
option is much simpler and consistent from both the library developer and
client points of view.
 
Is there a technical reason why exceptions and templates have not been built
into the MPW C++ compiler?  I hear the ANSI committee has completed the
specifications.  I would suspect that AT&T has already built these into a
CFront that they have laying around somewhere.  What gives?  Is Apple going to
move to adopt the ARM or ANSI in its C++ compiler?
 
...climbing higher on soapbox...
 
Software engineering is very, very expensive these days.  The types of programs
that we create are much more complex than even a few years ago.  With more
powerful hardware just over the horizon, I see these problems getting worse
instead of better.  While the current programming tools are better than they
used to be, I think we need a fundamental change (egad) in the way we develop
software if we want to meet our customers expectations.  This means developing
more complex software that does what the user wants, is very reliable, and is
less expensive that it is today.  We can use assemblers and low-level debuggers
to create "insanely great" products but the cost is very high.  We can use more
integrated object-oriented techniques and development environments that contain
editors, object-oriented programming tools (i.e., compilers, linkers), and
debuggers.  Even then, we have problems managing the complexity and reliability
without huge budgets, long testing periods, and maintenance releases that
contain bug fixes.
 
We need better ways to get from user requirements to finished product reliably
and quickly.  We need integrated tools that track these requirements and allow
us to create solutions that, in turn, generate working programs.  The solution
part of the system would help us manage the complexities of the program from
concept to code.  We should be able to deal with the solution at whatever level
of abstraction that we want.  This would help people to learn existing systems
easier.  We should have tools at the low-level that help prove that the
software is reliable.  Does something like this exist anywhere or is anyone
working on something that does these things?  If not, does it seem worthwhile?
Am I off in the weeds?  My guess is that a lot of the technology for these
things already exist but not in an integrated form.  This may not be the forum
to discuss these sort of things.  If not, where could this discussion be moved?
 
...climbing down from soapbox...
 
Dave Lucky
Progressive Computing, Inc.