Re: [Opencxx-users] C++ design patterns

[Grzegorz J. <ja...@he...>]

On Tue, 2 Mar 2004, SF Markus Elfring wrote:

> > (1) Sometimes you need a special value to mark "error", "not supplied",
> >     "the end" etc., so it is convenient to use null pointer for this
> >     purpose.
>
> Please look at a design or an implementation of the standard template
> library.
> Example: I think that the iterators do not need pointers in their
> public interfaces to mark special positions.
> - http://boost.org/libs/iterator/doc/index.html
> - http://dtemplatelib.sourceforge.net/index.htm
> - http://www.melikyan.com/ptypes/

First, please read my post again. I am not saying that you *need* pointers
to express "special value".

Second, I agree with your statement about iterators, however I don't think
it contradicts what I wrote. Please correct me if I am missing anything.

Third, I am not sure I fully understand your iterators example. The source
of my confusion may be the fact that raw poiters are also valid STL
iterators. Could you elaborate on what exactly you want to point out?

Four, just an observation: iterators really employ "special values"
(singular value, past-the-end value).

> > (2) References have different assignment semantics than pointers.
> >     Changing pointer class data members into references will most likely
> >     change the assignment semantics of the class.
>
> Which copy semantics do you use at the moment?

I am sorry, I do not understand the question. What copy semantics do I use
where?

What I meant is that you cannot assign to a reference the way you can
assign to a pointer. For example try to write cyclic double-link list on
references not pointers. Or consider boost::shared_ptr<>. Assume you want
to modify it, so that ctors throw when you try to pass NULL pointer. The
raw pointer stored internally (in 1.30.0 it is called 'px', file
shared_ptr.hpp:302) is now guaranteed to be non-NULL. Can you change it to
a reference?

>
> > (3) As I already mentioned, references can potentially confuse
> >     garbage collector.
>
> How do Java references fit into this picture?

By "garbage collector" I meant "Hans Boehm's garbage collector", currently
used in OpenC++.

Java references are more like C++ pointers than C++ references, because:

  * they can be null,
  * you can assign to them (in C++ you cannot).

Java bytecode is run on virtual machine which knows which pieces of memory
are pointers (references). On the contrary, compiled C++ runs directly on
CPU and HB's GC uses miscellaneous heuristics to figure out which bits of
memory are pointers. If GC misses a live pointer, it is likely to free an
object, which is still referenced.  HB's GC assumes that pointers are
implemented as memory addresses. As long as references are implemented in
the same fashion, it should be safe to use references.  My gut feeling is
that some compiler optimizations are more likely to confuse HB's GC when
GC-managed object is refenced by references only.

> Can "smart pointers" help?
> http://boost.org/libs/smart_ptr/smart_ptr.htm

Yes, they would definitely help to make OpenC++ independent of GC.
Sometimes people have problems getting GC to work on their platforms, so
it would be a plus. I have heard of people just switching GC off at all,
which still lets you run OpenC++ on reasonably sized sources.

However, changing all garbage collected pointers to boost::shared_ptr<>
would change all the interfaces, consequently totally break the backward
compatibility. One solution I had in mind was to define OpenCxx::ptr<> and
have three build options:

    (A) OpenCxx::ptr<T>::type is T* and GC is used
    (B) OpenCxx::ptr<T>::type is T* and GC is not used
    (C) OpenCxx::ptr<T>::type is boost::smart_ptr<T> and GC is not used

This is nontrivial to do, however. If you would like to help with this you
have a "go ahead".

BR
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################