|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r67270 - sandbox/opaque/libs/opaque/doc
From: vicente.botet_at_[hidden]
Date: 2010-12-16 02:05:15
Author: viboes
Date: 2010-12-16 02:05:14 EST (Thu, 16 Dec 2010)
New Revision: 67270
URL: http://svn.boost.org/trac/boost/changeset/67270
Log:
Opaque: first draft
Text files modified:
sandbox/opaque/libs/opaque/doc/opaque.qbk | 54 +++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 1 deletions(-)
Modified: sandbox/opaque/libs/opaque/doc/opaque.qbk
==============================================================================
--- sandbox/opaque/libs/opaque/doc/opaque.qbk (original)
+++ sandbox/opaque/libs/opaque/doc/opaque.qbk 2010-12-16 02:05:14 EST (Thu, 16 Dec 2010)
@@ -405,10 +405,62 @@
[section Using UDT as Underlying types]
-Talk about the problem with direct data access that can not be wrapped by the underlying type.
+Talk about the problem with direct member access that can not be wrapped by the underlying type.
For example we can access the fisrt field of the UT pair, but the OT can not give this access. Instead the OT could define some function accessors that inderectly will almost behave as the data member.
+ struct UT {
+ T member_;
+ };
+
+ UT ut;
+ ut.member_ = 88;
+
+
+ struct OT : new_class<OT,UT> {
+ T& member() {
+ return underlying().member_;
+ }
+ T member() const {
+ return underlying().member_;
+ }
+ };
+
+ OT ot;
+ //ot.member_=88 // compile-error
+ ot.member() = 88;
+
+For pointer to members, we have the same problem
+
+ T UT::* pm = &UT::member_;
+ UT* utp;
+ utp->*pm = 88;
+
+
+If UT had overloaded the pointer to member operator, OT should do the same think
+
+ struct OT : new_class<OT,UT> {
+ T UT::* pmt(T UT::* pm) {
+ return underlying().member_;
+ }
+ T member() const {
+ return underlying().member_;
+ }
+ T& operator->*(T& (OT::* m)()) {
+
+ }
+ };
+
+
+ T UT::* pm = &UT::member_;
+ T& (OT::* pm) = &OT::member;
+ UT* utp;
+ utp->*pm = 88;
+
+ OT* otp;
+ otp->*pm() = 88;
+
+
[endsect]
[endsect]
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk