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

Deprecating Raw Pointers in C++20

bfilipek.com

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Deprecating Raw Pointers in C++20

#61

Post by VHRanger »

rosshemsley wrote: post #14

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

Except if you can use Go for your usecase then you probably didn't even really need C++ in the first case

Re: Deprecating Raw Pointers in C++20

#62

Post by gmueckl »

pmorici wrote: post #44
gmueckl wrote: post #23

Earlier quoted context omitted.

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.

That only works if you are working alone. In a real world team environment you can’t always enforce your preferences on your teammates

I did not wrote these things for fun. I had a real need for each one. The STL is fine for the average case, but it is also limited. I hit these limitations.

Re: Deprecating Raw Pointers in C++20

#63

Post by rosshemsley »

VHRanger wrote: post #61
rosshemsley wrote: post #14

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

Except if you can use Go for your usecase then you probably didn't even really need C++ in the first case

Nah, plenty of overlap :) building networked services that deal with lots of data.

Re: Deprecating Raw Pointers in C++20

#64

Post by chi3 »

rosshemsley wrote: post #63
VHRanger wrote: post #61

Earlier quoted context omitted.

Except if you can use Go for your usecase then you probably didn't even really need C++ in the first case

Nah, plenty of overlap :) building networked services that deal with lots of data.

And why couldn't you do it in another language? If Go is performant enough, then I'm sure for example Java would be as well.

Re: Deprecating Raw Pointers in C++20

#65

Post by mannykannot »

andrepd wrote: post #37
codeflo wrote: post #28

Earlier 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://…

cppreference explains it pretty well: >std::reference_wrapper is a class template that wraps a reference in a copyable, assignable object. It is frequently used as a mechanism to store references inside standard containers (like std::vector) which cannot normally hold references. >Specifically, std::reference_wrapper is a CopyConstructible and CopyAssignable wrapper around a reference [...] of type T. Instances of st…

It is also an example of a sort of 'combinatorial pump' that inflates the language's complexity, as each new feature needs to work with every existing one. It is my guess that it is C++'s multi-paradigm flexibility that makes this both possible and necessary.

Re: Deprecating Raw Pointers in C++20

#66

Post by chi3 »

mbel wrote: post #6

The fact that this headline cannot be distinguished from April Fools joke by other commenters seems to say a lot about the direction in which C++ standard committee is heading.

Honestly, anyone with C++ experience should understand that it's a joke just from the title. I'm honestly surprised so many people thought this could be true; even Rust has raw pointers (in unsafe mode).

Re: Deprecating Raw Pointers in C++20

#68

Post by pjmlp »

_o_ wrote: post #32
codeflo wrote: post #28

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

You can have languages that prevent people making stupid mistakes and still offer full control over the hardware, that is what languages like Modula-2 and Ada offer.

Re: Deprecating Raw Pointers in C++20

#69

Post by electrograv »

titzer wrote: post #57

It'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 poi…

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

I’m not sure I’d say all the abstractions break down. If you and your team can agree on a subset of C++ features and patterns that work really well, you really can have some nice, clean code that yields both effective abstractions and good system-level results.

The problem with C++ is that it’s effectively a giant pile of tools, that keeps getting new tools dumped on the pile every few years —- some of which meant to “replace” older tools, yet rarely remove any tools (for fear of breaking backwards compatibility). So the pile keeps getting bigger and bigger, until it some day collapses under its own weight of complexity (maybe).

Skilled craftspeople can still use these tools to great effect, but there is at least an organizational overhead and danger from how cluttered and huge the set of tools is: every person or team may use a different subset of tools due to differing preference, not knowing about all the tools, not using some tools “properly”, using the “bad” tools, etc. etc.

Re: Deprecating Raw Pointers in C++20

#70

Post by evincarofautumn »

mbel wrote: post #15
enitihas wrote: post #10

Can someone with more knowledge about c++ standard comment whether this is for real or it is an April Fools joke. Wouldn't this be an enormous change and probably break the language?

It seems to be a joke, they would have serious problem with backward compatibility with "this" pointer. Also it would limit the use cases for the language, unless they would introduce something like std::raw_ptr, which to be honest would be quite funny.

Honestly this wouldn’t be a bad idea for consistency, teaching, and template programming purposes:

    namespace std {
        template
        using raw_ptr = T*;
    }

    // mutable pointer to const value
    int const *a_old;
    std::raw_ptr a_new;
    std::raw_ptr a_new_var;

    // const pointer to mutable value
    int *const b_old;
    std::raw_ptr const b_new;
    const std::raw_ptr b_new_var;

    // const pointer to const value
    int const *const c_old;
    std::raw_ptr const c_new;
    const std::raw_ptr c_new_var;
I’ve actually used this before to parameterise a struct/class with an ownership policy, for example:

    template class P>
    struct Wrapper {
        P value;
    };
Now Wrapper is a non-owning Wrapper, while Wrapper is an owning one.
Post reply on HN