With a complex language, somewhat complicated tasks can be done relatively quickly, but also the opposite is true.
For example, calling a non-static member function in C++ using the function's address is not allowed. Say you have a class
1 2 3 4
class X
{ public:
int foo(int bar);
};
Then the function foo has an extra parameter - const X* this. Now, what is the C equivalent x.foo(bar); - is it foo(bar, &x);, or is it foo(&x, bar); ? So, using classes we gained a streamlined way of relating data to functions, but we also introduced complexity (in what order is the this pointer passed? An object cannot delete itself - deletethis; is not allowed as this is const X*).
So, in C++ if I want to call member functions by their addresses, I need to write static "wrapper" functions, like
1 2 3 4 5
class X()
{
int foo();
staticint foo(X& x){return x.foo();}
};
Uh... Where did the const come from? Do you mean 'X * const'? That's not right either because this doesn't behave as a pointer:
1 2 3
X * const p=this;
*(X **)&p=this+1; //undefined behavior but compiles
*(X **)&this=this+1; //doesn't compile (non-lvalues have no address)
in what order is the this pointer passed?
Why would such a low level detail matter? For starters, the calling convention could even be to pass this through a register, in which case the question is meaningless.
An object cannot delete itself - delete this;
Sure it can. It's just usually not advisable.
OOP does introduce complexity, but neither of those are examples of it.
So, in C++ if I want to call member functions by their addresses, I need to write static "wrapper" functions, like [...]
C doesn't really include any algorithms or data structures in its standard library other than qsort().
That was also why in the old C days, developers or companies that cannot afford commercial C libraries resort to implement themselves. That alone takes a lot of time and a lot of testing to get it right. But the most important part is after all is done only then can you use them to build your business applications using them.
Tell me frankly, will end users have the patience to wait so long to use an application? In those days, options are limited and hence in a way end users expect a long wait time for new application release but fast forward to current days, this is no longer true. Other companies have resorted to other "faster" programming language and yet deliver working usable applications! End users are delighted and they will give their business to them instead of your company isn't it?
As developers we go with the times and not remain static on a sweet spot that you are very familiar and entrenched in. So say Java is norm currently, who knows 10 years down the road another new programming language take the world by storm and you bet I will be catching the wind also :P
#include<iostream>
class X
{
public:
void foo(int recursion)const
{ const X* x=this;
std::cout << x;
if (recursion<2)
{ recursion++;
x->foo(recursion);
}
deletethis; //!!!!this did indeed compile. However, I do have memories
// that on at least one version of one compiler (I think the Microsoft one), I did see an error
//when trying to compile delete this...
}
};
int main()
{ int x;
X y;
y.foo(0);
std::cin >> x;
return 0;
}
However, I do have memories that on at least one version of one compiler (I think the Microsoft one), I did see an error when trying to compile delete this...
Deleting this is perfectly syntactically legal in any non-const non-static member function. Like I said, though, It's rarely a good idea. For one, I'm not sure whether this needs to point to a valid object for the duration of the call for its behavior to be defined.