Quick question on smart pointers

> I am thinking of providing a wrapper for the first one as ff:

class Series {
std::auto_pointer<series> sPtr ;
....
}
This is very error prone. Consider:

Series s1;
Series s2 = s1; //!!!
Couple of quick questions:

1). Can I do this (I probably should have checked to see if it would
compile first)
Do you really want/need to use a smart pointer? Just use plain RAII
with private copy constructor and assingment operator.
2). From my understanding of auto_ptr, variable sPtr gets freed
automagically when class Series goes out of scope (I can't imagine how
this is possible)
The magic is called destructor (it's magic only for Java programmers).
3). Will the responses for the previous two statements hold true for a
more complicated structure like client above?

If you maintain the 'creator is deleter' rule many 'problems' disappear
in C++.

Jul 23 '05 #3

Susan Baker <sb****@no.spam.net> schrieb:

typedef struct {
float *data ;
int count ;
} series ;

typedef struct {
void *clientdata ;
FUNC_PTR1 cb1 ;
FUNC_PTR2 cb2 ;
struct param_ pdata ;
int size ;
} client

I am thinking of providing a wrapper for the first one as ff:

class Series {
std::auto_pointer<series> sPtr ;
....
}

I don't understand what you are planning. Why not use a real class
instead of the series struct? What should the auto_ptr do here?

I suggest not to use this auto_ptr stuff. This is for people who's
right hand doesn't know what the left hand is doing. You can always
have a simple pointer in your class and delete it yourself. This is
what destructors are made for.

T.M.

Jul 23 '05 #4

sugary.boy

typedef struct {
float *data ;
int count ;

} series ;

I am wondering as, what is the play of this count variable in
struct?...If it is counting number of object instanciated then better
make it static.
Panjandrum wrote:

I am thinking of providing a wrapper for the first one as ff:

class Series {
std::auto_pointer<series> sPtr ;
....
}

This is very error prone. Consider:

Series s1;
Series s2 = s1; //!!!
Couple of quick questions:

1). Can I do this (I probably should have checked to see if it would
compile first)

Do you really want/need to use a smart pointer? Just use plain RAII
with private copy constructor and assingment operator.
2). From my understanding of auto_ptr, variable sPtr gets freed
automagically when class Series goes out of scope (I can't imagine how
this is possible)

The magic is called destructor (it's magic only for Java programmers).
3). Will the responses for the previous two statements hold true for a
more complicated structure like client above?

If you maintain the 'creator is deleter' rule many 'problems' disappear
in C++.

Jul 23 '05 #5

Geo

Torsten Mueller wrote:

Susan Baker <sb****@no.spam.net> schrieb:
typedef struct {
float *data ;
int count ;
} series ;

typedef struct {
void *clientdata ;
FUNC_PTR1 cb1 ;
FUNC_PTR2 cb2 ;
struct param_ pdata ;
int size ;
} client

I am thinking of providing a wrapper for the first one as ff:

class Series {
std::auto_pointer<series> sPtr ;
....
}

I don't understand what you are planning. Why not use a real class
instead of the series struct? What should the auto_ptr do here?

I suggest not to use this auto_ptr stuff. This is for people who's
right hand doesn't know what the left hand is doing. You can always
have a simple pointer in your class and delete it yourself. This is
what destructors are made for.

T.M.

Surely auto_ptr is the last thing to use if you don't know what you're
doing ??

Jul 23 '05 #6

Susan Baker

Panjandrum wrote:

I am thinking of providing a wrapper for the first one as ff:

class Series {
std::auto_pointer<series> sPtr ;
....
}

This is very error prone. Consider:

Series s1;
Series s2 = s1; //!!!

Couple of quick questions:

1). Can I do this (I probably should have checked to see if it would
compile first)

Do you really want/need to use a smart pointer? Just use plain RAII
with private copy constructor and assingment operator.

2). From my understanding of auto_ptr, variable sPtr gets freed
automagically when class Series goes out of scope (I can't imagine how
this is possible)

