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

C-for-all: Extending C with modern safety and productivity features

cforall.uwaterloo.ca

Post reply on HN
Print view View original

91–100 of 143 posts

Re: C-for-all: Extending C with modern safety and productivity features

#91

Post by LessDmesg »

jbverschoor wrote: post #22
gambiting wrote: post #15

Earlier quoted context omitted.

I don't know, I work in the games industry and we're currently building a small project that's probably 95% C(the only C++ we have is for one library that has to have a C++ wrapper). It's just.....we don't need the C++ features, the compilation times are instant(last project I worked on was a large AAA game in C++ and compiling it from scratch was about 40-50 minutes on a single workstation), and pretty much all libs…

Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.

"Bad use of header files" is the fault of C++, not the developers. Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development.

Re: C-for-all: Extending C with modern safety and productivity features

#92

Post by madmax96 »

wwright wrote: post #83
madmax96 wrote: post #75

Earlier quoted context omitted.

How is strict aliasing magic? How could you possibly define the meaning of accessing an object through an incompatible type since the type of an object determines how the compiler interprets its value? The bits stored in the object do not even necessarily correspond to a value for every type, after all. And that's not even considering the fact that there is a great deal of freedom wrt how implementations can represen…

Not only can you cast away anything, but: - casting away types unsafely is required for many common patterns in C, including any form of runtime polymorphism - basically anything involving numerics has a good chance of happily casting for you without asking you or telling you

>- casting away types unsafely is required for many common patterns in C, including any form of runtime polymorphism

Which patterns? I'm thinking of stuff like the Berkeley Sockets API, which you can absolutely implement safely.

re numerics: fortunately, that's 100% amenable to static analysis (see -Wconversion, -Wsign-conversion in gcc/clang and coverity's warnings about potentially unsafe casts - e.g. promoting an int to a long is always safe, but an int to a float not necessarily) and follows very straightforward rules.

Re: C-for-all: Extending C with modern safety and productivity features

#93

Post by atilaneves »

madmax96 wrote: post #75
ernst_klim wrote: post #59

Earlier quoted context omitted.

> C - there's no magic Strict aliasing and weak typing say hello. > wysiwyg of high level -> asm Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.

How is strict aliasing magic? How could you possibly define the meaning of accessing an object through an incompatible type since the type of an object determines how the compiler interprets its value? The bits stored in the object do not even necessarily correspond to a value for every type, after all. And that's not even considering the fact that there is a great deal of freedom wrt how implementations can represen…

> Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks?

Exactly because nobody (except backend writers) can predict what C compiler backends emit, especially when abusing undefined behaviour.

Re: C-for-all: Extending C with modern safety and productivity features

#94

Post by pjmlp »

lerno wrote: post #24

It’s interesting how “evolutionary approach” is used. Compare with C2: http://www.c2lang.org/ I think that in the case of C2 it’s still a language that will rely on the same paradigms as C, whereas C-for-all is more of a “kitchen sink” style of language that moves very far from C in how the natural code solutions are. Just the small change adding destructors and constructors is a feature with huge impact on how data…

Also think that C2 makes more sense.

Re: C-for-all: Extending C with modern safety and productivity features

#95

Post by AlexeyBrin »

LessDmesg wrote: post #91
jbverschoor wrote: post #22

Earlier quoted context omitted.

Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.

"Bad use of header files" is the fault of C++, not the developers. Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development.

> Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development.

C++ does not have a BDFL like other languages, C++ evolution is governed by a committee. In other words, Stroustrup himself needs to submit any changes he wants to the committee and there is a vote ...

C++20 modules should partially solve the header processing problem, but it will take years until it will become widespread in big companies.

Re: C-for-all: Extending C with modern safety and productivity features

#96

Post by pjmlp »

ftvy wrote: post #71
saagarjha wrote: post #64

Earlier quoted context omitted.

That doesn't fix the issues mentioned. (Whether it's an "alternative" stdlib for C is debatable; nobody ever said that glibc is "the" stdlib for C…)

