Assert vector program terminates

[hyderabadblues]

Following is part of my program that I am trying to code to simluate
folder information which contains mp3 files.
At the end of main funcion there is assert, I have tried to debug the
program , what I found is resize() call was successful, but when main
terminates there is an assert in the vectors destructor.
#include <iostream>
#include <string>
#include <vector>

typedef int tU32;
typedef bool tBool;
typedef short tU8;
typedef void tVoid;
typedef char * tcString;
#define NULL 0

using namespace std;

enum tenFileType {
FI_EN_FOLDER = 0UL,
FI_EN_FILE = 1UL,
FI_EN_PLAYLIST = 2UL
};

enum tenGenre {
FI_EN_ROOT = 0UL,
FI_EN_PLAYLIST_1 = 1UL,
FI_EN_ARTIST = 2UL,
FI_EN_ALBUM = 3UL,
FI_EN_GENRE = 4UL,
FI_EN_TRACK = 5UL,
FI_EN_COMPOSER = 6UL,
FI_EN_AUDIOBOOK = 7UL,
FI_EN_PODCAST = 8UL,
FI_EN_UNKNOWNACTIVE = 9UL
};


enum FileAttributes
{
FILETYPE_FOLDER,
FILETYPE_FILE,
FILETYPE_ARTIST,
FILETYPE_ALBUM
};
struct trFolder{
tU32 u32Id;
tcString name;

};

struct trTime{
tU8 u8NoOfHrs;
tU8 u8NoOfMin;
tU8 u8NofSec;
};

struct trId3Data
{
tenFileType m_enFileType;
tenGenre m_enGenre;
char * m_szArtistName;
char * m_szFileName;
trTime m_trPlayTime;

trId3Data( )
{
m_szArtistName = NULL;
m_szFileName = NULL;
}

~trId3Data( )
{
if( m_szArtistName != NULL )
delete m_szArtistName;

if( m_szFileName!= NULL )
delete m_szFileName;
}

trId3Data( const trId3Data& rftrId3Data)
{
}

trId3Data(trId3Data& rftrId3Data)
{
m_enFileType = rftrId3Data.m_enFileType;
m_enGenre = rftrId3Data.m_enGenre;
vCopyStirng( m_szArtistName, rftrId3Data.m_szArtistName);
vCopyStirng( m_szFileName, rftrId3Data.m_szFileName );
m_trPlayTime.u8NoOfHrs = rftrId3Data.m_trPlayTime.u8NoOfHrs;
m_trPlayTime.u8NoOfMin = rftrId3Data.m_trPlayTime.u8NoOfMin;
m_trPlayTime.u8NofSec = rftrId3Data.m_trPlayTime.u8NofSec;
}

tVoid vCopyStirng( char *&dest , char *&src )
{
dest = (char*)malloc(strlen(src));
strcpy( dest, src );
}

tVoid vsetFileType( tenFileType enFileType )
{
m_enFileType = enFileType;
}

tVoid vsetGenre( tenGenre enGenre )
{
m_enGenre = enGenre;
}

tVoid vsetArtistName( char* ArtistName )
{
vCopyStirng( m_szArtistName, ArtistName );
}

tVoid vsetFilename(char * fileName)
{
vCopyStirng( m_szFileName, fileName );
}

tVoid vsetPlayTime( trTime &trPlayTime)
{
m_trPlayTime.u8NofSec = trPlayTime.u8NofSec;
m_trPlayTime.u8NoOfMin = trPlayTime.u8NoOfMin;
m_trPlayTime.u8NoOfHrs = trPlayTime.u8NoOfHrs;
}
};

/*!
* \fn trFolderInfo
* \brief
* Represents Basic structure of a folder
* \note
* \bug
* no bugs known
* \todo
* -Review
* \version
* 1.0 - Initial
******/
struct trFolderInfo
{
tU32 u32Id;
char* name;
struct trFolderInfo *parentdir;
std::vector<trId3DatafileList;
std::vector<trFolderInfosubdir;

trFolderInfo()
{
name = NULL;
}

~trFolderInfo()
{
if( name != NULL )
delete name;
}

tVoid vCopyStirng( char *&dest , char *&src )
{
dest = (char*)malloc(strlen(src));
strcpy( dest, src );
}

tVoid vsetFolderName(char * FolderName)
{
vCopyStirng( name, FolderName );
}

} ;

void main()
{
vector<trId3DatafileList;
fileList.resize(10);
}

[Ben Pfaff]

"Alf P. Steinbach" <al***@start.nowrites:

* hyderabadblues:

>typedef int tU32;
typedef bool tBool;
typedef short tU8;
typedef void tVoid;