The magic is called destructor (it's magic only for Java programmers).

The "magic" I was referring to (which everyone seems to have missed -
perhaps I did not make my self clear enough) was this: how can
auto_pointer correctly free memory allocated for a complicated structure
like client - which has several pointer members. It is my feeling that I
am misinterpreting the use(abuse?) of the auto_pointer and I just needed
some clarification on this point. The way I see it, using auto_pointer
in this way will lead to serious memory leaks - unless the container is
made aware of the details of the object (struct in this case), that it
is acting as a container of. This is what I mean when I say I cannot
imagine how the container finds out how to free the appropriate pointers
in the structure. The more I think abot it, the more it seems like I got
the wrong end of the stick. I don't think auto_pointers can be used this
way without memory leaks (although
http://www.parashift.com/c++-faq-lit....html#faq-17.4 appears
to suggest just that). I'll have to take another read to be sure....

3). Will the responses for the previous two statements hold true for a
more complicated structure like client above?

If you maintain the 'creator is deleter' rule many 'problems' disappear
in C++.

True - but then what is the point of the container?. I *thought* the
container was "managing" mem resources for me - I can just as quickly
roll my own "container" using an array. What "exactly" makes it a "safe
pointer".

Jul 23 '05 #7

>> I suggest not to use this auto_ptr stuff. This is for people who's

right hand doesn't know what the left hand is doing. You can always
have a simple pointer in your class and delete it yourself. This is
what destructors are made for.

That's just not true. If you want your code to be exception safe then
naked pointers are very tricky. It's unfortunate that the majority of
the C++ crowd doesn't think this way but smart pointers (not
necessarily std::auto_ptr) should be used instead of naked pointer
unless there's a good reason not to, NOT the other way around.

Jul 23 '05 #8

Susan Baker

ba***********@gmail.com wrote:

I suggest not to use this auto_ptr stuff. This is for people who's
right hand doesn't know what the left hand is doing. You can always
have a simple pointer in your class and delete it yourself. This is
what destructors are made for.

That's just not true. If you want your code to be exception safe then
naked pointers are very tricky. It's unfortunate that the majority of
the C++ crowd doesn't think this way but smart pointers (not
necessarily std::auto_ptr) should be used instead of naked pointer
unless there's a good reason not to, NOT the other way around.

So briefly, what do they buy me over and above naked pointers?, and how
may I use them in the example stucture I provided previously? (using the
simpler struct "series" as an example - if you please).

Thanks

Jul 23 '05 #9

kartoffelsack

Am Wed, 06 Jul 2005 13:32:36 +0200 schrieb Susan Baker
<sb****@no.spam.net>:

Hi,

I'm just reading about smart pointers..
I have some existing C code that I would like to provide wrapper classes
for. Specifically, I would like to provide wrappers for two stucts
defined as ff:

typedef struct {
float *data ;
int count ;
} series ;

typedef struct {
void *clientdata ;
FUNC_PTR1 cb1 ;
FUNC_PTR2 cb2 ;
struct param_ pdata ;
int size ;
} client
I am thinking of providing a wrapper for the first one as ff:

class Series {
std::auto_pointer<series> sPtr ;
....
}

Couple of quick questions:

1). Can I do this (I probably should have checked to see if it would
compile first)
Yes
2). From my understanding of auto_ptr, variable sPtr gets freed
automagically when class Series goes out of scope (I can't imagine how
this is possible)
The auto_ptr-Object is a 'normal' object on the stack. When it get's out
of scope it's destructor gets called. The dtor deletes the owned object
3). Will the responses for the previous two statements hold true for a
more complicated structure like client above?

Yes. But be aware the ownership-policy of auto_ptr. The ownership of the
pointer is passed, if the auto_ptr gets copied. The other forgets about
the pointer. Thus, one pointer belongs allways to exactly one auto_ptr. So
auto_ptr is in common not helpful if you want to copy your
wrapper-classes. If so, use boost/shared_ptr (www.boost.org)
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Jul 23 '05 #10

"Geo" <gg@remm.org> schrieb:

I suggest not to use this auto_ptr stuff. This is for people who's
right hand doesn't know what the left hand is doing. You can
always have a simple pointer in your class and delete it yourself.
This is what destructors are made for.

Surely auto_ptr is the last thing to use if you don't know what
you're doing ??

No, for a reason I don't know it's the first thing.

T.M.

Jul 23 '05 #11

ba***********@gmail.com schrieb:

If you want your code to be exception safe then naked pointers are
very tricky.
It's not. But you simply must know what you do.

