typedef in C++

[Allerdyce.John]

Is it a good practice in C++ to:
1. create a typedef for my STL container of my class?
like this:

typedef vector<A> AList;

and I create my vector of A using this:
AList* aList = new AList(10);

2. create a typedefor for a pointer to my class?
like this:

typedef A* APtr;

Thank you.

 

[Alf P. Steinbach]

* (e-mail address removed):

Is it a good practice in C++ to:
1. create a typedef for my STL container of my class?
like this:

typedef vector<A> AList;

Yes.

and I create my vector of A using this:
AList* aList = new AList(10);

Generally not -- it's a good idea to use smart pointers (e.g.
std::auto_ptr or boost::shared_ptr) instead of raw pointers, or if the
list is just used locally, writing

AList list( 10 );

2. create a typedefor for a pointer to my class?
like this:

typedef A* APtr;

Depends, but generally there's no strong reason to do or not to do. One
situation where you'd probably benefit from a typedef is where you have
qualifiers such as 'const', another is where the type expression is
textually long. The cost of a typedef is that when reading the code one
may have to check what that typedef really is, it might not be apparent.

 

[Thomas Tutone]

Is it a good practice in C++ to:
1. create a typedef for my STL container of my class?
like this:

typedef vector<A> AList;

Sure, if you like. But many would contend that calling a vector<A>
AList is confusing because it suggests it's a std::list rather than a
std::vector.

and I create my vector of A using this:
AList* aList = new AList(10);

With some exceptions, the above is probably bad practice. Why would
you create your vector using new instead of just creating it on the
stack? And, assuming you have good reason to do that, at least use a
smart pointer like std::tr1::shared_ptr, so that you don't have a
resource leak.

2. create a typedefor for a pointer to my class?
like this:

typedef A* APtr;

I don't see much advantage of APtr over A*, plus defining that typedef
encourages you to use raw pointers - generally a bad thing except in
very low-level code. How about:

typedef std::tr1::shared_ptr<A> APtr;

That way you'll always use a smart pointer instead of a raw pointer
when you use the typedef.

(If you don't have tr1::shared_ptr yet, you can download boost, and use
boost::shared_ptr, which gives the same functionality, instead.)

Best regards,

Tom

 

[Victor Bazarov]

Is it a good practice in C++ to:
1. create a typedef for my STL container of my class?
like this:

typedef vector<A> AList;

and I create my vector of A using this:
AList* aList = new AList(10);

2. create a typedefor for a pointer to my class?
like this:

typedef A* APtr;

It is a good practice if it leads to improvement. How do you measure
improvement? Less typing is an improvement, for example. 'APtr' is
in no way an improvement over 'A*' in that case, agree? Also, if your
code is easier to understand as a result of a typedef, that could be
an improvement as well. 'AList' over 'vector<A>'? I wouldn't really
call it an improvement simply because a 'vector' is not a 'list'.

Of course, using a typedef instead of "inline" type wins my vote if you
are currently deciding what container to use, and along with adding the
'AList' (or 'AContainer') typedef for 'vector<A>', you also add the
'AContainerIterator' as a typedef for 'vector<A>::iterator' and so forth
because (a) you keep them in one place, so it's easier to change and (b)
you keep them closer to each other, so it's easier to understand your
design intent.

V

 

[Allerdyce.John]

The reason I have to do this is
" AList* aList = new AList(10); "

I have to keep the list around (even when the function returns)

something like this:

AList& myFunc() {
AList* aList = new AList(10);
// do somethin here with aList;

return (*aList);
}


The reason I do 'typedef A* APtr;' is I can switch APtr to be a smart
pointer of A instead of a c++ raw pointer of A in the future.

I can't use Boost as my smart pointer library because my application
does not compile with RTTI enable (project restriction). And I heard
stl's auto_ptr<> is not that good. So that is why I am currently not
using any Smart pointers.

 

[Allerdyce.John]

The reason I have to do this is
" AList* aList = new AList(10); "

I have to keep the list around (even when the function returns)

something like this:

AList& myFunc() {
AList* aList = new AList(10);
// do somethin here with aList;

return (*aList);
}


The reason I do 'typedef A* APtr;' is I can switch APtr to be a smart
pointer of A instead of a c++ raw pointer of A in the future.

I can't use Boost as my smart pointer library because my application
does not compile with RTTI enable (project restriction). And I heard
stl's auto_ptr<> is not that good. So that is why I am currently not
using any Smart pointers.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

The reason I do 'typedef A* APtr;' is I can switch APtr to be a smart
pointer of A instead of a c++ raw pointer of A in the future.

Don't wait, write now a smart pointer class, even if his smartness is very
low, an use it. The code can be cleaner, and the switching in the future
easier.

 

[Fabio Fracassi]

The reason I do 'typedef A* APtr;' is I can switch APtr to be a smart
pointer of A instead of a c++ raw pointer of A in the future.

I can't use Boost as my smart pointer library because my application
does not compile with RTTI enable (project restriction).

Are you sure that Boost smart pointer's need RTTI? The smart pointer lib has
very few dependancys, so you might be lucky.
If not, there are several other free smart ptr implementations out there.
You should probably get one, or write one yourself, the basic functionality
is not too hard. (Have a look at the "Modern C++ Design" Book for example)

And I heard stl's auto_ptr<> is not that good.

They certainly have some restrictions, but if you are aware of them they can
still be put to good use.

HTH

Fabio

 

[Richard Herring]

The reason I have to do this is
" AList* aList = new AList(10); "

I have to keep the list around (even when the function returns)

something like this:

AList& myFunc() {
AList* aList = new AList(10);
// do somethin here with aList;

return (*aList);
}

That looks like a recipe for memory leaks. When a function returns a
reference, the caller doesn't normally expect to be saddled with the
responsibility for deleting the thing referenced.

Incidentally, what do you do with the returned reference? If you use it
to initialise another reference in the caller, you'll have a problem
making it exception-safe; if you copy it to somewhere else you might as
well have returned the AList by value in the first place.

The reason I do 'typedef A* APtr;' is I can switch APtr to be a smart
pointer of A instead of a c++ raw pointer of A in the future.

But as you've written the code above, the pointer is only used within
the function. If the function is transferring ownership to the caller,
it would be much clearer to have it returning a (smart) pointer.

But don't do this as a hack. If you don't know who is supposed to own
what, you'll end up with memory leaks or, worse, heap corruption caused
by double deletions. Start by defining an ownership policy and then
write code to enforce it.