Skip to content
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

Closed
JoshuaKGoldberg opened this issue Jan 10, 2017 · 4 comments
Closed

Investigate using C++ smart pointers #190

JoshuaKGoldberg opened this issue Jan 10, 2017 · 4 comments

Comments

@JoshuaKGoldberg
Copy link
Member

Perhaps the language can be supported after all?

@faulda
Copy link
Collaborator

faulda commented Jan 10, 2017

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.

@JoshuaKGoldberg
Copy link
Member Author

JoshuaKGoldberg commented Jan 10, 2017

@faulda forgive me, I haven't done real C++ work since college. :) Could you elaborate on both those points?

circular references

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.

nothing on the heap - all stack

Such a thing feels doable, but how C++-standard is it? Would people look at the code and go eww?

@faulda
Copy link
Collaborator

faulda commented Jan 11, 2017

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.

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.
TL;DR, memory leak that would only appear in C++ implementation.

Such a thing feels doable, but how C++-standard is it? Would people look at the code and go eww?

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.

@JoshuaKGoldberg
Copy link
Member Author

Based on all that, it sounds like C++ is still out. Thanks for the explanation!

JoshuaKGoldberg pushed a commit that referenced this issue Jan 11, 2017
Also added a link to #190 explaining why.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants