Re: Overly aggressive checking in new STL (Visual Studio 2005)?

Tech-Archive recommends: Speed Up your PC by fixing your registry

I'll gladly accept that my code is/was broken, and move on. Though the code
may have been broken, the idea behind it was not.

I like the C++ iterator paradigm - passing start/end iterators around and
using that consistently isntead of start/count.

Not all code uses templates - however - and sometimes - for example with IO
or other shared routines - its helpful to pass a bunch of data.

For example -

f (const T* start, const T* end);

The caller of f() might have been using a vector, memory-mapped file, or
some other source of data for the array of T's. It shouldn't matter.

I want to be able to easily convert to C++-style iterator (start/end)
pointers - and use them inside of f().

Now - you may argue:
(a) this is crazy - use templates
The problem with this argument is that - though templates are
quite powerful - they are not always the easiest thing to use, and one
shouldn't ahve to use templates ALWAYS - FOR EVERYTHING. Simply requring that
the data passed to 'f' is a contiguous block of 'T's - in this application -
makes sense.

(b) Jump thorugh hoops to call f - if you are calling it with a vector,
as in:
if (v.empty ()) {
f (NULL, 0);
}
else {
f (&v[0], &v[v.size()]);
}
Well, there is some merit to this argument, but C++ is meant to be
a tool to make programming easier. I just find :
f (&v[0], &v[v.size ()]);
or
f(&*v.begin(),&*v.end ());
much clearer and simpler (when done alot of times) - then the
if/else test above.

I hope one of you can either point out an easy way for me to
convert start/end iterators to start/end pointers, so that I can easily use
the STL/iterator paradigm in code that isn't template-burdoned; or perhaps
you can at least make me feel better about the fact that this is no longer
possible.










"Stephen Howe" wrote:

Before this release, I could do:
f (&*v.begin (), &*v.end ())

Which is illegitimate. You can't dereference v.end() and take the address.
Same is true of all the other STL containers. You are better off passing the
size as 2nd argument and doing any address calculation inisde f.

I really I can turn off ALL debug checking, but I really do like the idea
of
having some - perhaps most of the checking that you've implemented. I just
don't want perfectly legitimate reasonable code to be treated as broken!

Not legitimate. The code _IS_ broken (and always has been).
Previous compilers let you get aways with it. This one does not.

Cheers

Stephen Howe



.

Relevant Pages

  • Re: Overly aggressive checking in new STL (Visual Studio 2005)?
    ... I like the C++ iterator paradigm - passing start/end iterators around and using that consistently isntead of start/count. ... Not all code uses templates - however - and sometimes - for example with IO or other shared routines - its helpful to pass a bunch of data. ... template <class T, class Alloc> ...
    (microsoft.public.vc.stl)
  • Re: Problem with reading an int with operator>>
    ... Stephen Howe wrote: ... most of it is in header files is due to compiler limitations when it ... I also mean the general limitation of templates where the definition is dependent on the usage. ...
    (microsoft.public.vc.stl)
  • Re: Problem with reading an int with operator>>
    ... most of it is in header files is due to compiler limitations when it ... comes to templates. ... Stephen Howe ...
    (microsoft.public.vc.stl)