I mainly use dynamic languages. For many years I see statically typed hello worl

Question

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?

Explanation / Answer

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

constraints: either limited memory, or cache performance, or some other speed requirement that absolutely prohibits dynamic (re)allocation
laziness: IMO this is mostly a hang-over from C, which didn't have a rich library container library
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.

is it constrained in memory or performance? Not to start with, even if you're running it on a wristwatch these days
are we either lazy, or writing C 20 years ago? No!
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:

choose a standard container that suits your access patterns (std::list and std::vector are popular all-purpose choices)
write some class to represent an employee
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.

tl;dr

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.