I agree with Gabe, it's probably not worth the added complexity and resulting
bugs.
Ali
On Sep 10, 2010, at 1:56 AM, Gabe Black wrote:
> I think it would work pretty well, but also agree there's a chance for
> people to screw it up. This is especially true of Joe gradstudent who
> may not know the rule and may not look in the header file and would just
> end up with mysterious memory corruption problems when they did
> something that seemed right from looking at an isolated part of the
> source. I think this may not be viable since we have to keep in mind a
> lot of non-experts will end up changing this code, and it shouldn't be
> easy for them to innocently shoot themselves in the foot.
>
> Gabe
>
> nathan binkert wrote:
>> I want to point something out to all developers that use M5 that was
>> prompted by a recent diff that I reviewed for Gabe. If people find
>> this worthwhile, I can stick this into comments in the file. Also, if
>> this could use some clarification, please let me know.
>>
>> After you read what's below, think about this: should was start doing
>> something more along these lines?
>> typedef RefCountingPtr<Foo> FooPtrRef;
>> typedef Foo *FooPtr;
>>
>> And ask people to use FooPtrRef in containers and FooPtr for function
>> arguments? The danger of this is that people could screw up. The
>> benefit is that forward declarations are easier.
>>
>> Nate
>>
>> --------------
>>
>> When using reference counting (from base/ref_cnt.hh), we usually do
>> something like this:
>>
>> class Foo : public RefCounted
>> {};
>>
>> typedef RefCountingPtr<Foo> FooPtr;
>>
>> We then use FooPtr EVERYWHERE. This isn't strictly necessary. In
>> reality, we only need to use FooPtr in places that store pointers.
>> i.e. member variables, and containers. It is perfectly reasonable to
>> use a "Foo *" when calling a function instead of a FooPtr (and it's a
>> little faster to boot). The point is, you have to think of a FooPtr
>> as something that holds a reference. When a function is invoked, the
>> caller is loaning the function a reference, so a FooPtr is
>> unnecessary. The FooPtr is only necessary if the caller wants to keep
>> that reference after the function returns. This is perfectly
>> reasonable code:
>>
>> class FooContainer
>> {
>> FooPtr myFoo;
>>
>> void
>> setFoo(Foo *foo)
>> {
>> myFoo = foo;
>> }
>> };
>> _______________________________________________
>> m5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
