«

Stefan van Kessel <> wrote:
> On 2012-10-05 11:39 AM, wrote:
>> char* aPtr = new char[1024];
>> delete aPtr;
>>
>> The delete2 crashes sometimes.
>
> When you use new ... [] you need to use delete[] ...

For that matter, there's very seldom any need to use 'new' and 'delete'
directly in your code, unless you are implementing a special dynamic data
container (and even that happens quite rarely in practice, as it's not
very common to need a data container that's different from what the
standard library offers).

The lesson is: Only use 'new' and 'delete' if you absolutely must. Before
resorting to them, see if the standard containers will do what you want
in the way you want. It will not only be safer and less error-prone, it
will also be much simpler and your code will become clearer and easier
to read.

On Sat, 2012-10-06 at 11:24 +0000, Juha Nieminen wrote:
> Stefan van Kessel <> wrote:
> > On 2012-10-05 11:39 AM, wrote:
> >> char* aPtr = new char[1024];
> >> delete aPtr;
> >>
> >> The delete2 crashes sometimes.
> >
> > When you use new ... [] you need to use delete[] ...
>
> For that matter, there's very seldom any need to use 'new' and 'delete'
> directly in your code, unless you are implementing a special dynamic data
> container (and even that happens quite rarely in practice, as it's not
> very common to need a data container that's different from what the
> standard library offers).
>
> The lesson is: Only use 'new' and 'delete' if you absolutely must. Before
> resorting to them, see if the standard containers will do what you want
> in the way you want. It will not only be safer and less error-prone, it
> will also be much simpler and your code will become clearer and easier
> to read.

As does Item 16 in Scott Meyer's Effective C++. Brilliant book.
--
Tactical Nuclear Kittens

writes:

[ ... ]

You should trim the quoting in your replies, also it appears that your
newsreader puts double linefeeds in your quoting.

> Hi Thanks for the reply. Yes, giving different names solves the
> problem in the production code. However, the problem does not occur
> when you have only this much in a program(i.e on a sample
> program). My program has thousands of lines of code and I am not
> able to post all those lines due to legal aspects with my employer.

OK, you should have indicated that this was just an example in your
original post.

> That is why my suspicion is somehow the compiler has this same name
> bug in certain not so simple cases. Thanks so much.

The usual advice would be to simplify the original program until you
have something that can be posted, or until the bug disappears, in
your case this appears to be achieved, but I doubt that you've found
the real bug.

Sometimes one comes across a class of bugs where seemingly unrelated
or meaningless changes causes the bug to disappear. Often the bug
isn't at that place at all, rather there's some spurious overwrites
elsewhere in your program, the use of memset with constant numbers as
size may be an indication of a programming style where these kind of
errors would be likely.

Changing other parts of the code may cause code or data to move around
thus making the overwrites hit some other part of your data and cause
some other bug that you may or may not see as a failure in your tests.

I suggest you use a memory access checker such as purify - or the
system that I believe exist within Visual Studio to check for
overwrites.

--
... Øyvind - soon to appear in a kill file near you.
... Ignorance can be cured; stupidity is forever.