Good C++ book

[Jeff Schwab]

to me that still looks like a pointer. Hiding it behind a typedef
doesn't make it not a pointer.

Nobody talked about not using pointers. They talked about not using raw
pointers. There's a world of difference there.

 

[Jeff Schwab]

As a learning exercise there's certainly benefit to rolling your own.
But in production code I use Boost. And aren't they going to be in
the next standard? std::auto_ptr cut down the trees years ago.

shared_ptr is in tr1, a partial implementation of which is included with
any modern g++, and probably with other popular compilers.

 

[coal]

As a learning exercise there's certainly benefit to rolling your own.
But in production code I use Boost.  

I think some Boost libraries are better than others. I would
be sorely tempted to despair if my job forbade using alternatives to
the Boost Serialization library. It's performance is questionable -
http://www.webebenezer.net/comparison.html - and it's support
for multiple simultaneous versions is poor.

Brian Wood
Ebenezer Enterprises
www.webebenezer.net

A man that has friends must show himself friendly and there
is a friend who sticks closer than a brother. Proverbs 18:24

 

[peter koch]

Nobody talked about not using pointers.  They talked about not using raw
pointers.  There's a world of difference there.

A typedef'd pointer is as much a raw pointer as the real thing, and
the typedef has the sad property to obfuscate and complicate matters.
I must say that typedefs for pointers should be avoided in 99% of real
cases.

/Peter

 

[Jeff Schwab]

A typedef'd pointer is as much a raw pointer as the real thing, and
the typedef has the sad property to obfuscate and complicate matters.
I must say that typedefs for pointers should be avoided in 99% of real
cases.

A typedef is a compile-time abstraction. The fact that it doesn't
impose run-time overhead doesn't make it any less valuable. If you
really want to criticize it, then ask why there isn't a "hard typedef"
that defines entirely new types, as well as the "soft typedef" used to
alias type names.

When you iterate over a std::vector<int>, how do you know whether to use
std::vector<int>::iterator, and when to avoid this typedef's "sad
property to obfuscate and complicate matters" by directly using int*?
Do you write separate code for platforms where
std::vector<int>::iterator has different implementations?

Which of the following alternatives provides more information to the reader:

int i;
int32 i;

Suppose you're using std::string to mean four different things.
Eventually, you decide to switch to a new type for one of those things,
but not the others. If you've been using typedefs to associate names
with your ideas, then you change code in exactly one place. Else, you
have to walk through every use of string and try to figure out whether
it's one of the uses that has to be updated. For example:

std::string employee_name;
std::string employee_id;

Is a lot less maintainable than:

typedef std::string name_type;
typedef std::string id_type;

name_type employee_name;
id_type employee_id;

If the IDs ever switch to a more heavy-weight type, e.g. one that
maintains invariant properties of employee IDs, you change only the
typedef in the latter case, but have to go digging through all the uses
of std::string to figure out which strings represent IDs.

 

[Jerry Coffin]

[ ... ]

so how do you set up complex data types like trees?
Or collections of large objects?

It depends a lot on what you're doing with the tree. In many cases
you're just a dictionary -- something where you can put data and look it
up by a key. Depending on the details, set, multiset, map and multimap
can fulfill those requirements, without you're having to write any of
the code at all.

In other cases, you're creating a graph of some sort -- e.g. modeling a
network by creating a graph in which the nodes represent computers, and
the arcs represent network connections. The standard library doesn't
really have much to help out with this (yet), but you might want to look
into boost.graph for one possibility in that direction.

For collections of large objects that you just want to avoid copying
objects, you usually use the standard collection classes, with a smart
pointer of some sort to wrap your object.