little explanation-operator () overload

Hello,
can anybody explain me the difference between these two memory allocations:

Code:

#include <iostream>
using namespace std;

class Test
{
	/*something here*/
public:
	void operator() ()
	{
		cout<< "Operator()";
	}
};

int main()
{
	Test * pT = new Test;
	Test * pT2 = new Test();
}

I thought that that there is no difference except in case where operator() is overloaded but it seems that isn't true.
I need explanation about difference between Test and Test() in allocation.
Thanks

Code:

Test * pT = new Test;
Test * pT2 = new Test();

I think they are the same thing, the overloaded operator() will be used with the variable itself, like:

Code:

Test b;
Test* a = new Test();
...
b();
(*a)();

I think the overloaded operator() will only work like that. I'm not sure of this though.

This should indicate what is happening:

Code:

#include <iostream>
using namespace std;

class Test
{
	/*something here*/
public:
	
	Test()
	{
		cout<<"default constructor called."<<endl;
	}
	void operator() ()
	{
		cout<< "Operator()";
	}
};

int main()
{
	Test * pT = new Test;
	Test * pT2 = new Test();

	(*pT)();

	delete pT;
	delete pT2;
	
	return 0;
}

Note that there is a difference between these two:

Code:

Test T1;
Test T2();

>> Note that there is a difference between these two:

how so?

Originally Posted by Sebastiani

>> Note that there is a difference between these two:

how so?

becuase the second is a tricky b@$tard!

Code:

class X
{};

X anX; // constructs an object of type X, right?

X anotherX(); // does the same, just explicitly calls the default constructor, correct?

NOPE!

what if I type

Code:

X getX(); // obviously a function declaration returning X
// NOT A INSTANCE OF AN OBJECT!

I didn't actually believe this until I tried it. Scott Meyers calls it "C++'s most vexing parse"

BTW you can get around this, by requiring functions with no arguements to take void in your coding standard.
e.g.

Code:

void DoStuff(void);

I actually think there should be a compiler switch to require this, at least as a warning.

>> BTW you can get around this
I'm not sure how the coding standard would help there, since you generally make that mistake attempting to create the variable (with the empty parentheses) rather than when trying to create a function.

A compiler warning might be nice, though.

Originally Posted by Daved

>> BTW you can get around this
I'm not sure how the coding standard would help there, since you generally make that mistake attempting to create the variable (with the empty parentheses) rather than when trying to create a function.

A compiler warning might be nice, though.

You could setup splint to require all parameterless functions to require (void), which would be a start.

I guess it doesn't really help that much.

>> Scott Meyers calls it "C++'s most vexing parse"

right, I overlooked that. of course the ambiguity would only apply to objects declared outside any function.

Originally Posted by Sebastiani

>> Scott Meyers calls it "C++'s most vexing parse"

right, I overlooked that. of course the ambiguity would only apply to objects declared outside any function.

no, unforunatly it doesn't.

for the following code

Code:

class X
{
public:
	void DoStuff(void)
	{
	}
};
void func(void) // following my own coding standard :-)
{
	X x();
	x.DoStuff();
}

VC7.1 gives the following error:
error C2228: left of '.DoStuff' must have class/struct/union type
type is 'overloaded-function'

if you don't have the call to DoStuff you get the following warning (on level 4)
'X x(void)': prototyped function not called (was a variable definition intended?)

I was completely ignorant of that - I didn't even know the language allowed function prototypes within functions. IMO a completely ridiculous feature: not only does it degrade the overall sensibility of the language, there probably aren't many people that actually use it!

thanks for pointing that out, guys.

Originally Posted by Sebastiani

I didn't even know the language allowed function prototypes within functions. IMO a completely ridiculous feature: not only does it degrade the overall sensibility of the language, there probably aren't many people that actually use it!

'Tis merely limiting the scope. If you only want a function to be able to used in one particular function, rather than being available to every function in a module, then that is a pretty legitimate use. Just like with "global" variables.

I thought that was what namespaces were for.

I thought namespaces were for avoiding clashes between identifiers.