Re: extending c++ classes and enumerations
Alf P. Steinbach skrev:
* perrog@gmail.com:
// File enum.h
enum ThreadState { ERROR = -1, RUNNING, TERMINATED };
extend enum ThreadState { CANCELED };
Thanks in advance.
Yes, it could be useful, but... ;-)
First, when extending an enumeration type you're up agains the "Is a
circle an ellipse" conundrum. The answer is, a const circle is a const
ellipse. For a non-const circle it's not so; consider
...
Second, enumerations are generally -- not in all cases but generally
-- a sign of purely procedural non-OO code, which could much better be
recast at the design level in some OO way than focusing on language
level patches to the some of the mildest symptoms the code exhibits.
So you mean that to make this story work properly, C++ would require
another keyword, say "set", and statements like.
class Thread {
set ThreadState { ERROR = -1, RUNNING, TERMINATED };
};
class CancelableThread: public Thread {
set ThreadState : Thread::ThreadState { CANCELLED };
};
By the way, all uppercase should be reserved for macro names.
All uppercase for macros is an old convention dating back at least to
K&R C, wherefrom Java picked it and associated it with a slightly
different meaning, incompatible with the C and now C++ rationale, so the
above is indicative of Java background -- don't do that in C++ code.
That is absolutely not related to C++ grammar. :-)
Similar "convention" seems to be applied to accessors.
class Employee {
Employ& setName(const std::string &name);
std::string &getName();
const std::string &getName() const;
std::string name;
};
and this creates a property, an intermediate form between structure
function and field.
And used like
Employe person("Roger");
cout << person.Name << endl; // prints "Roger"
person.Name = "Fritz";
cout << person.Name << endl; // prints "Fritz"
There is a Java web server, where the view layer that generates XML
code maps similar kinds of Java functions to a data accesors in a
PHP-Smarty similar language. I personally think Microsoft's C# accessor
syntax is the "correct" way to handle accessors,
class Employee {
Name { get { return name; } set { name = value; } }
String name;
};
Have only heard rumours about Objective-C 2.0 @property syntax, but not
checked it yet.
Anyway, with the current RTTI level in C++, I think naming convention
plays a minor role. :-)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]