Indeed proponents of the auto_ptr template [1] are just too lazy to
think about a concept in their program. They just want to use an
object and don't want to waste any time with its allocation and
deallocation. Oftenly they are students, having not much time, knowing
just the Java world from their university and blaming C++ for bad
memory management. Normally this leads to sources I find complicated
to read because of an additional layer of indirection.
It's unfortunate that the majority of the C++ crowd doesn't think
this way but smart pointers (not necessarily std::auto_ptr) should
be used instead of naked pointer unless there's a good reason not
to, NOT the other way around.

But why? This is like driving a car with a helmet.

In the last 15 years I used exactly one smart pointer, and this one
had reference counting and methods for exchanging the inner object by
another ... I had never the idea of automatic memory management even
in my large applications. And I'm an extremist in asking for
prevention of memory leaks.

T.M.

[1] I don't mean smart pointers with reference counting, I mean just
such primitive smart pointers like auto_ptr.

Jul 23 '05 #12

Karl Heinz Buchegger

Susan Baker wrote:

The "magic" I was referring to (which everyone seems to have missed -
perhaps I did not make my self clear enough) was this: how can
auto_pointer correctly free memory allocated for a complicated structure
like client - which has several pointer members.
And the answer is: it can't

typedef struct {
void *clientdata ;
FUNC_PTR1 cb1 ;
FUNC_PTR2 cb2 ;
struct param_ pdata ;
int size ;
} client;

You are talking about having an auto_ptr (or some other smart pointer)
to a client object. Well, the only thing the smart pointer does, is
to keep track of when the client object itself should be destroyed.
It is the job of the client object to take care of its inner details.
It does this by eg. making all the pointers in the client struct smart
pointers by themselfs or to simply do the delete in the destructor.
The smart pointer cares about the client object as a whole. The client
object is repsonsible for the inner details of itself.

3). Will the responses for the previous two statements hold true for a
more complicated structure like client above?

If you maintain the 'creator is deleter' rule many 'problems' disappear
in C++.

True - but then what is the point of the container?.

To have one object that is reponsible for all the data in it.
I *thought* the
container was "managing" mem resources for me - I can just as quickly
roll my own "container" using an array.
Yes. Then the array *is* your container. No problem with that.
But don't roll your own. Use what is already available.
What "exactly" makes it a "safe
pointer".

A safe pointer, or what we call a smart pointer, *ensures* that the delete
is executed. Even if you, the programmer have long forgotten that something
was dynamically allocated. It does this delete in all cases by the shear fact
that the smart pointer object is itself destroyed in some way. Be it that the
smart pointer is a member of some structure and an object of that structure
is allocated as a local variable and goes out of scope. Or that this structure
object is dynamically allocated and gets deleted.
There is no magic in it. Everything can be done 'by hand' also. The only problem
is, that humans tend to make mistakes and forget to do things. Then it is handy
to have an object that does the cleanup all by itself without the programmer having
to do anything except just using that smart pointer instead of an ordinary pointer.

--
Karl Heinz Buchegger
kb******@gascad.at

Jul 23 '05 #13

Susan Baker wrote:

If you maintain the 'creator is deleter' rule many 'problems' disappear
in C++.

True - but then what is the point of the container?. I *thought* the
container was "managing" mem resources for me - I can just as quickly
roll my own "container" using an array. What "exactly" makes it a "safe
pointer".

Try this link: http://www.artima.com/intv/modern3.html and search the
internet for RAII.

Jul 23 '05 #14

Torsten Mueller wrote:

ba***********@gmail.com schrieb:
If you want your code to be exception safe then naked pointers are
very tricky.
It's not. But you simply must know what you do.

Indeed proponents of the auto_ptr template [1] are just too lazy to
think about a concept in their program. They just want to use an
object and don't want to waste any time with its allocation and
deallocation. Oftenly they are students, having not much time, knowing
just the Java world from their university and blaming C++ for bad
memory management.

That is a VERY presumptious statement. I come from a C background and
have been working in C++ for several years, and I'm the one to tell you
that. For SOME people what you're saying may be true, but if you ask
experienced C++ programmers (such as the people in c.l.c++.moderated)
you'll see a very different picture.
Normally this leads to sources I find complicated
to read because of an additional layer of indirection.
Consider:

class Foo
{
Bar* a;
Bar* b;
};

