Hey guys,
would you probably consider, introducing the smart-pointer-concept of C++ to Oxygene-Island`?
When no, where are u concerns about?
Would be nice to know.
–Shpend
What would you need them for?
The Thing is, that they are between the GC and Raw pointer, or different saying: safe and fast
Would you at least consider, allowing them as a Compiler-Directive? Because there would be much more to do with oxygene-island.
You could then decide, if:
1)the app Needs to be very fast and highly optimized, then you would develop totally with smart-pointer
2)the app Needs more safety, and a relative good Performance, then you could take the GC and disable the smart-pointer-model
To be honest, most of the C++ developer dont leave C++ because of this high-Performance-concepts, which when Oxygene would do as well, I am pretty sure that you would have even more customers 
Would really like to hear your opinion about this 
The concept of smart pointers wouldn’t work in Island since Island uses a gc and can’t currently allocate things on the heap manually. So no there are currently no plans to add this.
First,
I had forgotten this post totally and
second,
but why cant you then at least introduce a Compiler-directive for shutting GC completly off, like:
{$GC OFF}
and then, the smart-pointer-concept would behave like in C++.
In General, it actually should be a developer’s Option to develop his Software with GC Memory-Management or manually, when I want to write a relative not-performance-hungry app then ofc the developer would choose the GC variant but when he thinks he Needs, you know, every bit in Memory, he should be able to work directly with Memory.
Again the Thing is, why so much developer use C++ is because of such concepts, and now imagine, a more beautiful language (Oxygene) would also have the possibility to gain such a critical Performance lvl like C++…
Do you actually have performance issues with island? If so I’d like to know about them.
What c++ calls Smart pointers are basically ref counted objects. They’re not actually faster than gc, in some cases like multithreading they might even be slower.
That said, we’re not introducing a {$GC} switch.
To be honest with you, i tested the working-own-memcpy implementation in oxygene and free Pascal both with full optimization and always the same code-steps and the result was: fast_memcpy in oxygene was 50-60ms slower than in Pascal.
Yes, yes, I know that this is not the world, but as I Think, it has to do with the GC.
And I really would like to understand, why did you decide to make a GC for Island?
Its a honest question, because its a Topic which I really like to understand ^^
you think, or you know? How much of this is based on empiric evidence, and how much on expecting that GC is the reason it’s slower?
if you can share the concrete sets cases you used with us, we can have a look at what the actual problem is.
I have experienced firsthand the performance penalty derived from the combination of ARC + System.pas’s references handling in Delphi. I had to change System.pas to deal with a execution time increase of several minutes for the same code. (Huge JSON parsing, with lots of object destructions)
My point is neither ARC nor GC are slower or faster per se. It depends on the implementation and the use case.
I personally prefer GC for Island.
Here there is a performance comparison between several ARC/GC implementations in 2015.
Sometimes ARC is faster, sometimes GC is way faster. But the implementation is what matters.
3 Likes
Mark, I never said that I know dat much about GC and ARC, I was all day Long just wondering why C++ is always considered super-fast but ok, this has probably more do with the massive Compiler-optimizations rather the smart-ptr-concept.
And I just asked a honest question, why did you consider using GC instead of ARC, maybe to know some Facts, like with GC you would have this and that and loose this negative Impact over ARC or something like this…
And the reason why I am currently a Little bit “against” GC is because, the Moment I choose a truely native language, I want at that time to be in Control of nearly everything, let it be: direct memoryaccess, internal bitpacking, or alignment-optimazations… independet what it is, I want at least, 90% Control of what I am doing, and the GC concept fits IMO more to Business-language like C#, Java etc… because it takes all this internal stuff away from your eyes and encapsulates it for you to write goodlooking but “slower” Code, as I said, IMO.
But ok, when you guys decided to introduce this model, I really belive in you that you knew why it also fits in native-Island 
I wish a great Weekend
1 Like
mostly because when people talk about that, it’s in the context of comparing it to, sea, Java or other stuff that is NOT fast ;). C++ is not magically faster than C, or Pascal, or any other language.
1 Like
The issue with the garbage collector in Java (and quite possibly all garbage collectors) used to be that it could kick in at random times which would temporarily and uncontrollably slow performance. For some applications that needed a constant rate of performance above a certain threshold, that was a deal breaker. But if the garbage collector can run on a separate processor, maybe that issue goes away.
And, this page:
https://docs.elementscompiler.com/Concepts/ARC/
Says that the macOS Cocoa product does Automatic Reference Counting.
I just knew that Island is using automatic memory management without opt-out possibility. This made me think again to really consider Island as an option.
When I do native, I want full control over how my code behaves. It’s alright for a development tool to give some helpers like GC or ARC, but at least give me some options to do it my way. I’ll take full responsibility for my decision. Even Apple’s Swift give us option to go full control, albeit a bit complicated.
1 Like