Re: Memory Leaks - Can you help me find them in ths snippet
On Jan 29, 8:35 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Daniel T.:
[...]
vector< vector< char > >
block( lColumnCount, SE_QUALIFIED_COLUMN_LEN )=
;
[...]
Accepted about the try catch block, but what is wrong with the
constructor arguments, did I reverse them or something?
Well, I was wrong, but on a higher level (see below) I was right.
What I remembered was my practical experience with one
particular compiler, which would not accept the above, while
the standard does require that it is accepted, via a very very
subtle special case rule.
Note that there has been some discussion as to whether the fact
that the above is legal is due to an error in the wording of the
special case. The special case was designed to handle things
like:
std::vector< int > v( 10, 43 ) ;
Note that the best match for this constructor is the template
constructor taking (nominally) two iterators, which is probably
not what the user expected. (There is also a constructor taking
a size_t and a T---in this case an int. But of course, that
involves a conversion of int to size_t, where as the template
constructor taking two "iterators" is an exact match---the
template mechanism can't tell that int's can't be iterators.)
The result is that a special case was added to make this
constructor act as expected. I don't think that the original
intent of the wording was to also make Daniel's constructor well
formed (and in fact, as you point out, some compilers don't
accept it).
I believe that there was even a DR, although I'm not sure. At
any rate, I just checked the current draft: the wording of the
special case has been changed to make Daniel's version illegal
(so you're not really wrong, just living in the future:-).
Consider
#include <vector>
#include <iostream>
int main()
{
using namespace std;
vector< vector<int> > v( 3, 7 ); // The item discussed here.
cout << v.size() << ", " << v[0].size() << endl;
}
Trying to compile, various compilers:
It's a library issue, more than a compiler issue. If the two
arguments have the same type, and the first is not size_t, then
the template function taking two iterators is a better match.
Beyond that, it's up to the library to make it work "as if" the
(size_t, T) constructor had been called, with the arguments
"static_cast" to the correct type. (The latest draft changes
this, and says that only the first argument should be
static_cast to a size_type.) The 1998 version of the standard
also contains a note (non-normative) suggesting a simple
technique to implement this---a library which uses that
technique, however, will fail to compile Daniel's code.
My guess is that for the compilers where this code failed to
compile, the library implementation is based on that note.
So which compiler is right? Comeau usually is, and is also
this time.
For the moment:-). (Also, just curious, but does anyone know
what implementation of the library the Comeau on line uses?)
What happens is that instead of the explicit constructor taking size
argument, the templated constructor taking iterators is invoked for the
outer vector, and =A723.1.1/9, general requirements for containers, says
that when invoked with integral argument type instead of the expected
some iterator type, it shall behave the same as (in this case) vector<
vector<int> >( static_cast<size_type>(3), static_cast< vector<int> >( 7
) ), or in other words effectively the same as
vector< vector<int> > v( 3, vector<int>( 7 ) );
But I wouldn't rely on the compiler / library implementation
being smart enough to figure that out.
I'd write it as what the standard requires it ends up as,
namely this latter declaration, because then everybody
understand what it means, including the author, the MSVC 7.1
compiler, and maintenance... :-)
And libraries which will implement C++0x:-).
Totally agreed (and I would be even if the standards committee
had decided to live with the original text, on the grounds that
even if it wasn't what was meant, changing it now would break
too much codde).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34