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

C constructs that still don't work in C++

lospino.so

Post reply on HN
Print view View original

81–90 of 182 posts

Re: C constructs that still don't work in C++

#81

Post by crest »

jalospinoso wrote: post #2

I 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…

About half of them read as "I tried to use C++ as a worse C" e.g. using struct initilisation instead of constructors, using malloc instead of new or new[].

My pet peeve with C++ is that the sequence point operator can be overloaded at which point it stops being a sequence point.

Re: C constructs that still don't work in C++

#82

Post by pjmlp »

jstimpfle wrote: post #31
pjmlp wrote: post #25

Earlier quoted context omitted.

Except modern C also has plenty of abstractions, devs wrongly assume it doesn't. Then get surprised when it doesn't map to the SIMD/SIMT NUMA machine their code actually executes on.

such a strawman again... You don't want to be writing explicit platform specific SIMD most of the time. You just want to write a dumb function that doesn't do any non-obvious calls, doesn't cause thread contention, doesn't hide complexity, isn't going to be a nightmare to change later, no surprises. I am talking about self-inflicted complexity that is entirely within the C(++) machine model. Avoid that complexity and…

So abstractions are desired then?

I have seen plenty of self inflicted complexity in C, starting in the golden age of Yourdon Structured Method, and all those libraries that replicate C++ basic features with preprocessor macros.

Re: C constructs that still don't work in C++

#83

Post by zarzavat »

NooneAtAll3 wrote: post #72
zarzavat wrote: post #67

Earlier quoted context omitted.

Is that supposed to be a bad thing? I like having only one implementation. Multiple compilers is annoying for users, have to write "portable" code which can only target the lowest common denominator. Only when a feature ships in Clang, GCC and VC++ can you use it. Each compiler needs its own flags/project as well. Loosely coupling a language to its compiler is 20th century thinking for when programming languages were…

yes monopolies are always a bad thing

A programming language with a reference implementation is not a "monopoly", it's a standard. By having a common implementation to write code against we can avoid wasting time on pointless minutiae such as which features are portable in practice and which are not.

When a programming language community fractures into multiple incompatible implementations everyone is worse off.

Re: C constructs that still don't work in C++

#84

Post by pjmlp »

uecker wrote: post #26
pjmlp wrote: post #21

Earlier quoted context omitted.

Yet C23 isn't K&R C any longer, nor is the hardware a PDP 11. Also when we eventually start talking to agents that perform the whole execution steps by themselves, that is kind of irrelevant. Except for the lucky ones that still code to keep the infrastructure going, which is mostly C++.

The "nor is the hardware a PDP 11". Byte access was the main new feature of the PDP 11 that C adopted. Are you saying being able to access individual bytes is not relevant on modern hardware?

It is, however hardly something unique to C, as the C crowd pretends it to be.

Re: C constructs that still don't work in C++

#85

Post by spacechild1 »

crest wrote: post #81
jalospinoso wrote: post #2

I 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…

About half of them read as "I tried to use C++ as a worse C" e.g. using struct initilisation instead of constructors, using malloc instead of new or new[]. My pet peeve with C++ is that the sequence point operator can be overloaded at which point it stops being a sequence point.

What's the "sequence point operator"?

Re: C constructs that still don't work in C++

#86

Post by pjmlp »

flohofwoe wrote: post #51
pjmlp wrote: post #21

Earlier quoted context omitted.

Yet C23 isn't K&R C any longer, nor is the hardware a PDP 11. Also when we eventually start talking to agents that perform the whole execution steps by themselves, that is kind of irrelevant. Except for the lucky ones that still code to keep the infrastructure going, which is mostly C++.

The PDP-11 myth is getting a bit tired by now ;) If C would be so hardwired to the PDP-11 architecture it would have died with it. In reality C works just fine on all sorts of hardware (like GPUs) with only minor extensions.

Just like plenty of other programming languages.

I am also tired that language extensions in C to work around ISO defencies is considered an advantage when argued by C folks, while at the same time it is considered a language design fault when the same crowd points to other programming languages.

Re: C constructs that still don't work in C++

#87

Post by pjmlp »

uecker wrote: post #35
elch wrote: post #34

Earlier quoted context omitted.

IIRC PDP-11 was a 16 bit word machine with an 8-bit byte. Maybe you remember PDP-10 with 4x9=36 bit words?

Anyway, I do not see how this affects the design of C in a way that makes no sense anymore today (except that one could require CHAR_BIT to be eight, but there are still DSPs where this is not the case). I think people repeat the "the C design reflects the out-dated PDP-11 hardware" meme because it sounds smart while in reality it is just nonsense.

So when is WG14 standardising modern hardware into the C standard?

Basic stuff like SIMD, SIMT, without requiring users to go beyond language extensions, something that any programming language can offer in similar capacity?

Re: C constructs that still don't work in C++

#88

Post by pjmlp »

m_mueller wrote: post #43
pjmlp wrote: post #7

Earlier quoted context omitted.

I appreciate that restrict isn't there, because it is yet another UB source, programmer knows not to do errors kind of attitude, and secondly no one seems to care enough to write a language proposal for it.

I take it you probably never tried to use any of these languages for HPC. Without a language standard, you have two options there to compile decently performant executables: (1) compiler pragmas, (2) give up and drop to assembly code. I should add here that there's also (3): Switch to Fortran, which made fundamentally different choices and is IMO the only fully supported higher-than-C level language that can produce…

Long time ago at CERN.

There are some ATLAS TDAQ/HLT papers with my name on them.

Template metaprogramming, multi-threading, and custom IP protocols where much more relevant.

Re: C constructs that still don't work in C++

#89

Post by spacechild1 »

uecker wrote: post #76
TuxSH wrote: post #54

Earlier quoted context omitted.

> It shouldn't require casting from and to specific pointer types You don't need to explicitly cast T* to void* (guaranteed to be safe), you only need to cast when converting out of void*. The rules are basically the same as casting between pointer-to-derived-class and pointer-to-base-class and they make sense.

They make sense but reduce type safety, because once you add the cast the case might hide some real typing issue. I sympathize with the idea that the down-cast should be explicit though.

> They make sense but reduce type safety

Yes, downcasting can be unsafe and should be used carefully, but what's the alternative? At least in C++ you can't cast between unrelated types without an explicit reinterpret_cast (or C-style cast).

Re: C constructs that still don't work in C++

#90

Post by spacechild1 »

tardedmeme wrote: post #69
maxloh wrote: post #33

I think the problem is that C++ is a poorly designed language with a fundamentally flawed development process. Instead of letting compiler implementers decide which features to add and how to implement them, C++ employs a standards-first, top-down approach. Features are often defined by committee members who may not use modern C++ in their daily workflows, leaving it entirely up to the individual implementations to c…

I don't think that's true? Nothing gets in the standard without substantial actual experience on at least an experimental compiler branch first. It's just not always your compiler.

The one big and tragic exception being modules...
Post reply on HN