And I should have called it the implicit conversion operator. It's a
good example of how to use C++ as a better C to make use of destructors.
On 31/05/2017 9:41 PM, David Crayford wrote:
Re-posted due to formatting issues:
I think I should have used the term object based for non-OO languages.
Scope based finalization is a sweet spot of C++ with scoped based
destructors. I'm coding a lot of Java at the moment and having to code
finally blocks or use the try-with-resources statement is tedious. But
my point was mainly about polymorphism and how it can be implemented
in languages that have function pointers. Of course, in a language
that has no destructors or finalization you have to explicitly call a
destructor.
Here is a nifty piece of C++ code that wraps the C stdio FILE
structure which implements RAII to call fclose() by using a implicit
pointer operator! It's one of the many C++ features many people are
not aware of. Props to Jerry Coffin who invented it.
class file {
typedef FILE *ptr;
ptr wrapped_file;
public:
file(std::string const &name, std::string const &mode =
std::string("r")) :
wrapped_file(fopen(name.c_str(), mode.c_str()))
{ }
operator ptr() const { return wrapped_file; }
~file() { if (wrapped_file) fclose(wrapped_file); }
};
-----------------------------------------------------------------------------
file f("myfile.txt", "w");
if (!f) {
fprintf(stderr, "Unable to open file\n");
return 0;
}
fprintf(f, "Hello world");
On 31/05/2017 9:06 PM, Charles Mills wrote:
There's no reason why you can't write OO code in assembler.
And there's no reason you could not write OO code by keying the bits
in through a debugger.
The point of the OO constructs is not that there is no other way to
do things. Obviously, any object program that can be produced by a
compiler could have been written in HLASM.
The point of OO constructs is never having to say "was there
something I was supposed to call when I was finished with this record
(DSECT, struct, class, ...)?" What was its name? Where is the pointer
to it? What are the calling parameters? Or worse, I just realized I
am going to need a cleanup routine for this record. Now I have to go
back and make sure that every piece of code that uses it gets
modified to call the cleanup routine. You just delete the class and
if it has a destructor, it gets called. Voila!
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Crayford
Sent: Tuesday, May 30, 2017 7:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about C++
On 30/05/2017 9:52 PM, Charles Mills wrote:
You're trying to scare the poor man!
After I learned OO, I realized the problem in trying to communicate
the concepts.
- The easy-to-grasp explanations are stupid: Animal is a class. Dog
and Cat are child classes of Animal. Fido is an instance of Dog. You
could have an inherited public overridden method Speak() and say
myAnimal.Speak() and if it were a Dog it would bark and if it were a
Cat it would Meow ...
Agreed. Inheritance should generally be avoided anyway. It has it's
place but composition should be preferred 9 times out of 10.
Inheritance is tightly coupled and can become incomprehensible once
it gets a few layers deep.
- The real problems that are solved by the significant features are
too hard to explain in a simple tutorial. I solved a problem the
other day with a very sparsely-implemented virtual polymorphic
method -- but it would take me an hour to explain what the problem was.
Polymorphism is the key principle and you don't need an OO language
to use it. Any language with function pointers can implement
polymorphism.
A case in point is the z/OS C stdio runtime which supports many
different types of data source. fopen() is the factory function which
populates the read/write (virtual) function pointers in the FILE
structure. There's no reason why you can't write OO code in
assembler. I see lots of assembler code with constitutional logic
littered throughout which call different functions depending on some
type which would benefit from an OO design.
----------------------------------------------------------------------
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