I am tired of writing shared_ptr<>, it's lengthening the code lines tremendously. Any reason not to do this?
views:
201answers:
3
+9
A:
Why use macro's? Such a mechanism already exists:
typedef boost::shared_ptr<some_longer_name_omg_help> pointer_type;
pointer_type p; // phew
If you're asking about what Steve is suggesting in the comments, you could try:
template <typename T>
struct sp
{
typedef boost::shared_ptr<T> type;
};
typedef sp<some_longer_name_omg_help>::type pointer_type;
But I don't know if it's that much shorter.
I think your macro use is a sign of laziness, honestly. boost::shared_ptr is, in almost any reasonable measure of "lengthy", not lengthy at all. All you're doing is destroying readability.
GMan
2010-03-12 03:32:57
How does that help? It requires *knowing* the type to wrap. I use shared pointers everywhere with dozens of types, so this would not help, right?
ApplePieIsGood
2010-03-12 03:45:54
@Apple: Maybe you need to give an example. As far as I can tell, I could apply the same argument to your macro use. How can you make a macro of anything without knowing the type?
GMan
2010-03-12 03:59:38
I think he wants to write `sp<omg_all_that_stuff>`, so he's asking about `#define sp boost::shared_ptr`. Since C++ does not yet have template typedefs, you can't do `template <typename T> typedef boost::shared_ptr<T> sp;`. Closest you get is `template <typename T> struct sp { typedef boost::shared_ptr<T> t; };`. Then you can write `sp<omg>::t` for the type.
Steve Jessop
2010-03-12 04:25:53
Don't "use shared pointers everywhere". And for the few types you *do* use them on, write a simple typedef for each, in the scope they're needed.
jalf
2010-03-12 13:42:42
@Steve Jessop, exactly. @GMan, lazyness? Readability? You can end up with shared_ptr 3 times on one line of code if you're using containers and other things.
ApplePieIsGood
2010-03-13 01:21:15
"not lengthy at all". 17 characters? That's nearly an armful! `std::vector<boost::shared_ptr<Something> >` is 42 characters, over half a line. Say what you like about C++'s expressiveness, but by any reasonable measure of "lengthy", template types are lengthy. I don't disagree with you and jalf, though, typedefing one lengthy type per line is normally sufficient, and if you're doing that then there's no pressing need for them not to be lengthy. By comparison, woe betide if you #define `sp`, and someone uses it as a name in another namespace or context. "stack pointer"?
Steve Jessop
2010-03-13 02:07:29
... so another option is `#define sp boost::shared_ptr`, typedef `sp<this>`, `sp<that>` and `sp<the other>`, then `#undef sp`. There's no abstraction going on, it's just to save typing, so pin the macro down and it won't bite you later. Or do the typing, and send the bill to GMan if your keyboard actually wears out.
Steve Jessop
2010-03-13 02:12:12
@ApplePielsGood: You still have yet to post any example code. If you did we could recommend ways of cutting down on the typing. If you're using it 3 times on one line, just make a typedef local to the function: `typedef boost::shared_ptr<T> ptr;` and use `ptr` instead.
GMan
2010-03-13 18:33:45
+5
A:
One reason not to do this would be for new developer productivity. If you hire a new employee, it may be confusing for him to learn the intricacies of how you've changed the standard boost API.
Of course, you might say, "but we'll only do it for this one type" ... to that I say, "watch out for that slippery slope" ;-)
Joel Martinez
2010-03-12 03:34:08
Good point. Although probably not on its own too bad of a deal if the number of abbreviations are well documented and kept in one header? Still a valid thing to watch out for.
ApplePieIsGood
2010-03-12 03:47:16
+7
A:
I've got a much simpler suggestion: Use fewer shared_ptr's. If you use them so much, it sounds like you're blindly relying on them instead of a garbage collector. C++ requires you to think about object ownership, but if you do, most smart pointers can be replaced with simple references, which are not long-winded.
Do you really need shared ownership? If you stop and think for a few minutes, I'm sure you can pinpoint one owner of the object, and a number of users of it, that will only ever use it during the owner's lifetime. So simply make it a local/member object of the owners, and pass references to those who need to use it.
Admittedly, this doesn't solve the problem in the general case (there are many other long-winded template names), but in this specific case, I think it's the best solution.
jalf
2010-03-12 13:41:37