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

131–140 of 189 posts

Re: Lesser known tricks, quirks and features of C

#131

Post by skissane »

dezgeg wrote: post #123
tom_ wrote: post #122

Earlier quoted context omitted.

I've never seen locale-dependent format strings work well. The translators will change the formatting codes, and you can't change the order of the formatted arguments. You are much better off with some other mechanism for this. (I have no recommendations. When I've seen this stuff done properly, on the occasions I've managed not to avoid doing it, it's always been using some in-house system.)

> you can't change the order of the formatted arguments. You can with the $ syntax. Never seen it used though. Maybe it isn't very portable.

It is specified by POSIX, but not by ISO C (or C++). So most Unix(-like) systems support it. But the printf in Microsoft's C runtime doesn't. However, Microsoft does define an alternative printf function which does, printf_p, so `#define printf printf_p` will get past that.

I think the real reason you rarely see it, is it is only used with internationalisation–the idea being if you translate the format string, the translator may need to reorder the parameters for a natural translation, given differences in word order in different languages. However, a lot of software isn't internationalised, or if it is, the internationalisation is in end-user facing text, which nowadays usually ends up in a GUI or web UI, so printf has less to do with it. And the kind of lower-level tools/components for which people still often use C are less likely to be internationalised, since they are targeted at a technical audience who are expected to be able to read some level of English.

Re: Lesser known tricks, quirks and features of C

#132

Post by jokoon »

I'm currently trying to make a programming language that translates to C. I've started with a pseudo BNF parser.

I started reading the C BNF and I have to admit that I was not prepared at all. It's not as easy as it sounds.

I cannot imagine how difficult it must be to maintain a modern C++ compiler.

Re: Lesser known tricks, quirks and features of C

#133

Post by [deleted] »

LegionMammal978 wrote: post #48

> volatile type qualifier > This qualifier tells the compiler that a variable may be accessed by other means than the current code (e.g. by code run in another thread or it's MMIO device), thus to not optimize away reads and writes to this resource. It's dangerous to mention cross-thread data access as a use case for volatile. In standard C, modifying any non-atomic value on one thread, while accessing it on another…

[deleted]

Re: Lesser known tricks, quirks and features of C

#134

Post by foldr »

charcircuit wrote: post #121
webstrand wrote: post #105

Earlier quoted context omitted.

Nothing real is "Turing complete" if it requires infinite memory. That's a property only abstract machines can have. In common parlance, something is Turing complete if it can compute arbitrary programs that can be computed with M bits of memory, where M is arbitrary but finite.

So in common parlance finite state automata are Turing complete? That definition doesn't make any sense.

I'd say they're Turing complete (in common parlance) if they can reasonably viewed as a Turing-complete system that's been hobbled with an arbitrary memory limitation. FSAs generally can't be viewed this way as you can't just "add more memory" to an FSA. By way of contrast, consider a pushdown automaton with two stacks. While any physically real implementation of such a device will necessarily have some kind of limit on the size of the stacks, you can easily see how the device would behave if this limit were somehow removed.

It's definitely a bit fuzzy. I'm sure lots of philosophy papers have been written on when exactly it is or isn't appropriate to consider a finite computational system as a finite approximation to a Turing-complete system. In realistic everyday cases, however, it's usually clear enough what should and shouldn't count as such.

Re: Lesser known tricks, quirks and features of C

#135

Post by neverrroot »

suprjami wrote: post #45
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.

Professional C developers definitely should be using at least designated init and FAM, standard features both added in C99 and currently 24 years old.

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.

Re: Lesser known tricks, quirks and features of C

#136

Post by mjburgess »

charcircuit wrote: post #121
webstrand wrote: post #105

Earlier quoted context omitted.

Nothing real is "Turing complete" if it requires infinite memory. That's a property only abstract machines can have. In common parlance, something is Turing complete if it can compute arbitrary programs that can be computed with M bits of memory, where M is arbitrary but finite.

So in common parlance finite state automata are Turing complete? That definition doesn't make any sense.

https://en.wikipedia.org/wiki/Turing_completeness#Non-mathem...

Re: Lesser known tricks, quirks and features of C

#137

Post by Sharlin »

charcircuit wrote: post #121
webstrand wrote: post #105

Earlier quoted context omitted.

Nothing real is "Turing complete" if it requires infinite memory. That's a property only abstract machines can have. In common parlance, something is Turing complete if it can compute arbitrary programs that can be computed with M bits of memory, where M is arbitrary but finite.

So in common parlance finite state automata are Turing complete? That definition doesn't make any sense.

Strictly speaking there are essentially no programming languages that are even theoretically Turing-complete because they can only address a bounded amount of memory. For example, in C `sizeof(void*)` must be a well-defined, finite integer. But that definition is not useful in practical use.

Re: Lesser known tricks, quirks and features of C

#138

Post by NoZebra120vClip »

kstenerud wrote: post #106
NoZebra120vClip wrote: post #101

Earlier quoted context omitted.

The unary complement operator should get you there: unsigned int x = 0; const unsigned int max = ~x; while (x Or, #include const unsigned int max = UINT_MAX;

Or if you only wanted to iterate halfway: unsigned int x = 0; while (x Or going down: unsigned int x = ~0; while (x > ~x) { calc(x--); }

By "halfway", did you mean "off by one"?

Re: Lesser known tricks, quirks and features of C

#139

Post by Joker_vD »

charcircuit wrote: post #121
webstrand wrote: post #105

Earlier quoted context omitted.

Nothing real is "Turing complete" if it requires infinite memory. That's a property only abstract machines can have. In common parlance, something is Turing complete if it can compute arbitrary programs that can be computed with M bits of memory, where M is arbitrary but finite.

So in common parlance finite state automata are Turing complete? That definition doesn't make any sense.

Well, I'm pretty sure all existing digital computers are finite state automata, so they are not, strictly speaking, Turing complete. But that doesn't make any sense.

Re: Lesser known tricks, quirks and features of C

#140

Post by kstenerud »

NoZebra120vClip wrote: post #138
kstenerud wrote: post #106

Earlier quoted context omitted.

Or if you only wanted to iterate halfway: unsigned int x = 0; while (x Or going down: unsigned int x = ~0; while (x > ~x) { calc(x--); }

By "halfway", did you mean "off by one"?

no
Post reply on HN