Re: Use of symbol_table::varref in ov-classdef.cc

[Серёжа Плотников]

Michael, 

I'm not sure my comment is needed in the case you're discussing, but example of CDeriv class won't work in Matlab:

>> cdd = CDeriv

Error using CDeriv

Error: File: CDeriv.m Line: 8 Column: 19

A constructor call to superclass CBase appears after the object is used, or after a return.

Be happy,

Sergey

2014/1/22 Michael Goffioul <address@hidden>

On Wed, Jan 22, 2014 at 1:53 AM, John W. Eaton <address@hidden> wrote:

On 01/11/2014 11:23 PM, Michael Goffioul wrote:

Hi John,

While compiling from default branch, I see a deprecate warning in
ov-classdef.cc, due to the use of symbol_table::varref. This is
occurring in constructors, when calling a superclass constructor explicitly.

Can you show me some code and explain what it needs to do?

I wrote that code quite some time ago and tbh I don't remember all the details about the why. However I'm pretty sure one reason was optimizing superclass construction and avoiding unnecessary object copying (when using value class). Typically when you have the following:

classdef CBase

  properties

    pBase;

  end

  methods

    function this = CBase

      this.pBase = 0;

    end

  end

end

classdef CDeriv < CBase

  properties

    pDeriv;

  end

  methods

    function this = CDeriv

      this.pDeriv = 1

      this = address@hidden

    end

  end

end

During object construction, the internal representation will copied multiple time due to the COW.

Another reason might be that it's required for value-type objects to have the object properly constructed, however I'm not sure about this one. I don't think it's the case, though it's something to keep an eye on.

 

The comments in symtab.h say to use "assign" instead, but I don't see a
direct mapping between the two.

Could you advise what would be the right way to handle the case?

I'm not sure what advice to give.  I think the reason I deprecated it was because it was possible for varref to give up a pointer to an octave_value object and there could be no guarantee that later the pointer would still be valid.  I see that a direct pointer to an octave_value object was replaced with a symbol_table::symbol_reference object in octave_lvalue, which is a place that we still need to hold on to a reference to a variable instead of just doing an assignment directly.  Will something like that work?

The code in ov-classdef.cc is the following (it's the translation of "this = address@hidden"):

    octave_value& sym = symbol_table::varref (mname);

    cls.run_constructor (to_cdef_ref (sym), idx);

    retval(0) = sym;

In English, it means grab a reference to the "this" variable from the current scope and pass it to the superclass constructor; then use it as a return value. Using a reference avoids COW in the superclass constructor. Obviously in this use case, "this" will not get out of scope and deleted so using a reference should be safe.

However in this specific case, maybe I can get away by not using any temporary octave_value to avoid incrementing the reference counter, at the expense of 2 symbol lookup. Something along these lines:

    cls.run_constructor (to_cdef_ref (symbol_table::varval (mname)), idx);

    retval(0) = symbol_table::varval (mname));

Michael.