I agree that string handling with "normal" C string functions is
problematic and
error-prone; here the Pascal heritage (where "strings" are also arrays
of chars)
seems to be a problem.
But I recently had so much problems with C++ strings, that I don't
believe that
this is really a solution. The problem was that there were some C++ classes
which allocated string objects but didn't free them. So over time the
whole heap
storage got used up, and we had no - easy - chance to find the culprit,
given several hundreds
of modules (or DLLs) with C++ code.
In the old (legacy) system, where only C was allowed, we did all storage
allocation
through a site specific malloc replacement, so we were able in a similar
situation
to trace all storage allocations, and more: we registered all storage
allocations in
a linked list (in fact it's a tree structure), and this way, at a
certain point in the
application logic, we could implement
a function that frees ALL remaining storage. So in the legacy system we
never had
such problems that we now have in the C++ system, and we have no chance to
implement a similar "safety belt for storage allocations" in the C++
system,
due to the peculiarities of the C++ storage management scheme. So the
comfortable
C++ runtime features in fact makes it impossible for us to implement
safe schemes
of storage management like we had them before.
C++ is part of the new system mainly because one person suggested it;
the architects of the "old" system advocated against it, but management
decided
not to follow them.
Kind regards
Bernd
Am 05.09.2012 17:59, schrieb Charles Mills:
Well, that's the choice, isn't it? Either you do everything yourself, or the
compiler does things for you.
I really like C++. It provides a framework for organizing a large project
that is invaluable IMHO. If you just evaluate C++ as "is it a better way to
write Hello World?" then the answer is no -- it's just a more complex way.
But for serious product development I find it invaluable.
It also brings along the Standard Template Library. Everyone is fussing
about null-terminated char[] "strings." Well, the problem has been solved:
it's called the STL std::string -- a safe, variable-length (up to 2-gig)
automatic character string with built-in functions like ::compare() and
::append() that interoperates with "old" stuff that requires a char[]-type
"string."
Speaking of the problems of char[] "strings," no one has mentioned
char a[] = "foo";
char b[] = "bar";
if (a > b) printf("this printf will never happen\n");
(Well, probably never happen. The result is implementation-dependent.)
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bernd Oppolzer
Sent: Wednesday, September 05, 2012 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
Good point.
Many of you out there seem to dislike C for such reasons like that discussed
here: you have to take more responsibility for manageing the lengths of the
used buffers etc. - but the same people often like ASSEMBLER, where the
chance to put errors in your program is much higher.
My opinion is: if you handle C carefully and you know about its pitfalls, it
can be a really great implementation language for software that is targetted
not far from the operating system, that is, tools, compilers, parsers, db
systems, embedded applications etc. - but it works also for commercial or
scientific application systems. One of its biggests strengths is
portability. I work with C now for almost 20 years (and with PL/1,
ASSEMBLER, Fortran, Pascal, even COBOL, REXX etc.), and I like C very much.
It is possible to write secure programs in C, if you follow some rules, for
example when using string functions.
C++ is another thing - I would strongly recommend to make a difference.
There are too much strange things happening "under the cover", and I don't
like it, if the programming language does things that I'm not aware of.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
