If I struggle to think creatively or "outside the box", how badly well struggle with programming?

I can't build things, it's like I hammer something down and think "why am I doing it this way?". I never get off the ground with anything.
Wouldn't a more creative brain have helped me?

Like, how am I supposed to make a smart decision about whether an object should be on the stack or heap? I can get it to work both ways and I just think, "I don't know which is better and I'll probably fuck it up, why bother?"

It's like any configuration I can come up with eventually becomes fucking stupid. Should it be in this header or that header? I'm not even coding, I'm moving things back and forth indecisively.

>Congrats you are now on par with the average indian programmer
ftfy

Son, you got some wild insecurities.

>how am I supposed to make a smart decision about whether an object should be on the stack or heap
You know you're supposed to engineer things right?
Slapping shit together makes you a code monkey. If you want to be a code monkey, great. There are places and that'll suit you and this guy If you want to ENGINEER things, you figure out the OBJECTIVE cost of putting things on the heap or stack, how it interacts with other components present in the application, whether it be on the high level or as low level as whether the data fits on the L1 or L2 cache whether it exceeds the cache line, if that data gets called so many fucking times that you should strongly consider storing it closer to the CPU registers

tl;dr THINK, nigger. Read a goddamn book. There is an objective reason to do 99% of the things you program, and your JOB is to weigh the costs.

>Slapping shit together makes you a code monkey. If you want to be a code monkey, great. There are places and that'll suit you and this guy
I need something like that, I need someone to just give me orders.

>tfw i hit my head at a very young age
i'm sure that affected my thought patterns somehow, i'm just completely uncreative and i struggle with logic

>you should strongly consider storing it closer to the CPU registers
>implying programming languages even give you control over this and it isn't entirely controlled by the OS

toplmao

Code monkeys don't need creativity. Leave the thinking part to the system analysts.

It's controlled by the compiler, not the OS, you ignorant

Attached: 1525586288600.jpg (592x448, 18K)

>memory
>controlled by the compiler
lmao neet go read about operating systems, there are tricks you can do to make it a little more likely certain data will stay in cache longer but you can't explicitly control it, they are just tricks.

What do you think the compiler does? Generating native CPU instructions BY DEFINITION affects registers dummy. Registers aren't cache either.

This can be trained
Start with simple math problems

Yes, a compiler generates instructions, and the compiler you use may affect the structure of those instructions slightly, but the compiler in absolutely no way controls how the data come into and out of memory or the registers, that is entirely handled by the operating system. The OS controls all processes and what data is in memory/cache/registers. You clearly don't know shit about OS.

The OS can interrupt your program and do whatever it wants, but it must return the registers and flags to their original state. If I write assembly that loads the ECX register for a loop, the OS can't fuck with that register. It's ludicrous.

You can control registers, that is not the original point I was contesting. You said if you are processing data many times, you should store it "closer" to the CPU registers in this post
by "closer", this implies you keep it in cache rather than memory or on disk, so when it ultimately gets loaded into registers to do computations it takes less time. Yes, you can explicitly say "load this register with part of this data structure I am processing" but if that data structure has not been used recently, or is large, it will not be in cache, it could be on memory or disk even, and it will take longer to load into registers. Just because you as a programmer say to load a register with a value says nothing about the speed of your program. All your high level code is compiled down into instructions to load registers and whatnot just like you are saying, but the thing is you specifically said you should store the data "closer" to the registers which is wrong because you cannot control that. If you say "load this data into this register" and the data is on disk it will take a relatively long time to load, but if it is in cache it will be significantly faster. But the thing is you can't control whether it is in cache or not or "closer" to the registers as you said.

Just as you admitted here, the OS can come in and do whatever it wants, so when it does this it will move your data structure out of cache and even potentially out of memory if it is too big, and so even though you say load this register with this data that doesn't mean you are making the data more easily accessible or able to be accessed faster.

it's actually two people you're quoting
the other guy posted would stuff on the stack be more likely to be in cache?

More likely than what to be in the cache? If you're talking about the stack vs. heap, neither are "more likely". Stack and heap both sit in main memory, the difference is the stack is allocated per function call so each function has its own stack space, and the stack for a function is wiped when the function returns. The data on the heap does not get wiped until the end of the program execution, a good example of when you want to allocate something on the heap vs. the stack is if you are returning a value from a function, under the ansi c standard, if you allocate a variable on the stack, and return that variable, this is not safe as the value of that variable could be destroyed before it is returned. If you allocate the variable on the heap and return it, it is guaranteed to be there still, but you must explicitly free it yourself when you are done using it.

ITT idiots: