On Sunday, 30 October 2022 at 02:02:33 UTC, Walter Bright wrote:
> On 10/29/2022 1:26 PM, IGotD- wrote:
>> You are aware that you can always obtain a raw pointer from managed pointer right? Which be useful for FFI functions.
>
> Yes, and you can also always obtain a far pointer from a near one. But there's always a cost, otherwise there'd be no point to having near pointers.
>
> If C++/CLI nailed it, why has C++ in general not adopted it? Why has nobody create a C compiler, but with GC? What is the point of Rust if GC is the answer?

C++/CLI is used manually to create a gateway to the .net framework from c++ and back. That and the fact the implementation is windows only so that greatly hinders the adoption of the language.

- Alex

On 10/29/2022 3:59 PM, Adam D Ruppe wrote:
> First, I proposed raw, not managed, let's be safe by default. Also remember what `alias this` does; an unprotected pointer (aka raw!(T*)) can implicitly cast to a protected pointer (aka T*). Third, think about what strcpy does. There's no need to change that signature at all - it is exactly the same as it is now, since it doesn't actually write to any pointers.

strcpy writes through its first parameter

> I'd assume managed by default - just like how arrays are bounds checked by default. If the programmer gets lazy, they get the 1% performance penalty but default protection. You have to opt out of the barrier with the `raw!T` (or the command line argument to turn it all off).
> 
> And since the barrier is only meaningful to pointer writes, it is completely useless with a const pointer because they are never written. So no need to draw a distinction there at all. Moreover, writing *through* a pointer is not the same as writing *to* the pointer. strcpy is writing to `char`s, not to `char*`, so even the same code is generated anyway. You don't have to barrier a `char`, the GC doesn't care if its value changes.
> 
> But even if it did write to the pointer, there'd be no need to change the signature, since the raw pointer implicitly converts to the managed pointer. And remember, the managed pointer only even generated different code if the *pointer itself* is actually written to,

No, if what it points to is written, because that's what makes the target page "dirty".

> and moreover, we can even elide the checks if we know it is pointing to the same block, since the GC won't care about specifically where in the block it points, just that it points to the block. So even `a = a[1 .. $];` need not use a barrier. (I think.)
> 
> Arguably, all C functions should take raw pointers, but if the reference is borrowed, again it doesn't matter too much since you know there's another reference at the call site. So you might get away with ignoring that detail too. But still, the guiding principle is to be safe by default and allow people a chance to opt out with explicit action. Just like bounds checking in principle.

In DOS programming, near pointer could always be converted to far. So why didn't everyone just use far APIs? A lot did. But it turns out, you could get a lot more performance by mixing near and far, at the cost of ugly code and a lot of careful work.

I was glad to leave all that behind.

Besides, if it was so easy to do, why has nobody produced a C compiler that uses a GC instead of malloc/free?

Microsoft implemented a raw/managed pointer type in C++/CLI, and it has set nobody on fire. It appears to be a dead end.

On 10/29/22 02:16, Walter Bright wrote:
> My post is now #1 on news.ycombinator.com/news

Apologies for posting a direct link but it's number 73 at this time anyway:

  https://news.ycombinator.com/item?id=33381285

Ali

On 10/29/2022 7:14 PM, 12345swordy wrote:
> C++/CLI is used manually to create a gateway to the .net framework from c++ and back. That and the fact the implementation is windows only so that greatly hinders the adoption of the language.

I do understand that. But if it was a winner, why have none of the other C++ compilers adopted it? Why isn't in the C++ Standard? Why isn't it in the C Standard?

On Sunday, 30 October 2022 at 05:55:44 UTC, Walter Bright wrote:
> On 10/29/2022 7:14 PM, 12345swordy wrote:
>> C++/CLI is used manually to create a gateway to the .net framework from c++ and back. That and the fact the implementation is windows only so that greatly hinders the adoption of the language.
>
> I do understand that. But if it was a winner, why have none of the other C++ compilers adopted it? Why isn't in the C++ Standard? Why isn't it in the C Standard?

It is a standard,

https://www.ecma-international.org/publications-and-standards/standards/ecma-372/

As for why it isn't in ISO C++, for the same reason most GCC and clang extensions aren't in ISO.

No one has bothered to endure the work and the voting process to make it part of ISO, including Microsoft that published it via ECMA.

As for why no other has adopted it, it really only makes sense for bytecode based stacks, and there is no competition to CLR for low-level languages.

WebAssembly is the one that came closest, and they still don't have a GC story to talk about.

On Sunday, 30 October 2022 at 01:51:46 UTC, Walter Bright wrote:
> On 10/29/2022 1:11 PM, Paulo Pinto wrote:
>> Again mixing languages,
>> 
>> __gc is from Managed C++, .NET 1.0
>> 
>> C++/CLI, .NET 2.0 onwards, uses ^ for reference types and gcnew for GC heap.
>
> What's the difference between __gc* and ^ ?

Between Managed C++ and C++/CLI, none.

The latter replaces the former, Managed C++ died with .NET 2.0 release.

If we also bring C++/CX into the picture, ^ is a tracing GC pointer to .NET types in C++/CLI, while on C++/CX it is compiler native support for COM types with the compiler doing AddRef/Release calls on its own.

In modern native frameworks, WRL, WIL and C++/WinRT, the ^ get replaced by library smart pointer classes.

On 10/29/2022 11:41 PM, Paulo Pinto wrote:
> No one has bothered to endure the work and the voting process to make it part of ISO, including Microsoft that published it via ECMA.
> 
> As for why no other has adopted it, it really only makes sense for bytecode based stacks, and there is no competition to CLR for low-level languages.

Not a good sign for D needing to adopt managed pointers.