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

C++ Should Be C++

open-std.org

Post reply on HN
Print view View original

171–180 of 191 posts

Re: C++ Should Be C++

#171

Post by [deleted] »

MaxBarraclough wrote: post #93
CoolGuySteve wrote: post #24

> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. Everywhere in the std lib you can see compromises that require rewriting substantial portions for any real time application. Things like: shared_ptr eagerly using…

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs. C++ is at least still pretty committed to the you only pay for what you use principle. A…

[deleted]

Re: C++ Should Be C++

#172

Post by Const-me »

29athrowaway wrote: post #29

If C++ wants to continue evolving, it needs breaking changes. It needs to impose a migration duty to the user, but that is not going to happen. So it will die a death by entropy where noone can know the language.

> that is not going to happen

It’s even worse. They happily introduce breaking changes for some things, but not others.

I have once wasted days of work updating a codebase to build with C++/20 because the new standard suddenly changed the type returned by `u8` string literals (available for a decade already, it was introduced in C++/11) from const char* into const char8_t*, and they made these types incompatible.

Re: C++ Should Be C++

#173

Post by HarHarVeryFunny »

throwat2341 wrote: post #140

C++ has major flaws that cannot be rectified without serious breaking changes. With that said, Herb has been experimenting with a new cpp frontend with sane defaults [1]. In my opinion, the world is on standby until Anders Hejlsberg feels like tackling a modern, next generation systems language. [1] https://github.com/hsutter/cppfront

Herb Sutters' proposal is absolutely the right direction to go to reign C++ back into being a sane simpler language from the mess it has grown into. I doubt it'll ever happen though.

It seems that in the eyes of most of corporate America's management, C++ is a legacy language, and should be replaced with Java (which tbh makes sense in many cases given that Java's tooling and libaries are better than those of C++). Other companies are looking at Rust as a successor to C++.

Even if Herbs's work was completed and implemented by major compilers, it's hard to see much uptake - who's going to be approving porting legacy C++ code to a new modern C++, yet alone approving C++ for new projects?

Maybe if there is a Sutter C++ successor, it should drop the "C++" name which carries legacy associations, and call itself something new. Present itself as C++ successor, even if it comes from a starting point of being 99% backwards compatible with modern (say C++11 or later) C++. Sounds superficial, but I bet it'd make a difference in perception!

Re: C++ Should Be C++

#174

Post by HarHarVeryFunny »

jocaal wrote: post #38
lisper wrote: post #12

> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. No, that is false. It is akin to arguing that Christianity must be true because 2.4 billion Christians can't be wrong. The fallacy is easy to see because the argument can be applied equally to the world's 1.9 billion Muslims and 1.2 billion Hindus and 500 million Buddhists, etc. And yet these gro…

IMO the reason C++ isn't a general purpose programming language is due to memory management. Many many many applications can be built without having to worry about the garbage collector and the productivity gains of using a GC language is so so worth it. And I know you can force C++ into acting like a GC language, but why go through the effort? C++ is a precision tool for building complex and performant systems and t…

> but it is not something you would use for web api's, or a quick script, or UI's or any quick and dirty project

Maybe not, but that's a function of available/standard/free libraries rather than the language itself.

Personally I do use C++ for quick and dirty projects, but OTOH I've spent the last 10 years building libraries that make that convenient.

Re: C++ Should Be C++

#175

Post by steveklabnik »

fartsucker69 wrote: post #170
MaxBarraclough wrote: post #93

Earlier quoted context omitted.

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs. C++ is at least still pretty committed to the you only pay for what you use principle. A…

the only pay what you use thing is bullshit. because everything you want to use actually costs something. the point being that a better implementation would give you the same things without a cost...

"only pay for what you use" means that you do not pay for things you do not use. You are absolutely correct that everything has a cost, but that is not what this slogan is about. The "only" is load-bearing.

Re: C++ Should Be C++

#176

Post by pjmlp »

josephg wrote: post #137
aw1621107 wrote: post #122

Earlier quoted context omitted.

I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. I think separate compilation and monomorphization are the biggest contributors, but I wouldn't be surprised if there was something I was forgetting. Somewhat related, there was some work in Rust about sharing monomorphized g…