void Foo::Init()
{
a = new Bar;
b = new Bar;
}

But what if b's ctor throws an exception? You have a potential memory
leak right there. You have to write:

void Foo::Init()
{
try
{
a = new Bar;
b = new Bar;
}
catch(...)
{
delete a;
delete b;
throw;
}
}

Are you going to write the above code every time you need two or more
dynamic resources? Frankly, I think using some kind of smart pointer is
both shorter and more reliable. Note that I said SOME KIND of smart
pointer. I'm not necessarily advocating std::auto_ptr, only some kind
of management class that wraps just one pointer and provides some form
of access to it.
But why? This is like driving a car with a helmet.

Smart pointers are not about protecting lazy programmers but about
what's more practical. C++ is meant to be a practical language, and I
find smart pointers to be more practical than raw pointers. That's the
bottom line.

Jul 23 '05 #15

Susan Baker wrote:

So briefly, what do they buy me over and above naked pointers?, and how
may I use them in the example stucture I provided previously? (using the
simpler struct "series" as an example - if you please).

I'm not saying that you should use smart pointers in your example. I'm
just saying that whenever pointers are appropriate for the task at hand
then you should use smart pointers. In your case pointers are not even
appropriate for the task at hand.

Bart.

Jul 23 '05 #16

ba***********@gmail.com schrieb:

C++ is meant to be a practical language,
Yes, of course!
and I find smart pointers to be more practical than raw pointers.

I do not. That's the difference.

Sorry, perhaps I've just seen too many young programmers becoming
frustrated because of a serious memory problem in their own absolutely
safe smart pointer world, because they (or anybody else!) forgot
somewhere to use a smart pointer where he should use one and then they
soon begin to blame C++ for causing daylong debugging sessions in
their safe programs.

T.M.

Jul 23 '05 #17

ba***********@gmail.com wrote:

Normally this leads to sources I find complicated
to read because of an additional layer of indirection.

Consider:

class Foo
{
Bar* a;
Bar* b;
};

void Foo::Init()
{
a = new Bar;
b = new Bar;
}

But what if b's ctor throws an exception? You have a potential memory
leak right there. You have to write:

void Foo::Init()
{
try
{
a = new Bar;
b = new Bar;
}
catch(...)
{
delete a;
delete b;
throw;
}
}

Are you going to write the above code every time you need two or more
dynamic resources?

No, alone because your code contains at least 1 bug. BTW, dumb pointers
objects (misleadingly called smart pointers) are not the only and not
the best way to use RAII.

Jul 23 '05 #18

Karl Heinz Buchegger

ba***********@gmail.com wrote:

[snip] But what if b's ctor throws an exception? You have a potential memory
leak right there. You have to write:

void Foo::Init()
{
try
{
a = new Bar;
b = new Bar;
}
catch(...)
{
delete a;
delete b;
throw;
}
}

Note that this is not the end of the story.
The above code still has a problem: What happens, when a's ctor throws
an exception? Then the catch will try to delete b through an uninitialzed pointer.
As you correctly say, at the moment you have more then 1 pointer things
can get tricky.

--
Karl Heinz Buchegger
kb******@gascad.at

Jul 23 '05 #19

Karl Heinz Buchegger wrote:

ba***********@gmail.com wrote:

[snip]
But what if b's ctor throws an exception? You have a potential memory
leak right there. You have to write:

void Foo::Init()
{
try
{
a = new Bar;
b = new Bar;
}
catch(...)
{
delete a;
delete b;
throw;
}
}

Note that this is not the end of the story.
The above code still has a problem: What happens, when a's ctor throws
an exception? Then the catch will try to delete b through an uninitialzed pointer.

