frankish

Ok, picture this, you belong to a company called Software Originals, Ltd. Cool huh? Well, it's a small company consisting of me and you. We're an outsourcing company. Anyways, we've been asked to fix a problem with what is thought to be in the C++ STL. Specifically, it has to do with the vector object.

The problem is that the C++ containers seem to reallocate memory when stuff is added to them or when they are copied. Our client does not like this memory reallocation, he thinks it's possibly dangerous and would like us to do something about it. I'm sitting this one out 'cause I'm the owner of this company. You, the software engineer, must come up with a way to get by this. What do you do? Reimplement the STL? Is that a practical decision? What would you do in this situation and how would you do it? (whatever you do)

I'm serious here. Imagine that you are really in this company and you are faced with this choice. This is kind of to get you (an me) to think.

Nebula

I would quit ^_^

__________________
When will Jesus bring the porkchops?

Infinite Recursion

Sounds like a good homework assignment...

As such, I'd make the student do his own homework and get him to approach the problem from both sides.

I'll keep my answers short and broad, as to not derail the educational value.

First off, if I went into business with someone and it happened to be a software business, they will be able to code and willing to code just as much as I am. Because I wouldn't hang around long while they sit on their ass while I wrote the code that made the money. I would set up my own shop before that lasted more than a day.


"Reimplement the STL? " -- No.
"Is that a practical decision?" -- No.

"What would you do in this situation?"

I would go to the STL site, google for documentation and see if it is a known bug. Due to the widespread use of STL, chances are someone has already encountered it and there is a fix, so there is no need to reinvent the wheel.

"...and how would you do it? (whatever you do)"

See above.

__________________
http://jasonpowers.net

"There are a thousand hacking at the branches of evil to one who is striking at the root."

Narue

>The problem is that the C++ containers seem to reallocate memory when stuff is added to them or when they are copied.
Good thing too. Imagine the chaos that would ensue if dynamic containers didn't actually get more memory when they grew and all containers aliased each other.

>Our client does not like this memory reallocation, he thinks it's possibly dangerous and would like us to do something about it.
It sounds like your client is stupid. Clients dictate how the software is to behave and perform, but the inner workings are the decision of the developer based on those requirements and the client typically has no say in the matter. If a client told me to use an array because dynamic memory is possibly dangerous when a binary tree would be vastly superior, I would tell him to mind his own business and leave the programming to someone who actually knows how to do it right.

>What do you do?
Reserve enough memory from the beginning? Or perhaps write an allocator that somehow takes memory from a magic world where all the memory you'll ever need is already allocated and initialized just for you. I'm being sarcastic, but those are actually two realistic solutions. You can reserve memory and avoid reallocations, or you can write a specialized allocator that takes memory from an existing pool.

>Reimplement the STL?
In a production environment, this would be the height of stupidity. Unless you're a vendor of the C++ standard library, of course.

>Is that a practical decision?
Does it sound like a practical solution? Do you have any idea how much work and thought goes into even the "simple" standard containers like std::vector?

__________________
Even if the voices aren't real, they have some pretty good ideas.

DaWei

You can defer this action, reduce the number of incidences, whatever, by simply setting a larger than (immediately) necessary size on the first usage. If the owner of your company doesn't understand enough about the existing STL to use it advantageously, I doubt the owner of your company understands enough about the issues to rewrite it. What do you think?
Clients may rule the day, but the aren't always right. When they aren't it's someone's job to educate them with a rational approach. Does your client really know what he's talking about? Does the owner of your company? Someone needs to. Otherwise, it's the blind leading the blind, and you both fall and bitch (or however that old saying goes).

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

grumpy

Dictating something like this is not necessarily the sign of a stupid client.

One characteristic of safety critical code (eg code which, if it fails, causes loss of life) is that its behaviour to all possible sets of inputs must be completely characterised and completely predictable. The reason for that requirement is that, if the behaviour is not completely characterised and predictable, it is extremely difficult to prove that it does not have undesirable failure modes. The behaviour of dynamic memory allocation is rarely predictable so it is difficult to prove that anything which does dynamic memory allocation cannot fail in some undesirable manner. For example, it is not possible to guarantee that a memory allocation will succeed, or (if it succeeds) that it will occur within a fixed interval of time. Hence, one VERY common guideline for safety critical code is to avoid ANY use of dynamic memory allocation (except possibly at program startup). An intelligent client with a safety critical application (eg medical equipment, aircraft control systems, control of nuclear reactors, etc etc) could therefore quite easily go to the level of detail of stipulating no dynamic memory allocation.

frankish

Yeah, and lose a large salary of $80,000 a year! Man, you figure out this one I'll raise it to $90,000 a year!

DaWei

Add ten more, put it in writing, and contact me.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Narue

>Dictating something like this is not necessarily the sign of a stupid client.
In safety critical code, the client will make damn sure that the developers know to stress failsafes and redundancy. In such a case, there's no need for the client to specify implementation details because the developers (if they're qualified to write the software) know how to go about it, and the client probably isn't going to know how the software is implemented in the first place, so suggesting minute details would be irrelevant. It's akin to hiring a plumber and then standing there telling him how to do his job. It shows a complete lack of trust, and if the client doesn't trust his developers than he should get ones he does trust. If he fails to do that, then I think he's stupid.

__________________
Even if the voices aren't real, they have some pretty good ideas.

DaWei

I've had plenty of clients (like E-Systems and the Wild Weasel program) where the client knew MUCH more about the requirements and technology than I. Part of his responsibility was to stand over me while I unstopped a very high-tech sink.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers