Re: std::vector: reserve required?
On Jul 4, 10:25 pm, Mike -- Email Ignored <m_d_berger_1...@yahoo.com>
wrote:
On Fri, 04 Jul 2008 13:13:43 -0700, James Kanze wrote:
On Jul 4, 4:50 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
Mike -- Email Ignored wrote:
On:
Linux mbrc32 2.6.22.1-41.fc7 #1 SMP Fri
Jul 27 18:10:34 EDT 2007 i686 athlon
i386 GNU/Linux
Using:
g++ (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12)
The program below fails, but if the reserve(en) is
uncommented, it works.
I get a core dump from g++ 4.2.1, when I compile with the
usual options. With or without the reserve() commented out.
You probably forgot the necessary options to make g++
usable. (One of these days, someone will come out with a
compiler which is usable without special options. But it's
not happened yet.)
You may have forgotten some option if you get a failure with
reserve() uncommented; in my case options are correct as
verified by extensive use in other contexts.
I used the usual options that I use for compiling production
code:
-std=c++98
-ffor-scope
-fno-gnu-keywords
-foperator-names
-pipe
-Wall
-W
-Wno-sign-compare
-Wno-deprecated
-Wno-non-virtual-dtor
-Wpointer-arith
-Wno-unused
-Wno-switch
-Wno-missing-field-initializers
-ggdb3
-D_GLIBCXX_CONCEPT_CHECKS
-D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC
They're not complete (I forget why we don't have -pedantic in
there), but they're a start.
The important ones for error checking in the library are the
last three. Logically, they should be the default, but hey, no
compiler I know gets the defaults right.
It does not. You are observing a manifestation of undefined
behavior.
Is this as expected?
There are no expectations as to how undefined behavior will
show itself.
Yes and no. From experience, I find that undefined behavior
usually works in all of your tests, and then fails in the
most embarassing way possible in the demo before the most
important client.
I guess I should have said I was referring to the standard as is
usually the case on this group. There is no "Yes and no".
I guess I should have explained in detail that this was meant as
a somewhat humorous characterization. It didn't occur to me
that anyone would miss this.
From a quality of implementation point of view, would want
to see an abort if you compile the program with assertions
turned on.
You do with g++. I'm pretty sure you also do with VC++, but
I don't have a Windows machine handy here to test it with.
I see that in you use vec.at(jj) instead of vec[jj], it throws
an exception if the index is out of range. I changed the code
to use vec.at(jj) where there is uncertainly. My problem is
solved.
Except that you want an abort, not an exception. (The problem
isn't cases where there is uncertainly. Uncertainty can be
removed by means of an if. The problem is where your certitudes
turn out to be wrong.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34