Ah, yes. I forgot how picky the people in this newsgroup can get
(haven't been here in a long while). Obviously, this example is not
complete. I'm assuming all pointers are null initialized, which is what
I always do in my code.

Jul 23 '05 #20

In message <ui***********@fastmail.fm>, Torsten Mueller
<de******@shared-files.de> writes

ba***********@gmail.com schrieb:
C++ is meant to be a practical language,

Yes, of course!
and I find smart pointers to be more practical than raw pointers.

I do not. That's the difference.

Sorry, perhaps I've just seen too many young programmers becoming
frustrated because of a serious memory problem in their own absolutely
safe smart pointer world, because they (or anybody else!) forgot
somewhere to use a smart pointer where he should use one and then they
soon begin to blame C++ for causing daylong debugging sessions in
their safe programs.

So what you're saying is this:

Some student programmers have problems because they misuse (or
occasionally fail to use?) smart pointers. Therefore we should not use
smart pointers.

Did I get that right?

OTOH I've seen too many young programmers becoming frustrated because of
a serious memory problem in their C-shaped world, because they used raw
pointers without first designing an ownership model.

The cure for "forgetting somewhere to use a smart pointer" is not to
abandon smart pointers but to start with an ownership model, and then
enforce it by using factories etc. and make it impossible to expose raw
pointers at all (a quick search for all instances of "get()", "this",
"new", "delete" etc. should find most of the abuses).

--
Richard Herring

Jul 23 '05 #21

Richard Herring <ju**@[127.0.0.1]> schrieb:

So what you're saying is this:

Some student programmers have problems because they misuse (or
occasionally fail to use?) smart pointers. Therefore we should not
use smart pointers.

Did I get that right?

OTOH I've seen too many young programmers becoming frustrated because
of a serious memory problem in their C-shaped world, because they
used raw pointers without first designing an ownership model.

The problem of smart pointers is that they cause a feeling of safety,
and this feeling is thin ice. "Our program is safe - we always use
smart pointers. And so we have completely safe code. If something is
wrong it can't be our code - we are safe!" ... I heard this just a few
times too often. I have done endless debugging sessions in code of
other people who were not able to understand their own code but beeing
very sure it's safe ... Even explaining them the problem is a problem
itself. This feeling of false safety does not exist in the classic
style. And in my opinion this is indeed an advantage.

What I want to say is, everyone should use the things he understands
completely. If anyone understands how smart pointers work and if he
can be sure all the others in his team understand this as well, they
may use them. No problem! I have never seen a real reason for using
smart pointers. This is my opinion. But the question came from a
beginner. And I oftenly found, people who do not understand raw
pointers have also serious problems using smart pointers, at least
when calling system or API functions.

T.M.

Jul 23 '05 #22

In message <uz***********@fastmail.fm>, Torsten Mueller
<de******@shared-files.de> writes

Richard Herring <ju**@[127.0.0.1]> schrieb:
So what you're saying is this:

Some student programmers have problems because they misuse (or
occasionally fail to use?) smart pointers. Therefore we should not
use smart pointers.

Did I get that right?

OTOH I've seen too many young programmers becoming frustrated because
of a serious memory problem in their C-shaped world, because they
used raw pointers without first designing an ownership model.
The problem of smart pointers is that they cause a feeling of safety,
and this feeling is thin ice. "Our program is safe - we always use
smart pointers. And so we have completely safe code. If something is
wrong it can't be our code - we are safe!"

Then you have an education problem, not a smart-pointers problem.

Of course smart pointers don't guarantee safety. Smart pointers plus the
supporting concepts of factory patterns etc.) are just a part of a
well-defined ownership model. It's the latter which makes safe programs.
... I heard this just a few
times too often. I have done endless debugging sessions in code of
other people who were not able to understand their own code but beeing
very sure it's safe ... Even explaining them the problem is a problem
itself. This feeling of false safety does not exist in the classic
style. And in my opinion this is indeed an advantage.
So we should all deliberately use unsafe raw pointers to write fragile
code, just because it doesn't feel safe? Is that what they call "extreme
programming"? ;-)

What I want to say is, everyone should use the things he understands
completely. If anyone understands how smart pointers work and if he
can be sure all the others in his team understand this as well, they
may use them. No problem! I have never seen a real reason for using
smart pointers.
You've never seen an example of smart pointers removing the need for
putting try-catch blocks around multiple memory allocations? Never seen
an example of RAII? Never even seen a mismatched new and delete?
This is my opinion.
Indeed.
But the question came from a
beginner. And I oftenly found, people who do not understand raw
pointers have also serious problems using smart pointers, at least
when calling system or API functions.

Sure. But "what beginners don't understand" is no basis for deciding
what concepts to use to write reliable programs.

--
Richard Herring

Jul 23 '05 #23

Richard Herring <ju**@[127.0.0.1]> schrieb:

