Re: [c++] passing parameters and safety in deletion.

From: Anthony Borla (ajborla_at_bigpond.com)
Date: 02/06/05 

Date: Sun, 06 Feb 2005 06:58:15 GMT

"Val" <valmont_programming@hotmail.com> wrote in message
news:42059a3b$0$44104$5fc3050@dreader2.news.tiscali.nl...
>
> | You're asking about whether a 'OneClass' object has acquired
> | ownership of an 'OtherClass' object via a pointer to that object,
> | hence is responsible for 'deleting' that object when it reaches the
> | end of its own lifetime [i.e. does the 'deleting' when its destructor
> | is triggered] ?
>
> No I don't ask that. We covered this recently. I took the point
> then.
>
> The requirements are explicitly:
>
> 1) obj.AcceptClass(new OtherClas);
> 2) obj.AcceptClass(&otherclassObj); //not allocated dynamically.
> 3) obj->AcceptClass(new OtherClass); //obj is created dynamically.
>

Only 1) and 2), [free store-based object pointer, stack-based object
pointer, respectively] are significant here. 3) is superfluous in that the
caller's location [stack or free store] has no impact on 'AcceptClass'
behaviour.

>
> No "bool" value. That is so ugly.
>

Fair enough. However, in all cases you are passing a raw pointer argument to
'AcceptClass'. This means:

* Both function overloading and template-based 'tricks'
   cannot be applied [because there is no type-based
   difference: a pointer is a pointer !]

* Without such explicit information the compiler has no way
   of determining whether it is a free store address, or that of
   a stack-based object, nor whether it 'owns' the referenced
   object or not, hence should, or should not, perform a 'delete'.

I, personally, see no way other than supplying explicit,
behaviour-modifying, information. Other posters may have alternative views.

>
> - Perhaps is one of the famous cases to where to overload
> the "new" operator?
>

I don't see how this could help. In particular, what can you do in an
overloaded 'new' [whether global, or class-specific] that will affect
whether a 'delete' will, or will not, be performed ?

>
> - Or perhaps there is way to do tricks with static members or
> something. I heard a bell ringing once but I have no clue
> about the technique. Something with reference counting
> perhaps?
>

Building a class or co-operating classes to manage memory allocations /
deletions, which is what you seem to be alluding, is another ballgame. Also,
even if this were done, I don't see how you could make 'AcceptClass' calls
as you outlined earlier.

Personally, I would revert to a smart pointer-based design, whether this is
custom-written [not at all difficult to do], or from a third-party library
like 'boost'. I would rather get on with the job of programming rather than
get too involved in creating or using esoteric tricks which is why, these
days, I tend to prefer using [where I can] higher level languages [like
Scheme] or scripting languages [like REXX].

I hope this helps.

Anthony Borla

Relevant Pages

  • Re: why cant functions return arrays
    ... at initialization. ... I think you don't understand your own compiler. ... but you have not specified how overloading works with arrays unless I ... Pointer + integer ...
    (comp.compilers.lcc)
  • Re: Garbage collectable pinned arrays!
    ... Pinning is an explicit ... I've already given two examples of APIs in widespread use which require a buffer to stay in one position after the initial function call which accepts the pointer. ... That means a one time cost to pin a buffer that lives until the end of the process, if you do this early in the process you won't suffer from fragmentation of the gen0 heap as this object will end on the gen2 heap anyway. ... If this doesn't suits your needs, then you will have to use the Marshal class or GCHandle.Alloc, carefully considering it's costs. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: future C standards
    ... Your proposal talks about overloading of user-defined functions and needs to cover many more possible combinations of argument types than 7.22.3 needs to deal with. ... implement the semantics, and for that to be possible, the existing resolution rules would have to logically follow from your rules, or at least not conflict with them. ... As it happens, all the functions that those macros map to have only floating-point parameters, and the rules don't have to deal with functions defined with integer or pointer parameters. ... And this means that if we have to tread language ...
    (comp.std.c)
  • Re: future C standards
    ... Your proposal talks about overloading of user-defined functions and needs to cover many more possible combinations of argument types than 7.22.3 needs to deal with. ... Of course, it would be nice if your proposed mechanism could be used to implement the semantics, and for that to be possible, the existing resolution rules would have to logically follow from your rules, or at least not conflict with them. ... As it happens, all the functions that those macros map to have only floating-point parameters, and the rules don't have to deal with functions defined with integer or pointer parameters. ... That seems to imply that anything other than an exact match is not accepted for pointer arguments; but I would expect function overloading to allow matching a parameter defined as a pointer to a qualified type with an actual argument that points to a less-qualified type; I would also expect to be allowed to mix pointers to void with pointers to other object types. ...
    (comp.std.c)
  • Re: future C standards
    ... That seems to imply that anything other than an exact match is not accepted for pointer arguments; but I would expect function overloading to allow matching a parameter defined as a pointer to a qualified type with an actual argument that points to a less-qualified type; ... But from your remark about void pointers I assume that you don't want to make that promise: ...
    (comp.std.c)