my code breaks unique pointer rule?

This is a discussion on my code breaks unique pointer rule? within the C++ Programming forums, part of the General Programming Boards category; Hello everyone, Unique pointer should not allow aliasing. But my code which contains unique pointer aliasing and also compile/run ok. ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    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

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,174
    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".

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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? :-)

    Quote Originally Posted by CornedBee View Post
    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? :-)

    Quote Originally Posted by matsp View Post
    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,


    Quote Originally Posted by grumpy View Post

    In other words, the function is allowed to assume the pointers passed to it are "unique".
    How do you prove that?


    regards,
    George

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #7
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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.

    Quote Originally Posted by CornedBee View Post
    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

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    What's the code that gives you the compile error?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  10. #10
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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;
    }

    Quote Originally Posted by CornedBee View Post
    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.

    Quote Originally Posted by matsp View Post
    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

  11. #11
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #12
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Yes, try passing in the same pointer (value) for both arguments to foo() instead, and see if that's detected.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  13. #13
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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?

    Quote Originally Posted by CornedBee View Post
    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

  14. #14
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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;
    }
    Quote Originally Posted by matsp View Post
    Yes, try passing in the same pointer (value) for both arguments to foo() instead, and see if that's detected.

    --
    Mats

    regards,
    George

  15. #15
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problems passing a file pointer to functions
    By smitchell in forum C Programming
    Replies: 4
    Last Post: 09-30-2008, 02:29 PM
  2. unique pointer issue
    By George2 in forum C++ Programming
    Replies: 11
    Last Post: 02-14-2008, 10:25 PM
  3. Direct3D problem
    By cboard_member in forum Game Programming
    Replies: 10
    Last Post: 04-09-2006, 03:36 AM
  4. towers of hanoi problem
    By aik_21 in forum C Programming
    Replies: 1
    Last Post: 10-02-2004, 01:34 PM
  5. different pointer changes in same code
    By fizisyen in forum C++ Programming
    Replies: 3
    Last Post: 01-14-2004, 09:14 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21