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

81–90 of 143 posts

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

#81

Post by F-0X »

saagarjha wrote: post #76
GlitchMr wrote: post #68

Earlier quoted context omitted.

The function that calls `new_point`, the value is moved. Similarly, consider the following case. struct Point a = new_point(); struct Point a2 = a; Assuming `struct Point` has a destructor, this would move `a` into `a2`, and prevent accesses to `a` after `a2` assignment, as `a` is no longer considered to be alive at this point. C++ has a wrong default of cloning instead of moving, but a new language could fix that.

So you’re looking for Rust with C’s syntax?

Would be a big improvement on Rust.

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

#83

Post by wwright »

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…

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

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

#84

Post by microcolonel »

coldtea wrote: post #72
swebs wrote: post #51

Earlier quoted context omitted.

You can't say "one is bad, therefore the other is good." They can both be bad.

In which case you shouldn't paint one as the exceptional evil for doing the same thing, as is usually the case.

The CCP is exceptionally evil, they are conducting themselves like Nazi Germany.

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

#85

Post by quotemstr »

C with modern safety and productivity features is called "C++" and has been around for decades. I'm amazed at how much effort people will expend just to avoid the C++ boogeyman. No, writing C++ does not automatically make your code bloated. No, using C does not guarantee lean design.

Plain C ought to be considered a legacy language and not used for new code. There is zero reason to prefer it over whatever style of C++ you'd like. If you want procedural struct-based C++, you can have that, but gosh, don't write C.

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

#86

Post by microcolonel »

sremani wrote: post #2

What does powered by Huawei mean? Are they what Mozilla is to Rust?

It's a more general thing. Like elsewhere in the former British empire, the CCP is getting their fingers in the pie, and siphoning research product back to the weapons and surveillance industry in China.

We aren't in as dire a situation here in Canada as Australia [0] seems to be, but there's a reason it was so difficult to serve that Huawei extradition.

[0]: https://www.news.com.au/national/victoria/news/its-a-police-...

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

#87

Post by wwright »

GlitchMr wrote: post #68
saagarjha wrote: post #66

Earlier quoted context omitted.

Who owns the return value of new_point?

The function that calls `new_point`, the value is moved. Similarly, consider the following case. struct Point a = new_point(); struct Point a2 = a; Assuming `struct Point` has a destructor, this would move `a` into `a2`, and prevent accesses to `a` after `a2` assignment, as `a` is no longer considered to be alive at this point. C++ has a wrong default of cloning instead of moving, but a new language could fix that.

That default changes in C++11: https://en.cppreference.com/w/cpp/language/copy_elision

The logic around it is still pretty complicated, since we’re talking about C++.

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

#88

Post by gmueckl »

madmax96 wrote: post #77
GlitchMr wrote: post #68

Earlier quoted context omitted.

The function that calls `new_point`, the value is moved. Similarly, consider the following case. struct Point a = new_point(); struct Point a2 = a; Assuming `struct Point` has a destructor, this would move `a` into `a2`, and prevent accesses to `a` after `a2` assignment, as `a` is no longer considered to be alive at this point. C++ has a wrong default of cloning instead of moving, but a new language could fix that.

Why is cloning rather than moving the wrong default?

It isn't. Cloning is what actually happens under the hood, if a and a2 are in different memory locations. Making a inaccessible after the assignment is merely a convention. With a struct that only has data members, there are no further consequences.

If the struct contains a pointer, you need a kind of additional contract that says how the memory that is pointed to is going to be managed, particularly when it is going to be freed and by whom. And that is where move semantics establish a constricting convention that is intended to make that unambiguous.

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

#89

Post by wwright »

F-0X wrote: post #81
saagarjha wrote: post #76

Earlier quoted context omitted.

So you’re looking for Rust with C’s syntax?

Would be a big improvement on Rust.

What part of Rust’s syntax do you think is a detriment vs C? A lot of it is very similar to C, but with ambiguity removed.

- Variable types are changed to avoid ambiguity in lexing.

- Loops and conditionals require {}, which means the parentheses can be dropped on the condition and there’s no ambiguity about nested if’s and else’s.

What would you like improved?

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

#90

Post by flohofwoe »

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…

You realize that this is (almost) valid C99?

In C99 it looks like this:

    struct Point {
        int x;
        int y;
    };

    struct Point new_point(int x, int y) {
        return (struct Point) { .x = x, .y = y };
    }
Post reply on HN