3 ms·

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 probab

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?

ChrisSD 9y ago
It would break the C interface unless the spec had some kind of wrapper for such cases.
mbel 9y ago
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.
- evincarofautumn 9y ago
  Honestly this wouldn’t be a bad idea for consistency, teaching, and template programming purposes: namespace std { template<typename T> using raw_ptr = T*; } // mutable pointer to const value int const *a_old; std::raw_ptr<int const> a_new; std::raw_ptr<const int> a_new_var; // const pointer to mutable value int *const b_old; std::raw_ptr<int> const b_new; const std::raw_ptr<int> b_new_var; // const pointer to const value int const *const c_old; std::raw_ptr<int const> const c_new; const std::raw_ptr<const int> c_new_var; I’ve actually used this before to parameterise a struct/class with an ownership policy, for example: template<template<typename T, typename...> class P> struct Wrapper { P<int> value; }; Now Wrapper<std::raw_ptr> is a non-owning Wrapper, while Wrapper<std::unique_ptr> is an owning one.
mehrdadn 9y ago
If it were for real how would you implement smart pointers?
- mbel 9y ago
  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.
  - fooker 9y ago
    There is no magic in std::function Implementation. std::initializer_list, on the other hand needs some magic from the compiler.
  - mehrdadn 9y ago
    Inline assembly isn't standard C or C++ though?
    - mbel 9y ago
      But still can be (and is) used to implement some features from the standard library.
    - pjmlp 9y ago
      It is pseudo standard in C++. Meaning ANSI C does not refer at all to inline Assembly, from its point of view it does not exist. ANSI C++ on other hand, specifies the asm keyword and that it should enable a compiler specific way to write inline Assembly. But yeah, neither of them actually specifies how it should look.
    - foldr 9y ago
      There have always been library features in the C and C++ standards that can't be implemented using standard C or C++. setjmp and longjmp would be the obvious examples.
    - FrankHB 9y ago
      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.

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?

ChrisSD 9y ago

It would break the C interface unless the spec had some kind of wrapper for such cases.

mbel 9y ago

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.

evincarofautumn 9y ago
Honestly this wouldn’t be a bad idea for consistency, teaching, and template programming purposes: namespace std { template<typename T> using raw_ptr = T*; } // mutable pointer to const value int const *a_old; std::raw_ptr<int const> a_new; std::raw_ptr<const int> a_new_var; // const pointer to mutable value int *const b_old; std::raw_ptr<int> const b_new; const std::raw_ptr<int> b_new_var; // const pointer to const value int const *const c_old; std::raw_ptr<int const> const c_new; const std::raw_ptr<const int> c_new_var; I’ve actually used this before to parameterise a struct/class with an ownership policy, for example: template<template<typename T, typename...> class P> struct Wrapper { P<int> value; }; Now Wrapper<std::raw_ptr> is a non-owning Wrapper, while Wrapper<std::unique_ptr> is an owning one.

mehrdadn 9y ago

If it were for real how would you implement smart pointers?

mbel 9y ago
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.
- fooker 9y ago
  There is no magic in std::function Implementation. std::initializer_list, on the other hand needs some magic from the compiler.
- mehrdadn 9y ago
  Inline assembly isn't standard C or C++ though?
  - mbel 9y ago
    But still can be (and is) used to implement some features from the standard library.
  - pjmlp 9y ago
    It is pseudo standard in C++. Meaning ANSI C does not refer at all to inline Assembly, from its point of view it does not exist. ANSI C++ on other hand, specifies the asm keyword and that it should enable a compiler specific way to write inline Assembly. But yeah, neither of them actually specifies how it should look.
  - foldr 9y ago
    There have always been library features in the C and C++ standards that can't be implemented using standard C or C++. setjmp and longjmp would be the obvious examples.
  - FrankHB 9y ago
    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.