20

I'd like to reduce some visual noise in the code and hide shared_ptr behind a typedef like this:

typedef boost::shared_ptr<SomeLongClass> SomeLongClassPtr;

So this:

void foo(const boost::shared_ptr<SomeLongClass>& a, boost::shared_ptr<SomeLongClass>& b);

becomes this:

void foo(const SomeLongClassPtr& a, SomeLongClassPtr& b);

On the other hand I'm worried that I'm reducing the explicitness of the code.

Which is a better style?

Improve this question
6
  • This is sort of a duplicate of What's your convention for typedefing shared_ptr? Commented Aug 9, 2010 at 0:20
  • @James, thanks, I failed to find this question myself. Commented Aug 9, 2010 at 0:37
  • PleaseUseUnderScoresInsteadOfCapitalizingTheFirstLettersBecauseThisIsHardToRead Commented Aug 9, 2010 at 2:04
  • 5
    @Inverse: You have joined the Style Holy Wars. A war that will never be won by any side and will go on for eternity, or as long as we have human programmers... and even then who knows. I imagine even the robots will fight about it. :-) Commented Aug 9, 2010 at 16:41
  • 4
    @JustBoo Sure, I remember that movie with Arnold S. where he was sent back in time to kill the leader of the underscore resistance. Commented Aug 10, 2010 at 15:09

4 Answers 4

Reset to default
14

Given that std::string is itself a typedef, I think you are fine. I do it myself.

Even Scott Meyers recommends typedef for ease of reading code in cases like yours.

EDIT: Effective C++, Second Edition, Page 120, Item 28, fourth paragraph. "...provide typedefs that remove the need..."

More Effective C++, 7th printing, Page 237, Item 31 First paragraph.

More Effective C++, 7th printing, Page 238, Item 31 First paragraph after code sample.

In essence, no worries. :-)

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

I'd love to have a Scott Meyers' reference to that, but meanwhile I'll take your word for it.
9

We use TypePtr typedefs in our code for shared_ptr<Type> objects. It is also useful to have a TypeConstPtr for shared_ptr<const Type>.

Improve this answer

1 Comment

Ditto. If it improves readability and maintainability, it can hardly be a bad thing.
2

I'm kind of opposed to typedefs that hide whether things are real pointers (or references), having seen too much unreadable C code that does this. But applying some casuistry, I guess shared_ptrs are not real pointers, and so the typedef is OK. But you are losing information - you can no longer tell just by looking at the function declaration (or definition!) what its semantics are.

Improve this answer

3 Comments

And let me guess, you are absolutely opposed to putting a "p" in front of it. That would smack of Hungarian Notation and we certainly can’t have any of that! I favor pragmatism over the herd mentality. And no, I don't use or condone HN. I will put a "p" in front of a pointer name on occasion though.
@JustBoo I've never been accused of following the herd before, but I suppose there is a first time for everything. And I do use a very limited for of Hungarian myself - all my member variables are prefixed with an 'm'.
@Neil: Well alright then. :-D I do too. stackoverflow.com/questions/3461697/… coupled with the occasional "p" and that's it.
1

You might name the typedef 'SomeLongClassSharedPtr', which is both explicit and easy to type.

A negative consequence from this practice is that some autocomplete implementations (e.g. in Eclipse CDT) fail to follow through it. That hasn't stopped me personally from using it though.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.