>> First off, it is nonsense to argue that because some part of our program is C, all code around it should also follow C conventions.
I don't understand. In a post I wrote about iterators, you claim erroneously that I'm following C conventions. At best, the iterator concept is one used namelessly in C and made a more type strict and formal concept in C++. But if you won't begrudgingly accept that, I don't think it will make a difference in the discussion.
>> Does it make sense not to use them? Of course not. If we didn't use them, we might as well use C to begin with.
I consider it a personal failure that I am communicating so poorly. I am not trying to tell you to use anything C like. I'm trying to teach you about forms of the conventions you are already using.
>> We should instead abstract the C code with strongly typed C++ interfaces
You said specifically that I could show you how to make a function interface work well with arrays and vector. This is abstracting C code and making type safe C++ code. Like I said, a pointer is a bidirectional iterator. By far, the easiest thing to do is to accept a range bound in the type of bidirectional_iterator<T>. This works seamlessly with vector (in fact I am almost certain begin() and end() resolve to this at some point) and arrays (as long as T is the element type).
>> that perform a lot of static (and dynamic) checks to make sure we don't feed invalid input to the unsafe C code.
If you use bidirectional_iterator with a STL container you can do all sorts of things. Honestly I'm not as familiar with the exceptions that they throw, but out_of_range() is in the problem domain. With C code, it is harder, but as I told you earlier:
I thought I told you about the sizeof trick too in that post, but I ended up with not. If you divide the size of a fixed array by one of its elements, you get the size of the array from the compiler. The array has to be in scope so where you do that division matters, but that is easy, if you follow the convention of declaring variables where you need them.Originally Posted by whiteflags
>> Some STL algorithms don't work with raw pointers (can't recall any on the top of my head, though)!
Don't suppose things that you can't support. The only algorithms that could not work with a pointer as an iterator are the same algorithms that don't accept a sequence. I know of precisely none in the problem domain. Pointers being an example of bidirectional iterators is a fact. They have the same functional behavior. So this is how you make an interface for arrays and STL containers. I'm sorry you don't like it, maybe you and you alone can do something else, but it's conventional, offers a lot considering how little you say C has, and the flexibility can't be beat.