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

121–130 of 182 posts

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

#121

Post by tardedmeme »

mrec wrote: post #71
tardedmeme wrote: post #69

Earlier quoted context omitted.

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.

`export template` was included in the C++98 standard without any experience, experimental or otherwise. The first implementation was achieved by EDG after enormous pain in the early 2000s, and their advice for any others attempting it was "don't". I'm not aware of anything else quite that egregious, though. https://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2003/n14...

There were compilers that used the template export implementation, but not with that exact syntax. I think that's how cfront did templates.

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

#122

Post by nulltrace »

uecker wrote: post #28
Pay08 wrote: post #23

Is there some sort of tool that checks headers for this stuff? On the occasion that I write a C library, I prefer it to be directly usable in C++.

You can just run it through a compiler in c++ language mode.

Compiler mode won't catch the `extern "C"` thing though. Both sides compile happily, link blows up on mangled names. What I do is just keep a throwaway .cpp in tests that #includes the header and calls a few of the public functions. Dumb but it's basically the only thing that ever catches that case before some downstream user does.

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

#123

Post by spacechild1 »

addaon wrote: post #119
spacechild1 wrote: post #111

Earlier 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...

Thanks!

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

#124

Post by uecker »

fanf2 wrote: post #118
uecker wrote: post #115

Earlier quoted context omitted.

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...

Yes, attacker controlled size without limit is bad (and this is also true for heap allocations). For VLAs there is -Wvla-larger-than that can be used to ensure there is a hard limit. To understand the risks of VLAs one also has to compare it to the alternatives. A fixed-size array on the stack is basically always worse. alloca is substantially worse. heap allocation may be a bit better, but also much slower.

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

#125

Post by uecker »

Someone wrote: post #107
uecker wrote: post #46

Earlier quoted context omitted.

What IMHO Rust does not get right and why I do not use it: long compilation times, high complexity, its syntax, polymorphism based on monomorphization, the requirement for many dependencies to get anything done, an ecosystem susceptible to supply-chain attacks, no ISO standard.

> its syntax I haven’t used rust, but having gotten used to C and C++ at a time, I expect that would happen with rust, too, if I started using it. Because of that, I think this is just a matter of familiarity. > polymorphism based on monomorphization Implementation detail (yes, there is only one implementation at the moment, but this means it can be changed without changing the language) > the requirement for many de…

Some of Rust's problems may be fixable, but they are not being fixed at the moment and with something as complex as Rust, this is unlikely. I do not think monomorphization is an implementation detail, rather than a fundamental language design mistake that is difficult to correct.

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

#126

Post by pjmlp »

uecker wrote: post #105
pjmlp wrote: post #80

Earlier quoted context omitted.

Why should it be, the language doesn't expose any of it.

Assuming you mean the standard does not provide features for numa and simd? It doesn't necessarily have to. I think it is not surprising that you seem always bewildered that people still use C (as per your comments), as it seems you fundamentally do understand neither standardization nor systems programming.

I do certainly understand it, by the eyes of C++, Rust, Ada, Object Pascal, Modula-2, D.

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

#127

Post by pjmlp »

flohofwoe wrote: post #41
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…

> I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases. ...I've seen this more often in the opposite direction. Since C++ is stuck with a ca 1995 non-standard subset of C, C++ coders usually have a very outdated view of C. > I’d also be curious which C constructs people still genuinely miss in modern C++. Not implementing the full C99 designate…

Because Microsoft has been focusing on improved C# for low level coding, see recent update on memory model changes for C# 16/.NET 12 roadmap, Rust adoption, and good enough C++ support.

Following on the Secure Future Initiative activities.

The C updates have been what is required to compile critical FOSS projects, or support big name customers on Windows.

Apple and Google are also not racing to adopt new clang versions on their platforms.

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

#128

Post by pjmlp »

bitwize wrote: post #42
remix2000 wrote: post #38

Earlier quoted context omitted.

Rust is impl-first bottom-up and it's stuck with a single implementation and GCC for Rust is still in the works, meanwhile C++26 reflection is already in GCC trunk.

Rust is also the systems programming language of the future. They're pretty much doing everything right.

Except for compilation times, no it isn't the complexity of the language, it is the toolchain.

See Ada, D, Delphi,....

Granted, priorities, one cannot fix everything at the same time.

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

#129

Post by pjmlp »

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.

C++11 GC, modules, contracts, linalg are good examples of not having a substantial actual experience before ratification.

Now, I rather have them than not, but it is still clunky.

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

#130

Post by aw1621107 »

flohofwoe wrote: post #110
aw1621107 wrote: post #101

Earlier quoted context omitted.

> It's especially tragic because Clang already had the full C99 designated init feature set in C++ mode implemented long before C++20 and it worked just fine. How did Clang handle differences between member declaration order and the order in which initializers appeared?

It simply reorders them, same behaviour as in C: https://www.godbolt.org/z/ex138rh51 (the warnings in C++ mode had only been added after C++20)

Hrm, I take it that was considered too footgun-y for the committee?
Post reply on HN