17

I believe I have a good understanding of what is stored on the stack(for example primitive data types) and what's stored on the heap(for example an instance of a class. But is there anyway to verify this for educational/verification of my expectations reasons?

It can be in a debugger(gdb or rad debugger or worst case vs) or directly code based(thinking something like gettype(variable) but like isstackstored(variable).

you are viewing a single comment's thread
view the rest of the comments
[-] vrek@programming.dev 1 points 1 day ago

Wow, ok I guess I have a lot more to learn. I get the general concept of pointers/references and stack/heap. I kinda partially understand reading asm but didn't know about the rsp and rsb special memory locations, more familiar with like rax or eax but those are just general purpose registries, and that's mostly just from playing with https://godbolt.org/ if you're not familiar it's a website to convert code(many supported languages) to asm with several compilers and options similar to your g++ command but web based so I don't know how it would handle low level memory checking like this(also can't execute code, just display the asm code).

[-] Lee@retrolemmy.com 1 points 1 day ago* (last edited 1 day ago)

Wow, ok I guess I have a lot more to learn.

I think it depends on how low level you want to go. The benefit of using these kind of languages is that they abstract away the hardware so that you don't have to worry about the details. Granted details can matter when you're trying to push performance to the limits or be incredibly efficient, but that's so rare for people to do because it can be very time consuming and on modern CPUs, a compiler can often do optimizations that are better than a human would, especially when taking in to account advanced CPU features. With Out of Order Execution, branch prediction, pipeline flushes, and so on, trying to manually optimize stuff at a low level can result in things actually being less efficient (on a modern CPU) even though it would have been more efficient on a 1980s CPU (granted, my current hobby project is with a CPU popular in the 1980s -- Motorola 68K).

What I think is related to stack vs heap that's actually worth learning:

  1. new/malloc are slow
  2. pointers (don't worry about stack vs heap for this)
  3. variable scope/lifetime -- memory allocated via new/malloc stays allocated until it is deallocated with delete/free. Messing this up can cause memory leaks or other types of bugs and from what I understand, something that Rust is supposed to do better (but I've not looked at Rust, so don't really know for sure)

I think those are necessary. If you're wanting to go a little deeper on memory stuff, but not quite down to assembly, you could learn about memory pages/page tables/how operating systems handle memory allocations/virtual memory. Those topics are not C or C++, but more general computer/OS.

[-] vrek@programming.dev 1 points 1 day ago

Well my current project is not really performance critical within reason. Basically trying to write a program to handle a bunch of statistics for manufacturing. If you know what minitab is, kinda similar but multi-platform(gui is qt based) and removes some pain points. So for example if your company makes cuts wooden planks and you measure them, you can track those measurements and get a warning if something is going on before you make bad product(maybe something is wrong with machine, maybe it's high humidity causing wood to swell, maybe it's a new operator who needs training... Figuring that out is the engineers job)- . An example of additional feature is ability to generate a gage r&r plan sheet for a new measurement system. A gage r&r is often 10 samples, tested 3 times each by 3 different operators to see how repeatable and reproducible(hence r&r) your measurement system is. But you want the order randomized to eliminate hidden changes(for example humidity decreasing from morning to afternoon) how ever it's often easier to "borrow" an operator for an 2 hours then another then another than to borrow 3 operators for 6 hours. Minitab has the ability to generate a run order to do this but it randomizes both samples and operator meaning you need 3 operators for 6 hours. People got around this by faking their "randomness", one person I knew even tried to do this with a d10 die. This tends to not be real random and is easy to make a mistake(for example person with d10 didn't notice they rolled a 7 twice on the third run of the second operator). We had to investigate this failure, write a report of our findings and repeat the who test. I want to give an option to randomize samples and operators or only operators.

All the math for this stuff is pretty well known, proven and documented. The only performance I'm concerned with is with large datasets. For example we had one process that produced 5-7k data points per day, they had data going back till like 2010. The file was like 2 gig and took a good 5 minutes to open. I want to create a new file for each process, each year(time range may be adjustable). Then you have "product" file you open, then you select which processes you are interested in and the time frame you are interested in. All your data is then loaded(the product file effectively just has links to all associated process files for each year with data) and graphs all updated based only on the data you selected(my company reviewed data for previous month but had to keep records for up to 100 years for legal reasons). That should cut out most my performance concerns. But 7k data points on one process per day over 6 months is 1,281,000 data points so still have to be a little concerned.

I'm also unemployed so I guess that's why I'm ranting uncontrollably too. ๐Ÿ˜‹

this post was submitted on 01 Sep 2026
17 points (100.0% liked)

Learn Programming

2231 readers
53 users here now

Posting Etiquette

  1. Ask the main part of your question in the title. This should be concise but informative.

  2. Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.

  3. Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.

  4. Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 3 years ago
MODERATORS