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

Stop Memsetting Structures

anmolsarma.in

Post reply on HN
Print view View original

211–220 of 277 posts

Re: Stop Memsetting Structures

#211

Post by atq2119 »

hedora wrote: post #110
_bxg1 wrote: post #100

Earlier quoted context omitted.

I've only written a little of each, but my impression is that C has mostly remained a focused, effective language for careful systems programming. While C++ has become a sprawling cthulhu of leaky abstractions and other nasty foot-guns and people only use it because "it's as fast as C but sorta feels like a higher-level language". And that therefore Rust is a strict improvement over C++, but not necessarily C.

I thought this way too until I worked with competent C++ devs on a modern code base. (By my definition of “competent,” no one ever encountered by the Rust brigade bloggers is competent, fwiw). At some point, I realized that C++ is a language for implementing new languages in a way that is backward compatible with existing programs. Templates are Turing complete (lazily evaluated, purely functional, and side-effect fr…

Templates are not quite side-effect free, although it takes some effort to run into that. See http://b.atch.se/posts/constexpr-counter/ for a delicious exploit of that fact.

Re: Stop Memsetting Structures

#212

Post by bayareanative »

We use Crystal for networking code, and it has nice C binding semantics. Haven't had to drop down to pure C much because Crystal just works, and doesn't have the learning curve or un/boxing hoops of rust. It's basically Ruby-like but with rudimentary type-inference, like what Ruby 3 wants to be but Crystal already exists... and orders-of-magnitude more performant.

Re: Stop Memsetting Structures

#213

Post by atq2119 »

childintime wrote: post #109

Last I checked C99 initializers require constants, so they don't generalize, whereas the pattern shown does. I'd prefer if the initializers pattern did allow variables on the right-hand side for this reason.

Not true, designated initializers expect the same kind of expressions are variable initialization (which is limited at global scope, but arbitrary when initializing local variables).

Re: Stop Memsetting Structures

#216

Post by maxnoe »

snops wrote: post #27

My favourite trick with designated initialisers is using them with array indices and enums, e.g. enum color {RED, GREEN, BLUE}; char *color_name[] = { [RED] = "Red", [GREEN] = "Green", [BLUE] = "Blue" }; printf("%s",color_name[RED]); This means you don't have to ensure ordering is the same between the enum and the array, which can be a pain for more complex tables. It's a shame C++ doesn't support this, more details:…

Why would you ever want to do something like this in c++?

What you are implementing is a map. Just use std::map.

Re: Stop Memsetting Structures

#217

Post by hazeii »

swiley wrote: post #199

Ugh, what do you do when the structure definition is updated and you now have uninitialized values? If there's no explicit initializer I think memset,calloc or ={0} is just fine thanks.

Unclear to me why you've been downvoted; I've seen many cases where a structure has had elements added which would be end up uninitialised. A memset(&struct,0,sizeof(struct)) seems pretty reasonable to me.

Re: Stop Memsetting Structures

#218

Post by hazeii »

CJefferson wrote: post #16

There were a few old free implementations which misbehaved when given null. Maybe they are all gone now, but there was a reason to do it.

Indeed, I recall getting messages along the lines of "error: freeing a null pointer" or something like that. On the other hand, what are the chances of some freshly-written C being built with an old compiler? (possibly moderately high in the embedded world?).

Re: Stop Memsetting Structures

#219

Post by halayli »

maxnoe wrote: post #216
snops wrote: post #27

My favourite trick with designated initialisers is using them with array indices and enums, e.g. enum color {RED, GREEN, BLUE}; char *color_name[] = { [RED] = "Red", [GREEN] = "Green", [BLUE] = "Blue" }; printf("%s",color_name[RED]); This means you don't have to ensure ordering is the same between the enum and the array, which can be a pain for more complex tables. It's a shame C++ doesn't support this, more details:…

Why would you ever want to do something like this in c++? What you are implementing is a map. Just use std::map.

Lookup time is widely different if you use std::map. But you can use std::vector in a similar fashion.
Post reply on HN