Another blogger wrote about this : https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have... Is this actually a joke ?
No, never.
Deprecating Raw Pointers in C++20
51–60 of 84 posts
Re: Deprecating Raw Pointers in C++20
#52If you click on the "more details" link, you end up on a different blog post, saying some of the same things. Looks like it has a reference.
But then that post also has a link to a source, which is another blog post, which links to another, which via a few more links back to this one.
We have citogenesis[1] in actual action.
Re: Deprecating Raw Pointers in C++20
#53Another blogger wrote about this : https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have... Is this actually a joke ?
You can follow the links to more details, which goes to a different blog post. Each has another blog post as a source, and eventually comes back in a circle to the original one.
This is most definitely an April Fool's joke.
Re: Deprecating Raw Pointers in C++20
#54This could be a joke. Or not. It is very much in keeping with the current direction of C++, which appears to be: "Oh no, C++ cannot keep pace with modern systems languages, let's repair it by whatever means possible" Their heart is in the right place, but perhaps this accelerated process of mutating the language will ultimately be what kills it. Personally, after having deep expertise in C++(11/14) I jumped ship to G…
There is nothing in C++ 11 and later that is forced on you. Everything that was added is optional. For personal projects I depend on some alternate implementations for things that are now in the STL because these not complete enough for my needs.
C++17 removed exception specifications from the language, and parts of the standard library, including std::auto_ptr and a lot of the header.
Re: Deprecating Raw Pointers in C++20
#55I've never done any real development with a language that uses pointers. So noob question: why would one use a pointer over passing a variable? (those are the two flavors right?)
There's absolutely no reason to use pointers, unmentioned detail is that c++20 will bundle v8's garbage collector in the runtime to support this removal.
That's horrifying. And what's even more interesting is that C++11 even had a proposal for garbage collection, even if no-one implemented it.
Re: Deprecating Raw Pointers in C++20
#56Earlier quoted context omitted.
It’s not like the idea is completely crazy; pointer misuse is a big source of all kinds of problems, Rust shows how much can be done without constantly using raw pointers, and what are the C++ Core Guidelines if not an effort in exactly this direction? I finally “got” that this is a joke when they discussed the future alternatives: > For copyable and assignable references you can use std::reference_wrapper. ( http://…
1. April joke :) The point of c/c++ in comparision to other languages is that you can do anything and having a huge toolbox for that. Pointers are excelent sledgehammer. You can be perfectly fine with not using them but c++ need to have them. The pointers are not source of the problem, the developer is. That's why languages like java are prospering, it prevent incompetent people making stupid mistakes and that is fin…
Your point may be technically accurate but the elitism of the tone completely undermines it's point because even the best of us can and do write code with errors in it. I mean just look at all the mature code out there written by experienced developers which fails fuzz testing.
I've been writing software for close on 30 years and I know damn well how easy it is to make mistakes. Even on days when I think I'm in the zone, there will be occasions when I'll go back to it and think "WTF was I thinking?" when it bombs out of the first round of automated testing.
Re: Deprecating Raw Pointers in C++20
#57It's an April fool's day joke in the best tradition: a parody almost indistinguishable from truth. C++ has jumped the shark.
Prima facie C was created as a portable assembly language that very nearly reflected the underlying hardware. Then C++ added new abstraction mechanisms on top of C, that were at first totally orthogonal: just classes and templates. One could still use all of C to get at the raw machine (raw pointers and peeking/poking). Then as abstraction envy grew to overcome C++, as it does every active language in time, C++ drifted farther and farther from its system-y roots. Fine.
But in my day job, the only real reason to use C++ is because it's the only realistic choice as a systems language. I need to peek and poke memory, jump to raw machine code I've generated at runtime. This doesn't make me better or worse, it's just my use case (a virtual machine). As C++ becomes less and less capable of doing these low-level unsafe things (because too many people caused too much damage attempting this), and adds more ceremony to the old ways of peeking and poking memory, it becomes less useful to me. Who is it useful for?
I'd argue that C++ has drifted off into some fantasy world where it believes it's a beautiful language full of nice, solid abstractions. But IMO it isn't--probably can't be--as all the abstractions break down, leaving us in the lurch, with neither good systems programming support nor good application-level abstraction.
Re: Deprecating Raw Pointers in C++20
#58I hope this is a joke: the std::weak_ptr / std::shared_ptr combo (only non-reference alternative I can think of other than std::optional) can have pretty bad performance implications due to ref-counting atomics in multi-threaded scenarios... For the use-case of optional pointers that don't have any ownership (and can possibly be updated mid-lifetime) and have a guaranteed external lifetime, what's the alternative? Ar…
For the use-case of optional pointers that don't have any ownership (and can possibly be updated mid-lifetime) and have a guaranteed external lifetime
Those three things seem like a pretty rare co-occurrence, if something has no ownership how can it have guaranteed external lifetime without being reference counted? I guess it's possible but in any scenario I come up with reference counting seems an easier way to do it.
Re: Deprecating Raw Pointers in C++20
#59Having started using the Internet in the 90's, and thus still remembering Geocities-era websites, I loved that they did this as a webring (https://en.wikipedia.org/wiki/Webring): each blog post has a link to the next one, making a singly-linked circular list.
Starting with this one, we have:
- http://www.bfilipek.com/2018/04/deprecating-pointers.html
- http://www.modernescpp.com/index.php/no-new-new
- https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have...
- https://blog.tartanllama.xyz/no-pointers/
- https://arne-mertz.de/2018/04/raw-pointers-are-gone/
And it circles back to this one.
Re: Deprecating Raw Pointers in C++20
#60This could be a joke. Or not. It is very much in keeping with the current direction of C++, which appears to be: "Oh no, C++ cannot keep pace with modern systems languages, let's repair it by whatever means possible" Their heart is in the right place, but perhaps this accelerated process of mutating the language will ultimately be what kills it. Personally, after having deep expertise in C++(11/14) I jumped ship to G…
>this accelerated process of mutating the language Oh we can't be talking about the same language x) C++ moves fast? They took until 2017 to remove trigraphs for crying out loud! Absolutely nothing in C++>=11 breaks anything in the language.
Fair point. My feeling has been that the committee is trying to make the language safe (as is now the fashion) by adding increasingly more features, with the intention of deprecating old workflows aggressively.
But the language complexity is now so significant that a new dev would take years to fully understand both "old" C++ and new C++, and how to make them work well together