Wrapping member function technique in D

November 18, 2006

Posted by Yauheni Akhotnikau

Permalink

Yauheni Akhotnikau

Permalink

Hello!

D is a cool language and I&#8217;m seriously
considering switching from C++ to D in future
(when D becomes more stable and starts
support not only Windows and Linux, I hope it
well be near future :)). As I see from D
documentation there aren&#8217;t mush problems with
porting big part of our existing C++ code to
D. Except with fragments those use wrapping
member function calls described by Bjarne
Stroustrup in his paper &#8220;Wrapping C++ Member
Function Calls&#8221; (http://www.research.att.com/
~bs/wrapper.pdf).

We use similar technique for monitoring some
important values inside our 24x7 running
systems. We have monitoring library which
linked into each application and monitoring
software which installed on TechSupport
team&#8217;s computers. When some value changed in
application then monitoring library sends
information about that change into monitoring
software. Thus we have on-line monitoring.

For easy integration into application
monitoring library provides some template
classes (called value_holders). Value_holder
holds value of some type and provides access
to it, and automatically informs monitoring
library about each value change for further
processing. In most simply case value_holder
holds integer counters:

  value_holder_t< unsigned int > trx_counter;

  // Initialize trx_counter.
  (**trx_counter) = calc_restored_trx_count();
  // Use trx_counter in expression.
  if( (**trx_counter) <
cfg.max_trx_per_quantum() )
    {
      // New transaction can be started.
      start_new_transaction();
      ++(**trx_counter);
    }

In more complex cases value_holder can hold
complex types (like STL containers). For
example count of delayed transaction can be
monitored as size of container with
transaction descriptions:

  typedef std::vector< trx_desc_t >
delayed_trx_vector_t;

  value_holder_t<
      delayed_trx_vector_t, // Type of value.
      delayed_trx_vector_t::size_type, //
Type of monitoring information.
      stl_container_size<
delayed_trx_vector_t > // Type of extractor
of monitoring information from holding value.
    > delayed_trx;

  // Insert transaction.
  (**delayed_trx).push_back( some_description
 );
  // Do something with descriptions.
  std::for_each( (**delayed_trx).begin(),
(**delayed_trx).end(), some_actor );
  // Remove transaction.
  (**delayed_trx).pop_back();

This approach makes impossible to forget
update monitoring information after doing any
action on values those must be monitored. And
value_holder looks like double pointer to
actual value (that is not beautiful, but
sufficiently understandable and usable, IMHO).

But after reading D documentation I don&#8217;t
find any way to implement this approach in D
 :(

At first there isn&#8217;t appropriate operator
that can be overloaded in D (like operator*()
or operator->() in C++).

At second this technique in C++ works because
temporary objects those returning from
overloaded operator*() (operator->())
destroyed at end of expression. This makes
possible to do some useful actions in
temporary objects destructors. But as I see
it isn&#8217;t possible in D.

So my question is: Can &#8220;wrapping member
function calls&#8221; technique be implemented in D?

May be following two additions to D can help?

1) Dereferencing operator overloading:
  class ValueHolderSuffix(T) {
    T * opDeref() { return &p_; }
  private: T p_;
  }

2) Enabling returning of scope classes:
  scope class ValueHolderSuffix(T) {
    this(T * p) { p_ = p }
    ~this { /* some useful action */ }
    T * opDeref() { return &p_; }
    &#8230;
  }
  class ValueHolder(T) {
    alias ValueHolderSuffix!(T) Suffix;
    Suffix opDeref() { return new
Suffix(&p_); } /* Suffix object destroyed
immediately after expression finished. */
    &#8230;
  private :
    T p_;
  }
  alias ValueHolder!(int) IntHolder;
  auto trxCount = new IntHolder();
  **trxCount = calcRestoredTrxCount();

Thanks.
Yauheni Akhotnikau,
eao197 at intervale ru

Yauheni Akhotnikau wrote:

> I mean: "when GDC will be synchronized with DMD". At now on  http://dgcc.sourceforge.net/ last stable version from 11 july 2006. And  some of our clients use SPARC Solaris.

GDC is occasionally synched with DMD, but it usually lags a few
versions behind. You can check the SVN if you don't want to wait ?

I'm not sure if GDC will be ready for the "D 2.0 features" by the
Jan 1, 2007 release but it does have most of the old "D 1.0" stuff.

SPARC and Solaris are somewhat working now, see the D.gnu newsgroup.
I think the SPARC CPU had some odd-byte pointer alignment issues...

The D language specification only officially supports Windows, linux, X86, X86_64 but the GDC compiler also adds versions solaris and SPARC.

--anders

Forums