[Effective-cpp] Item 1: Uses and Abuses of vector

[White Wolf]

Balog Pal <pasa at lib.hu> írta:
[SNIP]
> That is one slicky point. Data flow of the local is all
there, clear,
> unmissable if you never get its address passed to the
outside world.
> Prove that a member of the vector does not change requires
*all* functions
> used on that vector to be inlined. Even then a code
generator may chose to
> play conservative, and drop the flow analysis, as soon as
the vector's
> address is passed to any function.  Having pointers and
refs around is
> generally an inhibitor. As class members are always
accessed through a this,
> it is easy for them to get 'lost'.

And yet, the optimisation value of the ore-fetch is only a
slight/light possibility, and as it seems it is
pessimisation with g++.

[SNIP]
> There's no known way to sidestep Murphy's Law.

And yet, you have to code against it.  See sleepers and time
bombs from Steve Dewhursts.
[SNIP]
> Yeah.  I generally use lists if on-the-fly insertions or
deletions are
> needed. And if a vector is 'transformed' I copy the
contents to a new one,
> and swap with the original at the end. That way leaves
less chance to break,
> and even plays better with lurking exceptions. At some
performance cost that
> shall is considered negligable -- if it weren't vector has
to be replaced.

Sounds a good approach.

> > > All that stuff shall be there commented.
> >
> > I do not agree with commenting every single detail.  The
only comment I
> > would put there would say:
> >
> > // if you do not understand this, do not touch it!
> 
> That goes against SD's gotcha #1.    That line brings no
information,
> as it applies to any code anywhere. 
> And helps nothing in understanding the code well.

On the contrary.  I find it fulfills every requirement of a
good comment.  it is very unlikely to go out of syn with the
code and at the same time MAKES YOU THINK.  It is a warning,
not a user's guide.  And as such, I find it much more
productive than a long comment (be it only 3 sentences)
which clutters the code, and even if it does not get out of
sync there is no guarantee that people will understand it
the way it was meant.  While good code will be understood,
because it is unambiguous - as opposed to natural language.
 All is needed is a sign saying: watch out, this code may
trick you.

> Also, that 'all stuff' may read misleading.  I don;t mean
to go
> Balzac-style.  In practice 2-3 sentences can cover all the
design-related
> decisions, and mark the lines depending on each other.  
It's not about
> showing off, just to keep all the information there.

The information should be kept in the code.  Not in the
comments.  If youcannot do that, you have chosen the wrong
algorithm,

> When the code is straightforward, it documents itself,
> but when there are those hidden relations, they must
> be added as a comment.

I fully disagree.  Half based on Steve's comments about
comments and half on my own experiences.

> > The reason being that comments describing what the code
does tend to
> either
> > go out of sync or in other ways become just clutter
(e.g.: people get
> better
> > at how to use vector).
> 
> I tend to insert what the state is at some key point
> (only where it is not obvoius), or a new operation
> starts, or reference to a step in outside dox.

That does not help with the FACT of life that comments do
not get updated and go out of sync.  No matter where they are.

[SNIP]
> Keeping comments in sync with code -- well sometimes it
really gets
> discovered only at some next update.

Which is one good reason not to do things twice, once in the
comment, once in the code.  Whoever does not understand the
code without comments should not touch it.

> > > In "in large teams or large organizations"?
> > > Unexperienced or unaware people will always wreak havoc --
> > > you can suggest them anything you like.
> >
> > Except that if code is written on a way to try to avoid
*inviting* them to
> > break things, they will have less chance to do so.
> 
> Dunno. I lost my sense of how beginners think, and just
> play by ear, when a problem is discoveretd try to go after
> it. Thinking ahead is much like the premature optimisation
> that often turns out to be pessimisation. :)

I am talking of experiences, not imagination.

