Deprecating Raw Pointers in C++20 • Hacker News Board

Re: Deprecating Raw Pointers in C++20

#81

Post by FrankHB » Mon, Apr 02, 2018, 1:54 AM UTC

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…

> Then C++ added new abstraction mechanisms on top of C, that were at first totally orthogonal: just classes and templates.

Not quite. Classes are based on struct types in C. Templates are based on classes, function types, and more.

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

This is not the truth. It is just never supported in a portable way. And there is no other choice. ISO C is also always lack of that capability (if not more restricted). Nevertheless, you can still rely on the usefulness provided by implementations, as-is.

Re: Deprecating Raw Pointers in C++20

#82

Post by FrankHB » Mon, Apr 02, 2018, 2:13 AM UTC

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

The problem is that pointers almost totally violate the single responsibility principle.

Technically, the only dependencies on pointers are types of the allocation/deallocation functions which are mandated in ISO C++ even for freestanding implementations (not the case in ISO C), and their derivations (new-expressions, etc). All other sane uses of pointers should be replaced by some better alternatives when appropriate (shared_ptr, unique_ptr, observer_ptr, reference, reference_wrapper without type completeness requirement, uintptr_t, iterator, etc).

In that sense every pointer is a badly designed variant type; basically each occurrence of a pointer would likely be mostly incorrect (or not correct enough) in program semantics. I always treat that vagueness as a can of worms, so even merely replacing pointer by observer_ptr somewhere makes a big win to me. There do exist real costs like verbosity and bloating of binary size, but they have to be paid for sin of the father. The ship has sailed too far in a regretful direction; but this is not the excuse to fix it - which is one source of the problem from many developers.

Re: Deprecating Raw Pointers in C++20

#83

Post by FrankHB » Mon, Apr 02, 2018, 5:52 AM UTC

mehrdadn wrote: post #21

mbel wrote: post #18

Earlier quoted context omitted.

In C obviously or you know, in inline assembly since it seems that it isn't going anywhere. But joking aside they could be implemented by the compilers similar to how std::function is implemented today.

Inline assembly isn't standard C or C++ though?

It isn't.

Quoted from the C++ standard: "the asm declaration is conditionally-supported; its meaning is implementation-defined". ISO C does not differ much in conformance (the asm keyword is common extension listed in annex J). There exists implementation without inline assembly support, e.g. MSVC x64. There are alternative keywords used in practice (e.g. `__asm` or `__asm__ __volatile__`). Actually the contents are not supposed to be assembly language in all cases when it is supported, as I know there exists implementation with JavaScript as the "assembly" (Cheerp). Even the implementation supports "genuine" assembly, it varies in syntax, e.g. for x86, Intel (MSVC), AT&T (Clang), or both (GCC) ?

So no, you can't expect it too much, if you have to.

Re: Deprecating Raw Pointers in C++20

#84

Post by Lorkki » Tue, Apr 03, 2018, 8:53 PM UTC

electrograv wrote: post #69

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…

To strain the analogy a bit further - that's the thing about going to a hardware store. Bringing everything home is not really useful, so you'll have to be educated on which tools are needed for your job. And possibly all you really wanted was a hammer, and that's perfectly fine too.