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

The case against a C alternative

c3.handmade.network

Post reply on HN
Print view View original

351–360 of 388 posts

Re: The case against a C alternative

#351

Post by FpUser »

nicoburns wrote: post #160
FpUser wrote: post #84

Earlier quoted context omitted.

And I wrote a firmware in C for 4-quadrant torque control in about the same time. I do not have any formal proof on how buggy/or not it is but the thing runs properly for 10 years already. If that is not "production code" I do not know what is. I am not inexperienced programmer. Rather quite opposite. But this was after I did not touch C and any microcontrollers for like 10 years.

I feel like C is somewhat manageable on microcontrollers. Programs tend to be smaller (micro!), you can often do static allocation which mitigates a lot of the memory management issues, and you're also often dealing with simple types and bit manipulation which is where C shines. In larger programs on full-fat operating systems, programs tend to be much larger (esp. if you include libraries - dealing with libraries be…

Generally I agree with everything you say. Each tool has areas where it shines and the opposite. One of the reasons I use multiple languages.

Re: The case against a C alternative

#352

Post by xigoi »

jokoon wrote: post #193

Finally an article I can agree with. C is great mostly because it's easy to learn, and it has many other advantages. I dislike all those new languages because they have too many features, and they're non trivial to learn. I've looked at some rust codebases and I don't think there will be a lot of people who will want to maintain them. Rust is difficult, even though it's an awesome language. A language that could comp…

> easy to learn

What exactly do you mean? Learn the basics? Become productive? Memorize the entire specification? I'd argue C isn't significantly faster at any of these than most other languages.

Re: The case against a C alternative

#354

Post by vitus »

a_t48 wrote: post #239
vitus wrote: post #231

Earlier quoted context omitted.

> unique_ptr is pretty bad for performance as well. Do you mean in terms of cache locality because it's heap-allocated instead of stack-allocated, or are you actually commenting on the overhead of copying some extra ints and invoking the destructor? Because it's certainly correct that just because you can use a unique_ptr, doesn't mean you should. ("A std::unique_ptr is used for expressing transfer of ownership. If y…

Safety is a good reason. I like protection against leaks and use after free. If I’m already allocating I’m not going to worry about the little bit of extra performance cost the abstraction might have.

To be clear: I'm not advocating for the use of `new` / `delete` over unique_ptr. But if you're creating a local object that never has to leave the current scope (or a member variable that's never moved in or out), there's no benefit to using a unique_ptr instead of creating the object directly on the stack or inline as part of your class, where the object's lifetime is bound to the scope, and your destructor is automatically run when its containing scope is cleaned up.

As an added bonus, you don't actually have to do a separate heap allocation.

Re: The case against a C alternative

#355

Post by jstimpfle »

WalterBright wrote: post #348
jstimpfle wrote: post #342

Earlier quoted context omitted.

Sure, I know who you are but I hold opinions too :-) I don't care about having to provide zero-terminated strings to OS and POSIX APIs, because somehow I almost always have the zero already. Maybe I'm a magician. Sometimes I have not, but >99% of what I give to printf is actually "text", and that pretty much always has the zero anyway. It's a C convention, you might not like it, but I don't sweat it. If I want to "pr…

The inconvenience and inefficiency is apparent when building functions to do things like break up a path & filename & extension into components and reassemble them. You wind up, for each function, dealing with 0 termination or length, separately allocated or not, tracking who owns the memory, etc. There's just no satisfying set of choices. Maybe you've found an elegant solution that never does a defensive copy, never…

I agree filepath related tasks are ugly. But there are a number of reasons for that that aren't related to zero termination. First, there is syntax & semantics of filepaths. Strings (whatever kind, just thinking about their monoidic structure) are a convenient user interface for specifying filepath constants, but they're annoying to construct from, and disassemble into, filepath components programmatically (relative to how easy I think it should be). Because of complicated syntax and especially semantics of components and paths, there are a lot of pitfalls. Filepath handling is most conveniently done in the shell, where also nobody has any illusion about it being fragile.

Second, you're talking about memory allocation, and this is arguably orthogonal to the string representations we're discussing here. Whether you make a copy or not for example totally depends on your specific situation. The same considerations arise for any array or slice type.

Third, again, you're free to make substrings using pointer + length or whatever, and this is in many cases the best solution. I could even agree that format strings should have better standardized support for explicit length, but it's really not a pain point for me. I'm only stating that zero-terminated is an acceptable default for string literals, and I want to stress this with another example: Last time you were looking at a binary using your editor or pager, how much better has your experience been thanks to NUL terminators? This argument can also extend to runtime debugging somewhat.

Re: The case against a C alternative

#356

Post by jstimpfle »

xigoi wrote: post #349
jstimpfle wrote: post #329

Earlier quoted context omitted.

No. You can't create a zero-terminated substring other than a proper suffix or a buffer copy. But that's not really a surprise right? Well then, don't use zero-terminated strings for proper string processing. You don't have to use zero-termination, even when some programmers in the 70s and 80s were convinced enough of it that abominations like strtok() landed in the standard.

>You don't have to use zero-termination You can choose between zero-termination and having to convert strings back and forth when using idiomatic libraries.

