«

Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it, and
I said that the code looks cleaner this way. He countered by saying
that he was regarded the dyanamic allocation that C++ STL classes
perform as being very inefficient. He also said that he wasn't
particularly interested in clean code (!). My question to the group:
In what situations, if any, would you use fast but hackish C-style
code in favor of the convenient STL classes? Would your answer change
if you were forced to use a questionable implementation (such as,
not-so-hypothetically, Borland 4)?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Christopher Benson-Manica wrote:
>
> Yesterday I changed some code to use std::vectors and std::strings
> instead of character arrays. My boss asked me today why I did it, and
> I said that the code looks cleaner this way. He countered by saying
> that he was regarded the dyanamic allocation that C++ STL classes
> perform as being very inefficient.

Really?
Has he tried it?
Does he have some performance data?

In most cases there is next to no difference in execution speed.

> He also said that he wasn't
> particularly interested in clean code (!). My question to the group:
> In what situations, if any, would you use fast but hackish C-style
> code in favor of the convenient STL classes?

Never

> Would your answer change
> if you were forced to use a questionable implementation (such as,
> not-so-hypothetically, Borland 4)?
>
> --
> Christopher Benson-Manica | I *should* know what I'm talking about - if I
> ataru(at)cyberspace.org | don't, I need to know. Flames welcome.


--
Karl Heinz Buchegger

Christopher Benson-Manica wrote:

> Yesterday I changed some code to use std::vectors and std::strings
> instead of character arrays. My boss asked me today why I did it, and
> I said that the code looks cleaner this way. He countered by saying
> that he was regarded the dyanamic allocation that C++ STL classes
> perform as being very inefficient. He also said that he wasn't
> particularly interested in clean code (!). My question to the group:
> In what situations, if any, would you use fast but hackish C-style
> code in favor of the convenient STL classes?

Exactly in this case: when the boss say that you must do it.

--
Salu2

"Christopher Benson-Manica" <> wrote in message
news:c7quih$1om$...
> Yesterday I changed some code to use std::vectors and std::strings
> instead of character arrays. My boss asked me today why I did it, and
> I said that the code looks cleaner this way. He countered by saying
> that he was regarded the dyanamic allocation that C++ STL classes
> perform as being very inefficient. He also said that he wasn't
> particularly interested in clean code (!). My question to the group:
> In what situations, if any, would you use fast but hackish C-style
> code in favor of the convenient STL classes?

Frankly, it sounds like your manager doesn't *really* know what he's talking
about. There is far, far more money wasted on fixing and customizing and
maintaining hard-to-read code than there is lost on inefficient code. Now
it just could be that your compiler does a crappy job with these things and
it is slow. But on the other hand, it still might not matter! (Does it
really matter to the user if something takes .03 seconds or .01 seconds?)

Christopher Benson-Manica wrote:

> Yesterday I changed some code to use std::vectors and std::strings
> instead of character arrays. My boss asked me today why I did it, and
> I said that the code looks cleaner this way. He countered by saying
> that he was regarded the dyanamic allocation that C++ STL classes
> perform as being very inefficient. He also said that he wasn't
> particularly interested in clean code (!). My question to the group:
> In what situations, if any, would you use fast but hackish C-style
> code in favor of the convenient STL classes? Would your answer change
> if you were forced to use a questionable implementation (such as,
> not-so-hypothetically, Borland 4)?

Well, you don't say if you're talking about some type of inner-loop, or
whatever, but still... in general...

Your boss is wrong.

Writing messy code is VERY expensive. You'll spend more time debugging
it. It will be less maintainable. It will lead to hacks upon hacks.
Vicious circle.

Clean code should ALWAYS be the first priority. Performance driven
(less clean, hacky) code should NEVER be implemented first. Only
optimize when you have to, and the minimum you have to. This is what a
profiler is for. Has your boss run a profiler and determined that your
new STL usage is his hot spot? Probably not.

Write clean code. When you're finished, if it's fast enough, then
you're done! [and you have easier-to-debug, more-maintainable,
nice-code to boot]. If it's NOT fast enough, profile it, and optimize
your hot spots.

Meanwhile, I'd try to tactfully explain this to your boss. If he
doesn't understand, then, well, don't say anything to him, but you
should probably start looking for another job because you're working for
a dumb ass.

--Steve

[NOTE: I am a game programmer. Have been (professionally) for 8 years.
We require the utmost of performance. While we don't use STL in our
game code, we use our own somewhat similar stuff. Anyway, it doesn't
matter that he decided to use STL as his example, he is JUST PLAIN WRONG..]

Karl Heinz Buchegger wrote:
>
> Christopher Benson-Manica wrote:
> >
> > Yesterday I changed some code to use std::vectors and std::strings
> > instead of character arrays. My boss asked me today why I did it, and
> > I said that the code looks cleaner this way. He countered by saying
> > that he was regarded the dyanamic allocation that C++ STL classes
> > perform as being very inefficient.
>
> Really?
> Has he tried it?
> Does he have some performance data?


Since when does the boss have to prove things to subordinates?

Christopher is the one who wants to introduce changes to the code base,
it's up to him to program it both ways and perform benchmark testing on
it. A nice boss would let him try that on company time, a hardheaded one
would suggest that weekends are made for such experiments.



Brian Rodenborn

"Christopher Benson-Manica" <> wrote in message

> Yesterday I changed some code to use std::vectors and std::strings
> instead of character arrays. My boss asked me today why I did it, and
> I said that the code looks cleaner this way. He countered by saying
> that he was regarded the dyanamic allocation that C++ STL classes
> perform as being very inefficient. He also said that he wasn't
> particularly interested in clean code (!). My question to the group:
> In what situations, if any, would you use fast but hackish C-style
> code in favor of the convenient STL classes? Would your answer change
> if you were forced to use a questionable implementation (such as,
> not-so-hypothetically, Borland 4)?

