This cannot work for unqualified names
That's odd, it does in my copy of VS2012...
passing std::shared_ptr to a function?
This cannot work for unqualified names
That's odd, it does in my copy of VS2012...
And it still does in 2013 (it's actually working so well, that I feel extremely irritated when I have to go back to 2010 at work).
Their early versions had some serious issues, though. I ended up writing my code in Wordpad and pasting it to the IDE, because it insisted to turn "int i" into "int IObscureWinAPIInterface" the moment you entered a space or ;
I'm also still trying to find a good example of hidden virtual functions, where the qualified name or "this->" are the only ways to make it compile (which also means that just using "this->" by default might hide a potential bug). Considering the actual code also involved overloads and templates, one could argue that it's a rare corner case anyway. I still prefer something less "noisy" like a prepended m or appended _.
I remember reading somewhere that people started uselessly writing this->whatever() in C++ after it was required by some other language, like with other idioms where people dont adapt.
I'm also still trying to find a good example of hidden virtual functions, where the qualified name or "this->" are the only ways to make it compile (which also means that just using "this->" by default might hide a potential bug).
Using this-> to qualify names is required for explicit disambiguation in a compliant C++ compiler when you have a member function in a templated class and a possible conflict could arise dues to the interaction of two-phase name lookup and the template arguments. It's not going to occur with the Microsoft compiler because it is famously non-compliant when it comes to two-phase name lookup. It's only really technically necessary when you're writing general-purpose template libraries where you have no control over the types used to instantiate the templates.
Other than that, the use of "this->" is just a wart, like a m_ prefix or a _ suffix. It contributes a good deal to readability and I would encourage the use of some kind of member designating wart ("this->" is too long for my taste, but tastes vary), but I recognize most code is write-only disposable code and software maintenance is a dying art, like buggy-whip manufacturing.
It's not going to occur with the Microsoft compiler because it is famously non-compliant when it comes to two-phase name lookup.
Thanks for that little detail. Explains why I wasted at least an hour trying to confuse the compiler and couldn't reproduce that particular issue. Maybe I should have just copied the example from Alexandrescu's book.
It contributes a good deal to readability and I would encourage the use of some kind of member designating wart ("this->" is too long for my taste, but tastes vary), but I recognize most code is write-only disposable code and software maintenance is a dying art, like buggy-whip manufacturing.
It is? Because for the last six years I spent at least 80% of my time staring at code and trying to fix bugs and add workarounds. With your own code you usually have a good idea where to look or change stuff, unfortunately due to the above, it's rare to get a chance to deal with your own code. Wait, I think my sarcasm radar might be broken...
Generally speaking, unless the function needs to interact with the shared_ptr part of the pointer (for lack of a better term), just take a reference for the parameter. Barring anything too crazy, the function returns to where it was called once it's complete, so you shouldn't have to worry about the object being destroyed.
(NB: If the object might actually get destroyed for some reason while the function is running, e.g. due to threads, then yeah, you'll probably want to pass a shared_ptr)
It's the most compelling reason I have. If I type this-> I can then see all methods and members of a class. Type a few more letters, and see all of them with a certain prefix, like get or set. Saves on typing, checking names, and prevents typos.I already know that it's pointless and that it's annoying as hell. I'm just wondering where it came from.
Did people really start doing this just for intellisense? I mean JFC, just upgrade to 2012.
This cannot work for unqualified names, in part because the set of candidates can be large, and in part because of argument dependent lookup. But when calling a method on a class, you don't want argument dependent lookup.
(emphasis mine)
Just press Ctrl+Space. That's the standard shortcut in most IDEs. =]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