> I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. It was a product of the design constraints in the 70s when memory was expensive, and compilers couldn't store a whole program in memory during compilation. The problem C++ has now is that the preprocessor operates on the r…

This was already the case with languages like Modula-2 and Object Pascal in the 1980's, C++ works that way because it was designed to be a drop-in in UNIX/C without additional requirements.

Re: C++ Should Be C++

#177

Post by menaerus »

Joker_vD wrote: post #169
menaerus wrote: post #160

Earlier quoted context omitted.

If the allocator is unaware of your type, how do you initialize the underlying object? That is - how do you invoke the default or non-default constructor of type T over the memory region you just allocated?

That's not the allocator's job, is it? It's up to the allocator's user to call one of the several available varieties of placement new on the block of memory allocated.

> That's not the allocator's job, is it?

I don't see that point because this is not a technical argument, is it?

> It's up to the allocator's user to call one of the several available varieties of placement new on the block of memory allocated.

This would have been a point if that's the control you don't have with the allocator interface. But you do.

I imagine that you're not suggesting invoking placement-new oneself all over the place whenever one allocates the backing storage?

Re: C++ Should Be C++

#178

Post by penguin_booze »

carlmr wrote: post #152
JohnFen wrote: post #113

Earlier quoted context omitted.

I know I'm weird, but as long as I can compile individual units and link them to other already-compiled units then compilation speed is something I don't care about much at all.

That's fine and dandy as long as you don't use C++ with templates and other stuff that needs 90% of the code to be in the headers. Any recompile triggers a lot of recompilation. And no, I can't change the code the other hundred devs are writing in my company. In C++ there is no individual units. In C it's somewhat plausible with some discipline.

> In C++ there is no individual units

There's a still a notion of the compilation unit, which is the cpp file on which you invoke the compiler. Due to templates being prevalent in C++, included files contain the implementation as well; so any changes you make there lead to re-compiling a lot more compilation units than, for example, in C.

Re: C++ Should Be C++

#179

Post by steveklabnik »

steveklabnik wrote: post #147
dtolnay wrote: post #146

Earlier quoted context omitted.

The best forecast I know is Sean Parent's on ADSP episode 160. [0:23:57] SP: We're also discussing internally around pending legislation around safety and security, what Adobe's response is going to be. Right now our thinking is we would like to publish a roadmap on how we're going to address that. That is not finalized yet in any form, but I expect a component of that roadmap is going to be that some of our critical…

Thank you. I have mostly heard people confusing the CISA stuff with "legislation," but this sounds like something that is actually legislation. I'll have to dig into it. Thank you.

The episode: https://adspthepodcast.com/2023/12/15/Episode-160.html

The legislation:

* https://www.congress.gov/bill/118th-congress/house-bill/2670

* https://digital-strategy.ec.europa.eu/en/library/cyber-resil...

Re: C++ Should Be C++

#180

Post by Joker_vD »

menaerus wrote: post #177
Joker_vD wrote: post #169

Earlier quoted context omitted.

That's not the allocator's job, is it? It's up to the allocator's user to call one of the several available varieties of placement new on the block of memory allocated.

> That's not the allocator's job, is it? I don't see that point because this is not a technical argument, is it? > It's up to the allocator's user to call one of the several available varieties of placement new on the block of memory allocated. This would have been a point if that's the control you don't have with the allocator interface. But you do. I imagine that you're not suggesting invoking placement-new oneself…

It is a technical argument. Allocator's responsibility is to allocate memory. Constructing objects in that memory is not (and must not be) its responsibility.

> This would have been a point if that's the control you don't have with the allocator interface. But you do.

Well, std::allocator::construct() has been removed in C++20. You still have std::allocator_traits::construct but it just calls std::construct_at().

> you're not suggesting invoking placement-new oneself all over the place whenever one allocates the backing storage

Well, that's what all the standard containers do (vector, list, map, etc). Or you can use std::construct_at() instead but that effectively is a variant of the placement new. Of course, you'd better use std::make_unique()/make_shared() (which normally still devolves to placement new IIRC) instead of manipulating raw pointers and invoking constructors manually.

Post reply on HN