STL vector<float> crash

[Active8]

I put the bare essentials in a console app.

http://home.earthlink.net/~mcolasono/tmp/degub.zip

Opening output.fft and loading it into a vector<float> screws
up, but input1.dat doesn't. It does load the vector, too. It just
craps out when you return to the console, or in a [wx]Windows app,
the message loop. I think it has something to do with the
vector<float> going out of scope and trying to free memory, but
don't know why it would do that. The fft file is 512 floats and I
converted the actual values (which came out of the vector which
crashed, BTW) to test.txt.

I did it in VC++. Maybe another compiler or OS won't have a prob
with it.

I'd appreciate it if someone could try it out and see what happens.

Thanks in advance.
--
Best Regards,
Mike

[Dietmar Kuehl]

Active8 wrote:

I put the bare essentials in a console app.

Actually, you didn't! This code uses at least one [actually even
unnecessary], environment specific header and I doubt that you
have reduced it to the bare minimum of code exposting the problem.
You are using the wrong convention for headers (you shall not use
angle brackets for your headers; angle brackets are reserved for
the system, i.e. the standard library headers), you pass string
literals as 'char*' (you can't: the type of a string literals is
'char const(&)[n]' which decays to a 'char const*'), and you don't
check for any error codes!

A minimal example typically takes something like 30 lines of code.
In reducing the code to a minimal amount you would normally also
stumble over some thinko...
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Andrew Koenig]

"Dietmar Kuehl" <di***********@ yahoo.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

you pass string
literals as 'char*' (you can't: the type of a string literals is
'char const(&)[n]' which decays to a 'char const*'

....umm, aren't you forgetting about the compatibility hack that permits a
string literal to decay to char*?

[Active8]

On Tue, 01 Mar 2005 15:56:29 GMT, Andrew Koenig wrote:

"Dietmar Kuehl" <di***********@ yahoo.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

you pass string
literals as 'char*' (you can't: the type of a string literals is
'char const(&)[n]' which decays to a 'char const*'

...umm, aren't you forgetting about the compatibility hack that permits a
string literal to decay to char*?

I've seen plenty of code that passes literals that way. I started
the <> includes when I put the files in a separate dir and meant to
change those to quotes. If I've read that <> is reserved for system
files, I forgot, but now I know.

--
Best Regards,
Mike

[Active8]

On 1 Mar 2005 07:41:27 -0800, Dietmar Kuehl wrote:

Active8 wrote:

I put the bare essentials in a console app.
Actually, you didn't! This code uses at least one [actually even
unnecessary], environment specific header and I doubt that you

What file would that be? stdio.h?
have reduced it to the bare minimum of code exposting the problem.
The dspfile class could've been stripped dow a bit, but it's so
small anyway...
You are using the wrong convention for headers (you shall not use
angle brackets for your headers; angle brackets are reserved for
the system, i.e. the standard library headers), you pass string
literals as 'char*' (you can't: the type of a string literals is
'char const(&)[n]' which decays to a 'char const*'), and you don't
check for any error codes!

A minimal example typically takes something like 30 lines of code.
In reducing the code to a minimal amount you would normally also
stumble over some thinko...

Does all that make it so hard to compile and run it?

--
Best Regards,
Mike

[Dietmar Kuehl]

Active8 wrote:

What file would that be? stdio.h?
windows.h as used in dspfile.cpp.
The dspfile class could've been stripped dow a bit, but it's so
small anyway...
There are nearly 500 lines. Typical example programs are 20 to 30
lines; rather big examples, commented in the text body of the
message, are typically still less than 100 lines.
Does all that make it so hard to compile and run it?

Yes, it does: it took me about 10 minutes before I got an executable
build. This executable immediately crashed when called without
arguments, i.e. a simple sanity check for the executable already
failed. Contrast this with maybe 40 lines of code I cut and paste
from the browser into a C++ file and which runs mere seconds later!
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Dietmar Kuehl]

Andrew Koenig wrote:

"Dietmar Kuehl" <di***********@ yahoo.com> wrote:

you pass string
literals as 'char*' (you can't: the type of a string literals is
'char const(&)[n]' which decays to a 'char const*'
...umm, aren't you forgetting about the compatibility hack that

permits a string literal to decay to char*?

No, I'm not! Maybe it is just me but I tend to use highest warning
level and remove at least most warnings before even considering to run
the code. This normally catches most problems. Using 'char const*'
instead of 'char*' is a trivial change and does not impose any new
constraints (writing to the string literal is prohibited even if it
declared as 'char*'; only the compiler cannot catch the errors related
to writing to string literals). A similar argument applies to the
things I mentioned. Of course, I can make <> delimited, user-defined
headers to work; it just takes another compilation cycle and editing
the compiler flags but should this really be necessary? Of course, I
can figure out how to call the program from the source rather than by
trying to just run it to see that there is yet another problem lurking.

I don't mind to help others as you are probably well aware of. However,
I generally assume that the others have made a reasonable attempt to
solve their problem first. I cannot see an indication of this here.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Dietmar Kuehl]

Active8 wrote:

I've seen plenty of code that passes literals that way.

.... and all of this code should be flagged with a warning! It is an
error prone habit since you cannot write to string literals but the
compiler cannot help you by prohiting it, i.e. the error occurs at
run-time. The fact there is plenty of code out there meant that a
deprecated features was added to C++ but no new code shall rely on
this feature!
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[E. Mark Ping]

In article <1b************ ****@ID-222894.news.ind ividual.net>,
Active8 <re*********@nd bbm.net> wrote:

Opening output.fft and loading it into a vector<float> screws
up, but input1.dat doesn't.

Your "load_vecto r" function is tremendously unsafe. You resize the
vector based on the leader bytes of the file, but there is no check
during the load if you go off the end. (IME, writing past the end of
the vector is the easiest way to crash.)

Furthermore, your call:
fread(it++, sizeof(vec_type ), 1, m_channel);

is problematic to say the least. "it" is a T::iterator, which is not
guaranteed at all to be a pointer. At least, you should use:

fread(&(*it++), sizeof(vec_type ), 1, m_channel);

And if you're using vector, you could do:

itemCount = vec.size();
fread(&vec[0], sizeof(vec_type ), itemCount, m_channel);

or something like that.
Have you verified that 'output.fft' has the right amount of data?
--
Mark Ping
em****@soda.CSU A.Berkeley.EDU

[assaarpa]

> I've seen plenty of code that passes literals that way. I started

the <> includes when I put the files in a separate dir and meant to
change those to quotes. If I've read that <> is reserved for system
files, I forgot, but now I know.

I'd double-check on that.