This feeling of false safety does not exist in the classic style.
And in my opinion this is indeed an advantage.
So we should all deliberately use unsafe raw pointers to write
fragile code, just because it doesn't feel safe?

But it's just not true that raw pointers are unsafe. You just should
know what your're doing. And this is how I understand my job.
You've never seen an example of smart pointers removing the need for
putting try-catch blocks around multiple memory allocations?
No, never. What should the try-catch-block do in this case? What
exception should be caught? bad_alloc? I would rather search for the
reason of the exception and I would find it definitely.
Never seen an example of RAII?
Is this something smart pointers are really necessary for?
Never even seen a mismatched new and delete?

Sure I have. But I can count such situations on just one hand. It's a
question of personal experience handling these things. It's not even
difficult, it's just a bit handwork.

T.M.

Jul 23 '05 #24

In message <us***********@fastmail.fm>, Torsten Mueller
<de******@shared-files.de> writes

Richard Herring <ju**@[127.0.0.1]> schrieb:
> This feeling of false safety does not exist in the classic style.
> And in my opinion this is indeed an advantage.
So we should all deliberately use unsafe raw pointers to write
fragile code, just because it doesn't feel safe?

But it's just not true that raw pointers are unsafe.

It's more true than that smart pointers are.
You just should
know what your're doing. And this is how I understand my job.
Sure, but even Homer nods. Why make things difficult for yourself?
You've never seen an example of smart pointers removing the need for
putting try-catch blocks around multiple memory allocations?
No, never.

Then you can't be reading this thread very carefully. Bart Kowalski
posted an example in
<11**********************@z14g2000cwz.googlegroups .com>.What should the try-catch-block do in this case?
I don't know what it "should" do since I'm arguing that it's not
necessary when you use smart pointers properly. What it does in the
usual example is to mop up half-allocated resources and rethrow.
What
exception should be caught?
Everything that might break an invariant (i.e. leave the object in an
inconsistent state.)
bad_alloc?
Much more. Anything that might happen while the invariant isn't
satisfied.
I would rather search for the
reason of the exception and I would find it definitely.
You're missing the point. The problem is not in detecting the exception,
but in clearing up after it.

Never seen an example of RAII?
Is this something smart pointers are really necessary for?

Nothing is necessary. You could just write C. But since memory is an
obvious example of a resource, they are an excellent example of it.
Never even seen a mismatched new and delete?
Sure I have. But I can count such situations on just one hand.

Even in other people/s code, like those young programmers who spend all
their time becoming frustrated because of a serious memory problem?
It's a
question of personal experience handling these things. It's not even
difficult, it's just a bit handwork.

The same is true of smart pointers, but the workload is even less, as
there are no deletes to be matched.

--
Richard Herring

Jul 23 '05 #25

Torsten Mueller wrote:

But it's just not true that raw pointers are unsafe. You just should
know what your're doing. And this is how I understand my job.

Right! And also it's just not true that 'smart pointers' are smart.
Actually they are a very crude way to handle resources.

Jul 23 '05 #26

"Panjandrum" <pa********@spambob.com> schrieb:

But it's just not true that raw pointers are unsafe. You just
should know what your're doing. And this is how I understand my
job.

Right! And also it's just not true that 'smart pointers' are smart.
Actually they are a very crude way to handle resources.

Nobody talks about resources. Resources are just there.

Smart pointer protagonists tend to use smart pointers always and
everywhere. This means they oftenly avoid to use simple local objects
on the stack. They allocate them on the heap rather because "all
objects need a safe smart pointer around". (This is oftenly
inconsequent - they put always std::string and std::vector objects on
the stack but self-made objects belong surely on the heap ...)

The problem is not only the allocation and deallocation time the heap
management and the OS well need but also that these millions of
temporary heap objects fragment the heap enormously. (This effect
differs from compiler to compiler.) Analyzing this in a given
application with a mysterious high memory usage I found situations
where more than 40% of the memory the heap management had requested
from the OS was not used anymore. This memory was allocated for just
small temporary objects and could not been released because of
fragmentation.

Indeed I use much more local objects directly on the stack. The stack
is is allocated just once and it gets never fragmented. I also try to
use real member variables in classes rather than pointers to heap
objects. That's why I can avoid these situations of partly initialized
objects in most cases. I never throw exceptions from constructors.

T.M.

Jul 23 '05 #27