Re: Memory Leaks - Can you help me find them in ths snippet
* Daniel T.:
In article <13pukm54dvccv84@corp.supernews.com>,
"Alf P. Steinbach" <alfps@start.no> wrote:
* Daniel T.:
"nmehring@gmail.com" <nmehring@gmail.com> wrote:
Thank you, I will correct that additional leak if i>0
The reason I am using these datatypes is because I am utilizing this
3rd party library method:
extern LONG SDEAPI SE_stream_update_row (SE_STREAM stream,
const ACHAR *table,
LONG *sde_row_id,
SHORT num_columns,
const ACHAR **columns);
So I figured I had to use the char data type.
Sorry, I thought you were using each column individually. i.e., I
thought the API was asking for char* and was being called multiple
times, not char** and called once.
However, I still recommend you use vectors rather than allocating the
memory yourself and hoping for the best.
Something like this would do nicely:
vector< vector< char > >
block( lColumnCount, SE_QUALIFIED_COLUMN_LEN );
for ( int i = 0; i < block.size(); ++i )
{
strcpy( &block[i].front(), CStringColumnName[i] );
}
vector< char* > columns( block.size() );
for ( int i = 0; i != block.size(); ++i )
{
columns[i] = &block[i].front();
}
SE_stream_update_row( /* other params */, &columns[0] );
This is a better idea than the code I posted: it uses a little more
memory but is safer (wrt. maintainance) and shorter and just more clear.
However, the 'block' constructor arguments need to be fixed, and the
whole thing needs to be put in a try-catch in order to conform to the
OP's boolean return.
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.
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:
<g++>
V:\> gnuc vc_project.cpp
V:\> a
3, 7
</g++>
<msvc 7.1>
V:\> msvc vc_project.cpp -o b.exe
vc_project.cpp
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\vector(357) : error C2664: 'std::vector<_Ty>::_Construct_
n' : cannot convert parameter 2 from 'int' to 'const std::vector<_Ty> &'
with
[
_Ty=std::vector<int>
]
and
[
_Ty=int
]
Reason: cannot convert from 'int' to 'const std::vector<_Ty>'
with
[
_Ty=int
]
Constructor for class 'std::vector<_Ty>' is declared 'explicit'
with
[
_Ty=int
]
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\vector(343) : see reference to function template
instantiation 'void
std::vector<_Ty>::_Construct<_Iter>(_Iter,_Iter,std::_Int_iterator_tag)'
being compiled
with
[
_Ty=std::vector<int>,
_Iter=int
]
vc_project.cpp(7) : see reference to function template
instantiation 'std::vector<_Ty>::vector<int>(_Iter,_Iter)
' being compiled
with
[
_Ty=std::vector<int>,
_Iter=int
]
V:\>_
<msvc 7.1>
<comeau online>
Your Comeau C/C++ test results are as follows:
Comeau C/C++ 4.3.9 (Mar 27 2007 17:24:47) for ONLINE_EVALUATION_BETA1
Copyright 1988-2007 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions
In strict mode, with -tused, Compile succeeded (but remember, the Comeau
online compiler does not link).
Compiled with C++0x extensions enabled.
</comeau online>
So which compiler is right? Comeau usually is, and is also this time.
What happens is that instead of the explicit constructor taking size
argument, the templated constructor taking iterators is invoked for the
outer vector, and ?23.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... :-)
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?