Are modern programming practices too dependent on heap/dynamic allocation?

Are modern programming practices too dependent on heap/dynamic allocation?

most modern languages are smart enough to alloc on the stack

Which ones?

Most of them.

>casting the result of malloc

Why do people do this? Was it the Windows API books that started this?

Allocating on the stack is not a solution to all problems. Go ahead and allocate an array of a million doubles.

oh no a few megabytes?

No.
Using shitty dynamic scripting languages isn't a modern programming practice, btw. It's from the 90s.

swift for example

64 megabytes, which is quite a decent amount

>64 megabytes, which is quite a decent amount

8

It's 8.

The maximum stack size is by default only 8 MB in Linux.

...

A linux limit, not a c limit. I mean we're dealing with theoreticals here.

C doesn't even specify a stack, so heap vs. stack allocation would be nonsensical in that context. I may have a C implementation that is entirely stack-less.

>Memory layout of C program

What the fuck does C have to do with it? The standard says nothing about memory layout.

Static type masturbation. The people who cast the result of malloc are the same people who refuse to use languages with type inference, thinking it's the same thing as dynamic types, and thinking that's for noobs.

Fair enough, but even within the confined of linux pthread_attr_setstacksize() should make the original million doubles array completely feasible, if potentially harmful.

>pthread_attr_setstacksize()
Read the manual user. This function will fail if it is not able to set the minimum stack size. In other words, if you attempt to set it more than 8 MB without increasing the process stack size limit (for example using ulimit), it will fail.

So what's the problem. It's how I was taught at uni. I get it that it will get converted to a right type of pointer but wht's the problem, seriously?

Autistic cniles believe that it is impure because weakly typed implicit casts are preferable to anything sepples does.

...

I may not be reading it right but my man page says nothing about that but a google does show it's limited by the system. I guess that's my mistake.

Oh to be so afraid to fail that you waste all your time mocking others.

>others

Most of them. Anything that runs on the JVM gets escape analysis for free stack allocation for example.

BSS=the bullshit segment

Yes. I swear to god 90% of programmers today have no idea there are devices with 2K of RAM. The stack is incredibly wasteful. All locals should be static. Recursion should be prohibited.

>His compiler doesn't implement tail recursion

>Recursion should be prohibited.
fuck that, recursion is baller

recursion is useful when you don't know the length of data, but know the delimiter for it

Dropping a rack on your bench isn't better you fucking nerd

No.

I wish I knew how pointers work...

pointers are the simplest shit though

Yet I cannot do more than change the value of an int

protip: inc(ptr); doesn't equal inc(*prt);

TFW you just wrote a program for a machine with 1K of code-space and 64B of RAM

>All locals should be static
Where do you think the bss segment gets loaded genius

Cortex-M MCUs are quite popular, top models have up to 256k Ram, but you usually try to get by with something cheaper.

You still have to be resourceful about memory if you are programming those.

not on the stack.

However, the argument can be made that storing an object on the stack will only occupy memory for the time the function is executed whereas when you declare it static, it will occupy the memory for the entire run time of the program.

C++ does tho.

lol got a genuine chuckle out of that user lmao

Yeah and if you have a restricted set of memory, the static variable is still going to occupy it at runtime - the same memory the stack uses. This is what made me wtf at the static claim.