Idiomatic is the wrong word here, because it's certainly not idiomatic to do extra allocations when unneeded. Most APIs let you give the length explicitly if it makes any sense. A not very well-known fact is that even printf format strings let you do printf("%.*s\n", 3, "Hello") which only prints "Hel\n". This is in POSIX C, just not sure when it was standardized.

Re: The case against a C alternative

#357

Post by [deleted] »

boffinAudio wrote: post #205
jhatemyjob wrote: post #9

Ive been thinking about this topic for years and OP was finally able to put it in writing. I dont think anyone would claim english is the best, but it just so happens that the most powerful empire on earth (until recently?) uses it as its primary language. Its good enough at what it does, and has a lot of history backing it up With this knowledge I choose to align myself with languages and platforms that respect C an…

I concur with you - everything I want to do in Rust or Golang, I can do with C+Lua just as easily and with far less tooling hassle. I'm yet to find a good reason to switch from just using C+Lua for everything - but the Rust guys sure are trying. Maybe Rust+Lua makes the most sense, though ..

[deleted]

Re: The case against a C alternative

#358

Post by Nursie »

weatherlite wrote: post #332
Nursie wrote: post #194

Earlier quoted context omitted.

> it's just that C developers avoid them. I'm not sure it's fair to say C developers avoid hash tables - I've worked on several projects with hash-table implementations in them. The 'problem' if there is one, is that such things are rarely picked up from any sort of standard library, and are instead implemented in each project. I'm also not really sure what the problem is with 'resorting' to void*, it's part of the l…

C noob here. Why isn't a hash table implementation merged into the c standard library? Is it because the stdlib has to be as thin as possible for some performance reason or something?

I did C for about 15 years....

Yeah C doesn't really go in for that sort of thing. The standard library tends to be much more about some minimal support for strings and interfaces to OS features like files, signals, memory allocation etc. It doesn't really provide much in the way of building blocks to be reused by application developers.

The recommendation out there on the net seems to be to look at Glib, which is used by gtk, for that sort of thing.

Another good alternative might be the NSPR - https://firefox-source-docs.mozilla.org/nspr/reference/index...

I used this way back in 2001-3 for a multi-platform project because it provides some good platform abstractions, and it looks like it has a hash-table implementation in amongst its other features.

Re: The case against a C alternative

#359

Post by WalterBright »

jstimpfle wrote: post #355
WalterBright wrote: post #348

Earlier quoted context omitted.

The inconvenience and inefficiency is apparent when building functions to do things like break up a path & filename & extension into components and reassemble them. You wind up, for each function, dealing with 0 termination or length, separately allocated or not, tracking who owns the memory, etc. There's just no satisfying set of choices. Maybe you've found an elegant solution that never does a defensive copy, never…

I agree filepath related tasks are ugly. But there are a number of reasons for that that aren't related to zero termination. First, there is syntax & semantics of filepaths. Strings (whatever kind, just thinking about their monoidic structure) are a convenient user interface for specifying filepath constants, but they're annoying to construct from, and disassemble into, filepath components programmatically (relative…

> memory allocation, and this is arguably orthogonal to the string representations

A substringz cannot be produced from a stringz without doing an allocation.

> you're free to make substrings using pointer + length or whatever, and this is in many cases the best solution

Right, I can. And it's an ongoing nuisance in C to do so, because it doesn't have proper abstractions to build new types with. Even worse, if I switch my stringz to length delimited, and then pass it to fopen() which wants a stringz, I have to convert my length delimited string to stringz even though it is already a stringz. Because my length delimited API has no mechanism to say it also is 0 terminated.

You wind up with two string representations in your code, and then what? Have each string function come in a pair?

Believe me, I've done this stuff, I've thought about it a lot, and there is no happy solution. It annoys me enough that C is just not a tool I want to reach for anymore. I'm just tired of ugly, buggy C string code.

The good news is there is a fix, and I've proposed it, but it gets zero traction:

https://www.digitalmars.com/articles/C-biggest-mistake.html

Re: The case against a C alternative

#360

Post by WalterBright »

jstimpfle wrote: post #355
WalterBright wrote: post #348

Earlier quoted context omitted.

The inconvenience and inefficiency is apparent when building functions to do things like break up a path & filename & extension into components and reassemble them. You wind up, for each function, dealing with 0 termination or length, separately allocated or not, tracking who owns the memory, etc. There's just no satisfying set of choices. Maybe you've found an elegant solution that never does a defensive copy, never…

I agree filepath related tasks are ugly. But there are a number of reasons for that that aren't related to zero termination. First, there is syntax & semantics of filepaths. Strings (whatever kind, just thinking about their monoidic structure) are a convenient user interface for specifying filepath constants, but they're annoying to construct from, and disassemble into, filepath components programmatically (relative…

> Last time you were looking at a binary using your editor or pager, how much better has your experience been thanks to NUL terminators?

Not perceptibly better. And yeah, I do look at binary dumps now and then, after all, I wrote the code that generates ELF, OMF, MachO, and MSCOFF object file formats, and librarians for them :-)

Post reply on HN