I understand your statement, but for our environment, there are some
different
considerations to make.
For example: the programs we are writing are not stand-alone (main)
programs,
but sub-programs, written in ASSEMBLER, PL/1 or C, that have to fit into
a very
sophisticated and complicated (40 year old) framework, which, for example,
cannot tolerate it, if the modules below it do exception handling of
their own.
All exception handling is done in the framework. The features that are
allowed,
for example, in PL/1, are very limited, so that the PL/1 modules behave
correctly
below the framework. In the beginning there was ASSEMBLER only, then in
1980,
PL/1 was added as second language, then in 1993 ca. C as third language.
We didn't allow C++ until today. I'm with this company since 1988 and was
involced in the C integration, but I started there as an ASSEMBLER teacher.
Another example for the restrictions imposed by the architecture: the
parameter
passing mechanisms are also limited, for example, no PL/1 descriptors.
This was
a deliberate design decision in 1980 - the architects then wanted to
make sure that
all modules can call each other, regardless of language, and that a
caller needs not
know the language of the module he or she is calling. The descriptions
of the module
interfaces are written in a language independent way (in a data
dictionary), and the
language specific definitions (normally structure definitions in macros
or include files)
are generated from there - for all three languages.
While this worked very well for us the last 40 years (and still does),
we have a new system
which inherited part of that software and has some new parts, and there
is another kind
of framework, with much less power and also much less restrictions.
Because there are
no restrictions, there are also some parts written in C++. And now, what
happens?
We suddenly have all sort of problems:
- performance problems due to RENT option and WSAs (needed by C++, not
needed
in the old system, where all was naturally reentrant)
- storage management problems, due to lack of storage management
routines in the framework
- lack of DB read/write and communication services in the framework, so
that the modules
have to do basic services themselves; this leads to enormous development
costs,
and the same work is done many times - the communication does not work
in big teams
which are not located at the same site.
Not all of these problems are due to the usage of C++, but many of these
problems
have their origin in
- lack of function in the application framework
- absence of programming standards, which is a killer, if you have many
hundred developers
(in the old system, the programming standards where enforced by
compilers etc.;
this is the only way it works) - you have all sort of programming
styles, which are not always
compatible, all sorts of interfaces, design patterns etc.
etc. etc.
My strong opinion is: things that may work well in small teams and small
projects
(some ten developers), will not work for projects which involve some
hundreds or
thousands of developers. In such a case you need other techniques and
you must be
much more restrictive concerning your programming tools and languages.
Our old
system only succeeded for such a long time (40 years until now), because
of the
strong programming standards and the powerful framework that hosted the
applications.
Of course there are some drawbacks:
- you must be able to adopt the framework at new requests (which we did,
for example:
integrate DB2, LE, MQS etc.)
- you must train the people to code applications for your spezialized
framework
(there is some learning curve for new people coming from outside); so
you have
to have a strong training department - which we had at least the first
35 years -
we don't have it now, because management believes that the old system dies
until 2016 - but this is not possible as it seems today, because it
still does 95 percent
of the business, and the new system only 5.
- you need some smart people to support the framework (this gets more
and more
difficult, because the people who do this now will retire in the next
years)
Well, we'll see what the future brings. At the moment, the old system is
alive and well,
and the new system sucks. Although the new system does only 5 percent of
the work,
it comsumes most of the programming staff and much more machine power
than the
old system.
Kind regards
Bernd
Am 18.09.2012 07:40, schrieb David Crayford:
I consider C++ a much safer language than C, wrt to both string
handling and memory management. In fact, I find it difficult to fathom
why anybody
would still write C code when C++ is such a superior language. Strong
typing alone is worth the effort.
Memory leaks in C++ code are almost always due to a bad design. The
RAII idiom is widely accepted as standard practice these days - resources
are allocated in the constructor and destroyed in the destructor. This
also makes them exception safe. C++ also has proxy based garbage
collection
in the form of smart pointers
http://en.wikipedia.org/wiki/Smart_pointer#C.2B.2B_smart_pointers.
There is a space and time trade-off but it's certainly worth it.
Debugging memory leaks in LE is trivial with the HEAPCHK runtime
option. It will produce a CEEDUMP when the program terminates with a
trace
of all memory allocations that have not been freed, with function
name, offset, module name, storage address and length etc.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
