Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory management in C programs (2014)

nethack4.org

Post reply on HN
Print view View original

91–100 of 106 posts

Re: Memory management in C programs (2014)

#91

Post by qwertyuiop924 »

sdegutis wrote: post #88
qwertyuiop924 wrote: post #83

Earlier quoted context omitted.

Well, that's because it IS the right tool for the job. C was built for systems programming: kernels, filesystems, and the like. It really wasn't built for applications space programming.

No, C wasn't built for those things. Rather, it just so happens to be suitable for them. C was built as a higher-level alternative to assembly, for writing any kind of computer programs.

You can say that, but Dennis and Ken were writing Unix. The language got its feature set from what they needed for that application. And that application was systems programming.

Re: Memory management in C programs (2014)

#92

Post by deathanatos »

theseoafs wrote: post #50
deathanatos wrote: post #21

Earlier quoted context omitted.

While I agree, strdup is POSIX. In the exceedingly rare event that you're on a system without it, it's simple enough to roll your own. (And if this occurred more than a couple of times, I'd roll my own anyways to keep the code obvious.)

In the exceedingly rare event that you need to target Windows?

Honestly, when I wrote the post, I thought I recalled that Windows had strdup (Windows does include some limited POSIX functionality, IIRC; e.g., "select" definitely exists, and is also a POSIX function, so I figured surely strdup was there.) MSDN seems to indicate that Windows does in fact have strdup — and that it's "deprecated" in favor of "_strdup", which appears to do exactly the same thing as strdup… what on earth is going on here?

Re: Memory management in C programs (2014)

#93

Post by robotresearcher »

PeCaN wrote: post #51
comex wrote: post #45

Earlier quoted context omitted.

Any function can overflow the stack. If the object is constructed on the heap, 'new' can fail but will always throw an exception; if you aren't using exceptions it will just crash the process.

Yeah. That's why I don't say it's a failure condition for a stack-allocated object to overflow the stack. Notice my parent comment said: > Constructors are resource allocation, so they can always fail. Which is false.

Can you explain why this is false? If I run out of stack or heap by exceeding the process limit, the constructor must fail. Is this incorrect?

I see your comment above that stack overflows essentially never happen, but having watched it happen, I disagree.

Re: Memory management in C programs (2014)

#94

Post by ori_b »

robotresearcher wrote: post #93
PeCaN wrote: post #51

Earlier quoted context omitted.

Yeah. That's why I don't say it's a failure condition for a stack-allocated object to overflow the stack. Notice my parent comment said: > Constructors are resource allocation, so they can always fail. Which is false.

Can you explain why this is false? If I run out of stack or heap by exceeding the process limit, the constructor must fail. Is this incorrect? I see your comment above that stack overflows essentially never happen, but having watched it happen, I disagree.

This is not an error that you can reasonably recover from. If you are out of stack, even constructing an exception to throw is likely to fail.

Because the only correct behavior here is to terminate the program immediately, it doesn't matter in the discussion of whether to use exceptions or not.

Re: Memory management in C programs (2014)

#95

Post by collinmanderson »

_RPM wrote: post #3
sdegutis wrote: post #2

As someone obsessed with writing C code, something just clicked. I think I understand better why there are so many JavaScript programmers, so many tools and frameworks written in and around JS every day. For me, C is the gateway to the computer. It's ubiquitous. It's deceptively simple. I can literally write anything I want in C. It's an exciting thing to have an open main.c file sitting in front of me. That must be…

I agree completely about C being the gateway to the computer. It really is the only way to go if you want to learn real programming. That doesn't mean I'm discounting JavaScript developers, but I like C better and it's more fun.

Slightly off topic: The way I look at it, C and C++ are the bedrock of all programming languages, because the popular compliers (llvm/clang, gcc and VisualStudio) are written in C and C++.

JavaScript, for example requires a browser to compile, which requires gcc or clang to compile. Python, Rust, etc all depend on programs written in C and C++.

Go is one recent exception of a popular language whose main implementation is completely self hosted. Though, Go doesn't host other popular languages.

Re: Memory management in C programs (2014)

#96

Post by gnaritas »

_RPM wrote: post #3
sdegutis wrote: post #2

As someone obsessed with writing C code, something just clicked. I think I understand better why there are so many JavaScript programmers, so many tools and frameworks written in and around JS every day. For me, C is the gateway to the computer. It's ubiquitous. It's deceptively simple. I can literally write anything I want in C. It's an exciting thing to have an open main.c file sitting in front of me. That must be…

I agree completely about C being the gateway to the computer. It really is the only way to go if you want to learn real programming. That doesn't mean I'm discounting JavaScript developers, but I like C better and it's more fun.

> I agree completely about C being the gateway to the computer. It really is the only way to go if you want to learn real programming.

Nonsense. That's as absurd as claiming assembly is the only way to go if you want to learn real programming.

> but I like C better and it's more fun.

Which is the only reason you think the above, nothing to do with reality, everything to do with personal preference.

Re: Memory management in C programs (2014)

#97

Post by hamiltonkibbe »

deathanatos wrote: post #21
vinkelhake wrote: post #18

Earlier quoted context omitted.

malloc+strcpy is standard C, strdup is not.

While I agree, strdup is POSIX. In the exceedingly rare event that you're on a system without it, it's simple enough to roll your own. (And if this occurred more than a couple of times, I'd roll my own anyways to keep the code obvious.)

I'd wager a significant amount of production C is running on systems without ANY OS

Re: Memory management in C programs (2014)

#98

Post by zerohp »

jemfinch wrote: post #27
userbinator wrote: post #22

Earlier quoted context omitted.

And above us is probably FORTRAN and above them is probably COBOL. Actually, I think assembly language would probably be the next age "peak". If you know Asm you'll be far better at C; things like pointers and indirection immediately make sense. The effect is weaker, but still there in the other direction. (FYI, FORTRAN predates COBOL by a few years.)

> If you know Asm you'll be far better at C; things like pointers and indirection immediately make sense. Be sure not to confuse cause and effect there: if you managed to learn ASM, you must not be the sort of programmer who is confused by pointers and indirection.

I don't think you can draw that conclusion either.

At my university, the Electrical & Computer Engineering curriculum teaches freshman assembly language before C. All of the ECE students understand pointers immediately. The Computer Science curriculum teaches C++ (with raw pointers) before assembly language. Pointers are significant source of frustration for many students in CS.

Re: Memory management in C programs (2014)

#99

Post by rat87 »

collinmanderson wrote: post #95
_RPM wrote: post #3

Earlier quoted context omitted.

I agree completely about C being the gateway to the computer. It really is the only way to go if you want to learn real programming. That doesn't mean I'm discounting JavaScript developers, but I like C better and it's more fun.

Slightly off topic: The way I look at it, C and C++ are the bedrock of all programming languages, because the popular compliers (llvm/clang, gcc and VisualStudio) are written in C and C++. JavaScript, for example requires a browser to compile, which requires gcc or clang to compile. Python, Rust, etc all depend on programs written in C and C++. Go is one recent exception of a popular language whose main implementatio…

I hate that way of looking at it because I think it's totally wrong.

C (this view is usually presented as only about c) isn't fundamental or bedrock in any way. Most of our current stacks just happen to be written in it.

The original Mac OS for instance was written in Pascal and C. The most popular open source compilers are written in c++. Most browsers are written in c++ not in c.

And there's no reason these days you couldn't rewrite llvm (a set of compiler libraries and compilers mostly written in c++, not that rust compiler uses llvm for code generation but the frontend is in rust) in haskell or java or javascript(they'd be slower but they would work). Haskell has useful features for writing compilers and a lot of language analysis libraries already. If you re-wrote in in rust it'd be just as fast.

Hell this guy (https://github.com/jameysharp/corrode) wrote a rust-c source-to-source compiler in literate haskell. Also in a few years servo will be a full browser in rust and Firefox is already adding components written in rust.

Other then os interface & c binary api linking there is nothing special about c or c++.

Re: Memory management in C programs (2014)

#100

Post by coroutines »

sdegutis wrote: post #87
coroutines wrote: post #59

Earlier quoted context omitted.

I hate installing things. :x I get pretty turned on by offering up something like Google Sheets as a webapp that installs and is usable in seconds over the Internet. I used to really love Lua but even though it was

Sure, unless you're the guy who writes Minecraft. People installed that. And Atom. And Spotify. There's still some room for desktop apps like these, granted not as much as before.

I'm not saying people won't install desktop apps - I just like that there is a diminishing reason to do it outside the browser. [High performance] games, browsers themselves, video players (VLC), and dev environments, are some of the last things left...
Post reply on HN