Oh yea! C++ owns j00!
#22
We don't do any C#/.NET here. But from what I hear, C# is very Javaish, and the whole .NET platform seems to me like Microsoft's response to J2EE.
I personally prefer J2EE because it's a standard, whereas .NET is a product, and a proprietary one at that.
I personally prefer J2EE because it's a standard, whereas .NET is a product, and a proprietary one at that.
#23
In actuality, he wasn't really writing C++...he was using it... I'de suggest something more like the following
#include <iostream.h>
class foo
{
public:
foo() { cout << "C++ Ownz Joo"; }
virtual ~foo() {} //Technically not needed here, but good practice to include a destrutor. Don't ask about virtual, I don't feel like explaining polymorphism
};
int main(int argv, char **argc)
{
foo bar; //Construct type foo on the stack, will self-deallocate when object goes out of scope.
return 0; //Standard main exit, no error.. Univerally accepted, where a negative value is typically and error.
}
$.02,
Aaron
p.s. I didn't check that for typo's... but that should be pretty damn close
#include <iostream.h>
class foo
{
public:
foo() { cout << "C++ Ownz Joo"; }
virtual ~foo() {} //Technically not needed here, but good practice to include a destrutor. Don't ask about virtual, I don't feel like explaining polymorphism
};
int main(int argv, char **argc)
{
foo bar; //Construct type foo on the stack, will self-deallocate when object goes out of scope.
return 0; //Standard main exit, no error.. Univerally accepted, where a negative value is typically and error.
}
$.02,
Aaron
p.s. I didn't check that for typo's... but that should be pretty damn close
#26
Aaron,
it's been a while since I've done C++, but doesn't the constructor get called only when you call new?
i.e.,
foo bar = new foo();
Also,
I'd prefer to not have the constructor do any work other than initializing the object states, where necessary, thus perhaps a foo.print() method might be useful.
And... any reason for the polymorphic destructor?
it's been a while since I've done C++, but doesn't the constructor get called only when you call new?
i.e.,
foo bar = new foo();
Also,
I'd prefer to not have the constructor do any work other than initializing the object states, where necessary, thus perhaps a foo.print() method might be useful.
And... any reason for the polymorphic destructor?
#27
The constructor will be called by generation of the object on the heap (as u illustrate above), or by instanciating the object on the stack (as I sampled).
It will work either way:
Fak * eau = new Fak(2);
or
Fak eau(2);
Are functionally equilivant, except the destructor fires on the eau object (in the second example, stack) when the object goes out of "scope"
also, in your previous example, you'de need a "*" between the class type and instance name... as in my example "Fak * eau", since the new operator will return a point to that type (Fak).
It will work either way:
Fak * eau = new Fak(2);
or
Fak eau(2);
Are functionally equilivant, except the destructor fires on the eau object (in the second example, stack) when the object goes out of "scope"
also, in your previous example, you'de need a "*" between the class type and instance name... as in my example "Fak * eau", since the new operator will return a point to that type (Fak).
#28
ok, so if I do
foo *bar = new foo();
I'll need to
delete bar;
right?
It's been a looooong time since I've done C++ programming (back in college). The only real language I've programmed in since I graduated was Java. Other than that, it's ASP (Javascript) scripting in my early days, TCL scripting (also early working days), and UNIX shell scripting, which I still do on occasions.
foo *bar = new foo();
I'll need to
delete bar;
right?
It's been a looooong time since I've done C++ programming (back in college). The only real language I've programmed in since I graduated was Java. Other than that, it's ASP (Javascript) scripting in my early days, TCL scripting (also early working days), and UNIX shell scripting, which I still do on occasions.
#29
As far as the polymorphic destructor, ugh... do I want to go into this?
Basically, any classes which inherit from the base class and need to be 'cleaned up' properly when only the base class type is known, the virtual function causes run-time binding to resolve functions pointers through the VMT (Virtual Method Table).
* Note: Polymorphism is the other reason, hence the example below why draw is resolved properly.. I just don't feel explaining it in the greatest detail..
Test book example (pardon my typos, I'm not going to spell check this or compile it, although it probably will):
//Note: I'm not going to implement the methods..use your imagination...
class Point
{
public:
Point();
virtual ~Point();
virtual void draw();
private:
int x,y;
};
class Square : public Point
{
public:
Square();
virtual ~Square();
virtual void draw();
private:
int x2, y2;
};
class Circle : public Point
{
public:
Circle();
virtual ~Circle();
virtual void draw();
private:
int r;
};
..some random function:
void foo()
{
Point * bar[3];
//Ideally after allocating these, we would have some "init" function which is also virtual and overloaded to set the coordinate, etc...
bar[0]=new Point();
bar[1]=new Square();
bar[2]=new Circle();
//I can then:
for (int i=0; i<3; i++)
bar[i]->draw(); //Notice the correct method is called even those the base class of for bar is type Point.
for (int j=0; j<3; j++)
delete bar[j];
}
Ok..So, in the destruction of bar[j], the proper classes destructor is called, then its parent.. this delete bar[2] (the circle) called ~Circle then ~Point... without the 'virtual' there isn't a run-time bind to resolve what destructor to call (the compiler is doing this for you)... so without it, ONLY the ~point is called for the destruction of the circle... now if circle had allocated memory, or resources, the destructor isn't called, and thus memory/resources can be leaked.
... Hope that clears it up.
-- Aaron
Basically, any classes which inherit from the base class and need to be 'cleaned up' properly when only the base class type is known, the virtual function causes run-time binding to resolve functions pointers through the VMT (Virtual Method Table).
* Note: Polymorphism is the other reason, hence the example below why draw is resolved properly.. I just don't feel explaining it in the greatest detail..
Test book example (pardon my typos, I'm not going to spell check this or compile it, although it probably will):
//Note: I'm not going to implement the methods..use your imagination...
class Point
{
public:
Point();
virtual ~Point();
virtual void draw();
private:
int x,y;
};
class Square : public Point
{
public:
Square();
virtual ~Square();
virtual void draw();
private:
int x2, y2;
};
class Circle : public Point
{
public:
Circle();
virtual ~Circle();
virtual void draw();
private:
int r;
};
..some random function:
void foo()
{
Point * bar[3];
//Ideally after allocating these, we would have some "init" function which is also virtual and overloaded to set the coordinate, etc...
bar[0]=new Point();
bar[1]=new Square();
bar[2]=new Circle();
//I can then:
for (int i=0; i<3; i++)
bar[i]->draw(); //Notice the correct method is called even those the base class of for bar is type Point.
for (int j=0; j<3; j++)
delete bar[j];
}
Ok..So, in the destruction of bar[j], the proper classes destructor is called, then its parent.. this delete bar[2] (the circle) called ~Circle then ~Point... without the 'virtual' there isn't a run-time bind to resolve what destructor to call (the compiler is doing this for you)... so without it, ONLY the ~point is called for the destruction of the circle... now if circle had allocated memory, or resources, the destructor isn't called, and thus memory/resources can be leaked.
... Hope that clears it up.
-- Aaron