-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate using C++ smart pointers #190
Comments
If you just use shared_ptr everywhere it's effectively free reference counting. Might run into a little trouble with circular references, but otherwise this could probably work. Though you could also look into doing C++ with nothing on the heap - all stack. |
@faulda forgive me, I haven't done real C++ work since college. :) Could you elaborate on both those points?
Do you mean that there could be a memory leak? If so, is it a type of memory leak that would be unique to C++? My concern would be C++-compiled programs having some unique form of error not present in other languages.
Such a thing feels doable, but how C++-standard is it? Would people look at the code and go eww? |
In Java or C#, create 2 objects and give them each a reference to each other. Or create 3 and give A a pointer to B, B a pointer to C, and C a pointer to A, like a triangle. Using pure reference counting, these objects all know they have 1 reference pointing to them, so they won't be cleaned up. Java and C# have more complicated garbage collection than pure reference counting, so they can recognize when the user program has no more references to these objects and then deallocate them, preventing a memory leak. However, using C++ shared_ptr is pure reference counting. In the C++ implementation, even if all shared_ptr from the user program were gone (thus signaling the user is done with the objects and they should be deleted), the objects will not be deleted since they all have a reference pointing to them (and thus think they're still being used). A practical example of some code that might do this is a graphics mesh (vertices and line segments pointing to each other in a polygon shape) or a circularly linked list that might be used to implement a ring buffer holding the most recent N entries inserted into it.
This is probably almost doable, but isn't C++ standard at all. Using all shared_ptr is also not C++ standard (and as pointed out above, doesn't work). If your goal is to introduce people to basic C++ syntax and you don't care if a couple complex edge scenarios don't work, then one of these ideas are probably worth considering. But I'd argue that memory management is a crucial topic in C and C++ for anyone learning to program in it - you need to be thinking of it constantly when writing your program. Using all shared_ptr would technically work, but it would be far better for a student to first learn to manually manage memory, why you need to, etc. and then to learn about how shared_ptr can automate a lot, but not all, of that work. And that would be difficult to do with GLS because none of the other languages need it. Of course, you could make the user do it in GLS and then have it amount to a no-op in every language that's not C++. In my above comment, I was speaking more to whether it is technically feasible as opposed to whether taking either of these paths is in the spirit of what GLS is trying to accomplish. Assuming you're trying to teach each language according to its standard, C++ would be a toughie. |
Based on all that, it sounds like C++ is still out. Thanks for the explanation! |
Also added a link to #190 explaining why.
Perhaps the language can be supported after all?
The text was updated successfully, but these errors were encountered: