Does the following code show undefined behaviour ?

**whiteflags** · 10-13-2011

Originally Posted by manasij7479

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.

**manasij7479** · 10-13-2011

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.

**whiteflags** · 10-13-2011

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.

**manasij7479** · 10-13-2011

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. )

**whiteflags** · 10-13-2011

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** · 10-14-2011

Originally Posted by manasij7479

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.

**manasij7479** · 10-14-2011

Originally Posted by whiteflags

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....

**whiteflags** · 10-14-2011

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.

**Elysia** · 10-14-2011

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).

**manasij7479** · 10-14-2011

Originally Posted by Elysia

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 ?

**Elysia** · 10-14-2011

Returning a node and changing the next/prev pointers, for example.

**manasij7479** · 10-14-2011

Originally Posted by whiteflags

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.

**manasij7479** · 10-14-2011

Originally Posted by Elysia

Returning a node and changing the next/prev pointers, for example.

The next, prev pointers are private.
The data stored by them are public.

**King Mir** · 10-14-2011

An iterator is a more elegant and standard design then returning a node reference.

**manasij7479** · 10-14-2011

Originally Posted by King Mir

An iterator is a more elegant and standard design then returning a node reference.

... I plan to have both ! ..

Thread: Does the following code show undefined behaviour ?

Thread Tools

Search Thread

Display

Similar Threads

Undefined Behaviour (Palindromic Number Finder)

Undefined behaviour telnet

bit shifting...undefined behaviour?

Is this undefined behaviour?