Returning a pointer in Binary Search

This is a discussion on Returning a pointer in Binary Search within the C++ Programming forums, part of the General Programming Boards category; I'm almost sure that this does not result in undefined behaviour as what I'm returning is within range of the ...

Returning a pointer in Binary Search

I'm almost sure that this does not result in undefined behaviour as what I'm returning is within range of the supplied pointers.
Still..there may be something I'm not aware of.
<I'm aware of <algorithm> but this is for a homework >

Manasij Mukherjee | gcc-4.9.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 !

You shouldn't need to check for x-y==1 because x should never be greater than y.

Also, add brackets round your first if-statement. Don't leave the reader able to accidentally think that the else corresponds to the outer if rather than the inner one.

There is no undefined behaviour in that code. Looks like it should all work to me. Just make sure you call it with the right values. In this case you need to pass a pointer to the last element as y rather than the more convient and optimal one-past-the-end.

You could always try and do it iteratively instead of recursively if you're keen to learn a bit more.

One thing that would be good to add to the comments of this function are that x and y must both be non-null, and in fact y must point to an item with a higher or equal memory address than x, and from within the same array. The code could check for NULL itself rather than relying on the documentation of the function, but the rest of that precondition is not something that you can validate from the code without invoking undefined behaviour according to the standard. So if it we me, I'd just document it.

y must point to an item with a higher or equal memory address than x...

x should never be greater than y

Though I'm not likely to use anything other than a x86...Isn't that system dependent (and could become just the reverse)?

In this case you need to pass a pointer to the last element as y rather than the more convient and optimal one-past-the-end.

I did not follow the 'one-past-the-end' convention..as in the STL iterators' end() function because I had no simple way to control what lay beyond the end here. (AFAIK.. those iterators put some thing which throws an exception if dereferenced at the end() ).

Manasij Mukherjee | gcc-4.9.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 !

Though I'm not likely to use anything other than a x86...Isn't that system dependent (and could become just the reverse)?

You're doing pointer arithmetic, not arithmetic with memory address values. If you were really subtracting memory address values, then you would have written x-y==sizeof(int) instead. So, whatever the value the address of the memory, the relative value of the pointers in C++ is such that x <= y.

Originally Posted by manasij7479

I did not follow the 'one-past-the-end' convention..as in the STL iterators' end() function because I had no simple way to control what lay beyond the end here.

You do not need to control that in the first place.

Originally Posted by manasij7479

(AFAIK.. those iterators put some thing which throws an exception if dereferenced at the end() ).

They might do that to aid error detection and debugging, but there is no such requirement.

Manasij Mukherjee | gcc-4.9.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 !

Manasij Mukherjee | gcc-4.9.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 !

Manasij Mukherjee | gcc-4.9.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 !