Re: Class objects work like built-in types, but is it worth it?
On 2008-10-26 04:29, tonytech08 wrote:
On Oct 24, 11:39 am, Erik Wikstr??m <Erik-wikst...@telia.com> wrote:
On 2008-10-24 02:01, tonytech08 wrote:
On Oct 23, 1:12 pm, Erik Wikstr??m <Erik-wikst...@telia.com> wrote:
On 2008-10-23 19:38, tonytech08 wrote:
On Oct 23, 12:13 pm, Erik Wikstr??m <Erik-wikst...@telia.com> wrote:
On 2008-10-23 13:41, tonytech08 wrote:
How valuable is it that class objects behave like built-in types? I
appears that the whole "constructor doesn't return a value because
they are called by the compiler" thing is to enable built-in-like
behavior for objects of class type. That leads to the "necessity" for
the exception machinery so that errors from constructors can be
handled. Is all that complexity worth it just to get built-in-like
behavior from class objects? Maybe a better architecture would be for
built-in types and class object types to be accepted as fundamentally
different animals and forego the extensive machinery required to
shoehorn class objects into being something they are not!
The reason for exceptions is that they allow for a much better and
simpler error handling than to old way of return-codes. In fact even
languages which does not have object might have exceptions (such as ML,
a functional language).
Apparently though, it's not a should we/shouldn't we implement
exceptions in the language, it's they HAD to (which brings the obvious
question if that is the main reason. I do think it is the main reason,
for many developers don't use exceptions unless they have to, such as
in constructors, operators etc). Not to be argumentative though, I'm
trying to decide whether class objects behaving like built in types is
worth all the complexity that brings. Perhaps only certain (a very
small subset) classes should be coded as "orthodox canonical
form" (Coplien) classes that may need exceptions.
I think most here will agree (you among them) that OO-programming is a
better paradigm than earlier paradigm such as procedural programming.
Well I like having objects (classes) available, yes. That's not to say
I don't also program procedurally. I just evaluate the problem and
create appropriately. Every C++ program starts up procedurally of
course (calls main, a function not belonging to an object).
So
if we regard C++ from an OO perspective the question becomes the
reverse: "Should built-in types behave like objects?"
Good point. If it means deriving everything from "Object" as in
Smalltalk, I think the answer is no. I don't know enough about
representations of things like integers at the machine level to
address that. I am curious to know though (read, I wish I had that
knowledge).
Having every object derive from an Object base class is not necessary,
for some languages it makes things much easier such as C# and Java
(though they did not go all the way). I don't see the need for it in C++
and I do not think it is desirable either.
? Personally I
think that they should and I think that the current state of affairs is
sub-optimal.
Well if fundamental inquiries don't bore you or aren't unworthy of
your time, do tell a little bit if it can be conveyed concisely (some
subjects can be short-circuite like that, I know). Not that I have
time to learn assembly or microcode, but that I can relate to it and
"get it" (as others may want to also).
It is not about machine code representations and stuff like that. What
I'm talking about is the fact the you have to write stuff like
std::numeric_limits<int>::max()
to get the highest representable value of an int, instead of just writing
int::max
just as if int was a class with a const static public member with the
largest representable value. I think that with modern compilers the
amount of work required to make something like the following perform
just as well as built-in types should be minimal.
class Int
{
int Val;
public:
static const int max;
static const int min;
Int() { }
Int(const int& i) : Val(i) {}
Int(const Int& i) : Val(i.Val) { }
Int& operator=(const int i) { Val = i; return *this; }
Int& operator=(const Int i) { Val = i.Val; return *this; }
operator int() { return Val; }
friend Int operator+(const Int& a, const Int& b)
{
return Int(a.Val + b.Val);
}
};
const int Int::max = std::numeric_limits<int>::max();
const int Int::min = std::numeric_limits<int>::min();
Some experimenting shows only small differences in the produces assembly
for addition of two Int objects and addition of two ints.
Personally I have successfully (in my opinion at least) programmed
object oriented in C++ (and other languages) for a number of years now
and the majority of the exceptions thrown in my code does not come from
constructors or other constructs used to make objects behave like built-
in types.
My guess is that you probably avoid that situation, as do I which
kinda brought up the topic.
No, I just do not end up in those kinds of situations, but I do suppose
it depends on what kinds of applications you are writing, and how you
wish to handle allocation-errors (I generally do not handle them).
--
Erik Wikstr??m