memory leaks

[Larry]

In fact, "vector< unsigned char >" is full-fledged type, which
behaves like any other type, where as "unsigned char buffer[ 51 ]"
creates an object of a second class type, which is fairly
broken, and doesn't behave normally.

Also, vector< unsigned char > will normally do bounds checking,
and other important things to avoid undefined behavior.

There are, of course, cases where something like "unsigned char
buffer[ 51 ]" is justified, but they aren't that common.

well, I could have done with vectors indeed. Yet, I thought becauese of all
those internal checks vector does maybe my solution would have been
faster...

where:

unsigned char buffer[51];

is fixed length. Also, I know that it will never deal with data longer that
51 bytes beforhand!

I am doing real time application I need to run fast.

thanks

 

[Jorgen Grahn]

Larry ha scritto:


You must not guess but measure.

It is unlikely that you will notice any difference in speed.

Yes. And also, *which* "all those internal checks"? People usually
complain about the *lack* of checks in the standard containers, e.g.
range checks.

/Jorgen

 

[Jorgen Grahn]

.

#define _CRT_SECURE_NO_WARNINGS
#include <windows.h>
#include <vector>
#include <cstdlib>
#include <ctime>
#include <cstdio>
#include <boost/circular_buffer.hpp>
using namespace std;
using namespace boost;
....
ZeroMemory(buff, sizeof(Buffer));

Just out of curiosity: did you define this one somewhere, or are
Microsoft daft enough to push a differently named std::memset()?

(Or bzero(), although that one is just traditional).

More helpfully, in the rare case that I have to manually initialize
buffers like this, I use std::fill and friends. The old C functions
which operate on raw memory (memset, memcpy etc) doesn't play nice with
C++ objects, which in turn can lead to nasty bugs.

/Jorgen

 

[red floyd]

Just out of curiosity: did you define this one somewhere, or are
Microsoft daft enough to push a differently named std::memset()?

Microsoft is that daft.

 

[Alf P. Steinbach]

* red floyd:

Microsoft is that daft.

I agree , but in this particular case it's not so. ZeroMemory is a Windows
API function. It's available whether you program in C or Pascal or Fortran, say
(actually I don't know about Fortran, it's near 30 years since I last rode that
beast, but I'm pretty sure it can be used also from Fortran).

The OP's code was

Buffer *buff = new Buffer;
ZeroMemory(buff, sizeof(Buffer));

and by the rules of C++ he could just have written

Buffer* buff = new Buffer(); // That's it.

by §5.3.4/15 second main dash, which in C++98 reads "If the new-initializer is
of the form (), default-initialization shall be performed" (and I guess that's
changed to "value initialization" in C++03, but I'm not checking that).


Cheers,

- Alf

 

[Rolf Magnus]

Just out of curiosity: did you define this one somewhere, or are
Microsoft daft enough to push a differently named std::memset()?

They have their own function for pretty much everything, just like they have
CHAR and VOID as replacement for char and void. Maximum incompatibility
seems to be the main goal.

 

[Jorgen Grahn]

They have their own function for pretty much everything, just like they have
CHAR and VOID as replacement for char and void. Maximum incompatibility
seems to be the main goal.

OK. To be fair, that's what my code looked like when I programmed in C
on the Commodore-Amiga too; their interfaces were full of CHAR and
WORD, and the had plenty of homegrown functions like ZeroMemory()
above. But that was twenty years ago, and using the C standard library
was considered uncool and "too slow".

/Jorgen