Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Does carbon solve the fundamental issue in c++ which is referring / pointing to objects outside their lifetime#3245

Kubiyak started this conversation inLanguage design
Discussion options

Hello,
Does carbon provide any means of restricting references and pointers to objects?

The main issue with c++ is that references and pointers are allowed to all objects without discretion which invariably leads to references and pointers to objects after (or even sometimes before) their lifetimes.

Carbon only has relevance if it can provide some mechanism for an API designer to limit misuse of interactions with that API. Providing some means to bound and limit the taking of references and pointers to objects would be helpful. At least provide some means to prevent the passing of specfically designated types by reference. For example, it should not be possible to return specifically designated smart pointer types by reference. The RAII qualities of smart pointers are defeated by accessing the same via reference or pointer. I'm not suggesting that Carbon turn into Java but lets be cold and honest about why c++ fails.

If this feature exists, I will be a lot more interested in Carbon. Without this feature, Carbon is just a not so glorified IDE for c++. I'll stick w/ CLion if all Carbon can do for me is what an IDE can.

You must be logged in to vote

Replies: 1 comment 5 replies

Comment options

Safety, especially memory safety, is atop priority for Carbon. However, we aredeferring that until the 0.2 milestone because we think we won't be able to design it effectively until we have more of the language foundations in place.

You must be logged in to vote
5 replies
@Kubiyak
Comment options

That's fair but it would be useful to see some of the initial thinking and direction on it. What are the ideas being hashed out around it?

@geoffromer
Comment options

This recent keynote has a good overview of how we're thinking about memory safety in Carbon.

@Kubiyak
Comment options

Thanks for the link. I appreciate the response. I skipped through it and found this:
https://www.youtube.com/watch?v=1ZTJ9omXOQ0&t=1847s

I hope that there is some notion of not allowing reference expressions at all to certain types or reference counting the references also etc. Categorizing references may make sense but the distinction between temporary references and durable references doesn't help me write safer programs by themselves.

@geoffromer
Comment options

Carbon is certainly putting more emphasis on non-addressable values than C++ has, with things likelet bindings andcustomizable value representations. I don't think we've discussed making wholetypes non-addressable, but I suppose it's possible, if it's well-motivated enough.

@Kubiyak
Comment options

Taking the address of an RAII type is a fail. Please consider providing a feature to tag certain types as non-addressable. I really appreciate your responsiveness and willingness to listen. Its a good sign. All the best.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Labels
None yet
2 participants
@Kubiyak@geoffromer

[8]ページ先頭

©2009-2025 Movatter.jp