Earlier quoted context omitted.
What's the "sequence point operator"?
,
That's the comma operator. I didn't know you could overload it! That's pretty crazy. However, I have never seen anyone do that. Do you have any real world examples?
C constructs that still don't work in C++
111–120 of 182 posts
Re: C constructs that still don't work in C++
#112I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases. Many of these differences are intentional and defensible from the C++ side. But some are still surprising because they invalidate patterns that were historically common, performant, or idiomatic in C. The interesting part to me isn’t "C vs C++," but where the languages diverged philosophical…
Did you use an LLM to write this comment? (I don't mean this as an accusation, I'm uncertain. I'm just trying to calibrate myself.) Edit: I should've had more conviction in my instincts, this is slop.
It didn't stand out to me on first read but pangram gives it a high confidence rating as being written by AI.
Re: C constructs that still don't work in C++
#113Earlier quoted context omitted.
Did you use an LLM to write this comment? (I don't mean this as an accusation, I'm uncertain. I'm just trying to calibrate myself.) Edit: I should've had more conviction in my instincts, this is slop.
It didn't stand out to me on first read but pangram gives it a high confidence rating as being written by AI.
It's much more obvious when you look at the user's comment history.
Curiously my comment above was on +3 karma last time I looked, but now it's on -2. It seems like the median HN user is getting worse at slop detection (or is otherwise ambivalent towards slop comments).
Re: C constructs that still don't work in C++
#114Earlier quoted context omitted.
The correct choice IMHO is type-erasure. It does not necessarily have overhead, because optimizers can specialize or devirtualize. Of course, this my depend on how you implement your language, but in C this works nicely. The problem with monomorphization is that it leads to exponential expansion, which later passes of the compiler can not unify again (at least this is much harder than not expanding in the first place…
I don't think the numbers bear out that "this works nicely" in C, it seems like you have worse perf numbers for some common cases like sorting ?
Not sure what numbers you are talking about. If you use qsort from the C library the comparison function will not be inlined, but if you provide your own, this is no problem.
Re: C constructs that still don't work in C++
#115I find variable-length arrays (i.e. arrays whose length is defined at run-time and typically live on the stack) to be kind of dangerous, and try to avoid them, even in C.
Why do you think they are dangerous?
Re: C constructs that still don't work in C++
#116Earlier quoted context omitted.
Not sure if you're aware, but defer is proposed for C2Y [1]. It's already available in Clang behind a compiler flag. It is interesting how the languages continue to diverge. [1] https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3734.pdf
Because the communities aren't the same. C++ is 1990's Typescript for C++, while C folks still think is a portable Assembly instead of designed to an abstract machine model. As such C++ community embraces high level abstractions and type systems improvements, whereas C wants to still code as targeting classical hardware.
> C folks still think is a portable Assembly
> C [community] wants to still code
> many still don't know to distinguish
> the culture that... despite easy proof that isn't the case
> devs wrongly assume
> self inflicted complexity
> considered an advantage when argued by C folks
> when the same crowd points
> as the C crowd pretends it to be
You're arguing in this thread not by addressing what people are actually saying but by bringing up some hypothetical version of what "the C Community" thinks, then arguing with that.
Re: C constructs that still don't work in C++
#117Is there some kind of ambiguity inherent in designated initializers such that the field ordering requirement is necessary for C++ or is it rather just a quirk of the compiler authors’ choices?
Re: C constructs that still don't work in C++
#118I find variable-length arrays (i.e. arrays whose length is defined at run-time and typically live on the stack) to be kind of dangerous, and try to avoid them, even in C.
Why do you think they are dangerous?
If the VLA size is not controlled it gives an attacker a primitive for arbitrarily shifting the stack pointer. There isn’t any spec for what is a reasonable limit on a VLA size. https://dotat.at/@/2010-01-22-coroutines-in-less-than-20-lin...
Re: C constructs that still don't work in C++
#119Earlier quoted context omitted.
,
That's the comma operator. I didn't know you could overload it! That's pretty crazy. However, I have never seen anyone do that. Do you have any real world examples?
See e.g. the very-popular Eigen library, in which the type CommaInitializer basically exists for the sole purpose of overloading `operator,`, allowing a cleaner matrix initialization syntax.
https://gitlab.com/libeigen/eigen/blob/master/Eigen/src/Core...
Re: C constructs that still don't work in C++
#120Earlier quoted context omitted.
Out of curiosity, what do you think is wrong with monomorphization-based polymorphism? The other alternatives I'm aware of are 1. type-erasure via v-table based dynamic dispatch (which Rust also has in the form of the `dyn` keyword), which has performance and memory-allocation overhead and 2. macros, which Rust also has and, if used for polymorphism, would essentially be like compile-time monomorphization, but clunki…
The correct choice IMHO is type-erasure. It does not necessarily have overhead, because optimizers can specialize or devirtualize. Of course, this my depend on how you implement your language, but in C this works nicely. The problem with monomorphization is that it leads to exponential expansion, which later passes of the compiler can not unify again (at least this is much harder than not expanding in the first place…
Type-erasure does have an inherent overhead. Sure, optimizations can be made, but they can be fickle and specialization is basically implicit monomorphization.
Using C macros to replicate Rust's monomorphism has several drawbacks: they are inherently unhygienic, even in comparison to Rust's own; you can't set type-bounds; they aren't even a part of C proper, etc.
I prefer Rust's approach with the choice between generics, macros, dyn and Any.