Prev: re-entrancy pattern issue setbacks
Next: c++ event sink
From: George on 12 Apr 2008 04:55
Hello everyone,


Some people doubt that the design below is inferior compared to design which
makes f, either Foo* or Foo&. The reason is below design will waste memory
space and degrade performance by creating a new instance.

I think it depends. If we really needs to wrap a new instance, I think the
following design is fine. If we needs to refers to an existing instance, this
design is inferior because it will waste memory space and degrade performance
by creating a new instance and destroy the original one.

[Code]
class Foo;

class Goo
{
Foo f; // change to Foo* pf or Foo& rf is always better?
}
[/Code]


thanks in advance,
George
From: David Wilkinson on 12 Apr 2008 08:46
George wrote:
> Hello everyone,
>
>
> Some people doubt that the design below is inferior compared to design which
> makes f, either Foo* or Foo&. The reason is below design will waste memory
> space and degrade performance by creating a new instance.
>
> I think it depends. If we really needs to wrap a new instance, I think the
> following design is fine. If we needs to refers to an existing instance, this
> design is inferior because it will waste memory space and degrade performance
> by creating a new instance and destroy the original one.
>
> [Code]
> class Foo;
>
> class Goo
> {
> Foo f; // change to Foo* pf or Foo& rf is always better?
> }
> [/Code]

George:

class Foo;

class Goo
{
Foo f;
};

As written, this code will not compile. Nor will it compile if you change it to
Foo&. It will compile if you change to Foo*.

These facts provide most of the information you need to decide which you want to
use in your application.

--
David Wilkinson
Visual C++ MVP
From: George on 12 Apr 2008 10:01
Hi David,

1.

> As written, this code will not compile. Nor will it compile if you change it to
> Foo&. It will compile if you change to Foo*.
>

You are correct. But my code is for illustration purpose only. :-)

You can use the following simple form to make compile pass. But I am more
about design pattern, not making runnable program this time.

[Code]
class Foo
{
};

class Goo
{
Foo f;
};
[/Code]

2.

> These facts provide most of the information you need to decide which you want
> to use in your application.

You mean Foo, Foo* and Foo& are all ok, means not 100% error code and not
100% correct code and depends on situations?


regards,
George
From: David Wilkinson on 12 Apr 2008 10:29
George wrote:
> Hi David,
>
> 1.
>
>> As written, this code will not compile. Nor will it compile if you change it to
>> Foo&. It will compile if you change to Foo*.
>>
>
> You are correct. But my code is for illustration purpose only. :-)
>
> You can use the following simple form to make compile pass. But I am more
> about design pattern, not making runnable program this time.
>
> [Code]
> class Foo
> {
> };
>
> class Goo
> {
> Foo f;
> };
> [/Code]
>
> 2.
>
>> These facts provide most of the information you need to decide which you want
>> to use in your application.
>
> You mean Foo, Foo* and Foo& are all ok, means not 100% error code and not
> 100% correct code and depends on situations?

George:

Your code will still not compile if you use Foo&.

The changes you need to make to your original code to make it compile for Foo or
Foo& should tell you which pattern you want to use. Note that the only one for
which your original code compiles is Foo*.

--
David Wilkinson
Visual C++ MVP
From: George on 12 Apr 2008 10:57
Thanks David,


> Your code will still not compile if you use Foo&.

I understand you mean using reference, we need to assign it a value at
first. I just want to check either of Foo, Foo* and Foo& are not always bad
(e.g. using auto_ptr on stack pointer is always bad), and it depends on
situation to choose which one fits the best, right?


regards,
George
 |  Next  |  Last
Pages: 1 2
Prev: re-entrancy pattern issue setbacks
Next: c++ event sink