Do I need to learn C before C ++?

[meBigGuy]

You are making exactly the point I have been propounding all along. It seems to me that you are agreeing with me while disagreeing with me.

No, I'm not reacting to you at all. The fact that C++ is built on top of C is not at issue (at least not for me). It's whether you learn the C basics before learning the higher level constructs. I'm a strong proponent for learning the basics first, but as has been mentioned there are courses that explicitly state that no C knowledge is required.

In any C++ course a person who already knows C will always have an easier time of it than a person who does not.

 

[Mark44]

No, it's not that we have a function pointer element in a struct. But it's a real method.

The member functions in a C++ class are typically implemented as pointers, same as what I was talking about.

Remember, that class without methods works like struct. Just member variable.
But in struct, you can't derive it, you can't inherit it.

You can simulate derivation by having a struct member that is itself a struct.

And I'm pretty sure there are no virtual/dynamic method in struct.

Of course, you can't get all of the OOP features of C++ in C, because C is roughly a subset of C++.

Frankly, I never used method in struct before. I just read in the C++ book, that it can do that. I only use class and played around with operator overloading.

 

[Stephanus]

The member functions in a C++ class are typically implemented as pointers, same as what I was talking about.

You mean in Test1 or Test2?

class Test1 {
   public: 
     int MyVar;
     int MyFunction(int b) { return(b*10); }
};

class Test2 {
   public:
     int MyVar;
     int (*MyFunction) (int);
};

int main()
{
  Test1 Test1Var[1000]; 
  Test2 Test2Var[1000];
}

Now, I'd say that Test2Var takes up more memory then Test1Var, IF we implement the member function as pointer.

 

[Mark44]

You mean in Test1 or Test2?

I mean in both.

class Test1 {
   public:
     int MyVar;
     int MyFunction(int b) { return(b*10); }
};

class Test2 {
   public:
     int MyVar;
     int (*MyFunction) (int);
};

int main()
{
  Test1 Test1Var[1000];
  Test2 Test2Var[1000];
}

Now, I'd say that Test2Var takes up more memory then Test1Var, IF we implement the member function as pointer.

I wouldn't say that. I would bet that both classes are exactly the same size.

 

[Stephanus]

I mean in both.

I wouldn't say that. I would bet that both classes are exactly the same size.

I think Test2Var takes up more space.
We just can't sizeof(a class). If we sizeof it, it would return 4, the size of the pointer. But...
Test1::MyFunction is a method
Test2->MyFunction is a variable, which is a pointer of a method.
In a class, you can new 1000 objects of that class. Only the variables are created. But there is only 1 method.
In Test2, since MyFunction is a variable it's included in every objects that are created.
We define a class, we create an object.

 

[Mark44]

I think Test2Var takes up more space.

I compiled your code (VS 2013), and a Test2 instance does take up more space, at least the MSFT does it, which is probably an implementation detail. The last time I checked, which was about 20 years ago, I believe that they implemented class methods as pointers to code, but they don't seem to do that any more.

We just can't sizeof(a class). If we sizeof it, it would return 4, the size of the pointer.

But you can take sizeof an instance of a class.

 

[Stephanus]

I compiled your code (VS 2013), and a Test2 instance does take up more space, at least the MSFT does it, which is probably an implementation detail.

How do you know? You increase the size of the array say.. 1000000 elements, and see the remaining memory in your computer?
And Mark, I forgot something. IF you define Test1::MyFunction as virtual not as static, I think it Test1 Test1Var[10000], will take some memory, because the compiler needs to store its address. But that's how it works in Pascal. I think the same goes to C++, too.

I The last time I checked, which was about 20 years ago, I believe that they implemented class methods as pointers to code, but they don't seem to do that any more.

Really?

But you can take sizeof an instance of a class.

In Pascal, we can't sizeof the instance of the class. How you do that in C?
MyClass *MyClassVar;
x = SizeOf(MyClassVar) will give you 4.
x = SizeOf(MyClassVar*), like this?

 

[Stephanus]

Correction.

... IF you define Test1::MyFunction as virtual not as static, I think it Test1 Test1Var[10000], will take some memory, because the compiler needs to store its address. But that's how it works in Pascal. I think the same goes to C++, too.

No. It doesn't work that way.
The compiler doesn't have to store virtual method pointer in the class. The compiler stores it in the class definition. For each class (not object) that we define, the compiler reserved some memory for their VMT, virtual method table. And some static function pointer.
Test1Var[100000] still takes a little memory. The compiler does not store the address of MyFunc, even if it is a virtual method.
I guess so.

 

[Mark44]

I compiled your code (VS 2013), and a Test2 instance does take up more space, at least the MSFT does it, which is probably an implementation detail.

How do you know? You increase the size of the array say.. 1000000 elements, and see the remaining memory in your computer?
And Mark, I forgot something. IF you define Test1::MyFunction as virtual not as static, I think it Test1 Test1Var[10000], will take some memory, because the compiler needs to store its address. But that's how it works in Pascal. I think the same goes to C++, too.

I didn't bother creating an array of objects of each type, just one of each. My program used the sizeof operator to determine how many bytes were used by each of the two objects

I The last time I checked, which was about 20 years ago, I believe that they implemented class methods as pointers to code, but they don't seem to do that any more.

Really?

That's the way I remember it.

But you can take sizeof an instance of a class.

In Pascal, we can't sizeof the instance of the class. How you do that in C?
MyClass *MyClassVar;
x = SizeOf(MyClassVar) will give you 4.
x = SizeOf(MyClassVar*), like this?

Yes, except that the operator is sizeof in C/C++

 

[Stephanus]

I didn't bother creating an array of objects of each type, just one of each. My program used the sizeof operator to determine how many bytes were used by each of the two objects.

I think the result of A=sizeof(ClassType*) could be misleading. There are additional variables involved.

But that is in the declaration for each class definition not each class instance that the compiler generate.
And it's in Pascal. Perhaps C compiler generates some table, too for each of their class definition declared.

Yes, except that the operator is sizeof in C/C++

Come on, I've been doing Pascal 90% than C. And in your later years as a progammer, you wouldn't use sizeof anymore. You might have known the size of the variables you once define them.
I think learning C in C++ compiler is Ok. As long as the beginner doesn't go straight to OOP.
I'm impressed with @jtbell 's approach.

I didn't do pointers (or OOP [added by me]) until near the end of the course...

... I remember having trouble ... to motivate introducing pointers. "OK, here's what I'd like to do, but none of the tools we've learned so far can accomplish it. So here's something new: pointers. (or OOP [added by me])"

 

[Stephanus]

And in your later years as a progammer, you wouldn't use sizeof anymore. You might have known the size of the variables you once define them.

Oops, sorry.

#define ArrSize 100
int a[ArrSize];
int *p;
p=malloc(ArrSize*sizeof(int)); // much better than
p=malloc(ArrSize*4);

It's a good discussion we have. Add more insights for me.

 

[jtbell]

The original question posed by this thread has been answered. The thread is now veering around in different directions related to C versus C++ with some Pascal thrown in. (I admit to being guilty of contributing to this.) This thread is now closed. If someone wants to continue one of these veered-off discussions in a new thread with a focused title, please feel free to do so.