I have committed the following additional changes:
1) implemented noDefaultMethods. See effective C++ Item 6. There it is
2) implemented Lock. See effective C++ item 14.
Matej, This is as easy to use as Java synchronize.
3) wrapper on top of std::string. All usage of string in pvData is one of:
String - Just a std::string
StringBuilder - Used whereever StringBuilder is used in the Java
version of pvData.
StringConst - Just a "std::string const". This is used wherever
String is used in Java version of pvData.
StringConstArray - Just like a String in Java. It is used
wherever a string array is used in the Java version of pvData.
4) The reference counting for the introspection interfaces
(incReferenceCount and decReferenceCount) are now private.
Reference counting is completely handled by the implementation.
Code that uses pvData has no need to even know about reference
On 09/24/2010 10:44 AM, Marty Kraimer wrote:
> I have committed many changes to
> The status is:
> Implemented but needs more testing.
> The interfaces have all been defined and stubs for much of the
> implementation has been created.
> Most method have not been implemented. The unimplemented interfaces
> throw an exception.
> For PVScalar only PVDouble has a stub.
> For PVArray only PVDoubleArray has a stub.
> The introspection interfaces are all pure virtual, i.e. like Java interface.
> This did NOT work for PVData interfaces. They are a mixture of
> non-virtual methods and virtual.
> I now realize that for the non-virtual methods the Java method should be
> declared final.
> What about memory management?
> The introspection interfaces are meant to be shared since they are all
> immutable objects. The implementation provides custom reference
> counting. The PVData implemention must call the reference counting
> methods. Client do not have to know anything about reference counting.
> PVData objects can only be shared via pointers, since copy and
> assignment operators are not allowed.
> Each PVData object is "owned" by some facility. The initial facility
> will be pvAccess. In the future maybe a pvDatabase i.e. a c++
> implementation of a javaIOC database.
> A client is provided access to a PVData object by whatever facility owns
> it. Each facility must provide a way to inform it's clients when a
> PVData object will be destroyed. The client must no longer access an
> object that will be destroyed.
> Although most methods are not properly implemented, the basic framework
> is in place. My next task is to start proper implementation of the
> methods. Thus means implementing what the javaIOC does. Progress should
> be swift.
> I think things are far enough along that you can think seriously about
> the c++ implementation of pvAccess.
> Also in pvDataCPP, bitSet and byteBuffer need to be described and
> defined. I will leave the PVData serialization methods unimplemented for
> now. Perhaps you will be able to implement them?
> Hopefully by the end of next week I can be ready for a complete
> implementation (except serialization) of the PVScalar objects. Then the
> epics meeting will take most of my time for the next two weeks.
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.