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

Tell HN: C Experts Panel – Ask us anything about C

news.ycombinator.com

Post reply on HN
Print view View original

661–670 of 978 posts

Re: Tell HN: C Experts Panel – Ask us anything about C

#661

Post by wahern »

AaronBallman wrote: post #509
natch wrote: post #175

Can you please repeat this AMA at a later date and at a time of day when people on the west coast of the USA are awake? Alternatively, please keep it going for a few hours if you would be able to be so generous with your time! Thank you for doing this! Do you also answer questions about the standard libraries? This is not so much a C question as a library question: I'm wondering if Apple's Grand Central Dispatch ever…

> Alternatively, please keep it going for a few hours if you would be able to be so generous with your time! We're remaining active while there are still people asking questions, so the west coast folks should hopefully have the chance to ask what they'd like. > Do you also answer questions about the standard libraries? Sure! > I'm wondering if Apple's Grand Central Dispatch ever made it into a more integrated role i…

GCD relies on Blocks (closures) for ergonomics, and Blocks have been proposed to WG14, for example N1451: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1451.pdf

Re: Tell HN: C Experts Panel – Ask us anything about C

#662

Post by kazinator »

eska wrote: post #653

There's a compiler attribute in GCC to promise that a function is pure, i.e. free from side effects and only uses its inputs. This is useful for parallel computations, optimizations and readability, e.g. sum += f(2); sum += f(2); can be optimized to x = f(2); sum += x; sum += x; Would the current motto of the consortium forbid adding a feature such as marking a function as pure, that would not just promise, but also…

No enforcing! This is useful even when it's, strictly speaking, a lie.

Suppose I want to add some debug tracing into f():

   f.c: 42: f entered
   f:c: 43: returning 2
that's a side effect, right? But now the pure attribute tells a lie. Never mind though; I don't care that some calls to f are "wrongly" optimized away; I want the tracing for the ones that aren't.

In C++ there are similar situations involving temporary objects: there is a freedom to elide temporary objects even if the constructors and destructors have effects.

Even a perfectly pure function can have a side effect, namely this one: triggering a debugger to stop on a breakpoint set in that function!

If a call to f(2) is elided from some code, then that code will no longer hit the breakpoint set on f.

Side effect is all P.O.V. based: to declare something to be effect-free in a conventional digital machine, you have to first categorize certain effects as not counting.

Re: Tell HN: C Experts Panel – Ask us anything about C

#663

Post by rseacord »

begriffs wrote: post #648
AaronBallman wrote: post #638

Earlier quoted context omitted.

If that macro is defined, then wchar_t is able to represent every character from the Unicode required character set with the same value as the short code for that character. Which version of Unicode is supported is determined by the date value the macro expands to. Clang defines that macro for some targets (like the Cloud ABI target), but not others. I'm not certain why the macro is not defined for macOS though (it m…

Would the following be a correct way to determine whether there's a problem? * First call setlocale(LC_CTYPE, "en_US.UTF-8") * Next feed the UTF-8 string representation of every Unicode codepoint one at a time to mbstowcs() and ensure that the output for each is a wchar_t string of length one * If all input codepoints numerically match the output wchar_t UTF-32 code units, then the implementation is officially good,…

Should work provided your wchar_t type is at least 21-bits wide.

Re: Tell HN: C Experts Panel – Ask us anything about C

#664

Post by _kst_ »

eqvinox wrote: post #90

What's the best way to deal with "transitive const-ness", i.e. utility functions that operate on pointers and where the return type should technically get const from the argument? (strchr is the most obvious, but in general most search/lookup type functions are like this...) Add to clarify: the current prototype for strchr is char *strchr(const char *s, int c); Which just drops the "const", so you might end up writin…

strchr() is one of several C library functions that have this issue.

C++ solved this by overloading strchr():

    const char *strchr(const char *s, int c);
    char *strchr(*char *s, int c);
C of course doesn't have overloading.

One solution could have been to define two functions with different names, perhaps "strchr" and "strcchr". The time to do that would have been 1989, when the original ANSI C standard was published.

I suppose a future C standard could leave strchr() as it is (necessary to avoid breaking existing code) and add two new functions.

Re: Tell HN: C Experts Panel – Ask us anything about C

#665

Post by DougGwyn »

0xDEEPFAC wrote: post #657
DougGwyn wrote: post #631

