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

Lesser known tricks, quirks and features of C

blog.joren.ga

Post reply on HN
Print view View original

151–160 of 189 posts

Re: Lesser known tricks, quirks and features of C

#151

Post by flohofwoe »

neverrroot wrote: post #42

It’s cool to have these, it’s fun to use them for fun. But please don’t use them in production code. Also don’t assume most of them will he known by other developers.

Some of those are regular modern C features and definitely should be used, most importantly compound literals and designated init, since they make the code both safer and more readable (and I blame the Visual Studio compiler team for dragging their asses for 16 years to support at least a subset of C99 for those features to be 'lesser known').

Re: Lesser known tricks, quirks and features of C

#152

Post by flohofwoe »

HybridCurve wrote: post #76
clnq wrote: post #49

Do we have something like this for C++ (parts not shared with C)?

Can't say for all, but I am reasonably certain C++ does not support designated initializers/sparse array definitions. Some of these features where added in more recent revisions to the C specification from which C++ has diverged from. I would expect most of the differences would become more pronounced starting with C99.

In theory, C++20 has designated init, but it has so many restrictions compared to C99 that it is pretty much useless for real world code.

Re: Lesser known tricks, quirks and features of C

#153

Post by mnaydin »

I am not able to understand how

  int (*ap3)[900000] = malloc(sizeof *ap3);
is nicer than

  int *a = malloc(900000 * sizeof *a);
Notice that, in the former case, the array elements must be accessed as (*ap3)[i] whereas in the latter case the usual method a[i] is fine.

Re: Lesser known tricks, quirks and features of C

#154

Post by flohofwoe »

zwieback wrote: post #39

Be interesting to see when these features showed up. I learned C from the K&R book back in the day and it doesn't mention most of these. Designated initializer is something I'll try to remember, seems handy.

Designated init and compound literals were added in C99. I think there are two reasons for those features not being better known:

1) C++ 'forked' their C subset before C99 (ca. "C95"), and while C++20 finally got its own version of designated init, this has so many restrictions compared to C99 that it is basically pointless.

2) MSVC hasn't supported any important C99 features until around 2016

Re: Lesser known tricks, quirks and features of C

#155

Post by augustk »

GnarfGnarf wrote: post #145
augustk wrote: post #144

There are three macros which I find indispensable and which I use in all my C projects, namely LEN , NEW and NEW_ARRAY . I keep them in a file named Util.h: #ifndef UTIL_H #define UTIL_H #include #include #include #include #define LEN(arr) (sizeof (arr) / sizeof (arr)[0]) #define NEW_ARRAY(ptr, n) \ (ptr) = malloc((n) * sizeof (ptr)[0]); \ if ((ptr) == NULL) { \ fprintf(stderr, "Memory allocation failed: %s\n", strer…

I found a lot of bugs went away when I switched to STL (Standard Template Library) arrays and ditched managing my own memory. That's C++, I guess it's not available in straight C?

It's even easier if you use a garbage collector, like for instance libgc. Then you just replace

  (ptr) = malloc((n) * sizeof (ptr)[0]);
with

  (ptr) = GC_MALLOC((n) * sizeof (ptr)[0]);
in the macro and don't have to worry about calling free.

Re: Lesser known tricks, quirks and features of C

#156

Post by neverrroot »

suprjami wrote: post #142
neverrroot wrote: post #135

Earlier quoted context omitted.

Well, it’s either a lesser known trick or it’s something people should be using. In general using lesser known tricks it’s not a good idea for production code. But I understand there are cases where there is no good alternative, so it’s warranted.

My point is that these aren't "lesser known tricks". They're important language features which solve real problems and which anyone writing production C should be at least aware of, if not actively using for the advantages they provide.

I was taking for granted the storyline, and assumed they are indeed lesser known and tricks. To me it’s never about what I know, it’s about what the others know, my production code is not mine alone, and I also don’t want to be responsible for it forever. So I try to be explicit and use no tricks wherever possible.

Re: Lesser known tricks, quirks and features of C

#157

Post by billpg »

charcircuit wrote: post #102
rerdavies wrote: post #21

Earlier quoted context omitted.

Fun fact about %n: The %n functionality also makes printf accidentally Turing-complete even with a well-formed set of arguments. A game of tic-tac-toe written in the format string is a winner of the 27th IOCCC. - sez wiki. A not so fun fact: Because the %n format is inherently insecure, it's disabled by default. - MSVC reference.

>The %n functionality also makes printf accidentally Turing-complete No it doesn't. Printf has no way to loop so it's not Turing complete. Even if you did what the IOCCC entry did with putting it into a loop it still wouldn't be Turing complete as it would not have an infinite memory.

My laptop with its finite RAM isn't Turing Complete? Wow.

Re: Lesser known tricks, quirks and features of C

#158

Post by gallier2 »

Joker_vD wrote: post #16

Never quite understood why compound literals are lvalues, but fine, whatever, I guess, it's so that you can write "&(struct Foo){};" instead of "struct Foo tmp; &tmp;"... which, on a tangential note, reminds me about Go: the proposals to make things like &5 and &true legal in Go were rejected because "the implied semantics would be unclear" even though &structFoo{} is legal and apparently has obvious semantics.

Compound literals are anonymous variables, i.e. like variables except that there is no label visible in the C program. If you look at the assembly you'll see that they are declared exactly like a variable except with a compiler generated internal label.

Re: Lesser known tricks, quirks and features of C

#159

Post by suprjami »

neverrroot wrote: post #156
suprjami wrote: post #142

Earlier quoted context omitted.

My point is that these aren't "lesser known tricks". They're important language features which solve real problems and which anyone writing production C should be at least aware of, if not actively using for the advantages they provide.

I was taking for granted the storyline, and assumed they are indeed lesser known and tricks. To me it’s never about what I know, it’s about what the others know, my production code is not mine alone, and I also don’t want to be responsible for it forever. So I try to be explicit and use no tricks wherever possible.

I agree with this in principle, but where do you draw the line between language features (good) and obscure tricks (bad)? Is your team really writing only ANSI C89 from the K&R 2nd edition book and ignoring the last ~35 years of language improvements?

Re: Lesser known tricks, quirks and features of C

#160

Post by syockit »

mnaydin wrote: post #153

I am not able to understand how int (*ap3)[900000] = malloc(sizeof *ap3); is nicer than int *a = malloc(900000 * sizeof *a); Notice that, in the former case, the array elements must be accessed as (*ap3)[i] whereas in the latter case the usual method a[i] is fine.

Me neither. In the VLA use cases page he does that with multidimensional array too.

    int (*arr)[n][m] = malloc(sizeof *arr);
which you have to access with

    (*arr)[i][j]
I prefer doing

    int (*arr)[m] = malloc(n*sizeof(*arr));
though this separates m and n to be one on left side while the other on the right side, it allows me to index directly

    arr[i][j]
Post reply on HN