Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I mainly use dynamic languages. For many years I see statically typed hello world examples like

const int STACK_SIZE = 100;

And I will think "wow, I can't think like that". I understand memory management, syntax, pointers (mostly). Please let me into your brain for a second and analyze this use case with me.

Let's say we have a command line application that's going to let us manage employees (exciting!). Let's just focus on adding new employees. We're a trendy new startup that's going to do a moonshot so our employee list size is going to start at 1 but we're eventually going to add 7 billion co-founders and maybe more (aliens? dogs? cats?).

In ruby/python/javascript, I'd just create an array and suffer/refactor later when performance is terrible. Of course, you'd use a database in either C++ or some other language. But let's entertain this for a second. Would a C++ person break the problem down past one data structure? I think of this problem as "an array" problem. But maybe someone with more low-level experience thinks like this?

  • Create a buffer to hold the list as the user adds in names, this can be fixed size
  • Periodically flush the buffer to a file or something like that.

Is that realistic? I understand the requirements here are contrived and vague. But let's say a C++ developer was creating this small application for themselves. Would they just use a smart pointer or something that would grow over time or would they create a std::string*?

Let me give another example. Let's say you write a problem to loop through a file and do something with each line. Some people (including myself) start thinking with a small example file. Then later, you find that your problem can't handle large files. Whoops. Sometime I feel like lower level programmers would naturally pre-optimize out of discipline or experience to read the file in a buffer or something like that. Do you agree?

share|improve this question
Apart from what @Useless said, you should be aware that there are lots of online sources using C++ in an old-school way(as C with classes) that make for a poor introduction to modern C++. A modern C++ program won't be that different from a similar python program and should have very little (if any) manual memory management, instead relying on RAII. It should operate on a high abstraction level only becoming low-level in a few key areas. BTW: std::string* is an odd mixing of abstraction levels that you should rarely see. – user786653 Dec 5 '13 at 18:34
up vote 14 down vote accepted

Small, fixed-size buffers might be used for any of the following reasons:

  1. constraints: either limited memory, or cache performance, or some other speed requirement that absolutely prohibits dynamic (re)allocation
  2. laziness: IMO this is mostly a hang-over from C, which didn't have a rich library container library
  3. correctness: if you're matching some external entity (hardware, or a file format or wire protocol) that genuinely has fixed size elements, then why not represent them exactly?

So, let's look at your employee DB example.

  1. is it constrained in memory or performance? Not to start with, even if you're running it on a wristwatch these days
  2. are we either lazy, or writing C 20 years ago? No!
  3. are we reflecting some external truth? Maybe if we move to a DB later, and decide to make some column VARCHAR(100), then having an array of size 100 might be reasonable. But we'd be doing it for expressiveness , not to show our low-level l33tness. And besides, you excluded this case in your question.

The right way to do it would probably be to:

  1. choose a standard container that suits your access patterns (std::list and std::vector are popular all-purpose choices)
  2. write some class to represent an employee
  3. write some code to (de)serialize this employee

If you do this right, it manages all the memory for you, and doesn't require any fixed-length anything. It will also look somewhat similar to the equivalent logic in Python or javascript.


your stated problem is not a low-level problem, so there's no reason to trade off clarity or simplicity for low-level magic.

If you had a low-level problem, those low-level design decisions would proceed from the problem & solution domains.

Using low-level style on a high-level problem is just bad style, because it doesn't match the problem domain.

share|improve this answer
Great answer; helps me to identify that even C++ has sort of a high-level and low-level. I'm not sure if it's part of the OP's question, but maybe you could identify some types of problems that you would consider to be "low-level", and would demand fixed buffers, pointer access, etc.? – Katana314 Dec 5 '13 at 18:29
some binary network protocols map naturally onto fixed-size structures, as do things like on-disk filesystem structures and some file formats. All of those also suit overlaying the struct onto buffers, to avoid redundant copying. – Useless Dec 6 '13 at 14:07

Just because C++ programmers tend to delve into the lower layers of abstraction more often doesn't mean we always live there. When faced with a high-level problem, we use high-level abstractions.

Your example problem would likely be solved with a vector at first, refactored into an EmployeeList class backed by a vector as complexity grew, then refactored to be backed by a database as the size grew. C++ programmers aren't prescient about how their application will grow or not. We're just as bound by design principles like YAGNI.

If there wasn't a standard library vector, a good C++ programmer would write his own, and a bad programmer would suffer with the limitations that were handed him. People who fail to use abstraction appropriately are bad programmers in any language.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.