Like Tree3Likes

Does the following code show undefined behaviour ?

This is a discussion on Does the following code show undefined behaviour ? within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by manasij7479 Don't we have move for that...when needed ? Move doesn't really transfer ownership though... move just ...

  1. #16
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,704
    Quote Originally Posted by manasij7479 View Post
    Don't we have move for that...when needed ?
    Move doesn't really transfer ownership though... move just makes an rvalue reference out of some expression, whether it is actually an rvalue or an lvalue. You would use std::move in combination with an rvalue reference operator= that swaps and the swap actually does the exchange.

    I'm just returning it to provide an interface tor linked structures' referenced node(s).
    Yeah, well, if you're returning an actual node, think really hard about that because you might be jeopardizing the integrity of the list. If you're interested in returning the pointee, make sure that the client code cannot also delete the pointee or your class has a design problem. Other than that, you are safe.

  2. #17
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    If you're interested in returning the pointee, make sure that the client code cannot also delete the pointee or your class has a design problem.
    They are private.
    Returning a reference would only allow the modification of the 'value' of a node... or accessing the next node's reference.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  3. #18
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,704
    It doesn't do any good to just say "well it's private!" and then write an interface that exposes the class's memory. Once you expose memory via a public interface it isn't really private any more. If a pointer serves as instance data and then you define get() publicly, the users of your class will figure out that delete current.get(); destroys the instance.

    Of course, people smarter than me do this all the time (hello Boost developers). I'm only luckily smart enough not to accidentally do things like that. If you really want a safe class with lots of hand holding, generally you are better off thinking about issues like this, and in this case, you are better off using iterators with your list. Meaning, the list owns everything, and the only way to touch the list is through iterators. This protects the nodes because iterators do not convert to node types so you can't just do delete iter and ........ your list. Even *iter will not allow you to access the node itself; it returns a reference to an object of the contained type.
    Last edited by whiteflags; 10-13-2011 at 10:52 PM.

  4. #19
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    returns a reference to an object of the contained type.
    That is 'almost' exactly what I'm doing....
    Anyway.. I'll post some code a few days later.. then the design nitpicking can commence.(Hopefully my code won't be leaky this time. )
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  5. #20
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,704
    Well I don't agree that the user should be able to access the nodes or the links. If your class does that, fix it. An iterator would do everything your class is letting users do safer.
    King Mir and Elysia like this.

  6. #21
    Registered User
    Join Date
    Apr 2006
    Posts
    2,035
    Quote Originally Posted by manasij7479 View Post
    Don't we have move for that...when needed ?

    I'm just returning it to provide an interface tor linked structures' referenced node(s).
    No.

    Ownership refers to which object or function is responsible for deleting dynamically allocated objects. Move does not do this. Move can be used to efficiently swap two objects, but it does not destroy either object, or free memory. This makes it rather useless for moving heap variables.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  7. #22
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by whiteflags View Post
    Well I don't agree that the user should be able to access the nodes or the links. If your class does that, fix it. An iterator would do everything your class is letting users do safer.
    What do I do if the structure is not something suitable for an iterator?
    ..say implementing a graph with links ... or some strange kind of tree....
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  8. #23
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,704
    Neither of the things you have mentioned are not iterable structures. There are ways to traverse both trees and graphs.

    It is very hard for me to think of a data structure that cannot be searched in any fashion.

  9. #24
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,608
    Then you would return a sort of "proxy object" (this would be a generalization of iterators).
    Still, the important point is that you should not expose your class internals. Or if you really must, do it in such a way that it does not allow the user to actually corrupt the state of that object (eg, deleting a pointer).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #25
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by Elysia View Post
    Or if you really must, do it in such a way that it does not allow the user to actually corrupt the state of that object
    What I can't understand : how does returning a reference allow such corruption ?
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  11. #26
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,608
    Returning a node and changing the next/prev pointers, for example.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  12. #27
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by whiteflags View Post
    Neither of the things you have mentioned are not iterable structures. There are ways to traverse both trees and graphs.

    It is very hard for me to think of a data structure that cannot be searched in any fashion.
    Sorry, iterable was a wrong choice of word here.
    I am unable to convey what I meant though..
    I would come up with this point later when implementing the classes in question.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  13. #28
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by Elysia View Post
    Returning a node and changing the next/prev pointers, for example.
    The next, prev pointers are private.
    The data stored by them are public.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  14. #29
    Registered User
    Join Date
    Apr 2006
    Posts
    2,035
    An iterator is a more elegant and standard design then returning a node reference.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  15. #30
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by King Mir View Post
    An iterator is a more elegant and standard design then returning a node reference.
    ... I plan to have both ! ..
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Undefined Behaviour (Palindromic Number Finder)
    By pobri19 in forum C++ Programming
    Replies: 12
    Last Post: 09-28-2008, 04:54 AM
  2. Undefined behaviour telnet
    By stevesmithx in forum Tech Board
    Replies: 0
    Last Post: 04-22-2008, 01:41 AM
  3. bit shifting...undefined behaviour?
    By Sebastiani in forum C++ Programming
    Replies: 15
    Last Post: 11-07-2007, 01:11 PM
  4. Is this undefined behaviour?
    By caduardo21 in forum C Programming
    Replies: 4
    Last Post: 01-15-2006, 11:55 AM

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