Earlier quoted context omitted.

If you're using parentheses, as has been recommended for decades, there is no problem. Otherwise, it is likely that such a change would adversely impact previously working code. There just isn't a pressing need to change it.

Besides the fact that its unintuitive and could lead to low-level or hard-to-find bugs? It seems to me that C would benefit greatly to iron over its many inconsistencies and exactly the kind of thing people expect in new revisions of the language. Also, I dont see how it would impact previous working code when compilers already do things like allow selections between versions of languages a la C99, C2x, etc. Users co…

I don't think most users of C want things changing underfoot. Keeping track of all the version combinations is infeasible, especially when you consider that an app and its library packages are likely to have been developed and tested for a variety of environments. To the extent that existing correct code has to be scanned and revised when a new compiler release comes out, one of the primary goals of standardization has failed.

Re: Tell HN: C Experts Panel – Ask us anything about C

#666

Post by quelsolaar »

clarry wrote: post #644
quelsolaar wrote: post #627

Earlier quoted context omitted.

They need to do better then remove NULL checks silently. You can read all about Linus rants on this. Every time the compiler breaks things they blame the C standard for letting them do what ever. Thats whats wrong with C today. The C standard hasn't put its foot down.

I want my compiler to remove redundant checks (without any noise), and that is why I pass it an optimization flag. If you don't want such optimizations, then maybe you should not ask the compiler to make them.

This attitude is terrible! Its an attitude that says that unless you know exactly every pit fall in the language by heart you have no place writing code. I guess you dont use a debugger either because you never write bugs right? And you think that every software that helps the user is for noobs right?

There is an endless list of bugs that have been produced by very competent C programmers, because the compiler has silently removed things for some very shaky reasons.

Re: Tell HN: C Experts Panel – Ask us anything about C

#668

Post by AaronBallman »

begriffs wrote: post #648
AaronBallman wrote: post #638

Earlier quoted context omitted.

If that macro is defined, then wchar_t is able to represent every character from the Unicode required character set with the same value as the short code for that character. Which version of Unicode is supported is determined by the date value the macro expands to. Clang defines that macro for some targets (like the Cloud ABI target), but not others. I'm not certain why the macro is not defined for macOS though (it m…

Would the following be a correct way to determine whether there's a problem? * First call setlocale(LC_CTYPE, "en_US.UTF-8") * Next feed the UTF-8 string representation of every Unicode codepoint one at a time to mbstowcs() and ensure that the output for each is a wchar_t string of length one * If all input codepoints numerically match the output wchar_t UTF-32 code units, then the implementation is officially good,…

I think this is correct, assuming that locale is supported by the implementation and wchar_t is wide enough, but I am by no means an expert on character encodings.

Re: Tell HN: C Experts Panel – Ask us anything about C

#669

Post by quelsolaar »

WalterBright wrote: post #634
quelsolaar wrote: post #633

Earlier quoted context omitted.

they are accessed using pointer arithmetic, if you wanted them to contain length data, you would need a different access pattern. I think one of the great features of C is that it doesn't do anything under the hood, its all explicit. If you want to bounds check, then do it.

> they are accessed using pointer arithmetic Not always. Consider: int a[3]; a[1] = 2; This is not using pointer arithmetic. Dump the generated code if you don't believe me :-)

Its still pointer arithmetic, its just done compile time rather then at execution. Still, you deserve style points :-)

Re: Tell HN: C Experts Panel – Ask us anything about C

#670

Post by jedbrown »

rseacord wrote: post #437
knz42 wrote: post #28

What is the story behind the removal of VLAs from C99 in later revisions?

So I spend a possibly unreasonable amount of time and page space discussing VLAs in the Effective C book. I understand there are some problems with them, but for what it is worth, I really like the feature, particularly when used in function prototype scope.

I usually don't let them leak into public interfaces, and don't allocate VLAs, but really like VLA pointers for multi-dimensional array processing such as []:

  double (*a)[N][P] = (double (*)[N][P])a_flat;
  for (i=0; i
The alternative would be

        a_flat[(i*M+j)*P+k] = f(i, j, k);
which is a lot more error-prone. I understand that some implementation (MSVC) declined to implement VLAs, but I really wish that at least VLA-pointers could have remained a mandatory part of C11 and later standards.

[] Has there been any discussion of adding GCC's "typeof" to the standard?

Post reply on HN