C++ is a horrible language ~ Linus Torvalds

Pages: 123
closed account (1yR4jE8b)
Couldn't the same be said for C?

C doesn't really include any algorithms or data structures in its standard library other than qsort().


Using memset to zero an array is cheating and leads to messy, unmaintainable code. You should be using a for-loop or inline assembly.

Using qsort leads to messy code, the only way you can know for sure is to write your own implementation of quick sort.

C expects you to know these things or at least have a vague understanding how zeroing memory or sorting arrays work.

/sarcasm
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 - delete this; 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();
static int foo(X& x){return x.foo();}
};
Last edited on
const X* this
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 [...]
What about member function pointers?
Last edited on
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
@helios: I do think the syntax is const X* x=this; is correct (using default gcc on latest updated version of ubuntu):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#include<iostream>

class X
{
  public:
  void foo(int recursion)const
  { const X* x=this;
    std::cout << x;
    if (recursion<2)
    { recursion++;
      x->foo(recursion);
    }
    delete this; //!!!!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;
}




Last edited on
const X* x=this; compiles the same way const int x = 5; does.
To see the type of this, you only need to compile
1
2
3
4
5
6
7
8
9
10
11
12
13
#include <iostream>
#include <typeinfo>
 
struct thing{
   const char* type(){
      return typeid(this).name();
   }
};
 
int main(){
   thing t;
   std::cout << t.type();
}
You are right: the this pointer is not const! Dunno how I got confused about it...

@hamsterman: the code you posted compiles very funny on my ubuntu's gcc: got output

P5thing
Last edited on
I know, I got the same on ideone (don't have a C++ compiler of my own, currently). Though I'm sure MSVC would produce a nice "thing* const".
closed account (1vRz3TCk)
Though I'm sure MSVC would produce a nice "thing* const"

or "struct thing *".
Last edited on
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.
Topic archived. No new replies allowed.
Pages: 123