It's not a good idea to obscure code by using names such as tVoid
instead of standard void.

It's really weird to use short as the type for tU8, since we
know that short has more than 8 bits.
--
"While the Melissa license is a bit unclear, Melissa aggressively
encourages free distribution of its source code."
--Kevin Dalley <ke***@seti.org>

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-10-06 16:58, hyderabadblues wrote:

Following is part of my program that I am trying to code to simluate
folder information which contains mp3 files.
At the end of main funcion there is assert, I have tried to debug the
program , what I found is resize() call was successful, but when main
terminates there is an assert in the vectors destructor.

Using a debugger you would notice that the problem occurs when you try
to delete m_szArtistName in ~trId3Data().

tVoid vCopyStirng( char *&dest , char *&src )
{
dest = (char*)malloc(strlen(src));

^^^^^^^

strcpy( dest, src );
}

tVoid vCopyStirng( char *&dest , char *&src )
{
dest = (char*)malloc(strlen(src));

^^^^^^

strcpy( dest, src );
}

Memory allocated with malloc must be deallocated with free, (likewise,
memory allocated with new must be deallocated with delete). In C++
programs new should be used unless you need to allocate memory
deallocated by libraries written in C (which is bad design, so you
probably should not use such libraries any way).

--
Erik Wikström

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-10-06 17:59, Ben Pfaff wrote:

"Alf P. Steinbach" <al***@start.nowrites:

>* hyderabadblues:

>>typedef int tU32;
typedef bool tBool;
typedef short tU8;
typedef void tVoid;

It's not a good idea to obscure code by using names such as tVoid
instead of standard void.

It's really weird to use short as the type for tU8, since we
know that short has more than 8 bits.

Actually, on a 7-bit machine a short could be 7 bits as well. All we
know is that short has at least as many bits as a signed char.

--
Erik Wikström

[hyderabadblues]

On Oct 6, 5:59 pm, Ben Pfaff <[e-mail]:

"Alf P. Steinbach" <[e-mail]:

* hyderabadblues:

typedef int tU32;
typedef bool tBool;
typedef short tU8;
typedef void tVoid;

It's not a good idea to obscure code by using names such as tVoid
instead of standard void.

It's really weird to use short as the type for tU8, since we
know that short has more than 8 bits.
--
"While the Melissa license is a bit unclear, Melissa aggressively
encourages free distribution of its source code."
--Kevin Dalley <[e-mail]>

I am working for a embedded systems company, so to try out something I
use visual studio, above defines are just mine for trials.

[Jerry Coffin]

In article <Cq*****************@newsb.telia.net>, Erik-
wi******@telia.com says...

[ ... ]

Actually, on a 7-bit machine a short could be 7 bits as well. All we
know is that short has at least as many bits as a signed char.

A signed char must support a range from at least -127 to +127. A short
must support a range from at least -32767 to +32767. Each signed type
must also occupy the same amount of storage as its corresponding
unsigned type, and an unsigned char must support a range from at least 0
through 255. An unsigned short must support a ranage from at least 0
through 65535.

IOW, in C or C++ a char or unsigned char must occupy least 8 bits, and a
short or unsigned short must occupy at least 16 bits.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-10-06 18:27, Jerry Coffin wrote:

In article <Cq*****************@newsb.telia.net>, Erik-
wi******@telia.com says...

[ ... ]

>Actually, on a 7-bit machine a short could be 7 bits as well. All we
know is that short has at least as many bits as a signed char.

A signed char must support a range from at least -127 to +127. A short
must support a range from at least -32767 to +32767. Each signed type
must also occupy the same amount of storage as its corresponding
unsigned type, and an unsigned char must support a range from at least 0
through 255. An unsigned short must support a ranage from at least 0
through 65535.

IOW, in C or C++ a char or unsigned char must occupy least 8 bits, and a
short or unsigned short must occupy at least 16 bits.

I forgot about good old C. This makes me wonder however, why is no
reference made to the relevant sections of the C standard when
discussing the integer types instead of hiding that away down in section
18.2.2?

--
Erik Wikström

[Jerry Coffin]

In article <5v*****************@newsb.telia.net>, Erik-
wi******@telia.com says...

[ ... ]

I forgot about good old C. This makes me wonder however, why is no
reference made to the relevant sections of the C standard when
discussing the integer types instead of hiding that away down in section
18.2.2?

There is, at least indirectly -- in 3.9.1 footnote 39 mentions that
int's most be "large enough to contain any value in the range INT_MIN
and INT_MAX as defined in the header <climits>"

That's about it though, and an extremely minimal reference (at best) it
is too...

--
Later,
Jerry.

The universe is a figment of its own imagination.