Issue 72499 - uno::Reference does not permit up-casting
Summary: uno::Reference does not permit up-casting
Status: ACCEPTED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: 4.x
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-12 14:38 UTC by thb
Modified: 2013-02-07 22:00 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Proposed patch (18.90 KB, patch)
2006-12-12 14:39 UTC, thb
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description thb 2006-12-12 14:38:38 UTC
Using the uno::Reference as a pointer abstraction, it is not possible to e.g.
assign uno::Reference<B> to uno::Reference<A>, even if A is a baseclass of B.

To-be-attached patch adds this functionality (and works around a few ambiguities
resulting from that change)
Comment 1 thb 2006-12-12 14:39:48 UTC
Created attachment 41371 [details]
Proposed patch
Comment 2 thb 2006-12-12 14:40:12 UTC
Setting a target.
Comment 3 Daniel Boelzle [:dbo] 2006-12-15 12:08:23 UTC
Having only a quick glance at the patch:
- we don't require boost for the SDK, thus including boost headers isn't allowed
- removing the conversion operator to Reference<XInterface> const& and adding a
member function template: this will create temporaries (requiring a pair of
acquire()/release() calls) in cases where currently Reference<XInterface> const&
doesn't. I can't foresee whether this is a performance problem or not. Can we
safely keep the conversion operator? We would avoid running into that potential
problem then.
Comment 4 thb 2006-12-15 13:35:37 UTC
@dbo: 
to item 1) - what's then the recommended way to configure those things at
compile time?
to item 2) - I don't see any (obvious) way how to keep that operator, because
stuff becomes ambiguous then. Regarding performance, I'll naturally run
performance tests before upstreaming such changes.
Comment 5 Daniel Boelzle [:dbo] 2006-12-15 17:35:53 UTC
1: Wouldn't be one known compiler that can handle template friends be
sufficient? Every other compiler would use the public _pInterface member, but we
will still break on that compiler.
2: you are right.
Comment 6 Stephan Bergmann 2007-04-11 15:02:45 UTC
To prevent frustration among patch writers, all issues of type
PATCH are monitored for extended inactivity periods, see
<http://eis.services.openoffice.org/patchreport/irt_index.html> and
<http://eis.services.openoffice.org/patchreport/iit_index.html>.
Please proceed with this issue in an appropriate way, to satisfy
the statistics and avoid frustration.  Thanks.

[http://wiki.services.openoffice.org/wiki/Uno/Misc/InactivePatchIssueReminder]
Comment 7 thb 2007-04-11 15:36:21 UTC
done.
Comment 8 Martin Hollmichel 2007-12-07 13:00:34 UTC
set target to 3.x according to http://wiki.services.openoffice.org/wiki/Target_3x
Comment 9 thb 2012-07-13 20:51:21 UTC
Reset to default assignee.