typedef cause any overhead?

[toton]

Hi,
I have some container class with type parameters. As the names are
going big, thus I am using some typedefs for the containers.

like typedef vector<PointTangent> PointTangentVector; etc.
This is done just to increase readability in some cases (mostly when
using template with type parameters which are frequently used).

1) Is it cause any overhead? or compiler just substitutes the typedef
with the actual type (i.e it is just an alias of the type). Any other
herm is there?
2) Is it a good practice?
thanks

 

[Rolf Magnus]

Hi,
I have some container class with type parameters. As the names are
going big, thus I am using some typedefs for the containers.

like typedef vector<PointTangent> PointTangentVector; etc.

Well, that isn't really much shorter.

This is done just to increase readability in some cases (mostly when
using template with type parameters which are frequently used).

1) Is it cause any overhead? or compiler just substitutes the typedef
with the actual type (i.e it is just an alias of the type).

It's just an alias.

Any other herm is there?
No.

2) Is it a good practice?

I'd say it is.

 

[toton]

Well, that isn't really much shorter.

In this case only one character shorter . Some cases more shorter,
where a shorter name is able to give enough meaning. But looks clear to
me. Looks like a normal class!
And I can put just a few char in my editor and a tab to complete it. I
need type Poi+TAB. which is not possible if I do not do typedef. In
that case I need to do type vec +TAB then <Poi + TAB (Thus, it is
shorter in a sense, that I dont need to type shorter things )
Only I needed to make sure I am just adding syntactic sugar, not
causing any herm to my program.

It's just an alias.


I'd say it is.

Thanks for the quick reply.

 

[Michael]

2) Is it a good practice?

Yes.

But even better practice would be:
typedef vector<PointTangent> PointTangentContainer;
That way if you ever go back and decide to use std::list instead of
std::vector, you only need to change it this one place.

Michael

 

[Marcus Kwok]

Yes.

But even better practice would be:
typedef vector<PointTangent> PointTangentContainer;
That way if you ever go back and decide to use std::list instead of
std::vector, you only need to change it this one place.

This practice is even more valuable if you use iterators instead of
index into the vector. For example, with the typedef, you can say:

PointTangentContainer::const_iterator it = whatever.begin();

which should work regardless of what type of container it is. However,
if you instead use indexing, like

whatever[3];

then this will not work for a std::list since list does not provide
random access.

 

[toton]

Yes.

But even better practice would be:
typedef vector<PointTangent> PointTangentContainer;
That way if you ever go back and decide to use std::list instead of
std::vector, you only need to change it this one place.

This practice is even more valuable if you use iterators instead of
index into the vector. For example, with the typedef, you can say:

PointTangentContainer::const_iterator it = whatever.begin();

which should work regardless of what type of container it is. However,
if you instead use indexing, like

whatever[3];

If I know the iterator is random access I can have it[3] also So it
keeps both the advantage of random access iterator as well a sequential
one. Removing some information helps sometime (as removing list or
vector information) , but also needed sometime.

then this will not work for a std::list since list does not provide
random access.

Yes, with template I found it is very much beneficial. That is why I
try to use it. Only I make sure I do not clutter my namespace with lots
of synonymous things with unnecessary typedefs. That causes confusion!

Thanks for the reply.

 

[Marcus Kwok]

Marcus Kwok wrote:

[typedef'ing containers]

This practice is even more valuable if you use iterators instead of
index into the vector. For example, with the typedef, you can say:

PointTangentContainer::const_iterator it = whatever.begin();

which should work regardless of what type of container it is. However,
if you instead use indexing, like

whatever[3];

If I know the iterator is random access I can have it[3] also So it
keeps both the advantage of random access iterator as well a sequential
one.

I was doubtful about this, but I just tried it and it works, at least on
my implementation (VS .NET 2003 SP1).

I guess that it[3] still converts to *(it + 3), which works since it is
random access. Is this guaranteed?