> > > IMHO books like the
> > > one we discuss, and this discussion is aimed at those
already
> > > having the basic experience, and look for ideas to
improve.
> >
> > Sure.  And within 3 months I was able to get out 4
promises of the bosses,
> > that they will actually order the basic books for
people.  Absolutely no
> > books, but I have nice promises.  That is life.  And
believe me that for
> > summer interns they won't buy the book, and also believe
me that it will
> be
> > me, in 16 hours days, cleaning up the mess aftewards -
if the code, any
> > piece of it, invites you to break it.
> 
> I found having the book is less a problem -- make people read
> it is the real one. The first just cost a couple of bucks,
the other,
> well, that beats me.

Well, than you probably get it why it is a good idea (what
Herb and Andrei did) to *not* include full discussion of the
topic next to a coding/design guideline.  Those who fail to
read the referred books have no bases of complaint.  Those
who will read will rarely complain.  And since not-reading
means you have no word in a possible argument, this means
people will read them, at least it is more likely they do.

> > > The primary purpose to write some code is to do some
> > > behavior. Do what is intended.  Speed and other
optimisation
> > > issues are secondary by nature.
> >
> > Yep.  I think this is quite obvious and I do not see
when did I say
> > otherwise.
> 
> You didn't. Though the whole thread came up from the
> point whether the speed-gain of fiddling with end() is
> positive, and what is its measure.

And as it turned out it is negative, on at least one
platform and one test case.

> IMHO exactly that is a question that shall be kept to
profiling
> time -- and before that shape the code using other points.

Where my major point is that I do not put anything into the
code which has no functionalty fulfilling a requirement. 
Each single character of redundant code will render a poor
sole to deadly boring maintenance work in the future.

> > > In a professional environment it is even more the
case, there
> > > I wouldn't even think certain shape of code suggest
> > > optimisation, it shall reflect the intent instead.
> >
> > Probably.  But in this mailing list, if it is sent in
with the word
> "faster"
> > next to it, I believe it is good enough cause to me to
think that it was
> > intended as an optimization.  And please also believe me
(or believe Herb
> > for that matter, he has a nice war story about it) that
large organization
> > fall into the trap of premature optimization just the
same as an
> individual.
> 
> LOL. When we talk about coding the dram world and the
> real world is easily tangled -- some sentences describe
> what we see otherd what we want/expect/woud like
> to see. Certainly I believe all kind of s*** happens
> everywhere, and just being large does not prevent it.
>  MS is not exactly a small company still fighting the most
> stupid bugs like buffer overruns.

Well, the point I have raised when talking about premature
optimisation is not at all about MS, but some other, unnamed
company Herb has been consalting to.

[SNIP]
> Somewhere I mentioned style, idioms, etc are dependent
> on the environment.
> 
> Unfortunately it is really easier to find blind
copypasters than people
> actually knowing all the whys.

Actually how things go nowadays, peopel are *trained* to be
copy-pasters.  You can find people with 15+ years of
experience who have never worked on anything form scratch.

[SNIP]
[SNIP]
> > That why you see there:
> >
> > // Black magic, do not change until you have grasped its
workings!
> >
> > :-)
> 
> Then comes your ' debugging night session 3 years later '.

Experience shows otherwise.

> I'd put a few-words tail comments:
> 
> vec.reserve(oldsize + 3); // line ** below will break
unless having space
> for 3 extra items
> ... for(...)
> {...
>     vec.push_back(newitem); // ** iterators still valid as
we reserved the
> extra space
> }
> 
> Call it my kind of magic to "not call any idiots to easily
break the code".
> ;-)

And you have effectively doubled your work.

> And if they do at least I can flame them at will.

So can I,but I never had to.

> I recall a night debug session, staring clueless why the
code doesn't pass
> some pont where I even inserted a messagebox popup.  Later
I discovered my
> wery own inserted banner telling 'this code is called from
working thread,
> do not even think use GUI especially messageboxes.'  It
was as many as 3
> lines above the point I inserted the messagebox.
> 
> I'm little skeptic people will reliably spot comments no
near enough.

See, that is one more reason to keep comments to the
minimum.  To ensure that if people see one, they know it is
important and they MUST read it.

Attila aka WW

Ps: who really stops now.