my code breaks unique pointer rule?

Hello everyone,


Unique pointer should not allow aliasing. But my code which contains unique pointer aliasing and also compile/run ok. Anything wrong?

Code:

__interface IFoo {

public:

	virtual int foo ([unique] char  *ptr1, [unique] char  *ptr2) = 0;
};

class Foo : public IFoo {

public:

	int foo (char  *ptr1, char  *ptr2)
	{
		char array1[] = "Hello";

		ptr1 = array1;
		ptr2 = array1; // should be wrong, no aliasing allowed, but compile and run ok
		
		return 0;
	}
};


int main()
{
	char* ptr1 = 0;
	char* ptr2 = 0;

	Foo f;
	f.foo(ptr1, ptr2);

	return 0;
}

thanks in advance,
George

I'm no expert on Microsoft extensions but I suspect, in this case, the unique keyword is an attribute of the pointer passed by the caller (i.e. main()), not to whatever the function might do to the argument.

In other words, the function is allowed to assume the pointers passed to it are "unique".

That's one part of it.

The second part is that the attribute might not be inherited. It could be part of the co-variance principle (overriding methods may be more lax in what they accept - note that this is a principle from type theory, NOT C++), or it could simply be an implementation issue.

Or the attribute could simply be not enforced. Do you know if the compiler actually uses flow analysis to enforce the attribute?

I have a felling the compiler doesn't actually CHECK the unique-ness of the pointer [for more complex cases it would be impossible to know anyways], but it's more like a contract - you promise to follow your part of the contract, and if you don't the "penalty clause" gets enforced, e.g. the behaviour of the called function is undefined.

--
Mats

Thanks CornedBee,


When I add [unqiue] to Foo class, compile not pass and compile error is,

1>d:\visual studio 2008\projects\test_uniquepointer1\test_uniquepoint er1\main.cpp(12) : error C3115: 'unique': this attribute is not allowed on 'ptr1'
1> d:\visual studio 2008\projects\test_uniquepointer1\test_uniquepoint er1\predefined c++ attributes (compiler internal)(1155) : see declaration of 'unique'
1> attribute can only be applied to: 'member', 'interface member function', 'formal argument of interface member function', 'typedef'

if you think we can make the pointer unique by adding the unique attribute to the foo method of class Foo, could you show me how to solve the compiler error please? :-)

Originally Posted by CornedBee

That's one part of it.

The second part is that the attribute might not be inherited. It could be part of the co-variance principle (overriding methods may be more lax in what they accept - note that this is a principle from type theory, NOT C++), or it could simply be an implementation issue.

Or the attribute could simply be not enforced. Do you know if the compiler actually uses flow analysis to enforce the attribute?

Good point, Mats!


Do you have any suppor documents from MSDN or? :-)

Originally Posted by matsp

I have a felling the compiler doesn't actually CHECK the unique-ness of the pointer [for more complex cases it would be impossible to know anyways], but it's more like a contract - you promise to follow your part of the contract, and if you don't the "penalty clause" gets enforced, e.g. the behaviour of the called function is undefined.

--
Mats

Thanks grumpy,

Originally Posted by grumpy

In other words, the function is allowed to assume the pointers passed to it are "unique".

How do you prove that?


regards,
George

if you think we can make the pointer unique by adding the unique attribute to the foo method of class Foo, could you show me how to solve the compiler error please? :-)

I have no idea what you're talking about. In my opinion, you're spending way too much time on a MS compiler extension.

Thanks CornedBee,


I am learning COM/ATL so I need to learn some Microsoft extensions and doing practices. :-)

What I am asking in last post, is about you mentioned before in post #3,

--------------------
The second part is that the attribute might not be inherited. It could be part of the co-variance principle (overriding methods may be more lax in what they accept - note that this is a principle from type theory, NOT C++), or it could simply be an implementation issue.

Or the attribute could simply be not enforced. Do you know if the compiler actually uses flow analysis to enforce the attribute?
--------------------

Looks like you mean the root cause is, I only add [unique] to interface IFoo and not add [unique] to class Foo? Right?

If yes, my question is, could you show me how to add [unique] to class Foo please? I have tried, but there is compile error. I have showed above in post #5.

Originally Posted by CornedBee

I have no idea what you're talking about. In my opinion, you're spending way too much time on a MS compiler extension.

regards,
George

I have no support for my surmising, I'm just speculating based on your statements - if the compiler doesn't complain for an obvious case, it seems reasonable that the reason is that the compiler doesn't check (properly).

--
Mats

What's the code that gives you the compile error?

Thanks CornedBee,


Here is the whole code,

Code:

__interface IFoo {

public:

	virtual int foo ([unique] char  *ptr1, [unique] char  *ptr2) = 0;
};

class Foo : public IFoo {

public:

	int foo ([unique] char  *ptr1, [unique] char  *ptr2)
	{
		char array1[] = "Hello";

		ptr1 = array1;
		ptr2 = array1; // should be wrong, no aliasing allowed, but compile and run ok
		
		return 0;
	}
};


int main()
{
	char* ptr1 = 0;
	char* ptr2 = 0;

	Foo f;
	f.foo(ptr1, ptr2);

	return 0;
}

Originally Posted by CornedBee

What's the code that gives you the compile error?

Thanks Mats,


I have got your idea. But maybe my code is wrong and does not enfoce unique property correctly.

Originally Posted by matsp

I have no support for my surmising, I'm just speculating based on your statements - if the compiler doesn't complain for an obvious case, it seems reasonable that the reason is that the compiler doesn't check (properly).

--
Mats

regards,
George

Well, that just goes to show. From the compiler message:

formal argument of interface member function

Can't put the attribute on implementation member arguments. And it also indirectly confirms that the attribute is about what the caller (main(), in this case) does, not about what the implementation does.

Yes, try passing in the same pointer (value) for both arguments to foo() instead, and see if that's detected.

--
Mats

Sorry CornedBee,


I do not agree with you. From the following MSDN link, about unique pointer's non-aliasing property,

http://msdn2.microsoft.com/en-us/lib...94(VS.85).aspx

Does not cause aliasing. Like storage pointed to by a reference pointer, storage pointed to by a unique pointer cannot be reached from any other name in the function.

You can see the restriction is in the function (foo in my case), not outside (in main), right?

Originally Posted by CornedBee

Well, that just goes to show. From the compiler message:


Can't put the attribute on implementation member arguments. And it also indirectly confirms that the attribute is about what the caller (main(), in this case) does, not about what the implementation does.

regards,
George

Sure Mats,


It is allowed. Here is the code. Any comments?

Code:

__interface IFoo {

public:

	virtual int foo ([unique] char  *ptr1, [unique] char  *ptr2) = 0;
};

class Foo : public IFoo {

public:

	int foo (char  *ptr1, char  *ptr2)
	{
		char array1[] = "Hello";

		ptr1 = array1;
		ptr2 = array1; // should be wrong, no aliasing allowed, but compile and run ok
		
		return 0;
	}
};


int main()
{
	char* ptr1 = 0;
	char* ptr2 = 0;

	Foo f;
	// f.foo(ptr1, ptr2);
	f.foo(ptr1, ptr1);

	return 0;
}

Originally Posted by matsp

Yes, try passing in the same pointer (value) for both arguments to foo() instead, and see if that's detected.

--
Mats

regards,
George

Yes, so the function is guaranteed that the data from the "unque" pointer is not reachable from any other pointer - this is a gurantee that the paraemeter coming into the function is unique, not necessarily that it actually is unique inside the function.

--
Mats