So Daved, am I to understand that you are saying a smart pointer is superior to a dumb programmer?
So Daved, am I to understand that you are saying a smart pointer is superior to a dumb programmer?
dumb programmer + smart pointer > dumb programmer + dumb pointer
smart programmer + dumb pointer > dumb programmer + smart pointer
smart programmer + smart pointer > dumb programmer + smart pointer
I think its most fair to then conclude
smart programmer + smart pointer >= smart programmer + dumb pointer
on the other hand, your third one could have been a typo.
I didn't want to comment on that one. I'm not adequately equipped to opine on that relationship. I would say this though:
me + smart pointer > me + dumb pointer
Although perhaps that could have been deduced from my first comparison.
You are right, its probably best not to open up a can of worms you aren't willing to sip from. I don't use smart pointers as often as I ought to. But that doesn't mean that I do not like them in any way shape or form. Its just a fact.
I really don't think you guys understand what I'm getting at.
You all seem to think that I don't understand the use of, or see the need for pointers. All of you who think that are completely wrong, at least about that specific point. As I said before, I use pointers where it is beneficial to do so, but prefer to use references when I can. You guys are taking most of what I said completely out of the context in which it was offered.
In case there is confusion about context here, I'll offer a bit of clarification. I like to use references for parameters to functions. certainly not for global objects, but for function parameters, they work really well. Also, any of my objects which allocates memory using new cleans up after itself as it should. I just prefer to pass the objects that those pointers represent by reference because it makes my life much easier. The point I was trying to make was that for local objects that need to be created and destroyed dynamically, it might be nice to be able to automatically have a reference that you could destroy and/or reassign sometimes.
The only reason I do not use references 100% of the time is the lack of the ability to know if null has been referenced without an explicit nullref type of some sort. Its just easier to use smart pointers for that task. But whatever floats your boat Elkvis.
I mean, did you ever really want to be on a dev team with me anyway? I am a sarcastic bastard.
[edit]Oh, and a cynic[/edit]
[edit2]Not to mention arrogant[/edit2]
Then let me ask you to elaborate on your suggestion, instead of insisting that you do the right thing normally. The discussion isn't about what you would do normally but rather why this hasn't been proposed.I really don't think you guys understand what I'm getting at.
Please reread my post and correct my interpretation of your idea if you can. If you can respond to the issue I pointed out, that might be helpful as well. We might get somewhere with the topic and that's mutually beneficial. What you've suggested is actually a significant change in the language, contrary to what you may believe... so you have a deal of explaining in order.
I think you've got your options laid out amongst all the other conversation. You sound like you want reference syntax with dynamic memory. You can do that if you want, but it is not really a good idea because of the expected behavior of references versus pointers. It makes little sense to add something new to the standard for it because the existing options work well enough and something new would add more confusion than it would solve.
I agree that reference syntax is nicer and when working with raw pointers I've considered using a reference anyway, but for the reasons mentioned it's just not worth it to worry about it or expect it to change.
Your best bet is to continue using functions and reduce the use of local dynamic variables. (It kind of makes me wonder why you have local dynamic variables in the first place.)
Just be sure to at least catch your std::bad_allocs, Elkvis. Those are my final words of advice before just leaving this thread unreplied to.
Why? Just so you can save 1 character of typing?Originally Posted by Elkvis
Hell no!
First of all, that would completely mess up all the existing code out there, since currently references can never be NULL, so nobody bothers to check if they're NULL.
Second, it would put a huge burden on all C++ developers, because now they can't guarantee that the object that a reference is pointing to at the beginning of a function is the same as what it's pointint to at the end of the function, so they have to go through all the code line by line to see if it gets reassigned.
"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008
"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010
Elvis has clearly stated he wanted something the same but different. So his new datatype is like a pointer when it's convenient and a reference otherwise.First of all, that would completely mess up all the existing code out there, since currently references can never be NULL, so nobody bothers to check if they're NULL.
What I fail to understand is why pointers cause you so much grief?
It's just a little more typing, that's all.
I'm with Elkvis here. Pointers are fugly. Period. End of debate.
Seriously, though, I don't see what all the fuss is about, giving references the same privilages as pointers. The argument that it would be too confusing or dangerous is purely a subjective one. Considering all of the bizarre, error-prone conventions used by programmers that are perfectly *legal*, I hardly think allowing someone a bit of syntactic sugar poses any real threat to safe programming practices.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
I still don't see what particular changes Elkvis envisions that are
1) as syntactically convenient as references
2) different from references, since it would run into my common usage points otherwise
3) not just a pointer with implicit dereference, which is syntactic sugar so trivial that it doesn't justify a change to the core language.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