It is the de facto standard on Linux.

That doesn't make it the official implementation of ISO C, just one among many.

Re: C-for-all: Extending C with modern safety and productivity features

#97

Post by flohofwoe »

saagarjha wrote: post #66
GlitchMr wrote: post #60

Wow, this is quite a trainwreck. I think it's possible to improve C while keeping compatibility with C programs, but that's not how you should do it. I think an improved C would be quite useful, but you really should be careful with what you include it, and keep the language simple. A lot of functionality feels like added because it could be added (WTF are nested routines). This way lies worse C++. In particular, I w…

Who owns the return value of new_point?

It lives on the stack and is handed around by value, the question of ownership really only gets interesting once heap memory and pointers/references come into play.

I guess ancient C compilers would do a memory copy on return, but there are various optimizations in "newer" compilers which remove redundant copies, and structs up to 16 bytes or so are passed in registers anyway (via the 64-bit Intel and ARM ABI conventions).

Re: C-for-all: Extending C with modern safety and productivity features

#98

Post by madmax96 »

atilaneves wrote: post #93
madmax96 wrote: post #75

Earlier quoted context omitted.

How is strict aliasing magic? How could you possibly define the meaning of accessing an object through an incompatible type since the type of an object determines how the compiler interprets its value? The bits stored in the object do not even necessarily correspond to a value for every type, after all. And that's not even considering the fact that there is a great deal of freedom wrt how implementations can represen…

> Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks? Exactly because nobody (except backend writers) can predict what C compiler backends emit, especially when abusing undefined behaviour.

OCaml: https://godbolt.org/z/8bWDXy C: https://godbolt.org/z/WAjsvk

I've never actually looked at the output of an OCaml compiler, I have to say I'm surprised by how clean it is. But I wouldn't call it more predictable than that C's output.

Re: C-for-all: Extending C with modern safety and productivity features

#99

Post by pjmlp »

kwhitefoot wrote: post #57
yitchelle wrote: post #45

Earlier quoted context omitted.

MISRA-C is just a set of rules. It does not stop humans making stupid mistakes or ignoring rules, and causing safety to be violated. It not as hard as rust where the binary is not built if a rule is violated.

Is it possible to check for compliance with MISRA-C rules programmatically? If it is then it can be made part of the build process and the effect will be the same: the binary will not get built if the rules are violated.

It is, but many developers have allergy to static analysers.

Re: C-for-all: Extending C with modern safety and productivity features

#100

Post by cain »

I was excited to read about this. An upgraded C would be nice. Unfortunately, after the homepage, this seems disastrously opposed to anything resembling a "better" C.

The features page feels extremely painful to read. It took me at least two minutes to even begin to make sense of the first section: "Declarations", then an explanation of Tuple, immediately followed by:

  int i;
  double x, y;
  int f( int, int, int );
  f( 2, x, 3 + i );      // technically ambiguous: argument list or comma expression?
Tuple isn't mentioned again until seven or so lines after its explanation. After reading further, I realise they aren't linked in any way, but this was confusing at first. I thought I was missing something major about the syntax.

  [ y, i ] = [ t.2, t.0 ];    // reorder and drop tuple elements
I don't know what this even means. If this:

  [ i, x, y ] = *pt;      // expand tuple elements to variables
pulls out tuple elements into variables, and this:

  x = t.1;        // extract 2nd tuple element (zero origin)
accesses tuple elements: then what is "reorder and drop" and why does the combination of the above two behaviour result in an ostensibly different third behaviour?

It gets worse the further down the page I try to understand. Very claustrophobic and presented as a mish-mash of syntax examples. I can't see how this is any better than C's syntax, honestly. What C would benefit from is a better baked-in stdlib, OR an easily available, downloadable, lib of helper functionality that doesn't require any modifications to existing code (eg. when I want a hashtable in an already-established project, I don't want to modify my existing structs!)

Post reply on HN