By char arrays, do you mean
char array[200];
array = new char[200]; delete[] array;
array = static_cast<char*>(malloc(200u)); free(array);
array = :perator new(200u); :perator delete(array);

As regards memory allocation, the first way may be slightly faster, but not
always. The 2nd, 3rd, and 4th ways are usually the same. The default STL
allocators use the 4th way.

Which way is faster depends very much on the details of your scenario, such
as the size of the array, number of objects created, etc. If you create
lots of small arrays, then the 1st way may be faster.

In general, the STL containers are extremely fast, and might be faster than
your home-grown containers due to specializations, fancy algorithms, etc.

The STL allocators let you use pool allocators, but you can also that by
overloading Classperator new. In the first case, the pool may be per
container; and in the second, the pool is shared across containers.

The STL containers also destruct their data by calling allocator.destroy on
each element, though in a good compiler this would be optimized away when
the element is a POD, as the statement has no effect.

The STL containers also default initialize their members, if you provide a
size parameter (but don't confuse this with reserve).

But std::string implementations may also provide an optimization for small
strings, namely to contain an element like char[32]. I don't know much
about this topic though, or whether any real implementations actually do
this.

As regards the topic of clean code versus hackish code, my theory is that
hackish code is easier to write and therefore produces immediate business
value (ie. profits). But it is harder to maintain and so over the long term
is more costly. How businesses fare with either method is an interesting
topic, and I have not done any formal research into the subject.

But also be aware that usage of STL does not automatically mean your code is
cleaner.

In article <c7quih$1om$>, Christopher Benson-Manica wrote:
> Yesterday I changed some code to use std::vectors and std::strings
> instead of character arrays. My boss asked me today why I did it, and
> I said that the code looks cleaner this way. He countered by saying
> that he was regarded the dyanamic allocation that C++ STL classes
> perform as being very inefficient. He also said that he wasn't
> particularly interested in clean code (!). My question to the group:
> In what situations, if any, would you use fast but hackish C-style
> code in favor of the convenient STL classes? Would your answer change
> if you were forced to use a questionable implementation (such as,
> not-so-hypothetically, Borland 4)?
[-]
IMHO clean code tends to be faster than "hackish" C-style code plus
I'd like to add writing clean C code is as easy as writing unreadable
and arcane crap in C++.

Or to cite myself (since no-one ever else does) -- "If the compiler
loves my code I got it right".

Changes to an existing code base are an tricky issue, though and
just making some changes here and there may just be what you want
to avoid -- a quick and dirty hack.

Not to mention the whole thing needs to be re-tested and your
project manager needs to give his or her thumbs up and it may
result in an unpleasent surprise for others who rely on the original
design (if there's any, that is) and ...

Well, and last but not least although bosses ought to mature enough
to rely on their developers abilities it's never a good idea to
start an argument with your boss for *he* is the one who's in
a position to fire *you*.

Cheers,
Juergen

--
\ Real name : Juergen Heinzl \ no flames /
\ Email private : \ send money instead /
\ Photo gallery : www.manannan.org \ /

Siemel Naran wrote:
> In general, the STL containers are extremely fast, and might be faster than
> your home-grown containers due to specializations, fancy algorithms, etc.

There was a mildly interesting talk at the Game Developers' Conference
this year given by a guy from the Xbox ATG.

ATG is a group that Xbox developers (1st & 3rd party) turn to for
optimization. They've seen LOTS of games and TONS of code in the past
few years.

This speaker mentioned that in *every single case*, the STL (shipping
with Xbox DK's, probably Roguewave?) outperformed the home brew lists,
arrays, maps, trees, etc.

He also mentioned lots of other mostly retarded things they'd found.
Most were unbelievable stupid, but that's OT.

> But also be aware that usage of STL does not automatically mean your code is
> cleaner.

Excellent point.. Though, it probably generally helps. I know most
one-off tools I've written in the past 5 or so years (with STL) look
much cleaner than those I wrote prior to that (without STL).

--Steve

"Stephen Waits" <> wrote
> Siemel Naran wrote:
> > In general, the STL containers are extremely fast, and might be faster than
> > your home-grown containers due to specializations, fancy algorithms, etc.
>
> There was a mildly interesting talk at the Game Developers' Conference
> this year given by a guy from the Xbox ATG.
>
> ATG is a group that Xbox developers (1st & 3rd party) turn to for
> optimization. They've seen LOTS of games and TONS of code in the past
> few years.
>
> This speaker mentioned that in *every single case*, the STL (shipping
> with Xbox DK's, probably Roguewave?) outperformed the home brew lists,
> arrays, maps, trees, etc.

That this happens in some -- maybe even most -- cases, doesn't make it a rule
(I'm not claiming that you're passing it off as one). When I was working with
John Lakos, he had written a family of replacement containers that consistently
outperformed Standard Library containers by a substantial margin, at the expense
of ease of use and, in some specific cases, generality. I'll be the first to
argue that in most cases, the Standard Library is more than adequate and should
be the first choice, but it's by no means the most runtime-efficient way to do
things for all situations.

> He also mentioned lots of other mostly retarded things they'd found.
> Most were unbelievable stupid, but that's OT.

And specific to their particular code base.

> > But also be aware that usage of STL does not automatically mean
> > your code is cleaner.

Definitely. I've seen some mighty ugly code that used Standard containers.

Claudio Puviani